Skip to main content

Rule-Based Approach

Formify applies conditional logic to Jira fields in real-time. Instead of static screen configurations that look the same for everyone, rules adapt field behavior based on context, field values, and user identity.

info

In short: Rules are if-then instructions that control field behavior. When conditions are met (like "Priority not equals High"), actions execute (like "Hide Root Cause field"). Rules evaluate continuously as users fill forms, making fields appear, disappear, become required, or lock automatically.

Understanding how this rule-based approach works helps you design effective rules and troubleshoot when things don't behave as expected.

How Rules Work​

A rule is a conditional instruction that modifies field behavior on Jira screens.

The basic pattern:

IF (conditions are met)
THEN (apply action to target field)

Components:

  • Target field - The field that will be affected
  • Screen - Where the rule applies (Create, View, Transition)
  • Scope - Which issue types the rule applies to
  • Conditions - When the rule should trigger
  • Action - What happens to the field when conditions are met

Example:

Target field: Root Cause
Screen: Global Issue Create
Scope: Bug issue type
Conditions (AND): Priority not equals High, Priority not equals Critical
Action: Hide field

This rule hides the Root Cause field when someone creates a Bug with any priority other than High or Critical. When the user picks High or Critical, the conditions are no longer met, the rule applies nothing, and Root Cause is on the form as usual.

An Action Applies Only While Its Conditions Are Met​

When a rule's conditions are not met, the rule changes nothing: the field is as Jira shows it, and fields on the screen are visible. A Show field rule on its own therefore never hides a field. To show a field only in some cases, hide it in all the others:

  • Hide field with the opposite condition (the simplest way): "Hide Root Cause when Priority not equals High AND Priority not equals Critical". 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. "Is one of A, B" becomes "not equals A AND not equals B".
  • A Hide rule, then a Show rule, when the condition has no opposite (contains or contains any of, or several conditions joined by OR): on the field's Visibility tab, add a Hide field rule with no conditions, which always applies, and below it a Show field rule with your condition. Give both rules the same Work type selection: rules with the same work types run from top to bottom, so the Show rule wins whenever its condition is met. Rules with different work type selections have no guaranteed order between them, even though the tab lists them together.

Show field on its own is for bringing back a field that another rule hides.

The Rule Execution Pipeline​

Rules execute in a predictable sequence each time a user interacts with a Jira screen.

1. Screen Loads​

When a user opens a create dialog, issue view, or transition dialog:

  1. All rules for that screen are identified - Formify finds rules configured for the current screen (Create/View/Transition)
  2. Scope is checked - Rules apply only if the issue type matches the rule's scope
  3. Conditions are evaluated - Each rule checks if its conditions are met
  4. Actions are applied - When conditions are satisfied, the action executes on the target field

Example: When a user opens the Create Issue dialog for a Bug, a rule "Hide Root Cause when Priority not equals High" checks: the screen matches, the scope matches, and Priority is Medium, so the condition is met. Root Cause is hidden.

2. Field Changes Trigger Re-Evaluation​

As users fill out the form, rules re-evaluate instantly when relevant field values change. Actions update in real-time - fields appear/disappear, become required/optional, lock/unlock. No page refresh needed.

Rules run again whenever the user changes a field used in a condition, including a field that another rule modifies (for example by limiting 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.

Example: User changes Priority to High → Rule re-evaluates → Condition no longer met → the rule applies nothing, and Root Cause appears instantly.

3. Actions Persist Until Conditions Change​

Once a rule's action is applied, it remains in effect until:

  • The condition is no longer met (e.g., user changes Priority to High); the field then goes back to how it was before the rule
  • The user navigates away from the screen
  • Another rule modifies the same field property with different logic

Example:

If "Priority not equals High" hides the Root Cause field, and the user changes Priority to High, Root Cause appears immediately. When the user switches back to Medium, it disappears again. Rules continuously monitor their conditions and update field behavior accordingly.

Real-Time Evaluation Model​

Formify evaluates rules continuously, not just once.

Key Characteristics​

1. Instant feedback

  • User selects Priority = High → Root Cause field appears immediately
  • User changes Priority to Medium → Root Cause field disappears immediately
  • No submit button click required, no page refresh

2. Multiple rules can affect the same field

  • Rule 1: Hide field when Priority not equals High AND Priority not equals Critical
  • Rule 2: Make field required when Priority equals Critical
  • When Priority = Critical, Rule 1 applies nothing, so the field is visible, and Rule 2 makes it required

3. Each rule checks its own conditions

  • Each rule evaluates its own conditions: in one run, every condition sees the form as it was when the run started
  • If one rule sets a field that another rule checks, the other rule sees the new value on the next run
  • Rules on a field's tab that have the same Work type selection run from top to bottom. When two of them change the same thing, for example a Hide field rule and a Show field rule on the Visibility tab, the lower one wins whenever both apply
  • Rules with different Work type selections appear together on the tab, but they don't run in the order of the list, and there is no guaranteed order between them
  • You can enable/disable rules individually

What This Means for Users​

Users experience adaptive forms that start simple and grow based on selections. Real-time validation means no surprises after clicking Submit - the form guides users naturally through the process.

Putting It All Together​

Let's see the complete execution model with a practical example.

Example Scenario​

Business requirement: "For high-priority incidents, we need root cause analysis and executive notification contact. For routine incidents, these fields just clutter the form."

Rules configured:

Rule 1:

  • Target field: Root Cause
  • Screen: Global Issue Create
  • Scope: Incident issue type
  • Conditions (AND): Priority not equals High, Priority not equals Critical
  • Action: Hide field

Rule 2:

  • Target field: Executive Contact
  • Screen: Global Issue Create
  • Scope: Incident issue type
  • Condition: Priority not equals Critical
  • Action: Hide field

Rule 3:

  • Target field: Executive Contact
  • Screen: Global Issue Create
  • Scope: Incident issue type
  • Condition: Priority equals Critical
  • Action: Make field required

A rule has one action, so hiding and requiring Executive Contact takes two rules, one on the field's Visibility tab and one on its Required tab.

How It Works in Practice​

Priority = Low: Rules 1 and 2 hide both fields, so the form stays simple.

Priority = High: Rule 1 no longer applies, so Root Cause appears instantly for analysis.

Priority = Critical: Rules 1 and 2 no longer apply, so both Root Cause and Executive Contact appear. Rule 3 makes Executive Contact required (red asterisk).

Forms adapt automatically to the situation, showing users only what's relevant without manual training.

Next Steps​

Now that you understand how rules work:

Learn about screens:

  • Screens & Contexts - Detailed breakdown of Global Issue Create, Issue View, and Issue Transition capabilities

Understand condition types:

  • Condition Types - Field-based, context-based, and user-based conditions explained

Start configuring:

See it in action:

Ready to dive deeper into screens? Continue to Screens & Contexts.