Product ideas | Community
Skip to main content

10000 Ideas

JohnMitchellWF
JohnMitchellWFNew Participant

Expand the External Lookup Fields to Support Rich Text FunctionalityNew

Description - Rich text fields have a few oddities when they are used in an External Lookup Field interaction. Rich text fields can cause External lookup fields to fail to be able to be selected OR result in an output that is not user-friendly.   Why is this feature important to you - The more consistent a feature is in Workfront, the more likely it is that I can use it to design a useful and impactful UX for my team. How would you like the feature to work - Either bring in full support for user-friendly Rich Text results in External lookup fields, or give additional features in the setup of an External Lookup Field to allow for system admins to control the results of the field. Current Behaviour - 1. The 2,000 character limit on an external lookup field will run into a conflict pretty easily when returning the results of a rich text field which to my understanding has a 15,000 character limit. The results of a rich text field are returned with their JSON wrapper intact. This uses quite a few characters, especially in results with multiple paragraphs or a good deal of "rich text" like attributes. It also displays the JSON wrapped output to a user which can be extremely confusing. Additionally, a calculated field, or a block of textmode akin must be used to "Clean up" the result. Example here:valueexpression=IF(CONTAINS("text",{DE:YOUR CUSTOM FIELD}), LEFT(SUBSTR({DE:YOUR CUSTOM FIELD},SUM(SEARCH("text",{DE:YOUR CUSTOM FIELD},1),7),LEN({DE:YOUR CUSTOM FIELD})), SUM(SEARCH("type",SUBSTR({DE:YOUR CUSTOM FIELD},SUM(SEARCH("text",{DE:YOUR CUSTOM FIELD},1),7),LEN({DE:YOUR CUSTOM FIELD})),1),-3)),"") 2. Manipulating a field with a dependency can cause an error result on an otherwise valid choice, creating hidden "invalid" choice amongst valid choices all driven by character limits. This is difficult to control because the JSON wrapper is variable as well, so text block of 1,800 characters could be valid in some cases and invalid in others solely based on how many paragraphs were used in the text. 3. There seems to be no support for a JSON Path-based "cleaning" of the output of an external lookup field.Example:$.data[*].parameterValues['DE:YOUR CUSTOM FIELD']     ---> This one works, but results in the JSON wrapped text$.data[*].parameterValues['DE:YOUR CUSTOM FIELD'].blocks[*].text     ---> Does not work$.data[*].parameterValues['DE:YOUR CUSTOM FIELD'].blocks[0].text    ----> Does not workIf either of the 2nd or 3rd approaches worked, we could bypass some of the obscure and inconsistent outputs we get as of today by trimming the results of their JSON wrappers. 

JohnMitchellWF
JohnMitchellWFNew Participant

Allow External Lookup Fields to utilize a "Select All" buttonNew

Description - When using a $$HOST-based external lookup field and maintaining a data table, such as a list of US States, users currently have to click on each valid option that appears in the picklist for a multi-select-allowed External lookup field.  Why is this feature important to you - This will bring parity to the External Lookup Field with the Multi-select Dropdown field. Much of the discussion around external lookup fields is that they can be used as a dependency-driven list of results that helps control front-end user input, especially when flowing through a custom form for an intake process. This really supports staying away from the "Garbage in, garbage out" trap of users mis-selecting options in an intake process. How would you like the feature to work - When "Multi Select Dropdown" is selected in the field setup, users should be given a UI-button that responds the same way the current Multi-select options (Dropdown, Checkboxes) works. A "Select All" option should populate all of the choices that are valid for the JSON path, and then from there, users should be able to use the "x" button on the individual choices they DO NOT want to include. When the 1st option removed, the "Select All" button should also clear, allowing for it to be re-selected, and any options that were removed, should be re-added to the list within the field. Current Behaviour - Users have to click every valid option in an external lookup field result. Bonus fix/Observation!!! - The user experience when selecting multiple options from an external lookup seems to be wildly inconsistent. Some users can click a result, and the list of possible results stays open allowing them to quickly click more options to add to the selection. Other users have the external lookup dropdown interface close with each and every selection, requiring an additional click to re-open the selection field, and another click to select an item, which subsequently closes the field again.

Josh__Stephens
Josh__StephensNew Participant

Improve sorting and display of CJA bucketed dimensionsNew

Description Sorting for bucketed dimensions in CJA should default to logical sorting by the dimension's numerical value, rather than it's label. Buckets should be displayed more clearly (Less than 30, 30 to 59, 60 to 119, 120 or more) Why is this feature important to you Bucketed dimensions are intuitively understood when sorted in logical order by the value of the dimension. For example, shortest to longest time. It's confusing when two buckets are ambiguously defined and contain the same value (example: 30 to 60, 60 to 120). How would you like the feature to work Bucketed dimensions should default to logical sorting by the dimensions numerical value. At a minimum, users should have the option to sort by logical order. Example: If I have a bucketed dimension for time in seconds (Less than 30, 30-60, 60-120, 120 or more), I'd like the option to sort them logically as either:     Less than 30, 30 to 60, 60 to 120, 120 or more, or     120 or more, 60 to 120, 30 to 60, Less than 30 Bucket ranges should be clearly displayed (without any overlap) Current Behavior Sorting by the bucketed dimension sorts by non-intuitive, alpha-numeric orders either:      Less than 30, 60 to 120, 30 to 60, 120 or more, or      120 or more, 30 to 60, 60 to 120, Less than 30 Bucket ranges overlap (30 to 60, 60 to 120, 120 or more), causing confusion.