nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Comments

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.

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

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

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.

Aaron Morris_49u8f7

Update (2025-06-19): @Kim-Stacey Kidder I learned something new! 🙂

My original answer is wrong as identified by @Long Le {Appfire} . Your use case is possible through third-party scripting using something like Live Fields or ScriptRunner.

The way it works is that the field name stays the same inside Jira, but the scripting app can dynamically update the screen after it loads. So, you might see an approximately one-second lag between screen load and the field name changing.

Here's an example I just tested using Live Fields with JMWE.

My system contains a field called "Verification Summary" for user stories:

Verification Summary.png

In a single project, I can have this field dynamically change to "Verification Notes" after the screen loads:

Verification Notes.gif

Using this Live Fields script:

Live Field Script.png

Note 1: Limitation -- This solution only works on the Create and View screens. As far as I can tell, it won't update the List View, filter results, or anywhere else users may use the field. So it probably addresses the main scenarios, but not all scenarios.

Note 2: Again, this is probably possible through ScriptRunner and other apps, too. I tried Live Fields because it was suggested by @Long Le {Appfire} , and because I am already a JMWE user.

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.

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!

Long Le {Appfire}

Hi! I'm Long, a senior developer at Appfire, and I just wanted to chime in here since this topic came up. We have an app called Live Fields that can help with this kind of customization.

It allows you to change the way fields behave on Jira screens (like Create, View, and soon Transition) based on specific conditions. One of the supported features is dynamically updating the field name or description, which sounds like what you're trying to do, for example, displaying a field as “Notes” for one user/group and “Release Comments” for the others

Beyond renaming, Live Fields can also:
- Show or hide fields based on issue type, status, or field values
- Make fields required or read-only for certain users or groups
- Pre-fill fields with default content
- Set field values automatically based on simple rules

There are example use cases and scripts available to help get started, and they can be tailored depending on the needs of your team or project setup.

Hope this helps. I'm happy to provide more details or examples if needed.

Garth Smitman

For this I use the Context and update the Description of the field so that the help text is relevant to the context of use (whichever projects need to know that 'Notes' is 'Any remarks, comments, or other details relevant to the release, aka Release Comments').

Kim-Stacey Kidder

@Aaron Morris Thank you!! Very helpful info! 😊
The Live Fields app looks awesome!

Kim-Stacey Kidder

@Long Le {Appfire} - thank you! This looks promising!

Raju Kadam

This looks like JMWE extension. I didn't know that we can change the field names too. Will take a look.

@Long Le {Appfire} one question for you: Will this also make sure new name is reflected in JQL too? If that's also it can do, then it's a huge win for Admin community to set the rule - *one custom field covers all (similar cases)*

Thanks,
Raju

MattD_6wbwou

The hardest part is not changing the field names in screens but in the JQL searches and filters. It's also related to the problem of localizing field names in different languages. Tricky, tricky

MattD_6wbwou

Extending JQL to use field aliases would indeed be very useful, but I don't think that Live Fields or ScriptRunner have that feature at the moment

Disclosure: my employer is Adaptavist, the ScriptRunner vendor

Raju Kadam

I think localization is definitely need to be there. But at the most basic level if we have this solved without localization, it will be a big win!

Bernd Gurn

Due to this situation we try to avoid renaming. To conserve the fields in older tickets the way they are used formerly we put a "...(deprecated)" or something similar to the fields name and create a new custom field. That´s not the best way i know but it´s simple.

Besides that we store on a internal Confluence page the history & menaing of our custom fields for site-admins/project-admins as change-logs. (i know that there are audit logs available but you have to know for what you search to find it).

Regards, BeGu

Sascha Weber_ox0uw0

Hi @Kim-Stacey Kidder ,

We have looked everywhere on this as well, but I do not think, there is a way as of right now.

So we have a few workarounds for a few scenarios, but in the end, "Notes" or "Release Comments" verbally really serve a different use-case and here we would create a field for each. It does not harm the System, if done strategically.

What are our Workarounds:

We sometimes use different description (as you described above), via field config / config scheme
We also add dynamic messages below a field, with Scriptrunner Behaviours. Also allows sizing of messages, coloring, panels etc. Anything out of WIKI Markup 👍
With properties on a transition or Status, you can alter the appearance as well, but it's pretty basic

We just recently looked into altering Field-options with the options as well, based on roles / languages, but behaviors and properties are not capable of replacing text on the UI. Just hide / reveal etc.

I checked with multiple folks at Atlassian, and that's the current situation. Nothing better seems to be available yet, as Atlassian is the "Limiting" factor. Apps are simply not allowed to manipulate here as of right now.

Hope this helps.

Sascha

Sascha Weber_ox0uw0

Hi @Kim-Stacey Kidder ,

something else just came back into my mind, but it would only help users upon creating issues.

I think the limits for search and all other UI places, are clear from the great input above.

The new JIRA Forms feature, may help you, but just with standard fields, not even asset based fields.

So you can create a new form in a Project, select Issue Type and Fields. Next you can alter the name of each field and the description.
So it would work for Input-collection:

BR
Sascha

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

custom-field