Have separate Field API Names vs Label

[#1]

We are looking to “decouple” front end element names from backend element names for Custom data elements in Workfront. Is that possible? For e.g. for this field on a custom form for tasks -

the backend field is called “DE:Has spend been committed for this campaign?”. This makes the backend fields very verbose, and the SQLs that use them hard to work with. (Note: this is a relatively short name ‚Äì some custom fields are complete and very lengthy sentences/questions)

Is there a facility (mapping) in workfront whereby we could have this element assume –

1. A Front end name ‚Äì “DE:Has spend been committed for this campaign?”

2. A back end name – de_spend_committed_flag

[#2]

This would be very useful and more enterprise ready.

[#3]

I agree! It is goofy to have to use all the underscores in the field name if you are going to post to it externally.

[#4]

I'd like to see this as a general change overall.

When creating a custom field we should be able to have a 'name' and a 'display label'

[#5]

I agree. The Reports area has "Custom Column Label" functionality where you can overwrite the field name, and I think that should be spread to other parts of the application.

We also have punctuation/special characters in our field labels to make them more readable (ex. "What would you like to do? Select all that apply.") and we can't write Calculated Fields off these fields because of the punctuation.

[#6]

Correction to my earlier statement. When there are special characters in the field name, you can add slashes to help with calculation. Ex: (ex. "What would you like to do/? Select all that apply.")

[#7]

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.

[#8]

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.

[#9]

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

[#10]

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.

[#11]

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.