Is there a way to restrict access to a custom field in a Jira ticket?

[Tom Horton]

I have a Developer Notes custom field and would like to restrict its visibility to admin users only. Is that possible?

Thanks!

Tom

[Mikael Sandberg]

No, that is not possible out-of-the-box, the closest you can get is to hide the field and only have it available on a screen that is shown for a circular transition that only certain users can access. There are apps in the Marketplace that allows you to set field restrictions. 

[Charlie Misonne]

Yes, a circular transition is the out of the box way of doing this.

Note: the button to perform the transition will appear under the action/ automation icon and not under the button that is normally used to change a status. This has been reported in JRACLOUD-94299  

[Geert __ 2improveIT]

Hi @Tom Horton 

Another option where you have full control using scripting is with ScriptGenie (full disclosure: I am the developer).
You can:
- Use your current custom field and use UI Modifications to enable/disable the field.
- Create a custom "ScriptGenie" field and enable/disable the field.
- Create your own UI (entry form) with full control.
- ...

Happy to help you out with the scripting if you need help.

[Julia Foden]

I would go with the option mentioned by @Ben Friedman _Ben_viter_io_ : a separate issue. It could be a linked issue of a specific type though my preference would be a subtask of a specific type. This subtask would hold the field Developer Notes and you would use Issue Security to ensure that only Admins can view these subtasks. This would enable  Admins viewing the main issue to click into the subtask to view the Developer Notes. But reporting and csv export etc would be more complex.

---

The title of this question is "Is there a way to restrict access to a custom field in a Jira ticket?" so I'm adding a few words for people who might land here wanting to know how to restrict who can edit a custom field. For this scenario you would remove that field from the Edit screen and add it to a transition screen of a transition that is restricted to the group/role that you want to be able to edit it. Note though that the field, when filled, is still visible to everyone who can view the ticket (either on its face, in the history tab, in list/search, in csv export etc).

[Emre Karaduman - The Starware]

Hi @Tom Horton 

Short answer: not with native Jira Cloud. Permissions stop at project and issue level — there is nothing at field level.

That's Atlassian's own position rather than folklore: JRACLOUD-69298  (field level security) is still Gathering Interest after ~580 votes, and the December 2024 update says the team "cannot implement this suggestion in the near future". Newer requests keep getting closed as duplicates of it.

So your native options are the ones @Mikael Sandberg and @Ben Friedman _Ben_viter_io_  described, with the caveats they both flagged. A restricted transition screen controls who sets the value, not who reads it — it's still on the issue view, in the REST API, in CSV exports and in automation. Issue security levels do protect properly, but the unit is a whole issue, so you'd move the notes onto a separate linked issue and accept two issues per piece of work.

Disclosure: I work for The Starware, so treat the rest as a vendor recommendation.

If you want it as one field on the same issue, we built Secure Field for exactly this case:

1. Create a custom field of type Secure Field, name it Developer Notes, add it to your screens as usual.

2. In its context configuration pick Field Type: Text.

3. Add `jira-administrators` to View Permission and Edit Permission, and save.

Everyone else now gets a Permission Denied message where the value would be:

 

Grants can be users, groups, project roles, or the value of a user field on the issue (Reporter, Assignee, your own user picker) — useful for "only the assignee sees this". Field types are text, number, date, and attachments.

On @Ben Friedman _Ben_viter_io_ 's point about reporting and automation: he's right, and it's deliberate. The issue itself only stores an opaque key — the value lives in Forge storage and is released only after a server-side permission check, so the REST API and automation see the key, not the note. That's what makes the restriction real, and it also means no app can honestly offer "restricted and usable in JQL/automation". For reviewing across issues there's a Secure Fields Navigator grid, where cells you can't read stay locked and Excel/PDF exports follow the same rules:

Two things worth knowing before you commit: the field type is locked after the first save, and in JSM agents see the field while portal customers don't.

- Secure Field: Secure Field 

- Or as part of Custom Fields ++ For Jira , together with 11 other field types

- Docs: Secure Field Documentation 

Both have the standard free trial, so you can test it against your own permission scheme first. Happy to help if you hit anything odd.

[Ben Friedman _Ben_viter_io_]

Hi @Tom Horton ,

in short, Jira doesnt support field security restrictions.

marketplace apps provide some options here, but the downside is that these fields are (i havent done a check on these types of apps in the last 6 months) not fully available in other interfaces of jira (reporting, autoamtions...) and they remain solely in the ticket. another downside, generic for marketplace apps, is the price, that is calculated on the number of licensed jira/jsm user that you have.

To note, even with limiting the field to the transition screen, it doesnt block the view access. Checking the ticket from a list view in jira, or API for example, would still render the information. on the ticket itself,restrcited user will not see the data, but also admins, since in this configuration the field is only on the trasntion screen and not the view/edit screen. 

Another option is to consider a forge app that is specific to your site. this means you can keep using the jira fields as they are, enforce edit/view the logic so the field remains on the main (not transition) screen, not pay the marketplace price (maybe even not pay monthly at all), and you can extend the logic in ways that are tailored to you in the future. it still doesnt resolve the access by additional interfaces (jql, list view, api...). i have actually done that kind of implementation to a customer before, let me know if you need assistance

A more complex option is to consider combining a specific issue type for that data point that is linked to the main ticket (can be stiched with automation) where that issue type will be restrcited for view only for admins. Then only admins see that data point, always.