How to make Jira fields read-only after approval (what Jira can and cannot do)

An independent developer published a guide explaining that Jira Cloud cannot make selected fields read-only after approval, and detailing the workarounds available: the jira.issue.editable workflow property, which locks an entire work item in a status but also blocks work logging and Jira Automation edits; field configurations and screens, which lack any read-only setting and are bypassed by bulk edit, Automation, CSV imports and REST API calls; and UI modifications, which only apply in supported views. The developer, who sells the Record Lock app for field-level locking with an audit trail, notes that its screen still accepts typing into locked fields and reverts and logs the change rather than blocking it in the form.

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 https://go.kayabyte.dev/atl/record-lock?s=dv-record-lock 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 https://kayabyte.dev/atlassian/guides/jira-field-read-only-after-approval