Managing Rules
Once you've created rules, you need to manage them: enable and disable rules, edit existing configurations, delete obsolete rules, and organize rules for maintainability.
This guide covers all aspects of rule management to keep your configuration clean, effective, and easy to maintain.
The Rules List
The rules list is your central hub for managing all rules in a project.
Accessing the Rules List
Navigate to your Jira project
Open Project Settings → Apps → Dynamic Screen Rules
Select the screen tab (Global Issue Create, Issue View, or Issue Transition)
You'll see all rules configured for that screen.
Understanding the Rules List Display
For each rule, you typically see:
Rule name (auto-generated)
Descriptive name based on configuration
Example: "Show Root Cause when Priority = High OR Priority = Critical (Bug)"
Target field
The field the rule affects
Example: "Root Cause"
Conditions summary
Quick overview of when the rule applies
Example: "Priority = High OR Priority = Critical"
Action
What the rule does
Example: "Show field"
Status indicator
Enabled (active) or Disabled (inactive)
Visual indicator (toggle, badge, or icon)
Action buttons
Edit - Modify rule configuration
Delete - Remove rule permanently
Enable/Disable toggle - Turn rule on or off
Enabling and Disabling Rules
You can turn rules on or off without deleting them.
Why Disable Instead of Delete?
Temporary deactivation:
Testing other rules without interference
Seasonal or event-specific rules that you'll re-enable later
Troubleshooting to isolate rule conflicts
Preserving configuration:
Keep the rule configuration for future reference
Avoid having to recreate complex rules from scratch
Staged rollout:
Disable rules in production while testing
Enable when ready to deploy
How to Disable a Rule
1. Find the rule in the rules list
2. Click the Enable/Disable toggle (usually a switch or checkbox)
3. The rule becomes inactive
Visual indicator changes (dimmed or marked "Disabled")
Rule no longer executes, even if conditions are met
4. No confirmation needed - toggle is instant
How to Re-Enable a Rule
1. Find the disabled rule in the rules list (may be dimmed)
2. Click the Enable/Disable toggle again
3. The rule becomes active
Visual indicator changes back to enabled state
Rule resumes execution when conditions are met
Testing with Disabled Rules
Common workflow:
Disable all rules for a field
Enable one rule at a time
Test each rule individually
Identify which rule causes unexpected behavior
Edit or delete the problematic rule
Re-enable other rules
This incremental approach helps isolate issues when multiple rules affect the same field.
Editing Rules
Modify existing rule configuration without creating a new rule.
How to Edit a Rule
1. Find the rule in the rules list
2. Click the Edit button (pencil icon or "Edit" text)
3. Rule configuration form opens with current settings pre-filled
4. Modify any settings:
Change target field
Update conditions
Change action or action parameters
Modify scope (issue types)
5. Click Save to apply changes
6. Rule updates immediately
New configuration takes effect for all subsequent evaluations
No need to refresh screens or restart Jira
What Can You Edit?
Target field:
Change which field the rule affects
Useful if you realize you configured the wrong field
Conditions:
Add or remove field-based conditions
Change context-based conditions (project, issue type, status)
Update user-based conditions (groups, roles, permissions)
Action:
Switch from Show/Hide to Make Required
Change from Lock to Set Value
Any action can be changed to any other compatible action
Action parameters:
Update Smart Value expressions
Change static values
Modify label or description text
Adjust option visibility settings
Scope:
Add or remove issue types
Change which issue types the rule targets
When to Edit vs Create New Rule
Edit when:
Fixing a mistake in the current rule
Updating conditions as requirements evolve
Refining action parameters based on user feedback
Scope needs adjustment (add/remove issue types)
Create new rule when:
Adding a completely different behavior for the same field
Targeting a different field with similar logic
Creating variations for different screens
Example:
Edit: Rule shows Root Cause for Priority = High. You want to also include Critical.
Edit existing rule, add Critical to conditions
New rule: Rule shows Root Cause for high priority. You also want to require Root Cause.
Create new rule with Make Required action (different behavior)
Deleting Rules
Remove rules permanently when they're no longer needed.
How to Delete a Rule
1. Find the rule in the rules list
2. Click the Delete button (trash icon or "Delete" text)
3. Confirmation dialog appears (typically)
"Are you sure you want to delete this rule?"
Explains that deletion is permanent
4. Confirm deletion
Click "Delete" or "Confirm"
Rule is removed immediately
5. Rule disappears from the list
Cannot be recovered
Field behavior reverts to default (no rule applied)
Deletion is permanent. There's no undo or recovery for deleted rules. If you might need the rule later, disable it instead of deleting it.
When to Delete Rules
Delete when:
Rule is obsolete and will never be used again
Requirements changed permanently
Rule was created for testing and is no longer needed
Simplifying configuration by removing redundant rules
Don't delete when:
You might need the rule later (disable instead)
You're just testing whether the rule causes an issue (disable for testing)
The rule is seasonal or event-specific (disable until next occurrence)
Before Deleting
1. Document the rule configuration if you might need to reference it later
2. Check if other rules depend on this rule's absence
Some rules might assume this rule isn't active
Deleting could cause unexpected behavior
3. Test impact by disabling the rule first
See what happens when the rule isn't active
If everything works fine, deletion is safe
Organizing Rules
As you create more rules, organization becomes important for maintainability.
Rule Naming
Rules are auto-named based on configuration, but good configuration creates good names.
Auto-generated names follow patterns:
Examples:
"Show Root Cause when Priority = High (Bug)"
"Make Business Justification required when Cost > 10000 (All)"
"Lock Fix Versions when Status = Done (Bug, Task)"
Good configurations create clear names:
Use descriptive field names
Use clear condition values
Scope to specific issue types when relevant
The name appears in the rules list, so clear auto-generated names make rules easy to identify.
Grouping by Screen
Rules are automatically grouped by screen (Create, View, Transition) via tabs.
Strategy:
Keep related rules on the same screen when possible
If a behavior needs to apply across screens, create separate rules for each
Screen-specific capabilities guide which rules go where
Example grouping:
Global Issue Create: Progressive disclosure rules, pre-fill rules, dynamic required fields
Issue View: Field locking by status, role-based visibility, audit field protection
Issue Transition: Transition validation rules, status-specific requirements
Grouping by Concern
Within a screen, mentally group rules by what they do:
Visibility rules (Show/Hide):
Rules that control which fields appear
Progressive disclosure patterns
Validation rules (Make Required):
Rules that enforce data quality
Conditional validation
Protection rules (Lock):
Rules that prevent editing
Audit trail preservation
Automation rules (Set Value):
Rules that auto-populate fields
Smart Value calculations
Clarity rules (Change Label, Change Description):
Rules that adapt field names and help text
Context-specific guidance
Option control rules (Limit Options):
Rules that manage dropdown options
Prevent invalid selections
This mental organization helps you find rules quickly and understand your configuration at a glance.
Rule Count Best Practices
How many rules are too many?
There's no hard limit, but consider:
Per field:
2-3 rules per field is common (e.g., Show + Require + Lock in different contexts)
5+ rules for the same field might indicate over-engineering
Consider consolidating if rules have overlapping conditions
Per screen:
10-20 rules per screen is typical for moderate projects
50+ rules suggests complex requirements (valid for large projects)
100+ rules may impact performance or maintainability
Signs you have too many rules:
Hard to understand which rules apply when
Rules conflict or override each other unpredictably
Performance degrades (forms load slowly)
Team members struggle to maintain configuration
Solutions:
Consolidate rules with similar conditions
Remove rules that rarely apply (edge cases)
Split complex projects into smaller projects if feasible
Rule Execution Order
Rules evaluate continuously and independently. Understanding execution order helps prevent conflicts.
How Rules Execute
1. All rules for the screen load when a user opens the screen
2. Each rule evaluates its conditions independently
Rules don't depend on other rules
No guaranteed execution order between rules
3. When conditions are met, actions apply
Multiple rules can affect the same field
Multiple actions can apply simultaneously (if compatible)
4. Field changes trigger re-evaluation
When a field value changes, rules referencing that field re-evaluate
Actions update in real-time
Multiple Rules for the Same Field
Compatible actions can coexist:
Example:
Rule 1: Show "Root Cause" when Priority = High
Rule 2: Make "Root Cause" required when Priority = Critical
Result when Priority = Critical:
Both rules apply
Field is shown (Rule 1 doesn't trigger, but show is default if field is on screen)
Field is required (Rule 2 applies)
Conflicting actions - last applied wins:
Example:
Rule 1: Change label to "Steps to Reproduce" when Issue Type = Bug
Rule 2: Change label to "Problem Description" when Priority = High
Result when Issue Type = Bug AND Priority = High:
Both rules try to change the label
Whichever applies last wins (unpredictable)
Best practice: Avoid conflicting rules
Don't create multiple rules that apply incompatible actions to the same field in the same context
Use mutually exclusive conditions if you need different behaviors
Troubleshooting Execution Order Issues
Symptom: Field behavior is unpredictable or changes unexpectedly
Cause: Multiple rules with conflicting or overlapping logic
Solution:
Disable all rules for the field
Enable one rule at a time
Identify which rules conflict
Modify conditions to be mutually exclusive
Or consolidate into a single rule with conditional logic
Best Practices for Rule Management
1. Start Simple, Add Complexity Gradually
Approach:
Begin with one or two rules
Verify they work correctly
Add more rules incrementally
Test after each addition
Why: Incremental development makes troubleshooting easier. If something breaks, you know which rule caused it.
2. Document Your Rules
What to document:
Business requirement each rule addresses
Why specific conditions or actions were chosen
Edge cases or special considerations
Testing notes
Where to document:
Project documentation wiki
Comments in project management tool
Shared team document
Why: Future maintainers (including future you) will understand the rationale behind rules.
3. Use Descriptive Configurations
Good configurations create clear auto-generated names:
Use full condition values (not abbreviations)
Scope to specific issue types when relevant
Choose actions that clearly describe intent
Example:
Good: "Show Root Cause when Priority = High OR Priority = Critical (Bug)"
Bad: "Show Field when Field = H (All)"
4. Test with Real Users
Why: Permissions, roles, and groups behave differently for different users.
How:
Test with accounts in different groups
Verify user-based conditions work correctly
Ensure role-based rules apply as intended
5. Review Rules Periodically
Schedule quarterly or semi-annual reviews:
Are all rules still needed?
Do conditions still match current workflows?
Are there obsolete rules to delete?
Can rules be simplified or consolidated?
Why: Requirements evolve. Rules that made sense 6 months ago might be obsolete now.
6. Disable Before Deleting
Workflow:
Disable the rule
Monitor for a period (days or weeks)
If no issues arise, delete the rule
If issues arise, re-enable and reconsider
Why: Verifies the rule isn't needed before permanent deletion.
7. Avoid Over-Engineering
Signs of over-engineering:
Rules for edge cases that rarely happen
Complex conditions with 5+ criteria
Multiple rules doing similar things with slight variations
Solution:
Focus on common scenarios (80/20 rule)
Simplify complex rules if possible
Consolidate similar rules
Why: Simple rules are easier to understand, maintain, and debug.
8. Communicate Changes to Your Team
When adding or modifying rules:
Notify affected teams
Explain what changed and why
Provide examples of new behavior
Offer to answer questions
Why: Users may notice form behavior changes. Proactive communication prevents confusion.
Common Management Scenarios
Scenario 1: Rule Isn't Working
Steps:
Check if rule is enabled
Verify conditions match the context you're testing
Check if field is on the screen
Disable other rules to isolate the issue
Check browser console for errors
See Debugging Rules for detailed troubleshooting.
Scenario 2: Too Many Rules
Steps:
List all rules and their purposes
Identify redundant or overlapping rules
Consolidate rules with similar conditions
Delete obsolete rules
Document remaining rules
Result: Cleaner, more maintainable configuration.
Scenario 3: Changing Business Requirements
Steps:
Identify which rules implement the old requirement
Disable those rules (don't delete yet)
Create new rules for the new requirement
Test new rules in context
Delete old rules after verification period
Result: Smooth transition from old to new behavior.
Scenario 4: Seasonal or Event-Based Rules
Example: "Show 'Release Notes' field during release weeks."
Approach:
Create rule with appropriate conditions
Disable when event isn't happening
Enable when event begins
Disable again after event ends
Alternative: Use date-based conditions if supported (e.g., "Show field when Current Date is between X and Y").
Scenario 5: Migrating Rules to Another Project
Steps:
Document rule configuration from source project
Navigate to target project's Dynamic Screen Rules config
Manually recreate rules in target project
Test rules in target project context
Adjust conditions if project-specific differences exist
Note: Rules are project-specific and don't automatically copy. Manual recreation is required.
Performance Considerations
Rule Count and Performance
General guidelines:
1-20 rules per screen: Minimal performance impact
20-50 rules: Slight impact, likely unnoticeable
50-100 rules: Monitor performance, optimize if needed
100+ rules: Significant complexity, may impact form load times
Optimization strategies:
Remove unused or rarely-triggered rules
Simplify complex conditions
Consolidate similar rules
Scope rules to specific issue types to reduce evaluation overhead
Complex Conditions
Simple conditions evaluate faster:
Complex conditions take longer:
Optimization:
Use context-based scope (issue type) instead of field-based conditions when possible
Reduce number of OR conditions
Avoid deeply nested conditional Smart Values
Impact: Usually minimal unless you have hundreds of rules with complex conditions.
Next Steps
Now that you understand rule management:
See rules in action:
Use Cases & Examples - Practical rule examples and patterns
Troubleshoot issues:
Debugging Rules - Identify and fix rule problems
Common Issues - Solutions to frequent problems
Master best practices:
Designing Effective Rules - Principles for creating maintainable rules
Organizing Rules - Strategies for rule organization
Testing Rules - Comprehensive testing approaches
Understand limitations:
Screen-Specific Limitations - What works where
Known Platform Limitations - Atlassian API constraints
You now have all the knowledge needed to create, configure, and manage rules effectively. Start building your dynamic forms!
Last updated