Full disclosure: I make Record Lock, one of the options below. AI-assisted (grammar help), facts checked.
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.
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. Here is what Jira Cloud can do on its own, what each option misses, and how to keep an audit trail of changes that happen anyway.
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.
jira.issue.editable with the value false, and publish the workflow.
What it misses:
overrideEditableFlag option for people with the Administer Jira permission and for apps.
A field configuration decides whether a field is shown, hidden or required, its description and its renderer. There is no read-only setting.
Screens decide which fields appear when you create, edit or view a work item, per work type. Leaving a field off the edit screen keeps it out of the edit form, but:
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.
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.
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:
If you build your own process, decide these first: 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.
recordLocked = yes in JQL.
The limit: the screen still lets people type into a locked field. The change is put back and logged rather than blocked in the form. If you need the field to be greyed out, Record Lock is not that.
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? The status property does not. Team-managed projects have no way to restrict editing by status.
Jira and Atlassian are trademarks of Atlassian. I'm an independent developer and not affiliated with Atlassian.
Original guide: https://kayabyte.dev/atlassian/guides/jira-field-read-only-after-approval