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.
A Field's Rules
Rules are managed per field: each field's page lists its rules, one tab per kind of rule.
Opening a Field's Rules
- Navigate to your Jira project
- Open Space settings → Apps → Dynamic Screen Rules (Formify's name in Jira's menus)
- Select the screen tab (Create Issue, Issue View or Transition)
- Select a field
The field list shows how many rules each field has. On a field's page, Rules has one tab per kind of rule (Visibility, Options, Required, Value, Read-only, Description, Name, Validation); each tab shows how many rules it holds, such as Rules (2), and has its own + Add Rule button.
What a Rule Card Shows
Each rule is a card with:
Rule name
- Generated by Formify from the rule's settings; you don't type or edit it
- Example: "Hide root Cause when Priority not equals High and Priority not equals Critical"
Scope
- The icons of the work types the rule applies to; hover over an icon to see the work type's name
Conditions
- One line per condition, each marked IF
- Example: "Priority not equals High" and "Priority not equals Critical"
- A rule without conditions has no IF lines; it always applies to its work types
Status labels
- Syncing while a change you made is being passed to Jira's forms
- DISABLED when the rule is switched off
The ⋯ menu
- Edit rule - change the rule's settings
- Disable / Enable - switch the rule off or back on
- Move up / Move down - change the rule's place in the tab's list (shown when the tab has more than one rule)
- Delete rule - remove the rule
The card doesn't show the target field or the action as separate items: the field is the one whose page you're on, and the tab and the rule name tell you the action.
Disabling and Enabling Rules
You can switch rules 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:
- Create a rule, disable it, and enable it when your team is ready
How to Disable a Rule
Open the field's page and the tab that holds the rule
Open the rule card's ⋯ menu and select Disable
The card is marked DISABLED. The rule no longer runs, even when its conditions are met
There's no confirmation step.
How to Re-Enable a Rule
Open the disabled rule's ⋯ menu and select Enable. The DISABLED label disappears and the rule runs again when its 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
Change an existing rule without creating a new one.
How to Edit a Rule
Open the rule card's ⋯ menu and select Edit rule
The rule form opens with the rule's current settings, titled after the tab, such as Edit Field Visibility Rule
Change what you need (see below) and select Save Changes
Formify rebuilds the rule's name from the new settings. The card shows Syncing while the change is passed to Jira's forms; once the label disappears, open the screen again to see the new behavior.
What Can You Edit?
Work type:
- Add or remove work types under Scope; at least one must stay selected
Action:
- Switch between the actions of the rule's tab, such as Show field and Hide field on Visibility, or Make required and Make optional on Required
- Change the action's settings: the value a Set value rule sets, Smart Values, the label or description text, the options a Limit options rule shows or hides, a validation's limits and error message
Conditions:
- Add, change or remove conditions
- Switch between AND and OR
What you can't change:
- The field the rule belongs to and the screen it runs on: the rule stays on the field's page and screen tab where you created it
- The kind of rule: a Visibility rule can't become a Required rule. Create a new rule on the other tab instead
When to Edit vs Create New Rule
Edit when:
- Fixing a mistake in the current rule
- Updating conditions as requirements evolve
- Refining action settings based on user feedback
- The work types need adjusting
Create new rule when:
- Adding a different kind of behavior for the same field (another tab)
- Targeting a different field with similar logic
- Creating variations for different screens
Example:
Edit: Rule hides Root Cause when Priority not equals High. You want Root Cause for Critical too.
- Edit existing rule, add the condition Priority not equals Critical (joined with AND)
New rule: Rule hides Root Cause for lower priorities. You also want to require Root Cause for high priority.
- Create a new rule on the field's Required tab with the Make required action
Deleting Rules
Remove rules permanently when they're no longer needed.
How to Delete a Rule
Open the rule card's ⋯ menu and select Delete rule
The Delete rule dialog asks you to confirm, with the rule's name, and warns that the action can't be undone
Select Delete rule in the dialog. The rule disappears from the tab
The field goes back to its default behavior on the screen (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. Note the rule's settings if you might need to reference them later: the card shows the name, work types and conditions; Edit rule shows the rest
2. Check if other rules depend on this rule
- A Show field rule placed below this rule may rely on it hiding the field first
- 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 this pattern:
[Action] [field] when [Field] [operator] [value] and [Field] [operator] [value]
Examples:
- "Hide due date when Priority equals High"
- "Require business Justification when Cost Band equals Over 10,000" (Cost Band is a select list)
- "Make fix versions read-only when condition" (an Issue status condition)
How the name is built:
- The target field's name starts with a lowercase letter
- Field value conditions use the operator as the rule form shows it, such as equals or contains
- Other conditions, such as Issue status or User group, appear as "condition"
- Conditions are joined with "and", also in a rule switched to OR. The card lists the conditions but doesn't show whether they're joined with AND or OR: open the rule with Edit rule to see it
- The work type scope isn't part of the name; it appears on the card under Scope
You can't type or edit a rule's name. It changes when you edit the rule's settings. The name is built from the field names and values Jira shows, so clear field and option names in Jira give clear rule names.
The name appears on the rule card and in the Delete rule dialog, so you can tell rules apart without opening them.
Grouping by Screen and Field
Formify groups rules for you: by screen (the Create Issue, Issue View and Transition tabs of the field list), then by field, then by kind of rule (the tabs on a field's page).
Strategy:
- If a behavior needs to apply on several screens, create a rule on each screen's tab: a rule runs only on the screen it was created for
- What each screen supports guides which rules go where
Example grouping:
- Create Issue: progressive disclosure rules, pre-fill rules, dynamic required fields
- Issue View: field locking by status, role-based visibility
- Transition: transition validation rules, status-specific requirements
Grouping by Kind of Rule
On a field's page, each tab holds one kind of rule:
| Tab | Actions | Typical use |
|---|---|---|
| Visibility | Show field, Hide field | Progressive disclosure |
| Options | Show options, Hide options | Dropdowns limited to valid choices |
| Required | Make required, Make optional | Conditional required fields |
| Value | Set value | Pre-filled values, Smart Values |
| Read-only | Make read-only, Make editable | Fields locked by status or role |
| Description | Set description | Context-specific help text |
| Name | Set field name | Context-specific labels |
| Validation | 15 validation types, such as Must not be empty | Data quality checks with custom error messages |
Which tabs a field has depends on the screen and the field type.
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., Hide + 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
- The rules on a field's tab that have the same Work type selection run from top to bottom, in the order of the list; Move up and Move down in a rule's ⋯ menu change it
- Rules with different work type selections have no guaranteed order between them, even though the tab lists them together. Give rules that must run in a set order the same work types
- In one run, every condition sees the form as it was when the run started; a value one rule sets reaches other rules' conditions on the next run
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 the user changes a field value, rules referencing that field re-evaluate, also when another rule modifies that field (for example limits its options)
- Summary and Description count as changed when the user leaves the field; on Issue View, a change counts once the edit is saved
- A change made while the form is still loading, or while the rules are still running, isn't picked up: the rules react to the user's next change
- Actions update in real-time
Multiple Rules for the Same Field
Compatible actions can coexist:
Example:
- Rule 1: Hide "Root Cause" when Priority equals Low
- Rule 2: Make "Root Cause" required when Priority equals Critical
Result when Priority = Critical:
- Field is shown (Rule 1 doesn't apply, and a field on the screen is visible by default)
- 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
- If both rules have the same Work type selection, the rule lower on the field's Name tab applies last and wins; with different work type selections, either one can win
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. Give Fields and Options Clear Names in Jira
Rule names are built from Jira's field names and values, so the clearer those are, the easier rules are to read:
- Name select list options in words, not codes
- Avoid fields with near-identical names
Example:
- Clear: "Require business Justification when Cost Band equals Over 10,000"
- Hard to read: "Require field when Band equals 3"
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 only during release weeks."
Approach:
- Create a Hide field rule on Release Notes, with no conditions
- Disable the rule when a release week begins, so the field shows
- Enable it again when the release week ends
Formify has no date-based conditions, so seasonal rules are switched on and off by hand.
Scenario 5: Migrating Rules to Another Project
Steps:
- Note the rules' settings in the source project (the cards show names, work types and conditions; Edit rule shows the rest)
- Open Space settings → Apps → Dynamic Screen Rules in the target project
- Recreate the rules there
- Test the rules in the target project
- Adjust conditions where the projects differ (work types, options, groups)
Note: Rules belong to one project. Formify has no copy, export or import of rules, so they're recreated by hand.
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 equals High AND
Summary contains backend AND
Current user is in group Finance
Optimization:
- Use context-based scope (issue type) instead of field-based conditions when possible
- Reduce number of OR conditions (on a select list or radio buttons, one is one of condition replaces several)
- Keep Smart Values short
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
Understand limitations:
- 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!