How to make a Jira field read-only in Jira Cloud

Decide what you mean first

The native routes, and where each one stops

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

1. Remove the field from the Edit screen

The simplest read-only there is: the field appears on the View screen, not on the Edit screen, so the issue view offers no way to change it. It applies to everyone, and it does not stop a write through the REST API, a bulk edit or an automation rule — those do not go through your screens.

2. The jira.issue.editable status property

Set on a status, it makes issues in that status uneditable. This is the honest answer to "read-only after the issue is closed" — but the scope is the issue, not the field. As a Community answer puts it, it "will stop all edits to the issue, not just that one field".

3. "Read-only on transition"

A popular phrasing, and the source of a common misunderstanding. Screens attached to a transition control which fields that transition asks for; leaving a field off a transition screen does not make it read-only anywhere else. What genuinely narrows editing to one group is the reverse trick: a transition from a status back to itself, carrying the field on its screen, guarded by a condition such as "user is in project role". This works only if the field is first removed from the Edit screen — otherwise everyone still edits it inline in the issue view; Atlassian's own knowledge base pairs the two steps. Done properly, everyone else has no route to the field and that role does. It has to be repeated per workflow, and Jira records the change in issue history without a reason for it.

4. A read-only custom field

Some fields are read-only by definition — fields an app owns and writes itself. Jira renders them without an edit control, so no user, script or rule can change them after the issue exists; the one gap is issue creation, where the REST API can still inject a value — a well-built app detects that and clears it. That is the strongest form of read-only in Jira Cloud, and it comes from the app that owns the field, not from configuration.

Read-only with a key

Most teams who ask for a read-only field do not want it frozen forever — budgets get revised and contracts get amended. They want it read-only by default, changeable only with someone's agreement, and they want to be able to show later who agreed.

FieldLock for Jira is a Forge app for exactly that case. It offers two modes, which promise different things:

In both modes the way through the lock is the same: anyone who can browse the project proposes a value with a reason, project admins or a project role you choose approve or reject it, and the app writes it. An optional four-eyes rule stops the author of a request approving their own request. Approvers can also set a value directly in the panel — that path is recorded in the log with their account, and the four-eyes rule does not apply to it. Every event goes into an append-only audit trail that exports as a readable document and JSON.

Limits, stated up front

• Read-only, not invisible. FieldLock controls who can change a value; it does not hide it from anyone who can see the issue. If you need the value kept secret, see edit vs. view.
• Per project, not per status. There is no "read-only after this transition" condition — the protection is configured for a project and holds in every status. If your rule is genuinely status-based and covers the whole issue, jira.issue.editable is the right tool, not this app.
• Field types. Locked's own field is always a number. Guarded protects a number or a single-line text field (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.
• Issue creation. In Locked mode an unapproved value put in at creation is cleared 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 ordinary edit, from anyone — becomes the starting value. Clearing the approved value puts a Guarded field back into that state: it will adopt the next value it is given.
• 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.