Parentheses allowed in Custom Form Field Labels

Simple answer, no. Parentheses are not allowed as a custom for label or parameter label. Marty Gawry - CapabilitySource

Sorry - missed the second half of the question. I think it has something to do with the database and API calls, but not positive. Parentheses cause problems when not properly trapped and are often not allowed as a database field name. As far as I can tell, these are the only characters not allowed, but there are likely some non-printable characters that fall into this category as well. Marty Gawry - CapabilitySource

in general I would advise to steer clear of as many non-letter/non-number characters as possible. Not that they won't display (they will) but more that if you start getting into calculated fields, they will make your life miserable. For example, I think to this day, we still haven't figured out how to perform any calculated field equation (even a concat) on a field if the name of the field has an apostrophe in it. (e.g. have you ever been able to make a calculated field referencing a field like "URL's"?) -skye

Hi, I recommend that you upvote this idea to "Have separate Field API names vs label names". Right now the field name in the backend has to be the same as the label, which limits your options if you want to use sentences, special characters, or the same field name across different forms. https://support.workfront.com/hc/en-us/community/posts/115006012627-Have-separate-Field-API-Names-vs-Label Vincent Goodwin The Capital Group Companies

Skye, To answer your question, you can put { } around the field name to capture the special character. For example: IF({URL's}="X","X","Y") Vincent Goodwin The Capital Group Companies

thanks Vincent, I think we tried that and it didn't work (we normally default to curly braces around all custom fields and let Workfront automatically delete whatever it doesn't want). But I'll certainly tinker with it again and see. (Edit: it's working now :), not sure why it didn't work before) -skye

Hey everyone, We recommend avoiding use of special characters, you can read more on step 9 here: https://support.workfront.com/hc/en-us/articles/216668788-Creating-Custom-Forms Thanks! Dustin Martin Assigned Support Engineer Workfront

I have no idea. :) I was about to recommend my go-to of using slash marks before the special character (ex. URL/'s) but for some reason, in my tests that wasn't working today. Vincent Goodwin The Capital Group Companies

Thanks Dustin. Is there any appetite for making the field ID and its label separate? This would allow greater flexibility in naming fields: Special characters Use plain language sentences to introduce selections (Ex. "How would you rate our service today?") Multiple fields with the same value (if two forms wants to have a field called "Type" with different value selections, we currently can't do that. We have to get creative, which can make our intake forms flow weird.) Also, as Fusion rolls out, changing a field name can have impacts to the Fusion call. There's an Idea on Idea Exchange with great ideas too that I highly recommend. https://support.workfront.com/hc/en-us/community/posts/115006012627-Have-separate-Field-API-Names-vs-Label Vincent Goodwin The Capital Group Companies

Thanks, all, for your replies. We have some real use cases where it adds value for our users to have parenthetical information appear in parentheses. I will submit this in Idea Exchange as suggested above or second the idea if already submitted by someone else. Appreciate your help. Best, M.L. de la Rosa Genentech