Field permissions in Jira Cloud: what the native setup gives you, and what it doesn't

There is no per-field permission in Jira Cloud

Jira's permission scheme grants things like Browse Projects and Edit Issues. Both work at issue level: if you may edit the issue, you may edit every field on it that the screen shows you. Atlassian's own knowledge base states the limit without hedging — "Jira Cloud does not natively support field-level restrictions based on roles, groups, or transitions."

The open request to change that, JRACLOUD-69298 — "Allow fields to be hidden/edited …" — had 585 votes as of September 2026, is still Gathering Interest and has no delivery date; its Server predecessor JRASERVER-1330 was filed in 2003 and closed as Won't Fix. The question keeps coming back on Community, in posts like "I want to protect some fields on an Issue of a specific project".

Two different permissions people ask for

Mixing the first row with the rest is the most expensive mistake here: an app that controls changes will not keep a value secret, and an app that hides a value does not necessarily stop the people who can see it from overwriting it.

What the native configuration can do

All the native routes below assume a company-managed project — team-managed projects do not expose screens, field configurations or workflow properties in the same way.

Screens — which fields appear where

A field that is not on the Edit screen cannot be edited from the issue view, and a field that is not on the Create screen is not offered on the create form — but the REST API and CSV import can still put a value into it while the issue is being created. Screens are per project and issue type, so this applies to everyone, including the people who are supposed to change the value.

Field configuration — hide a field

A field configuration can hide a field for a project and issue type. Again: for everyone, not for a group. It is a layout switch, not a permission.

A looping transition with a role condition

Add a transition from any status back to itself, put the field on its screen and guard it with a condition such as "user is in project role". Only that role sees the transition, so in practice only that role edits the field. This only restricts anything if the field is first removed from the Edit screen — otherwise everyone still edits it inline in the issue view, and Atlassian's own knowledge base pairs the two steps. It is the closest native thing to an edit permission. It has to be repeated per workflow, it clutters the diagram, and it records nothing beyond Jira's issue history.

The jira.issue.editable status property

Makes issues uneditable in a status — the whole issue, as a Community answer puts it, it "will stop all edits to the issue, not just that one field".

Where FieldLock fits — and where it doesn't

FieldLock for Jira is not a permission matrix. It answers the second question only, and it answers it in one move: an unapproved value does not stay in the protected field — whether it came from the issue view, the REST API, a bulk edit or a Jira automation rule. In Locked mode the write is refused outright; in Guarded mode it goes through and is undone, usually within a minute or two (see the limits below). A change is proposed as a request with a reason and approved by project admins or a project role you choose. Approvers can also set a value directly in the panel; that is recorded in the log with their account. Every request, approval, rejection and correction lands in an append-only audit trail that exports as a readable document and JSON.

Limits, stated up front

• Two modes, two different promises. Locked uses the app's own field and refuses the outside change immediately. Guarded protects a custom field you already have: the outside change goes through and FieldLock restores the approved value shortly after, usually within a minute or two. Compare the modes.
• Field types. Locked's own field is always a number. Guarded protects a custom field holding a number or single-line text (text compared exactly as written, at most 255 characters). Dates, multi-line text, select lists, user fields and built-in Jira fields such as Due date are not supported in either mode.
• Per project, not per status. The protection is configured for a project; there is no condition tied to a workflow status or transition.
• Automation is not an exception. A write from a Jira automation rule is treated exactly like a write from a person — if you need "users no, automation yes", this is not the app for it.
• The first value is not an approved value. In Guarded mode, while the field has no approved value, the first value it gets — at creation or from an ordinary edit — becomes the starting value. In Locked mode an unapproved value put in at creation is cleared shortly after, usually within a minute or two.