A value your Automation rule calculates, which people keep overwriting. A Description that has to stay as the customer wrote it, for audit. Two fields only one team may touch once the work item is Closed.
All three are the same question, and it has been coming back to the Community since at least 2019. The answers are spread across a dozen or so threads, each with one workaround, and some no longer match how Jira Cloud behaves.
This article lines up the four native options for Jira admins: what each one locks, who can still edit, and where it leaks. We tested them on a Jira Cloud site in October 2026, mostly on a number field called Approved budget. Where a point comes from Atlassian's documentation instead, we say so.
As of October 2026, Jira Cloud has no per-field edit permission. Taking a field off the Edit screen stops edits in the work item view and the List view, but bulk edit, the REST API and Automation can still change it. A workflow status property blocked edits through every channel we tested (assignee aside), but for the whole work item, in company-managed and team-managed spaces alike.
Screens pick the fields, for everyone. Permissions pick the people, for the whole work item. One field, after one status, except one group, falls between the two.
Why there's no read-only checkbox
Jira Cloud controls editing at two levels, and neither works on a single field:
- Screens choose which fields can be edited, but for everyone.
- Permissions choose who can edit, but only for the whole work item. The permission scheme grants Edit work items, and a status property can narrow that per status.
Field configurations, and the field schemes now replacing them, can hide a field or make it required. Neither has a read-only setting, whatever some AI-generated answers suggest.
Atlassian's knowledge base says it directly: "Currently there's no native functionality to restrict users from editing specific custom fields" (Atlassian KB). The request for field-level security, JRACLOUD-69298, has close to 600 votes. Atlassian's latest update on it (December 2024) says it can't be implemented in the near future.
1. Take the field off the Edit screen
This is Atlassian's documented answer (KB: How to Make a Field Uneditable (Read-Only) in Jira Cloud). In a company-managed space:
- In Settings → Work items → Screens, keep the field on the Create and View screens and leave it off the Edit screen. If one screen serves all three operations, copy it and use the copy, without the field, as the Edit screen.
- In Screen schemes, map each operation to its screen. Check the Default row too: any operation without its own row uses that screen.
- In Work type screen schemes, assign the screen scheme to your work types, and check that your space uses that work type screen scheme.
The field still shows on the work item view, but nobody can change it there. The List view follows the same rule: the cell shows the value and doesn't open an editor. Older answers say the List view lets people edit such a field; in our test it didn't.
The screen scheme behind option 1: the Edit issue row points to a screen without Approved budget, while Create and View still include it.
Where it ends:
- It applies to everyone, in every status, admins included. Option 3 adds a way back in.
- Bulk edit ignores it. The Bulk edit panel offered the field and changed it on two work items.
- The REST API ignores it. Since October 2025, the edit API no longer checks screens (Atlassian developer announcement), so integrations and scripts can still write to the field.
- Automation ignores it too, with the default actor. A rule that runs as Automation for Jira updated the field without errors. That's often what you want: the rule keeps writing a calculated value that people can no longer overwrite in the work item view or List view. Switch the rule's actor to User who triggered the event, and the same action skips the field with "some of the set fields aren't available", as an Atlassian KB article describes.
Approved budget isn't on the Edit screen, yet the Bulk edit panel offers it. The change went through on both selected work items.
2. Lock the whole work item in a status
Workflow properties on a status change who can edit a work item while it's in that status (Atlassian docs: Use workflow properties). In the workflow editor, select the status, open Properties and choose Add new property:
jira.issue.editable = false: nobody can edit the work item in that status.jira.permission.edit.group = the group's ID, not its name: only that group keeps editing. Per the docs, .user takes an account ID and .projectrole a role ID.jira.permission.edit.denied with an empty value: per the docs, nobody can edit, admins included. We didn't test this one.
Status properties on Done: jira.permission.edit.group with the group's ID. Only that group can edit work items in Done.
What it gets right: it works on the permission, not on what a screen shows. In our tests, a work item in the locked status couldn't be edited from the work item view, the List view, bulk edit, the REST API or an Automation rule. With jira.permission.edit.group, that included a site admin outside the group. Transitions still work, so the work item can leave the status.
Where it ends:
- It locks the whole work item. Summary, labels and the other fields freeze with it.
- The assignee can still be changed. Assigning is a separate permission; the docs list
assign among the permissions you can restrict the same way. - It stops your own rules too. With
jira.issue.editable = false, our Automation rule finished with "Some errors" and skipped the field. - The REST error points the wrong way. It says the field "is not on the appropriate screen", although the cause is the status property.
- Handle with care. Atlassian warns that "some of the workflow properties on this page may cause bugs", and saving the workflow updates every space that uses it.
3. Give one group a way back in
Option 1 locks the field for everyone. To let one group edit it anyway, give them a door only they can open:
- A manual Automation rule. Use the Manual trigger from work item, choose the group in Groups that can run trigger, and turn on Prompt for input when this flow is triggered to ask for the new value (Atlassian docs: Automation triggers). An Edit work item action then sets the field from
{{userInputs.<variable name>}}. No workflow change. (The Automation editor now calls rules "flows".) - A guarded transition. Add a transition from the status back to itself, with a condition only your group passes and a transition screen that holds the field. The cost is a workflow change in every status where editing should work. We didn't test this one.
A manual rule for one group: who can run it, what it asks for, and the field it writes, although that field isn't on the Edit screen.
Keep the rule's default actor, Automation for Jira: it's what lets the rule write a field that isn't on the Edit screen. The side effect is that the work item history credits the change to "Automation for Jira", not to the person who ran it. If you need that name, add a Log action with {{initiator.displayName}}, so the rule's audit log records who ran it.
4. Let people edit, then revert with Automation
Atlassian also documents the opposite approach: leave the field editable and undo changes made by the wrong people (Atlassian KB: Revert unwanted field changes in Jira Cloud using Automation).
- Trigger: Field value changed on your field, for the Edit work item operation.
- An IF or ELSE block set to At least one condition matches: the user who triggered the event is in group or team (or is in role). Keep the conditions positive; the KB notes that negative operators don't work properly with multiple conditions.
- A Log action in the IF branch, so changes by the group are only logged.
- In the ELSE branch, Edit work item sets the field back to its previous value,
{{fieldChange.fromString}} in the KB's example.
The revert rule guarding Approved budget, and four changes by someone outside the group: through the REST API, the work item view, bulk edit and the List view. Each one was set back within a few seconds.
Where it ends:
- It corrects; it doesn't prevent. The change lands, gets undone a few seconds later, and both edits stay in the history.
- Bulk edits are caught too, at least today. An Atlassian KB article says this trigger doesn't fire for bulk edits (Atlassian KB). With the current Bulk edit panel, our rule reverted a bulk change like any other.
- Other automations aren't checked by default. A rule's settings default to Only user actions can trigger this flow, so, going by that setting, a change made by another rule isn't reverted. We didn't run this case.
- Field types matter. On our number field, the KB's
{{fieldChange.fromString}} worked. On Priority, it failed with "The priority selected is invalid. (priority)", and {{fieldChange.from}} worked instead. Test the rule on your own field first.
The scorecard
Where each option holds, tested on one Jira Cloud site in October 2026. Options 1 and 3 leak through bulk edit, the REST API and Automation. A status property blocks all five, but for the whole work item. A revert rule sets changes back, though by default it doesn't react to changes made by other automations.
Option | What it locks | Who can still edit | The main cost |
|---|
1. Off the Edit screen | Chosen fields, in every status | Nobody in the work item view or List view; bulk edit, the REST API and Automation still can | Locked in every status, for admins too |
2. Status property | The whole work item, in that status | Nobody, or only the group, user or role you name | Freezes the other fields too and blocks your own rules |
3. A way back in for one group | Same as 1 | One group, through a rule or a transition; bulk edit, the REST API and Automation still can | A rule or a workflow change to maintain |
4. Revert rule | Nothing: it undoes changes | Everyone, but changes from outside the group are set back | Corrects after the fact; both edits stay in the history |
Team-managed spaces
Team-managed spaces have no screens, so option 1 doesn't exist there. Option 2 does, although older answers and JRACLOUD-87543 (closed in 2024) say otherwise. Go to Space settings → Work types, pick a work type and choose Edit workflow: statuses have a Properties section here too. In our test, jira.issue.editable = false on Done locked the work item in the interface and in the REST API. When you save, Jira asks which work types should use the workflow.
Beyond that, roles act on the whole space: the Viewer role can't edit work items at all (Atlassian docs). For a single field, the revert rule from option 4 is what's left.
Jira Service Management
Customers are the easy part: they "can't make changes to Jira fields once they've submitted a request" (Atlassian KB). The suggestion to change that, JSDCLOUD-93, has about 1,000 votes. In a company-managed service space, options 1–4 apply to agents as described above. JSM also adds two tools:
- Forms that lock on submission. In the form's Settings, under Preferences, turn on Lock this form once it's submitted so only admins can edit, and turn off Keep this form open for edits, which is on by default. Per the docs, only space admins can then edit the form (Atlassian docs: form settings). Form fields you don't link to a Jira field live only on the form (Atlassian docs: form fields and Jira fields). So if the audit question is "what did the customer originally write?", a locked form with an unlinked field answers it. (We saw the setting but didn't test a submitted, locked form.)
- Hidden fields. Per the docs, Use preset value and hide from portal on a request type's request form fills in a value and hides the field from customers, so they can't change it (Atlassian docs: customize a request type).
JSM form settings: the lock option sits under Preferences. Keep this form open for edits is on by default and does the opposite, so turn it off.
Who changed it anyway?
JQL can't tell you. CHANGED and WAS work only with Assignee, Fix Version, Priority, Reporter, Resolution and Status (Atlassian docs: JQL operators). On a custom field, Jira answers "History searches do not support the '…' field." Use the work item's History tab instead, or a Field value changed rule whose Log action records {{fieldChange.fromString}}, {{fieldChange.toString}} and {{initiator.displayName}}.
Where this lands in practice
- A value an Automation rule calculates: take the field off the Edit screen and keep the rule's default actor. People can't overwrite the value in the work item view or List view, and the rule keeps writing it. Avoid a status property here: it blocks the rule too.
- What the customer submitted, kept for audit (JSM): a form that locks on submission, with the answer in a form field that isn't linked to a Jira field. The Description field itself stays as editable as before.
- Fields only one team may change after Closed:
jira.permission.edit.group on Closed, if that team can own the whole work item from then on.
Quick answers
Can I make a field read-only in Jira Cloud?
Not with a per-field permission. Off the Edit screen, a field can't be edited in the work item view or List view, but bulk edit, the REST API and Automation still change it.
How do I make a field read-only after a specific status?
Natively, only for the whole work item. Add jira.issue.editable = false to that status, or jira.permission.edit.group with a group ID to let one group keep editing. In our test, jira.issue.editable worked in company-managed and team-managed spaces. For a single field, the closest is a revert rule (option 4) with an added status condition, which undoes changes instead of preventing them.
I removed the field from the Edit screen and it's still editable. Why?
Bulk edit, integrations and Automation rules with the default actor ignore screens, so check where the change came from. Then check which screen scheme each work type uses, and whether Edit falls back to the Default row. The Team field is a special case: it keeps a dropdown by design, but users can't change the team there (JRACLOUD-82368).
Can I make a field read-only in a team-managed space?
Not per field, because there are no screens. A status property can lock the whole work item in a status, and a revert rule can undo changes to one field.
Jira Cloud gives you two levels to work with: screens, which pick the fields, and permissions, which cover the whole work item. One field, after one status, except one group, falls between them. If that's the gap you keep hitting, JRACLOUD-69298 is where the votes count.
How do you handle it? Which of these did you settle on, or have you found a fifth way?
Michał Krysiuk, Terano Apps
