Field Locking on Transitions
Field locking prevents edits by making fields read-only during workflow transitions. This pattern ensures data integrity at critical workflow moments—when issues change status.
Dynamic Screen Rules enables transition-based field locking, ensuring fields are protected during specific status changes.
Screen Limitation: The "Lock Field" action is only supported on Global Issue Create and Issue Transition screens. It is NOT supported on Issue View due to Atlassian's UI Modifications API constraints.
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 Field Value to auto-fill and protect values
Basic Pattern: Lock Field During Transition
The simplest field locking rule makes a field read-only when transitioning to a specific status.
Example 1: Lock Resolution During Done Transition
Requirement: When transitioning to Done, auto-fill Resolution and lock it to prevent changes
Rule Configuration:
Screen: Issue Transition
Target Field: Resolution
Scope: Bug
Condition: Status = Done (target status)
Action: Lock field (read-only)
Combined with Set Field Value rule:
Same conditions
Action: Set Field Value = "Fixed"
User Experience:
User clicks "Done" transition button
Transition dialog appears with Resolution = "Fixed" (auto-filled and locked)
User sees the value but cannot modify it
Ensures consistent resolution for completed bugs
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: Issue Transition
Target Field: Fix Versions
Condition: Status = Closed (target status)
Action: Lock field
Rule 2: Lock Components
Screen: Issue Transition
Target Field: Components
Condition: Status = Closed (target status)
Action: Lock field
User Experience:
User transitions issue to Closed
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 specific roles to modify 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: Issue Transition
Target Field: Fix Versions
Scope: Bug, Story
Conditions:
Status = Ready for Release (target status)
User NOT in group "Release Managers"
Action: Lock field
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 Field Value with Lock Field 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
Rule 1 - Set value:
Screen: Issue Transition
Target Field: Completion Date
Condition: Status = Done
Action: Set Field Value =
today()
Rule 2 - Lock field:
Screen: Issue Transition
Target Field: Completion Date
Condition: Status = Done
Action: Lock Field
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
Practical Use Cases
Software Development Team
Lock Resolution on completion transitions:
Screen: Issue Transition
Condition: Status = Done OR Status = Closed
Action: Lock Resolution field
Result: Resolution can only be set once during transition, then locked
Lock Story Points when starting work:
Screen: Issue Transition
Condition: Status = In Progress
Action: Lock Story Points field
Result: Estimates can't change after work begins
Release Management
Lock Fix Versions on release transition:
Screen: Issue Transition
Condition: Status = Released
Action: Lock Fix Versions field
Result: Version assignment locked at release
Lock Release Notes on completion:
Screen: Issue Transition
Condition: Status = Done (for release issues)
Action: Lock Release Notes field
Result: Release documentation protected after sign-off
Quality Assurance
Lock Test Results after approval:
Screen: Issue Transition
Condition: Status = Approved
Action: Lock Test Results field
Result: QA results preserved after approval
Best Practices
Use Issue Transition Screen
Field locking works on Issue Transition screen where users change status.
Why Issue Transition:
Captures the moment of status change
Transition dialogs have focused scope
Prevents changes at critical workflow points
Combine with Set Field Value
Lock fields that you auto-fill to prevent user modifications.
Pattern:
Rule 1: Set field value when conditions met
Rule 2: Lock field with same conditions
Result: Field is populated automatically and protected from changes.
Lock Related Fields Together
When protecting data at a workflow stage, lock all related fields.
Example: When transitioning to Released:
Lock Fix Versions
Lock Release Notes
Lock Affects Versions
Document Lock Behavior
Users should understand which transitions lock which fields.
Recommendation: Add notes to transition screens or workflow documentation explaining locked field behavior.
Common Patterns
Pattern 1: Lock on Completion
Lock fields when work is done.
Pattern 2: Auto-Fill and Lock
Set value and lock in the same transition.
Pattern 3: Role-Based Lock Exception
Lock for everyone except specific roles.
Pattern 4: Lock Multiple Related Fields
Create separate rules for each field with same conditions.
Troubleshooting
"Field is locked but I need to edit it during transition"
Check:
Does your user role have an exception in the rule?
Is there a legitimate reason to edit at this transition point?
Solution: Either add your role to exceptions, or transition to a different status that allows editing.
"Field isn't locked when I expect it to be"
Check:
Is the rule on Issue Transition screen?
Does the target status match the condition?
Is the rule enabled?
Does scope match issue type?
Solution: Verify rule configuration matches your transition.
"I want to lock fields on Issue View, not just transitions"
Limitation: Lock Field is not supported on Issue View due to Atlassian's UI Modifications API constraints.
Alternative approaches:
Use Jira's native field permissions for view-level restrictions
Lock fields during all transitions that access the field
Use workflow validators for enforcement
Lock Field vs Other Actions
Understanding differences helps choose the right action.
Prevent editing
Lock Field
Create, Transition (NOT Issue View)
Remove from view
Hide Field
Create, Issue View, Transition
Enforce filling
Make Field Required
Create, Transition (NOT Issue View)
Auto-populate
Set Field Value
Create, 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
Lock Field
✅
❌
✅
Set Field Value
✅
❌
✅
Show / Hide Field
✅
✅
✅
Make Field Required
✅
❌
✅
Change Field Label
✅
✅
✅
Change Field Description
✅
✅
✅
Limit Field Options
✅
❌
✅
Related Patterns
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
Implement your first field locking rule:
Creating Your First Rule - Step-by-step guide
Combine with other patterns:
Dynamic Required Fields - Require fields before transitions
Pre-filling Values - Auto-fill and lock fields
Learn about actions:
Defining Actions - Lock Field action details
Ready to implement field locking? Start with a simple transition-based lock rule and expand from there.
Last updated