Organizing Rules
As your rule set grows, organization becomes critical. Well-organized rules are easier to find, maintain, and troubleshoot. This guide shares strategies for structuring rule sets that scale from a handful to hundreds of rules.
Formify already sorts rules for you: by screen, by field and by kind of rule. Your part is deciding where each rule goes and keeping a record of why it exists.
Why Organization Matters
Small rule sets (1-10 rules):
- Organization is nice to have
- Can manage without strict structure
- The rule names Formify generates are usually enough
Medium rule sets (10-50 rules):
- Organization becomes important
- Hard to find specific rules without structure
- A shared rule inventory prevents confusion
Large rule sets (50+ rules):
- Organization is critical
- Impossible to maintain without clear structure
- Systematic approach required
Benefits of good organization:
- Find rules quickly when troubleshooting
- Understand rule dependencies
- Avoid creating duplicate rules
- Onboard new team members faster
- Identify gaps in coverage
How Formify Groups Rules
By screen. The field list has a tab per screen: Create Issue, Issue View and Transition. A rule runs only on the screen it was created for.
By field. Each field's page holds that field's rules. The field list shows how many rules each field has, and its Rules filter lets you pick rule counts (No rules, 1 rule, 2 rules ...); pick every count except No rules to see the fields that have rules.
By kind of rule. On a field's page, each tab holds one kind of rule: Visibility, Options, Required, Value, Read-only, Description, Name and Validation.
By order. Within a tab, Move up and Move down in a rule's ⋯ menu set the order. The order decides which rule applies last only for rules with the same Work type selection; rules with different work type selections have no guaranteed order between them.
By work type. Each rule card shows its work types under Scope.
To review everything users see on one screen, open that screen's tab, filter the field list by Rules, picking every count except No rules, and go through the fields one by one.
Reading Rule Names
Formify builds each rule's name from its settings. You can't type or edit a name, and there's no description field; the name changes when you edit the rule.
Format:
[Action] [field] when [Field] [operator] [value] and [Field] [operator] [value]
Examples:
Hide root Cause when Priority not equals High and Priority not equals Critical
Require business Justification when Cost Band equals Over 10,000
Make fix versions read-only when condition
Story Points > 0
What the name tells you:
- The action and the target field (the field's name starts with a lowercase letter)
- Field value conditions, with their operator and value
- For a validation, the check itself, such as
Story Points > 0
What the name doesn't tell you:
- The screen: that's the tab the field list is on
- The work types: they appear on the card under Scope
- Conditions other than Field value: Issue status, User group, User role and User permission conditions appear as "condition" in the name; the card's IF lines show them in full
- Whether the conditions are joined with AND or OR: the name always says "and"; open Edit rule to see it
Two rules on the same field with the same action and conditions but different work types get the same name; the Scope icons tell them apart. Clear field and option names in Jira give clear rule names, because the name is built from them.
Choosing Where Rules Go
Group by Screen
Strategy: Decide what each screen is for, and put rules on the screen where the behavior belongs.
Why this works:
- Screen determines context and capabilities
- Rules on same screen often relate to similar user workflows
- Easy to review all rules affecting a specific user experience
Example split:
- Create Issue: progressive disclosure, pre-filled values, conditional required fields
- Issue View: fields locked by status, role-based visibility
- Transition: fields required on a transition, status-specific requirements
If a behavior needs to apply on several screens, create a rule on each screen's tab.
Keep One Field's Behavior Together
Strategy: Every rule on a field lives on that field's page, one tab per kind of behavior. Use them together:
- Visibility: Hide root Cause when Priority not equals High and Priority not equals Critical
- Required: Require root Cause when Priority equals Critical
Opening Root Cause shows both, so anyone changing one sees the other.
Use the Same Work Types for Rules That Work Together
Strategy: When rules on one tab must apply in a set order (for example a Hide field rule with no conditions and a Show field rule below it), give them the same Work type selection. With different selections, their order isn't guaranteed.
Documentation Strategies
Maintain a Rule Inventory
Formify's names can't carry your own prefixes or categories, so keep them in an inventory outside Jira.
Create a master list of all rules with:
- Rule name, as Formify shows it
- Screen (Create Issue, Issue View, Transition)
- Field and tab
- Work types
- Conditions, and whether they're joined with AND or OR
- Your own category (for example Validation, Visibility, Pre-fill, Locking, Options, Labels)
- Business rationale
- Date created
- Created by
Example inventory (spreadsheet or table):
| Rule name | Screen | Field / tab | Work types | Category | Why | Created | By |
|---|---|---|---|---|---|---|---|
| Hide root Cause when Priority not equals High and Priority not equals Critical | Create Issue | Root Cause / Visibility | Bug | Visibility | Critical bugs need root cause analysis per QA process | 2024-03-15 | Jane |
| Make fix versions read-only when condition (Issue status is in status Done) | Issue View | Fix Versions / Read-only | Story, Bug | Locking | Prevent version changes after QA testing | 2024-03-20 | Bob |
Benefits:
- Single source of truth for all rules
- Easy to search and filter
- Historical record of changes
- Helps identify redundancy
Document Rule Dependencies
Track which rules depend on or interact with each other:
Example dependency documentation:
Rule: Require root Cause when Priority equals Critical (Required tab)
Depends on: Hide root Cause when Priority not equals High and Priority not equals Critical (Visibility tab)
Reason: Field must be visible when it is required
Notes: If the Hide rule's condition is changed to also match Critical,
users can't submit Critical bugs
Dependency types:
- Visible when required - Can't require hidden field
- Condition on same field - Multiple rules checking same field value
- Sequential disclosure - Field B stays hidden until Field A is filled in, Field C until Field B is
- Hide and Show on the same field - The order of the rules on the field's Visibility tab decides which one wins, if both rules have the same Work type selection. Rules with different work type selections have no guaranteed order between them
Document Business Rationale
For each rule, explain:
- What: What does the rule do? (covered by the name)
- Why: Why does this rule exist? (business requirement)
- Who: Who requested it? (stakeholder, team)
- When: When was it approved? (date)
Example:
Rule: Require business Justification when Cost Band equals Over 10,000
What: Makes "Business Justification" field required when
Cost Band (select list) = Over 10,000 on Feature issues
Why: Finance department requires written justification for
all features above the 10,000 budget threshold
Who: Requested by the Finance team
Approved by Product Management
When: Approved Q2 2024, implemented 2024-04-15
Notes: Budget threshold may be adjusted annually
Review policy in Q1 each year
Rule Organization Checklist
Use this checklist when organizing your rule set:
Grouping:
- Each rule is on the screen where its behavior belongs
- Rules that must apply in a set order share the same Work type selection
- Grouping strategy documented and communicated
Documentation:
- Master rule inventory maintained, with Formify's rule names
- Business rationale documented for each rule
- Dependencies between rules identified
- Rule ownership clear (who created, who maintains)
Maintenance:
- Process for reviewing and updating rules
- Process for archiving or deleting obsolete rules
- New team members can understand rule set
Reorganization: When and How
Signs You Need to Reorganize
Warning signs:
- Can't find specific rule without searching every field
- Creating duplicate rules because existing ones are hard to find
- New team members confused by rule organization
- The same behavior is set up on different screens in different ways
- No clear grouping strategy
How to Reorganize
1. Audit existing rules:
- On each screen tab, filter the field list by Rules, picking every count except No rules, and list the rules field by field
- Group rules by logical categories
- Identify duplicates or conflicts
- Note which rules are actually used
2. Choose organization strategy:
- Decide what each screen is for
- Define your categories for the inventory
- Document the strategy
3. Move rules where they belong:
- A rule can't be moved to another screen, field or tab: create it again where it belongs, test it, then disable and later delete the old one
- Within a tab, use Move up and Move down to put rules in the order you want
- Update the inventory as you go
4. Create rule inventory:
- List all rules with metadata
- Document dependencies
- Note business rationale
5. Archive obsolete rules:
- Identify unused rules
- Disable (don't delete immediately)
- Monitor for 2-4 weeks
- Delete if truly unused
6. Communicate changes:
- Inform team of new organization
- Update team documentation
- Train new admins on organization strategy
Multi-Project Organization
When Managing Rules Across Multiple Projects
Challenge: Rules belong to one project, and Formify has no copy, export or import of rules, so each project's rules are set up by hand.
Strategies:
1. Pattern recipes:
- Write down common patterns as recipes: screen, field, tab, action, work types and conditions
- Recreate them in each new project from the recipe
- Keep the recipes up to date when a pattern changes
2. Same fields and options across projects:
- Where projects share fields and option names, the same rules get the same names in every project
- Makes it easier to recognize patterns
- Simplifies knowledge transfer
3. Shared documentation:
- Maintain central wiki or README with rule patterns
- Link to project-specific rule lists
- Document project-specific variations
Example structure:
Documentation/
├── Rule-Patterns/
│ ├── progressive-disclosure-patterns.md
│ ├── validation-patterns.md
│ └── pre-fill-patterns.md
├── Project-Rules/
│ ├── support-project-rules.md
│ ├── dev-project-rules.md
│ └── ops-project-rules.md
└── Rule-Organization-Guide.md (this guide)
Team Collaboration
When Multiple Admins Manage Rules
Establish conventions:
- Agree on what each screen is for
- Decide on inventory categories
- Document in team wiki
Communication:
- Notify team before creating new rules
- Document rule purpose and rationale
- Review rules together periodically
Ownership:
- Assign rule owners (who maintains each rule)
- Track who created each rule
- Coordinate changes
Change history (optional):
- Record rules in a wiki page or spreadsheet (Formify has no rule export)
- Note each change with its date and author
- Track changes over time
Related Pages
Design:
- Designing Effective Rules - Principles for creating rules
Testing:
- Testing Rules - How to test rule sets systematically
Management:
- Managing Rules - Enable, disable, edit rules in UI
Pitfalls:
- Common Pitfalls to Avoid - Organizational mistakes to watch for
Well-organized rules are self-documenting and maintainable. Invest time in organization early - it pays dividends as your rule set grows.