New Feature: Separate Label and Name for custom fields

[Exp_-_GevorgKa]

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

[Doug_Den_Hoed__AtAppStore]

Fabulous: thank you, Gevorg.

I look forward to putting this one to good use!

Regards,

Doug

[CalvinFold]

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]

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

[CalvinFold]

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.

[Exp_-_GevorgKa]

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]

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

[Exp_-_GevorgKa]

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