Have separate Field API Names vs Label

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?

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.

THIS

IS

AMAZING.

YOU ARE MY HERO!

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.

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.

I would like to see this not just to simplify API calls and text mode calculations, but also to simplify the interface for the user.

I could use the same label/question across forms bu have a different backend field name to keep them straight. For example, we have "Project Type" but it means different things to different groups. I had to invent new names, which further confused people.

So let us have a "UI name" and a "backend name" as something usable by text mode as well as API use.

I agree that this needs to be part of improvements in API documentation and functionality as this allows better differentiation of user focused labels and backend simple field names. This is particularly important for enterprises that need to categorize fields by group ownership.

Upvote with Karen and Skye's suggestion on the back end ID number for API calls.

I agree with Karen, there's already a Parameter ID field, and I would rather copy/paste this string than have to figure out what combination of brackets and slashes I need.

We would like to take this one step further, front end names should all be given a back end ID number. The ID number should then be used for API calls (and fusion calls), so that changes to the custom field front end name do not impact the call. Currently, any changes to a custom field name break any corresponding API or fusion calls.