Expand my Community achievements bar.

Have separate Field API Names vs Label

Avatar

Level 9

4/12/17

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
15 Comments

Avatar

Level 2

5/2/17

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'

Avatar

Level 6

2/22/18

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.

Avatar

Level 6

4/10/18

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.")

Avatar

Level 8

8/29/18

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.

Avatar

Level 10

2/12/19

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.

Avatar

Former Community Member

4/5/19

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.

Avatar

Level 10

8/12/19

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.