Skip to main content

Field Locking on Transitions

Field locking makes a field read-only: people still see its value but can't change it. Formify locks fields in the transition dialog, so data stays put at the moment a work item changes status. Locks also work on the Issue View, so a field can stay read-only after the work item reaches a status; see Locking fields on the Issue View.

A lock is a rule on a field's Read-only tab with the action Make read-only.

How a lock in the transition dialog decides​

  • A rule made on the Transition tab runs in the dialog of every transition whose screen shows the field. To lock a field on one transition only, keep the field on that transition's screen only, or narrow the rule with a condition.
  • The Issue status condition checks the status the work item is in when the dialog opens: the status it is leaving, not the one it is moving to. "Issue is in status In Review" locks the field in every transition out of In Review.
  • To keep a field locked once a work item has reached a status, lock it on the Issue View with that status as the condition. There the condition reads the work item's current status.

Why Field Locking on Transitions Matters​

Problem: Users can accidentally change field values during transitions, leading to incorrect data being saved when issues move between statuses.

Solution: Lock fields automatically during specific transitions. Show the current value but prevent changes at critical workflow moments.

Benefits:

  • Prevents accidental data changes during transitions
  • Maintains data integrity at workflow gates
  • Clear visual indication - read-only fields show users what can't be modified
  • Works well with Set value to auto-fill and protect values

Basic Pattern: Lock Field During Transition​

The simplest field locking rule makes a field read-only in the dialog of the transition whose screen shows it.

Example 1: Lock Priority During Done Transition​

Requirement: When transitioning a Bug to Done, show its Priority in the dialog but prevent changes

Rule Configuration:

  • Screen: Transition
  • Target Field: Priority (on the screen of the transition to Done only)
  • Work type: Bug
  • Tab: Read-only
  • Action: Make read-only
  • Conditions: none. Priority appears only on the screen of the transition to Done, so the lock shows only there.

User Experience:

  • User clicks "Done" transition button
  • Transition dialog shows Priority as read-only
  • User sees the value but cannot modify it
  • Priority reports keep the value the bug was worked on with

Lock Multiple Fields on Transition​

Lock several fields together when transitioning to protect related data.

Example 2: Lock Development Fields When Closing​

Requirement: When closing issues, lock Fix Versions and Components to preserve historical data

Create Rules for Each Field:

Rule 1: Lock Fix Versions

  • Screen: Transition
  • Target Field: Fix Versions
  • Condition: Issue is in status Resolved (the status the Close transition starts from; use your workflow's)
  • Action: Make read-only

Rule 2: Lock Components

  • Screen: Transition
  • Target Field: Components
  • Condition: Issue is in status Resolved
  • Action: Make read-only

Without the condition, each lock applies in every transition dialog that shows the field.

User Experience:

  • User closes a resolved issue
  • Transition dialog shows Fix Versions and Components as read-only
  • Values are preserved; user cannot accidentally change them
  • Historical accuracy maintained

Role-Based Lock During Transitions​

Lock fields for most users but allow a specific group to modify them during transitions.

Example 3: Lock Fix Versions Except for Release Managers​

Requirement: Only Release Managers should modify Fix Versions during the "Ready for Release" transition

Rule Configuration:

  • Screen: Transition
  • Target Field: Fix Versions (on the "Ready for Release" transition's screen only)
  • Work type: Bug, Story
  • Condition: Current user is not in group Release Managers
  • Action: Make read-only

User Experience:

  • Regular developer transitions to Ready for Release → Fix Versions locked
  • Release Manager performs same transition → Fix Versions editable
  • Release team maintains control at critical workflow point

Lock Auto-Filled Fields​

Combine Set value with Make read-only for controlled auto-population during transitions.

Example 4: Auto-Fill and Lock Completion Date​

Requirement: When transitioning to Done, set Completion Date to today and lock it

Keep Completion Date on the Done transition's screen only. Then:

Rule 1 - Set value:

  • Screen: Transition
  • Target Field: Completion Date
  • Tab: Value
  • Action: Set value = {{ today() }}

Rule 2 - Lock field:

  • Screen: Transition
  • Target Field: Completion Date
  • Tab: Read-only
  • Action: Make read-only

User Experience:

  • User transitions to Done
  • Completion Date auto-fills with today's date
  • Field is locked—user sees date but cannot change it
  • Accurate completion tracking without manual entry

Locking fields on the Issue View​

A lock on the Issue View keeps a field read-only on the work item itself, not only inside the transition dialog. It covers the full issue page and the side panels opened from the board, backlog, list and search. The lock follows its conditions live: when the status changes, the field locks or unlocks without a page reload.

Example 5: Only the Delivery Team Edits Closed Work Items​

Requirement: "Number of Users and Effort in Hours must stay visible, but only the delivery team can change them once the work item is Closed."

Rule Configuration (one rule per field):

  • Screen: Issue View
  • Target Fields: Number of Users, Effort in Hours
  • Tab: Read-only
  • Action: Make read-only
  • Conditions (joined with AND, the default):
    • Issue is in status Closed
    • Current user is not in group delivery-team

User Experience:

  • Everyone sees both fields (when they have a value)
  • After the work item is Closed, only members of delivery-team can edit them inline
  • The workflow stays unchanged: no extra transitions, validators or screens
info

Issue View rules run in Jira Software projects. Jira hides locked fields that have no value. The lock applies to the issue page only: inline editing in list view cells, bulk edit, the REST API, Automation and the Jira mobile app can still change the fields. Use Jira permissions or workflow properties if the data must be protected everywhere.

Practical Use Cases​

Software Development Team​

Fill and lock Verified By on the verification transition:

  • Screen: Transition
  • Condition: none (Verified By, a user picker field, is only on the screen of the transition to Verified)
  • Action: Make read-only on Verified By, next to a Set value rule that fills it with {{currentUser()}}
  • Result: Verified By records who made the transition, and nobody changes it in the dialog

Lock Story Points once work has started:

  • Screen: Issue View
  • Condition: Issue is not in status To Do
  • Action: Make read-only on Story Points
  • Result: Estimates can't change after work begins

Release Management​

Lock Fix Versions after release:

  • Screen: Issue View
  • Condition: Issue is in status Released
  • Action: Make read-only on Fix Versions
  • Result: Version assignment locked once the work item is released

Lock Release Notes on completion:

  • Screen: Issue View
  • Condition: Issue is in status Done
  • Action: Make read-only on Release Notes
  • Result: Release documentation protected after sign-off

Quality Assurance​

Lock Test Results after approval:

  • Screen: Issue View
  • Condition: Issue is in status Approved
  • Action: Make read-only on Test Results
  • Result: QA results preserved after approval

Common Patterns​

Pattern 1: Lock on Completion​

Lock fields once work is done.

Screen: Issue View
Condition: Issue is in status Done
Action: Make read-only

Pattern 2: Auto-Fill and Lock​

Set value and lock in the same transition. Keep the field on that transition's screen only.

Screen: Transition
Rule 1:
  Action: Set value = {{ today() }}

Rule 2:
  Action: Make read-only

Pattern 3: Role-Based Lock Exception​

Lock for everyone except one group.

Screen: Issue View
Conditions (AND):
  - Issue is in status Ready for Release
  - Current user is not in group Release Managers
Action: Make read-only

Create separate rules for each field with same conditions.

Rule 1: Make Fix Versions read-only when Issue is in status Released
Rule 2: Make Components read-only when Issue is in status Released
Rule 3: Make Release Notes read-only when Issue is in status Released

Troubleshooting​

"Field is locked but I need to edit it during transition"​

Check:

  • Does the rule have an exception for you, such as "Current user is not in group …"?
  • Is there a legitimate reason to edit at this transition point?

Solution: Either add a condition that leaves your group out of the lock, or change the field outside this transition.

"Field isn't locked when I expect it to be"​

Check:

  • Is the rule on the Transition tab, and is the field on this transition's screen?
  • Does the Issue status condition name the status the work item is in when the dialog opens (the status it is leaving)?
  • Is the rule enabled?
  • Does the rule's work type match the work item?

Solution: Verify rule configuration matches your transition.

"I want to lock fields on Issue View, not just transitions"​

Add the rule on the Issue View tab instead of Transition. See Locking fields on the Issue View.

If the field still isn't locked there, check:

  • Is the project a Jira Software project? Issue View rules run only there
  • Is the field Status, Due date, Issue type, Resolution, Target start, Target end or Request type? These can't be locked on Issue View. Due date, Target start and Target end can be locked on Create only, and Resolution in a transition dialog only; Status, Issue type and Request type can't be locked on any screen
  • Was the field changed outside the issue page? Inline editing in list view cells, bulk edit, the REST API, Automation and the Jira mobile app aren't covered by the lock

"A locked field disappeared from Issue View"​

Jira hides locked fields that have no value. The field shows again once it has a value or the lock no longer applies.

Make read-only vs Other Actions​

Understanding differences helps choose the right action.

GoalActionScreen Support
Prevent editingMake read-onlyCreate, Issue View, Transition
Remove from viewHide fieldCreate, Issue View, Transition
Enforce fillingMake requiredCreate, Transition (NOT Issue View)
Auto-populateSet valueCreate, Transition (NOT Issue View)

Example scenarios:

  • Lock: Resolution during Done transition (visible but unchangeable)
  • Hide: Root Cause for low-priority bugs (not relevant, remove from view)
  • Require: Release Notes when transitioning to Done (must be filled)

Screen Support Reference​

ActionCreate IssueIssue ViewTransition
Make read-onlyYesYesYes
Set valueYesNoYes
Show field / Hide fieldYesYesYes
Make requiredYesNoYes
Set field nameYesYesYes
Set descriptionYesYesYes
Show options / Hide optionsYesYesYes

Dynamic Required Fields: Require fields before transitions - ensures completeness before status changes

Pre-filling Values: Set values during transitions, optionally lock them

Role-Based Visibility: Combine with user conditions for fine-grained access control

Next Steps​