Skip to main content

Common Pitfalls to Avoid

Learning from common mistakes saves time and prevents frustration. This guide highlights frequent errors when creating Formify and shows how to avoid them.

Understanding these pitfalls helps you design rules that work reliably from the start.

Expecting Show Field to Hide a Field​

The Problem​

Mistake: Creating a "Show Field" rule and expecting the field to stay hidden while the condition isn't met.

Example:

Rule: Show Root Cause when Priority = High

What happens:

  • A field on the screen is visible unless a rule hides it
  • The rule acts only while Priority = High, and then Root Cause is already visible
  • With any other priority the rule does nothing
  • Root Cause is visible for every priority

Impact: The form stays as long as before, and the rule looks broken.

How to Avoid​

Solution 1: Hide the field with the opposite condition

Rule: Hide Root Cause when Priority not equals High

Root Cause stays hidden until the user picks High. Most conditions have an opposite: equals and not equals, is empty and is not empty, is in group and is not in group, has role and doesn't have role, has permission and doesn't have permission, is in status and is not in status. Instead of "is one of A, B", use "not equals A" AND "not equals B".

Solution 2: Hide the field always, show it when the condition is met

When the condition has no opposite (contains, contains any of, or several conditions joined by OR), create two rules on the field's Visibility tab:

Rule 1: Hide Approver Notes (no conditions)
Rule 2: Show Approver Notes when Approvals Needed contains Finance

A rule without conditions always applies. Give both rules the same Work type selection and keep the Show Field rule below the Hide Field rule: rules with the same work types run in the order of the list, from top to bottom, so the Show Field rule brings the field back whenever its condition is met. Rules with different work type selections have no guaranteed order between them, even though the tab lists them together.

Use a Show Field rule on its own only to bring back a field that another rule hides.

Hiding Native-Required Fields​

The Problem​

Mistake: Creating a "Hide Field" rule for a field that is already marked as required in the Jira screen configuration.

Example:

Jira Screen Configuration: Description field is REQUIRED
Dynamic Screen Rule: Hide Description when Priority = Low

What happens:

  • User opens Create issue dialog
  • Sets Priority = Low
  • Description field becomes hidden
  • User clicks "Create"
  • Error: "Description is required" (but field is hidden - user can't fill it!)
  • Form submission fails

Impact: Users cannot submit form. Creates confusion and frustration.

How to Avoid​

Solution 1: Don't hide native-required fields

  • Check Jira screen configuration before creating hide rules
  • If field is required on screen, don't hide it with rules

Solution 2: Make field optional on screen

  • Remove required status from Jira screen configuration
  • Use Formify "Make Field Required" action instead
  • Now you have full control over when field is required/visible

Verification checklist:

  • Check Project Settings → Screens → Field Configuration
  • Identify fields marked as required
  • Don't create hide rules for these fields
  • Or remove native required status and use rules instead

Circular Dependencies​

The Problem​

Mistake: Creating rules where field A's visibility depends on field B, and field B's visibility depends on field A.

Example:

Rule 1: Hide Budget Code when Finance Approval not equals Yes
Rule 2: Hide Finance Approval when Budget Code is empty

What happens:

  • When the form opens, both fields are empty, so both rules hide their field
  • User cannot fill in Budget Code (it's hidden)
  • User cannot set Finance Approval = Yes (it's hidden)
  • Neither field ever appears
  • Circular dependency deadlock

Impact: Fields remain permanently hidden. Users confused about missing fields.

How to Avoid​

Solution: Break circular dependency

Option 1: Use independent condition

Rule 1: Hide Budget Code when Cost Band not equals Over 10,000
Rule 2: Hide Finance Approval when Cost Band not equals Over 10,000

Both rules depend on same independent field (Cost Band, a select list).

Option 2: Chain conditions hierarchically

Rule 1: Hide Budget Code when Priority not equals High
Rule 2: Hide Finance Approval when Budget Code is empty

Priority → Budget Code → Finance Approval (one-way chain, no loop).

Detection:

  • Draw dependency diagram
  • If arrows form a loop, you have circular dependency
  • Redesign to eliminate loop

Overly Broad Conditions​

The Problem​

Mistake: Creating rules with conditions that match more contexts than intended.

Example:

Rule: Require Root Cause when Priority = High
Scope: All issue types

What happens:

  • Rule applies to ALL issue types (Bug, Story, Task, Epic, etc.)
  • Root Cause is required on Stories with Priority = High (doesn't make sense)
  • Root Cause is required on Tasks with Priority = High (also doesn't make sense)
  • Rule applies in unintended contexts

Impact: Confusing user experience. Users must fill in fields that are irrelevant to their work.

How to Avoid​

Solution: Narrow scope appropriately

Better:

Rule: Require Root Cause when Priority = High
Scope: Bug (only)

Or use compound conditions:

Rule: Require Root Cause when Priority = High AND Issue Type = Bug
Scope: All issue types

Best practice:

  • Use specific scope when possible (limits evaluation to relevant issue types)
  • Add Issue Type condition when scope needs to be broad
  • Test rule with different issue types to verify it only applies where intended

Verification:

  • List all issue types in your project
  • Test rule with each issue type
  • Verify rule only applies where it should
  • Narrow scope if rule applies too broadly

Forgetting User Role Conditions​

The Problem​

Mistake: Creating visibility rules without considering who fills in the form, so fields meant for one team show up for everyone.

Example:

Rule: Hide Budget Code when Issue Type not equals Purchase Request
(No user-based conditions)

What happens:

  • ANY user creating a "Purchase Request" sees the Budget Code field
  • Requesters don't know the right code and guess or enter placeholders
  • The Finance team has to correct the field later
  • Field shown to users who shouldn't fill it in

Impact: Cluttered forms. Wrong values. Extra clean-up work.

How to Avoid​

Solution: Add user conditions for fields that only some users fill in

Better:

Rule: Hide Budget Code when Issue Type not equals Purchase Request OR User is not in group "Finance"

Or:

Rule: Hide Budget Code when Issue Type not equals Purchase Request OR User doesn't have role "Administrators"
warning

Hiding is not access control. A hidden field's value stays readable elsewhere in Jira, for example in search, list views, bulk edit, Automation and the Jira mobile app. Users who must not see the data need Jira permissions or issue security levels.

Checklist for team-specific fields:

  • Identify fields that only one team or role fills in
  • Add user group/role/permission conditions to the rules affecting these fields
  • Test with different user accounts (not just admin)
  • Verify users outside the team don't see the field on the form
  • Document which groups see which fields

Fields that often need user conditions:

  • Approval and sign-off fields
  • Finance fields (budget code, cost center)
  • Triage fields filled in by the support or QA team
  • Internal notes for the delivery team
  • Fields used only by team leads or project admins

Not Testing with Actual Users​

The Problem​

Mistake: Testing rules only as Jira admin, not with regular user accounts that have different permissions.

Example:

Rule: Hide Budget field when User doesn't have permission "Schedule Issues"
Tested as: Jira Administrator (has ALL permissions)

What happens:

  • Budget field shows for admin (during testing)
  • Deploy to production
  • Regular users without that permission report: "Budget field not showing"
  • Permissions behave differently for non-admins

Impact: Rules work in testing but fail in production. Users frustrated.

How to Avoid​

Solution: Test with representative user accounts

Testing user matrix:

  • Jira Administrator (all permissions)
  • Project Admin (project-level permissions)
  • Regular user (basic permissions)
  • External user (limited permissions)
  • User in specific groups (Finance, Managers, QA, etc.)
  • User NOT in specific groups (verify rule doesn't apply)

Testing workflow:

  1. Create rule as admin
  2. Test rule as admin (verify basic functionality)
  3. Log out
  4. Log in as regular user
  5. Test rule again (verify it works for regular users)
  6. Repeat with different user roles

Common permission differences:

  • Admins usually have every permission, so for them "has permission" conditions always match and "doesn't have permission" conditions never do
  • Regular users may not have "Edit" permission (affects locking rules)
  • External users may not have "Browse" permission for certain projects
  • Group membership affects group-based conditions

Hidden Required Field Trap​

The Problem​

Mistake: Creating separate rules that make a field required while another rule hides it.

Example:

Rule 1: Hide Budget field when Issue Type = Task
Rule 2: Require Budget field when Cost Band = Over 5,000

What happens:

  • User creates Task and selects Cost Band = Over 5,000
  • Budget field is hidden (Rule 1)
  • Budget field is required (Rule 2)
  • Required field is hidden - user can't submit form

Impact: Form submission impossible. User sees "Budget is required" error but can't see Budget field.

How to Avoid​

Solution: Ensure required fields are always visible

Option 1: Combine show and require

Rule 1: Hide Budget field when Issue Type = Task
Rule 2: Show Budget field when Cost Band = Over 5,000
Rule 3: Require Budget field when Cost Band = Over 5,000
(Rules 2 and 3 have the same condition - field is visible when required)

Give the Hide Field and Show Field rules the same Work type selection, and keep the Show Field rule below the Hide Field rule on Budget's Visibility tab. Rules with the same work types run from top to bottom, so the Show Field rule brings the field back whenever the Require rule applies; rules with different work type selections have no guaranteed order between them.

Option 2: Use mutually exclusive conditions

Rule 1: Hide Budget field when Issue Type = Task AND Cost Band = Under 5,000
Rule 2: Require Budget field when Cost Band = Over 5,000
(Conditions don't overlap - field can't be hidden and required simultaneously)

Detection checklist:

  • List all fields with "Hide" rules
  • List all fields with "Require" rules
  • Check for overlap (same field in both lists)
  • Verify conditions are mutually exclusive OR show-before-require pattern
  • Test with conditions that could trigger both rules

Ignoring Screen Limitations​

The Problem​

Mistake: Creating rules with actions not supported on the selected screen.

Example:

Screen: Issue View
Action: Make Field Required

What happens:

  • Rule is created and enabled
  • Rule never works (Make Required not supported on Issue View)
  • User expects validation but field is not required
  • No error message - rule silently fails

Impact: Rules don't work. Users expect behavior that never happens.

How to Avoid​

Solution: Understand screen-specific action support

Make Field Required:

  • Supported: Global Issue Create, Issue Transition
  • Not supported: Issue View

Other screen-specific behaviors:

  • Issue View: Empty read-only fields are automatically hidden (Jira behavior)
  • Issue View: Rules run only in Jira Software projects. Rules on Due date have no effect there, and Status, Issue type, Resolution, Target start, Target end and Request type can't be locked there
  • Issue Transition: Rules act only on fields on the transition screen, and rules on Due date have no effect there, with one exception: a Must not be empty validation on Due date always fails and blocks the transition, even when Due date is filled (Jira doesn't give apps the Due date value there), so don't add one. Conditions can also check option fields that aren't on the screen, using the value saved on the work item before the transition

Before creating a rule:

Not Documenting Rule Rationale​

The Problem​

Mistake: Creating rules without documenting WHY they exist or what business requirement they address.

Example:

Rule: Hide Root Cause when Priority not equals High
(Nobody recorded why it exists)

What happens:

  • 6 months later: "Why was this rule created? Who asked for it?"
  • New team member: "Can I delete this rule? I don't know what it's for"
  • Business requirement changes but nobody knows if rule is still relevant
  • Rules become unmaintainable

Impact: Rule set becomes black box. Fear of changing anything because purpose is unclear.

How to Avoid​

Solution: Document every rule

Good documentation:

Rule: Hide Root Cause when Priority not equals High
Why: QA process requires root cause analysis for all
     high-priority bugs (approved Q2 2024). The field is
     hidden for other bugs to simplify the form.
Created by: Jane Smith (QA Team)
Date: 2024-03-15

Minimum documentation:

  • What the rule does (Formify names each rule after its action and conditions)
  • Business rationale (why it exists)
  • Who requested it (stakeholder, team)
  • When approved (date)

Where to document:

Formify rules have no description field, so keep the rationale outside the app:

  • Team wiki or README
  • Rule inventory spreadsheet

Pitfall Avoidance Checklist​

Use this checklist when creating new rules:

Before creating rule:

  • Check if field is native-required on Jira screen
  • Verify action is supported on selected screen
  • List all existing rules affecting same field (check for conflicts)
  • Identify if only some users fill in the field (add user conditions)

While creating rule:

  • To show a field only in some cases, hide it with the opposite condition
  • Use specific scope (narrow to relevant issue types)
  • Add user conditions for fields only some users fill in
  • Ensure required fields will be visible (show-before-require)
  • Avoid circular dependencies (draw dependency diagram)
  • Document rule rationale

After creating rule:

  • Test as admin (verify basic functionality)
  • Test as regular user (verify permissions work)
  • Test with different issue types (verify scope is correct)
  • Test edge cases (empty values, nothing selected in option fields)
  • Monitor for user confusion or support tickets

When You've Made a Mistake​

If you discover a pitfall in production:

  1. Immediate action:
    • Disable problematic rule
    • Verify issue is resolved
    • Communicate to users if needed
  2. Investigation:
    • Identify which pitfall occurred
    • Understand why it wasn't caught in testing
    • Document the mistake (learn from it)
  3. Fix:
    • Redesign rule to avoid pitfall
    • Test thoroughly in sandbox
    • Re-enable in production
  4. Prevention:
    • Add to team documentation
    • Update testing checklist
    • Train team members

Don't be afraid to disable rules that aren't working. Better to have no rule than a broken rule causing user frustration.

Design:

Testing:

Understanding:

Troubleshooting:

Learning from these common pitfalls helps you create rules that work reliably from day one. Test thoroughly, document clearly, and verify with actual users before deploying to production.