Custom prompt set up for Keyword filtering

[TinoMe]

Hi WF community!

I am currently struggling a bit with two of my custom prompt setups where I am trying to filter for specific words people have entered into a custom field. (Not ideal, I know :-) )

In the beginning I had one of my prompts working but now they both don't seem to filter properly.

This is how I have set it up: DE:project:Keywords_Mod=in DE:project:Keywords=Manufacturing & Supply Chain

Could it be the space between the words? How do I need to set up the filter inside the Custom prompt to get a functioning prompt?

Thanks in advance

Tino

[skyehansen]

hey Tino, I see a couple of things going on here.

1) You don't appear to have the correct syntax for your custom prompt (you can refer to this page to discover the right syntax: https://one.workfront.com/s/document-item?bundleId=the-new-workfront-experience&topicId=Content%2FRe... )

2) The keyword you're searching on is problematic. It contains a special character (the ampersand is already in use as part of the syntax). It would be better if you changed the keyword options so that special characters don't show up in items that you intend to do this kind of textmode reporting on.

[kevinmathew2]

@skyehansen say we already have n number of objects with special characters in their names, do you know if it is absolutely impossible to create prompts on them? Or is it something that could come in the future. We could simply wrap the string in quotes.

[skyehansen]

@kevinmathew2  -- not really in scope for the original post, but it's a question we are often asked so I will try and answer briefly:

1) I specifically called out the ampersand in this case, because the custom prompt operates by linking lines together with an ampersand. 

2) can you work around it in some way or is it "absolutely impossible"? Let me pose to you the opposite question: why do you think it's a good idea to introduce elements into your environment that less experienced users will need additional knowledge to implement? Additional to this, there are a lot of areas in the system where you will need to use this same type of text with different syntax rules. I called out a specific problem with custom prompting, but different issues might occur with Fusion, valueexpressions, calculated fields and group and filter text modes. This is even BEFORE you get asked to integrate between workfront and other systems like AEM and Jira.

TLDR: Because you cannot predict the use of your objects in the future, I strongly advocate that this is not the best use of any admin's time (trying to figure out workarounds that will work in all cases), because I can pretty much guarantee that there is no "one solution". You will simply create a strong dependency on a field over time, that will fail you in some way when you try to flex a little more on its use.

[kevinmathew2]

Thank you for the prompt reply, but I think you misunderstand where my question originates from.

'why do you think it's a good idea to introduce elements into your environment that less experienced users will need additional knowledge to implement?'. The answer to this question is rather simple. This is to  enhance the end user experience. The version of prompts before this was too technical and not user friendly. Custom prompts definitely made it easier to create often used prompts. But it doesn't solve all the problems. In my specific use case, there is a dropdown field with values that have special characters and i would like to create a prompt on this field. With the new update i cannot use these field values as part of my custom prompt. And when you talk about introducing technical elements - I do not see any merit in that question. Custom prompts already opened the box to all kinds of custom expressions, which are not for the 'less experienced users' to implement. If users are willing to use custom prompts, then i do not see the harm in making String values acceptable the way they are (including special characters). This is the case with text mode in report filters. 

To remove options with special characters for features in Workfront to work sounds like a lazy explanation. We are trying to make Workfront look and feel appealing to the end users. So when the advisable way forward is to limit the end user experience, it is discouraging. It's like basicaly saying rename 'Johnson & Johnson' to Johnson-Johnson.

You mentioned using the same text with different syntax rules in other parts of the system. I did not understand what you meant here. How can the text be same if the syntax is different? If you are referring to the actual text with the special characters, then those are handled in most of the other places where custom expressions are allowed. Also i don't see why there would be any issue with integrations with Workfront. All custom expressions are evaluated to a value for end user comsumption. The expressions in the calculations are not available for consumption, so this does not pose any issues with integrations.

Regarding the footnote, I did not understand what you were trying to say here. Were you suggesting not to use special characters in any WF objects or were you suggesting not to use custom prompts or any custom expressions?

Thanks in advance @skyehansen