Expand my Community achievements bar.

The next phase for Workfront Community ideas is coming soon. Learn all about it in our blog!
SOLVED

Project Naming Convention, specifically ampersands

Avatar

Level 1

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!

1 Accepted Solution

Avatar

Correct answer by
Level 10

 

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):

 

  • Leading Capital Lettered Words And Spaces Only Are Safest And Logical
  • Lettered Words With Numbers Such As 1 2 3 Are Safe But A Slightly Less Logical
  • Lettered words with Some Capitals And Spaces Only Are Safe but LeSs LoGiCal
  • Certain Symbols, Such as Commas, Make Reading Easier But Might Need To Be Encoded If Using the API, Depending On The Symbol
  • Other Symbols, Such As ' ` And (True Story) The Hungarian Alphabet Might Be Allowed "Out" But Not "In" Without Special Handling Via the API

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

View solution in original post

3 Replies

Avatar

Community Advisor

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

Avatar

Level 10

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.

Avatar

Correct answer by
Level 10

 

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):

 

  • Leading Capital Lettered Words And Spaces Only Are Safest And Logical
  • Lettered Words With Numbers Such As 1 2 3 Are Safe But A Slightly Less Logical
  • Lettered words with Some Capitals And Spaces Only Are Safe but LeSs LoGiCal
  • Certain Symbols, Such as Commas, Make Reading Easier But Might Need To Be Encoded If Using the API, Depending On The Symbol
  • Other Symbols, Such As ' ` And (True Story) The Hungarian Alphabet Might Be Allowed "Out" But Not "In" Without Special Handling Via the API

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