Project Naming Convention, specifically ampersands | Community
Skip to main content
T
TSpav
April 12, 2023
Solved

Project Naming Convention, specifically ampersands

  • April 12, 2023
  • 3 replies
  • 1001 views

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!

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Doug_Den_Hoed_AtAppStore

 

Hi @tspav,

 

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

3 replies

skyehansen
Community Advisor and Adobe Champion
skyehansenCommunity Advisor and Adobe Champion
April 12, 2023

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

    RandyRoberts
    Community Advisor
    RandyRobertsCommunity Advisor
    Community Advisor
    April 12, 2023

    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.

      Doug_Den_Hoed_AtAppStore
      Community Advisor
      Doug_Den_Hoed_AtAppStoreCommunity AdvisorAccepted solution
      Community Advisor
      April 12, 2023

       

      Hi @tspav,

       

      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

        Terms & ConditionsAccessibility statement

        Loading footer...