Rule-Based Approach
Dynamic Screen Rules applies conditional logic to Jira fields in real-time. Instead of static screen configurations that look the same for everyone, rules adapt field behavior based on context, field values, and user identity.
In short: Rules are if-then instructions that control field behavior. When conditions are met (like "Priority = High"), actions execute (like "Show Root Cause field"). Rules evaluate continuously as users fill forms, making fields appear, disappear, become required, or lock automatically.
Understanding how this rule-based approach works helps you design effective rules and troubleshoot when things don't behave as expected.
How Rules Work
A rule is a conditional instruction that modifies field behavior on Jira screens.
The basic pattern:
IF (conditions are met)
THEN (apply action to target field)Components:
Target field - The field that will be affected
Screen - Where the rule applies (Create, View, Transition)
Scope - Which issue types the rule applies to
Conditions - When the rule should trigger
Action - What happens to the field when conditions are met
Example:
Target field: Root Cause
Screen: Global Issue Create
Scope: Bug issue type
Condition: Priority equals High
Action: Show fieldThis rule makes the Root Cause field visible only when creating Bug issues with High priority. In all other contexts, the field remains hidden.
The Rule Execution Pipeline
Rules execute in a predictable sequence each time a user interacts with a Jira screen.
1. Screen Loads
When a user opens a create dialog, issue view, or transition dialog:
All rules for that screen are identified - Dynamic Screen Rules finds rules configured for the current screen (Create/View/Transition)
Scope is checked - Rules apply only if the issue type matches the rule's scope
Conditions are evaluated - Each rule checks if its conditions are met
Actions are applied - When conditions are satisfied, the action executes on the target field
Example: When a user opens Create Issue dialog for Bug, a rule "Show Root Cause when Priority = High" checks: Screen matches (✅), Scope matches (✅), but Priority is empty so condition not met (❌). Root Cause field stays hidden.
2. Field Changes Trigger Re-Evaluation
As users fill out the form, rules re-evaluate instantly when relevant field values change. Actions update in real-time - fields appear/disappear, become required/optional, lock/unlock. No page refresh needed.
Example: User changes Priority to High → Rule re-evaluates → Condition now met (✅) → Root Cause field appears instantly.
3. Actions Persist Until Conditions Change
Once a rule's action is applied, it remains in effect until:
The condition is no longer met (e.g., user changes Priority back to Medium)
The user navigates away from the screen
Another rule modifies the same field property with different logic
Example:
If Priority = High shows the Root Cause field, and the user later changes Priority to Medium, the Root Cause field disappears immediately. Rules continuously monitor their conditions and update field behavior accordingly.
Real-Time Evaluation Model
Dynamic Screen Rules evaluates rules continuously, not just once.
Key Characteristics
1. Instant feedback
User selects Priority = High → Root Cause field appears immediately
User changes Priority to Medium → Root Cause field disappears immediately
No submit button click required, no page refresh
2. Multiple rules can affect the same field
Rule 1: Show field when Priority = High
Rule 2: Make field required when Priority = Critical
When Priority = Critical, both rules apply (field is shown AND required)
3. Rules are independent
Each rule evaluates its own conditions
Rules don't depend on other rules (no execution order issues)
You can enable/disable rules individually without affecting others
What This Means for Users
Users experience adaptive forms that start simple and grow based on selections. Real-time validation means no surprises after clicking Submit - the form guides users naturally through the process.
Putting It All Together
Let's see the complete execution model with a practical example.
Example Scenario
Business requirement: "For high-priority incidents, we need root cause analysis and executive notification contact. For routine incidents, these fields just clutter the form."
Rules configured:
Rule 1:
Target field: Root Cause
Screen: Global Issue Create
Scope: Incident issue type
Condition: Priority equals High OR Priority equals Critical
Action: Show field
Rule 2:
Target field: Executive Contact
Screen: Global Issue Create
Scope: Incident issue type
Condition: Priority equals Critical
Action: Show field and Make field required
How It Works in Practice
Priority = Low: Form stays simple - no additional fields appear.
Priority = High: Root Cause field appears instantly for analysis.
Priority = Critical: Both Root Cause and Executive Contact appear. Executive Contact becomes required (red asterisk).
Forms adapt automatically to the situation, showing users only what's relevant without manual training.
Next Steps
Now that you understand how rules work:
Learn about screens:
Screens & Contexts - Detailed breakdown of Global Issue Create, Issue View, and Issue Transition capabilities
Understand condition types:
Condition Types - Field-based, context-based, and user-based conditions explained
Start configuring:
Creating Your First Rule - Step-by-step configuration guide
Defining Conditions - Master all condition types and logic
See it in action:
Use Cases & Examples - Ready-to-use configurations for common scenarios
Ready to dive deeper into screens? Continue to Screens & Contexts.
Last updated