Make a Jira field read-only after approval or when closed

Q: Can I see who changed a field after approval?

The History tab lists every field change with who made it and when. It shows changes, not the approved state, so showing what was approved means working backwards through it.

By Kayabyte · Updated 1 November 2026

Short answer: Jira Cloud can make a whole work item read-only in a status with the jira.issue.editable workflow property, but it has no setting that makes chosen fields read-only after approval: screens work per operation and work type, not per status, and UI modifications only cover some views. Record Lock for Jira, in Atlassian Marketplace review and not yet available, locks the fields you choose when work reaches a status and logs or reverts later changes.

A change is approved by the CAB, a requirement is signed off, a ticket is resolved. From then on, some fields should stay exactly as they were: the description of what was approved, the due date that was agreed, the fix version that shipped. This guide shows what Jira Cloud can do on its own, what each option misses, and how to keep an audit trail of changes that happen anyway.

Option 1: the jira.issue.editable status property

In a company-managed workflow you can add a property to a status. With jira.issue.editable set to false, work items in that status can’t be edited (Use workflow properties).

Go to Settings > Work items > Workflows and edit the workflow.
Select the status, for example Approved or Done, and open its properties.
Add the key jira.issue.editable with the value false, and publish the workflow.

What it misses:

It locks the whole work item, not chosen fields. Every field is read-only in that status, and logging work counts as an edit too (Atlassian KB). Bulk edit no longer offers custom fields for those work items (Atlassian KB).
Your own automation stops too. Automation rules can’t edit the fields of a work item in that status; the rule fails (Atlassian KB). Status properties that grant permissions don’t override it either (JRACLOUD-63580), so you can’t let one team keep editing.
Company-managed projects only. Team-managed projects have no way to restrict editing by status (JRACLOUD-87543).
Jira admins and apps can override it. The REST API’s edit call has an overrideEditableFlag option for people with the Administer Jira permission and for apps (Jira REST API: Edit issue).
It is tied to the status. Move the work item back to an earlier status and it is editable again, with nothing that records what the approved values were.

Option 2: field configurations and screens

A field configuration decides whether a field is shown, hidden or required, its description and its renderer (Specify field behavior). There is no read-only setting.

Screens decide which fields appear when you create, edit or view a work item, per work type (Manage screen schemes). Leaving a field off the edit screen keeps it out of the edit form, but:

Screens are chosen per operation and work type, not per status. A field left off the edit screen can’t be edited before approval either.
Transition screens help at the moment of approval (collect the approver, the agreed date), not afterwards.
The REST API’s edit call has an option that lets Jira admins and apps edit fields that aren’t on the screen (same REST page as above).

Option 3: UI modifications (behaviour-style apps)

Apps can change how fields behave in the Jira UI, including making them read-only, through Jira’s UI modifications. They apply in the views the module supports: global create, the work item view and the transition dialog, plus some Jira Service Management views (UI modifications module).

What it misses: bulk edit, Jira Automation, CSV imports, other apps and REST API calls don’t go through those views, so a field that looks read-only on screen can still change.

The audit trail angle

Often the question isn’t only “can it be changed” but “can we show what was approved, and everything that happened since”. The History tab on a work item lists every field change with who made it and when. That is a good start, but:

It shows changes, not the approved state. To show an auditor what the record looked like at approval, someone has to work backwards through the history.
It doesn’t say whether a change was allowed, or by whom it should have been approved.
Exporting history for many work items over a date range needs the REST API or a script.

If you build your own process, decide these first:

When a record counts as approved: entering a status, getting a resolution, or some time after it was created.
Which fields must stay as approved, and which may keep changing (comments, time tracking, links).
Who may still change them, for example a change manager group, and whether those changes become the new approved values.
What happens to other changes: log them only, or put the approved value back.

Record Lock for Jira

Record Lock for Jira is the app I make for this. It locks the fields you choose, not the whole work item, and keeps an audit trail of every attempt to change them.

Lock rules per project and work type, triggered when work enters a status, gets a resolution or is created (with an optional grace period). Works in company-managed and team-managed projects.
Every later change to a locked field is checked, whether it comes from the work item view, bulk edit, Jira Automation, an import, another app or the REST API. In Audit only mode it is logged; in Enforce mode the approved value is put back within seconds, without notifications, and logged.
Exempt groups or project roles can still make changes, which are logged and become the new approved values. Jira Automation edits can be allowed per rule.
Each lock stores the approved values with a SHA-256 hash. Verify a work item at any time, unlock with a logged reason, and export the audit log and snapshots as CSV for a date range.
Find locked work items with recordLocked = yes in JQL.
It runs on Atlassian Forge and makes no calls outside Atlassian.

The screen still lets people type into a locked field; the change is put back and logged rather than blocked in the form.

Record Lock is in Atlassian Marketplace review and not yet available to install.

FAQ

Does jira.issue.editable = false also stop logging work? Yes. Logging work counts as an edit, and bulk edit no longer offers custom fields for those work items.

Can Jira Automation edit a work item in a status with jira.issue.editable = false? No. Automation rules can’t edit its fields; the rule fails.

Does this work in team-managed projects? No. Team-managed projects have no way to restrict editing by status.

Can I see who changed a field after approval? The History tab lists every field change with who made it and when. It shows changes, not the approved state, so showing what was approved means working backwards through it.

Jira and Atlassian are trademarks of Atlassian. Kayabyte is an independent developer and is not affiliated with or endorsed by Atlassian.