How to restrict who can edit a field in Jira Cloud

The short answer

Jira Cloud permissions work per project and per issue, not per field. Atlassian's own knowledge base says it plainly: "Jira Cloud does not natively support field-level restrictions based on roles, groups, or transitions." The feature request JRACLOUD-69298 has collected hundreds of votes and is still gathering interest; the older server request JRASERVER-1330 dates back to 2003.

So you have two routes: bend the workflow configuration, or use an app.

Native workarounds people usually suggest

1. Remove the field from the Edit screen

Take the field off the edit screen and it can no longer be changed from the issue view. It applies to everyone, including the people who should be allowed to change it.

2. A transition from any status to itself, with a role condition

Add a looping transition with a screen containing the field and a condition such as "user is in project role". Only that role sees the transition, so only that role can edit the field through it. It works for simple cases, but it clutters the workflow, has to be repeated per workflow, and leaves no record of why a value changed or who agreed to it.

3. The jira.issue.editable property

A status property that makes issues non-editable in that status. As a Community answer puts it, it "will stop all edits to the issue, not just that one field".

What the workarounds do not give you

• A request with a reason. Someone who should not edit the value directly still needs a way to propose a new one and say why.
• An approval step. A named person accepts or rejects the change before it is written.
• One rule for every write path. Screens and transitions shape the issue view; automation rules and integrations are configured separately and can still write the value.
• Proof. An exportable record of who requested, who approved and what the value was, that you can show outside Jira.

How FieldLock restricts editing

FieldLock for Jira is a Forge app that makes a field changeable only through the FieldLock panel — by an approved request, or directly by an approver — with every change logged.

1. A project admin picks the field to protect and the mode (see below).
2. Direct changes are refused — in the issue view, through the REST API, by bulk edit and by automation.
3. Anyone who can browse the project can request a new value and must give a reason.
4. Project admins, or a project role you choose, approve or reject. An optional rule stops the author approving their own request.
5. Every request and decision lands in an append-only audit trail you can export.

Limits, stated up front

• FieldLock controls who can change a value. It does not hide fields from people who can view the issue. If you need to hide salaries or other confidential values, you need a different kind of app — see edit vs. view.
• Protected values are numbers (contract value, budget, cost estimate) and, in Guarded mode only, single-line text (contract number) — Locked's own field is always a number. Text is compared exactly as written and can be at most 255 characters. Dates, multi-line text and built-in Jira fields are not supported.
• A value can be put into the field when an issue is created through the API or CSV import. In Locked mode FieldLock clears unapproved values shortly after, usually within a minute or two; in Guarded mode, while the field has no approved value, the first value it gets — at creation or from an edit — becomes the starting value.
• No condition per workflow status, and automation is refused like any other writer.