Custom Fields appearance - any way to change name per project/user group?
7 comments
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:
In a single project, I can have this field dynamically change to "Verification Notes" after the screen loads:
Using this Live Fields script:
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:
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.
Recommended Learning For You
Level up your skills with Atlassian learning
Learning Path
Become an effective Jira admin
Manage global settings and shared configurations called schemes to achieve goals more quickly.
Streamline Jira administration with effective governance
Improve how you administer and maintain Jira and minimize clutter for users and administrators.
Learning Path
Become an effective Jira software project admin
Set up software projects and configure tools and agile boards to meet your team's needs.
