How it works
When a work item locks
A rule locks a work item when its trigger happens:
- Status: the work item enters one of the chosen statuses (also when it is created straight into one).
- Resolution: a resolution is set on a work item that had none.
- Creation: the work item is created. With a grace period, changes during the period are still allowed and become the approved values; the lock starts when the period ends.
Record Lock then stores the current values of the locked fields: the snapshot. Changes made before the lock, or together with the transition that locks the work item (for example on a transition screen), are never touched.
The trigger happening again does not replace the snapshot. To approve new values, unlock the work item; the next trigger locks it again with the values at that moment.
What happens to a change
Every change to a locked field is checked, whatever made it: the issue view, bulk edit, Jira Automation, a CSV import, another app or the REST API.
| Who changed it | Audit only | Enforce |
|---|---|---|
| Anyone not exempt | Logged | Put back and logged |
| An exempt group or project role | Logged as Exempt; the new value becomes the approved value | Same |
| Jira Automation, when the rule allows it | Logged as Allowed; the new value becomes the approved value | Same |
Put-backs are made by the app, without notifications, usually within 2 to 5 seconds. They appear in the work item’s history as changes by Record Lock for Jira. Jira admins are not exempt unless they are in an exempt group or role, but they can always unlock.
Loops with automation
If an automation rule or another app reacts to a put-back by changing the field again, Record Lock stops after 5 put-backs of the same field within 10 minutes and logs Put-back failed with the reason. Changes by people are put back up to 20 times per field in 10 minutes, which is far more than anyone edits by hand; the higher limit still stops automation rules that run as a person.
The as-approved record
Each snapshot holds the approved values in a fixed, normalised form (IDs rather than names, sorted lists) and a SHA-256 hash of the work item, rule, lock time and values. Verify on the work item recomputes the hash and compares every locked field with its current value. The CSV export of snapshots includes the hash and whether it still matches.
When an exempt person changes a locked field, or a work item is unlocked, the old snapshot ends and stays in the history; the panel lists earlier snapshots.
Supported fields
Summary, description, priority, due date, labels, components, fix versions, affects versions, assignee, reporter and environment, plus custom fields of these types: short text, paragraph, number, date, date time, select list (single and multiple), radio buttons, checkboxes, user picker (single and multiple), labels and URL.
Changing a rule later
- Adding a field to a rule applies only to work items locked after the change. To include it on work items locked before, unlock them and lock them again (or use Lock existing work items after unlocking).
- Removing a project or a field from a rule stops checking the locks the rule already made there. When those locks exist, the rule editor shows how many and asks whether to end those locks (their snapshots stay in the history) or keep them. Ending them ends only locks made before you saved that are in a removed project or hold a removed field; locks made after the save stay. Lock existing work items started meanwhile waits until those locks have ended, then locks the work items again with the new fields. Kept locks show on the Record lock panel as “Not checked: project no longer in the rule”, and removed fields as “Not checked: field no longer in the rule”.
- Switching a rule off keeps its locks but stops checking them until it is switched on again.
What it does not do
- The field stays editable on screen; a change is put back seconds later. Record Lock does not hide or grey out fields.
- Some fields cannot be locked: cascading selects, sprint, parent, time tracking, attachments, comments and links.
- Automation rules that run as a person (not as Automation for Jira) count as that person.
- Edits made within a second or two of the transition that locks a work item can end up as part of the approved values, because Jira delivers the two events separately.
- For the description and paragraph fields, an exempt change that is overwritten within a second or two by someone else’s change can be approved with that later value, because Jira’s history gives no comparable value for these fields.
recordLocked = yesin JQL reads a work item property. Anyone who can edit a work item can change its properties through the REST API, so search results can be wrong after such an edit. The locks themselves, the panel and Test a work item are not affected.recordLocked = yeslists every work item with an active lock, also locks that are not checked right now: the rule is switched off, its project was removed from the rule and the lock kept, the rule cannot be read, or the work item was moved to a project no rule covers. The Record lock panel says “Not checked” and why.- Without an active license, nothing is put back or logged and no new locks are made. Unlock, Verify, the audit log and Export keep working, so your records stay readable.
- A locked work item moved to a project no rule covers is no longer checked there. The panel shows “Not checked: work item moved to a project no rule covers”; moving it back, or adding the project to a rule, checks it again.
Next: Troubleshooting and FAQ.