New Feature: Separate Label and Name for custom fields | Community
Skip to main content
G
gevorgkazaryan
Level 4
July 2, 2020
Question

New Feature: Separate Label and Name for custom fields

  • July 2, 2020
  • 5 replies
  • 1304 views

Hey folks,

I’m excited to announce a new feature that is now available in your Preview environment! The separation of name and label for custom fields is there! From now on, you can freely change the custom field labels without any impact on the API usage of the field.

You can find more information here: New for administrators: Create both an internal name and a user-facing label for a Custom Form field.

Thanks!

Gevorg Kazaryan

Product Manager

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

    5 replies

    Doug_Den_Hoed__AtAppStore
    Community Advisor
    Doug_Den_Hoed__AtAppStoreCommunity Advisor
    Community Advisor
    July 2, 2020

    Fabulous: thank you, Gevorg.

    I look forward to putting this one to good use!

    Regards,

    Doug

    K
    KevinQu1
    Level 10
    July 6, 2020

    Gevorg, or Doug, what wasn't clear (to me) is if this applied only to Fusion, or does this also affect calculations, text mode, etc. in the web UI?

    Doug_Den_Hoed__AtAppStore
    Community Advisor
    Doug_Den_Hoed__AtAppStoreCommunity Advisor
    Community Advisor
    July 6, 2020

    Hi Kevin,

    From the video, my understanding is that the Parameters Name we're familiar with will continue to work as always (i.e. the API, calculations, text mode etc. will use the "name" as always), and that the new feature will allow a different Parameter Label to appear on screen (i.e. on the custom form, and -- tbd -- on labels in lists, optionally returned through the API if requested, etc.)

    Regards,

    Doug

    K
    KevinQu1
    Level 10
    July 6, 2020

    Then the programmer in me is overjoyed.

    Doing nested IF statements with a field label that is 10+ words long (because it's a question in the form of a sentence) has always been it's own special kind of torture. 😵

    Already pondering the naming schema we'll use, taking into account getting field labels to group together when sorting alphabetically. (Sure how we can report by both name and label separately).

    Does this also mean we can have the same question (field label, i.e. the question asked of the user) but different field name? Or do both still have to be unique?

    We have a number of instances of "Project Type" that mean different things in different contexts. I'd like to stop doing constructions like "Project Type - [groupname]" other other odd prefix/suffix labels.

      G
      gevorgkazaryanAuthor
      Level 4
      July 7, 2020

      Hi Kevin,

      Thank you for the feedback!

      We do require field names to be unique, as those serve as differentiators, however, the new field labels don't have to be unique and you are free to reuse labels.

      I hope this helps.

      Thanks,

      Gevorg

      Doug_Den_Hoed__AtAppStore
      Community Advisor
      Doug_Den_Hoed__AtAppStoreCommunity Advisor
      Community Advisor
      July 7, 2020

      Good morning Gevorg,

      I've been giving this some thought, and am coming to appreciate that the mechanics involved in converting existing Parameters to leverage this new feature could become quite involved (i.e. setting conventions, changing Parameter Names to more "permanent" values, following through any calculations that need changing, and ensuring any API's that referred to those old Parameter Names are kept in sync).

      As you and your team have started working with this new feature, have you developed any techniques, best practices, and conventions you could share with those interested in converting their existing "verbose" parameters to a more "terse" underlying Name (or vice versa, if you've seen a usecase to do so)?

      Regards,

      Doug

      G
      gevorgkazaryanAuthor
      Level 4
      July 8, 2020

      Hi Doug,

      That's a great question! Thanks for asking!

      When we started this initiative among our top priorities were to make sure this improvement does not require any immediate changes or updates to be made by the customers.

      We realize that it may take some time until the custom field names are effectively utilized, so we don't want to force anyone.

      As for the best practices, I think the simple rules that apply to everybody and are commonly used across the industry are:

      • Keeping those field names as short and as descriptive as possible.
      • Avoiding changes to those field names, as you mentioned those are recommended to be "permanent".

      I hope this helps.

      Thanks,

      Gevorg

      Terms & ConditionsAccessibility statement

      Loading footer...