When naming a project in Workfront, is it okay to use ampersands. An example of our naming convention:
AC-XXXXXXXXX-STHS-XXXXXXX-Holiday Card & Envelope-CRD
The ruling regarding DO NOT USE ampersands was put in place when we first launched over two years ago. The person who shared that information is no longer here so I can't find any history or reason of why that was put in place. I am worried that it had something to do with when reports are pulled but I'm not sure. If anyone has any advice to offer it would be greatly appreciated TYIA!
Solved! Go to Solution.
Views
Replies
Total Likes
Hi @SpavT,
So long as you're working with data through the web interface, it's possible (and usually fine) to use almost any character in text fields (such as names). Where it gets a bit trickier is when you're working the the API, where certain characters such as < > and & have special meaning, which you can learn about here.
As a general rule, depending on your tolerance and ability to enforce conventions (particularly when it comes to naming custom parameters), I'd recommend (pretending each of the following is a custom parameter name):
Regards,
Doug
TIP: if this solved your problem, I invite you to consider marking it as a Correct Answer to help others who might also find it of use
Do you have any automations? I think sometimes ampersands can play havoc with these or other more advanced calculations?
For similar examples, see https://medium.com/@johnteckert/how-little-bobby-tables-ruined-the-internet-d714c20d2ce0
I make it a general rule to not use symbols associated with coding. It just makes things easier so I never have to escape any weird symbols. I do use underscrores and dashes and the occassional period (Although period is often used as a separator - {task}.{name})
I'd stay away from !@#$%^&*()[]{}/ \ though.
Hi @SpavT,
So long as you're working with data through the web interface, it's possible (and usually fine) to use almost any character in text fields (such as names). Where it gets a bit trickier is when you're working the the API, where certain characters such as < > and & have special meaning, which you can learn about here.
As a general rule, depending on your tolerance and ability to enforce conventions (particularly when it comes to naming custom parameters), I'd recommend (pretending each of the following is a custom parameter name):
Regards,
Doug
TIP: if this solved your problem, I invite you to consider marking it as a Correct Answer to help others who might also find it of use
Views
Likes
Replies