Have separate Field API Names vs Label

Yep I agree this should be deployed across the API and UI. It's common practice in most databases to separate the Display Name from the Database Name for the field - even Workfront allows this type of functionality in the reporting side where you can already rename the columns in a report.

This functionality needs to keep the database field name as the unique key, allowing the use of the same Display Name to refer to different Database Fields in multiple places in the UI.

Once this is implemented there is no need to use "special" characters in the Database Field Names, so the issue which seems to be driving the suggestion to use backend ID numbers instead of names ought to go away. The use of names rather than numbers in the API seems to me to at least provide some context to the data being manipulated.

Another request along the same lines is that a Custom Field should be able to return the value and label from the API call (where the fields have multiple choices). For instance if i have a field where i have the options Yes / No / Don't Know as the labels, and i have chosen to use 1, 2 and 3 as the equivalent values I have no way from the API call to specify if i want a label or value returned. Instead I have had to create a FUSION FLO that goes to look for all the options that have that particular value (using POPT), then filter this list to only show me the the POPT for the particular parameter ID (i.e. custom field) where i can then take the label and replace my value with this.

GEVORG.

THIS

IS

AMAZING.

YOU ARE MY HERO!

We are excited about this feature being added, but finding issue converting all out custom fields to use custom name fields due to a limitation with reports.

The two issues are:

1) Using the API name as the default "display name" in a column. This requires us to add a custom display name for every use of a custom field in a report/view. This sinks the utility of this feature for us.

2) Searching internally in Workfront while building a report uses the API name. This one is less of an issue, but still creates a frustrating experience as you can only find "targetPubDate" for example by searching "tar..." instead of "Date" (which would work if it searched the label "Target Publication Date")

I posted this idea here:

https://one.workfront.com/s/idea/0870z000000XiSLAA0/detail

Gevorg,

Functionality question:

Currently, if I rename a field the name gets changed in all calculations; which is handy in our case when someone decides to change the wording of the question (aka "field label").

Will this still be the case? If I change the "Name" attribute, will it fix all instances of it's use in calculations and such system-wide?