Have separate Field API Names vs Label | Community
Skip to main content
A
AnkurSh1
Level 3
April 12, 2017
Delivered

Have separate Field API Names vs Label

  • April 12, 2017
  • 15 replies
  • 1988 views
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 replies

    E
    EricDe
    Level 3
    April 24, 2017

    This would be very useful and more enterprise ready.

    D
    DaveZeltser
    Level 2
    May 1, 2017

    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.

    K
    KeithFa
    Level 2
    May 2, 2017

    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'

    V
    VincentGo
    Level 5
    February 22, 2018

    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.

    V
    VincentGo
    Level 5
    April 10, 2018

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

    K
    KarenMa
    Level 3
    August 29, 2018

    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.

    S
    SkyeHa
    Level 10
    February 12, 2019

    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.

    J
    JaclynRe1
    Level 4
    February 22, 2019

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

    A
    Anonymous
    April 5, 2019

    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.

    K
    KevinQu1
    Level 10
    August 12, 2019

    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.

    Show more replies
    Terms & ConditionsAccessibility statement

    Loading footer...