Skip to main content

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​

  1. Navigate to your Jira project
  2. Open Project Settings → Apps → Dynamic Screen Rules
  3. 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:

  1. Disable all rules for a field
  2. Enable one rule at a time
  3. Test each rule individually
  4. Identify which rule causes unexpected behavior
  5. Edit or delete the problematic rule
  6. 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)
warning

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:

[Action] [Field] when [Conditions] ([Scope])

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:

  1. Disable all rules for the field
  2. Enable one rule at a time
  3. Identify which rules conflict
  4. Modify conditions to be mutually exclusive
  5. 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:

  1. Disable the rule
  2. Monitor for a period (days or weeks)
  3. If no issues arise, delete the rule
  4. 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:

  1. Check if rule is enabled
  2. Verify conditions match the context you're testing
  3. Check if field is on the screen
  4. Disable other rules to isolate the issue
  5. Check browser console for errors

See Debugging Rules for detailed troubleshooting.

Scenario 2: Too Many Rules​

Steps:

  1. List all rules and their purposes
  2. Identify redundant or overlapping rules
  3. Consolidate rules with similar conditions
  4. Delete obsolete rules
  5. Document remaining rules

Result: Cleaner, more maintainable configuration.

Scenario 3: Changing Business Requirements​

Steps:

  1. Identify which rules implement the old requirement
  2. Disable those rules (don't delete yet)
  3. Create new rules for the new requirement
  4. Test new rules in context
  5. 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:

  1. Create rule with appropriate conditions
  2. Disable when event isn't happening
  3. Enable when event begins
  4. 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:

  1. Document rule configuration from source project
  2. Navigate to target project's Dynamic Screen Rules config
  3. Manually recreate rules in target project
  4. Test rules in target project context
  5. 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:

Priority = High    // Fast

Complex conditions take longer:

(Priority = High OR Priority = Critical) AND
(Component contains "Backend" OR Component contains "API") AND
(User in Finance OR User in Leadership)

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:

Troubleshoot issues:

Understand limitations:

You now have all the knowledge needed to create, configure, and manage rules effectively. Start building your dynamic forms!