Custom Fields appearance - any way to change name per project/user group?

[Kim-Stacey Kidder]

Hi! When custom fields are "re-used" with differing contexts, the name of the field can be confusing to end-users using agent screens. 

• Is there a way within Jira to change the name of the field per project/ user group? 
  (Example - not a real use case, but used to exemplify the issue): 
  Custom field: "Notes"
  Project A users see the field as "Notes"
  Project B users see the same field as "Release Comments"
  
  
• If not, is there a 3rd-party app that can accomplish this? 

---

(Note: we have tried using field descriptions per project, but most people don't use the info bubble when looking at the field.)

Thanks in advance for any ideas! 
-Kim-Stacey

[Susan Waldrip]

Hi @Kim-Stacey Kidder , I'm thinking you want to use aliases for a custom field? If so, you can do this on the Customer portal -- you can drag the Notes field onto to the Request form/screen and give it the name "Release Comments". Unfortunately, if it's on the agent screen, you're stuck w/ the field name itself. 

Another way to use different field names, if it would fit your needs, is to use Forms -- you can give any field you use whatever name you want. And with this option, you can use a different name for the same field in each form you use in a single project.

Not sure about 3rd-party apps enabling aliases, perhaps others will post about that. Good luck!

[Raju Kadam]

From my understanding this option is available only in JSM projects and not to regular Jira projects.

This remains a sore point in Jira Software world! Most of the time users don't agree on the field name and as a admin you end creating new field. 

I was hoping this feature will make it's entry in Jira Cloud but yet to be seen.

[Kim-Stacey Kidder]

@Susan Waldrip Thanks, Susan! Good suggestions - we're currently using all. I edited my post to address the agent screen. 

[Anne Saunders]

Is there a reason you don't want to make a separate field? I have a couple like that, where reporting needs trump the display name.

I wish we could populate placeholder text a la the Confluence Macro, at least for text fields. it would help in situations like this and save me a lot of repetitive Slack messages.

[Kim-Stacey Kidder]

I believe that as the number of custom fields increases, they can negatively impact system performance. Utilizing custom field contexts instead can help minimize the impact.

[Hayley Skelton]

@Kim-Stacey Kidder Yes, excessive custom fields can impact system performance. However, in Cloud this limit is 6,000 (according to the site optimizer), so you should hopefully not hit this for a while!

We also encounter this issue of field naming in our sites. We're aiming to keep our config items as low as possible as we're opening up the permission for trusted users to edit their own screens. We've moved to keeping field names as generic (but clear) as possible to make this easier for users - but as @Anne Saunders mentioned sometimes reporting needs (or a pushy business owner) win!

[Aaron Morris]

Hi @Kim-Stacey Kidder -- This is probably a difficult use case to satisfy due to the way Jira handles custom fields. As far as I know, even third-party apps cannot dynamically change their own custom field names.

So, without understanding your use case, here are a few non-ideal workarounds:

• Set default values -- You can use Jira Automation, third-party automation, or a specialized app (like Default Values for 'Create Issue' screen - Issue Templates) to set different default values in your custom field.  The default value can be a project-specific instructional text to guide the users. (Like the field descriptions, but much easier to see.) A downside is that the field will never be empty, which could affect field validation rules if you have any.
• Sync fields -- You can create two separate fields and then synchronize them for reporting purposes.  For example, use Notes as the master field...create a custom field for Project B called Release Comments...then use Jira Automation or third-party automation to synchronize Release Comments and Notes. Then, Project B can display Release Comments on its screens, Project A can display Notes, and everyone can share the same reports, etc.  A downside is that you'll have the administrative burden of two fields plus supporting automation.
• Forms -- You can map custom fields to form fields and give the field any name you want on the form. A big downside is that this workaround requires a good deal of user training, because the agents (or users) will need to learn to view the form for certain tasks instead of the regular work item screen.
  • Forms in JSM: https://support.atlassian.com/jira-service-management-cloud/docs/use-forms-in-jira-service-management/
  • Forms in Jira Software: https://support.atlassian.com/jira-software-cloud/docs/what-are-forms-and-what-can-they-do/
  • Forms in the Marketplace:
    • https://marketplace.atlassian.com/apps/1227085/smart-forms-for-jira-works-in-jsm-jwm-jpd-confluence?hosting=cloud&tab=overview
    • https://marketplace.atlassian.com/apps/1210820/dynamic-forms-for-jira?hosting=cloud&tab=overview

Of course, these workarounds may not be usable for your use case.  But I strongly suspect the ideal solution isn't possible based on what I know about custom fields.