Defining Rule Conditions

Conditions determine when a rule triggers. They answer the question: "Under what circumstances should this field behavior apply?"

Formify supports five types of conditions, named in the rule form's Add Condition list:

1. Field value - Based on values in fields
2. User group - Based on the current user's group membership
3. User role - Based on the current user's project role
4. User permission - Based on the current user's Jira permissions
5. Issue status - Based on the work item's status (Issue View and Transition only)

Understanding how to configure each condition type gives you precise control over when rules execute.

---

How Conditions Work

Basic principle: Rules check their conditions when the form opens and again whenever the user changes a field that a condition uses. When the conditions are met, the action applies to the target field; when they aren't, the action doesn't apply and the field stays as Jira shows it. A change made while the form is still loading, or while the rules are still running, is picked up only with the user's next change.

Condition logic:

• All conditions of a rule are joined by one operator. By default it is AND: the rule applies when every condition is met.
• Between two conditions, the AND menu switches the rule to OR: the rule then applies when any one condition is met.
• The choice covers all of the rule's conditions, whatever their type, so one rule can't mix AND and OR.
• To match one of several values of a field and another condition at once, use is one of on a select list or radio buttons field, or contains any of on a multi-select list or checkboxes field. For other fields, name the values to leave out with not equals, joined by AND: "Priority not equals Low" AND "Priority not equals Medium" AND the other condition.

Example:

Work type: Bug
Condition 1: Priority equals Highest
Condition 2: Current user is in group Developers
Operator: AND

Result: Rule applies on Bugs when Priority is Highest
        AND the current user is in the Developers group

info

Not all rules need all condition types. You can use just field value conditions, just user conditions, or any combination. Add only the conditions that match your business requirements.

---

Field Value Conditions

Field value conditions trigger rules based on the value of a field: what the user types or picks on the form, or, for option fields on Transition and Issue View, the value saved on the work item.

When to Use

Use field value conditions when field behavior should change based on user input.

Common scenarios:

• Keep a field hidden until a specific option is selected
• Require a justification when a "Cost band" select list is set to "Over 10,000"
• Lock fields when a checkboxes field contains a given option
• Limit the options of one dropdown based on the option picked in another
• Change labels based on another field's value

Configuring Field Value Conditions

Steps:

1. In the rule form, find the Conditions section
2. Click + Add Condition
3. Select Field value
4. Configure the condition:
   • Field: Select which field to evaluate (see Fields You Can Use)
   • Operator: Choose the comparison; the choices depend on the field type (see Operators by Field Type)
   • Value: Type the value, or pick it from a list for users, priorities, work types and the options of option fields

Example Configuration

Requirement: "Show 'Root Cause' field only when Priority is High or Critical"

A Show field rule only shows a field and never hides it, so build this as a Hide field rule on Root Cause with the opposite conditions (see Show / Hide Field).

Configuration:

Condition 1:

• Field: Priority
• Operator: not equals
• Value: High

Condition 2:

• Field: Priority
• Operator: not equals
• Value: Critical

Operator between them: AND

Result: Rule triggers when Priority is neither High nor Critical and hides Root Cause, so the field shows for High and Critical only.

Fields You Can Use

A field value condition can check these fields:

Field	Type
Summary, Description	Text
Issue type, Priority	Picked from a list
Assignee, Reporter	User
Labels	Labels
Custom fields	Single-line text, URL, number
Custom option fields	Select list (single choice), radio buttons, multi-select list, checkboxes

Fields of other types, such as dates, components, versions, sprints, paragraph (multi-line) text and custom user pickers, don't appear in the field list. To check the work item's status, use the Issue status condition.

Operators by Field Type

The operators offered depend on the type of the field you pick:

Field type	Operators
Summary, Description, single-line text, URL	equals, not equals, contains, is empty, is not empty
Number	equals, not equals, is empty, is not empty
Issue type, Priority, Assignee, Reporter	equals, not equals, is empty, is not empty
Labels	contains, is empty, is not empty
Select list, radio buttons	equals, not equals, is one of, is empty, is not empty
Multi-select list, checkboxes	contains, contains any of, is empty, is not empty

What each operator checks:

• equals / not equals - The field's value is (or is not) the given value. Comparisons ignore upper and lower case. On an empty field, not equals is met. Number fields compare exact values; there is no greater-than or less-than comparison.
• contains - On a text field: the text appears anywhere in the value. On Labels: the work item has that label. On a multi-select list or checkboxes: that option is among the selected ones.
• is one of - Select list and radio buttons: the selected option is any of the options you list.
• contains any of - Multi-select list and checkboxes: at least one of the options you list is selected. To require several options at once, add one contains condition per option and keep the rule on AND.
• is empty / is not empty - The field has no value (or has one). A checkboxes field is empty when no box is ticked, a multi-select list when nothing is selected. An empty Description counts as empty.

Description: use contains with a distinctive word, is empty or is not empty. equals and not equals don't work on Description: equals never matches, and not equals is met by any Description that has text. contains can also match words of Jira's internal formatting, such as "paragraph" or "text".

Examples:

• Summary contains "outage"
• Priority equals Highest
• Assignee is empty
• Labels contains escalation
• Customer Tier (select list) is one of Premium, Enterprise
• External Bug (checkboxes) contains Yes
• Affected Platforms (multi-select list) contains any of iOS, Android

Option Fields

Select list, radio buttons, multi-select list and checkboxes fields are option fields: in the condition you pick the value from the field's options instead of typing it. Cascading select fields can't be used in a condition.

• Which options are listed: the options of the field's contexts that apply to the rule's project and work types, so you pick from what users see on that form.
• Renaming an option is safe: the condition keeps the option itself, not its name, so the rule keeps working after an option is renamed in Jira. The rule form always shows the option's current name.
• Disabled options appear with "(disabled)" after the name, because work items can still hold them.
• Deleted options appear as "Unknown option (id …)", with a warning that the option no longer exists in Jira. The rule still saves, but that option never matches. Pick another option or remove it.

Fields Not on the Screen

On Transition and Issue View, a condition can also check an option field that isn't on that screen. The field list shows these fields in a second group, Other fields, with the note "Not on this screen. The condition checks the value saved on the work item."

• Such a condition reads the value saved on the work item. In a transition dialog, that is the value before the transition, and it doesn't change while the user fills in the dialog.
• An option field that is on the transition screen gives the value the user picks in the dialog.
• On Create, the list offers only fields on the Create screen.
• Fields of other types must be on the screen. If such a field is later removed from the screen, the condition is no longer met.

Example: Require "Test Evidence" when a work item moves to Done, unless the "SDLC Exempt" checkboxes field is ticked. SDLC Exempt is set earlier and isn't on the transition screen.

• Screen: Transition (Test Evidence is on the screen of the transition to Done only)
• Target field: Test Evidence, Required tab
• Condition: SDLC Exempt (from Other fields) is empty

Result: In the transition dialog, Test Evidence is required on work items where no SDLC Exempt box was ticked.

Multiple Field Conditions

You can add several field value conditions to the same rule. Like all of a rule's conditions, they are joined by the rule's one operator: AND by default, or OR when you switch it.

Example with OR:

Condition 1: Priority equals Highest
Condition 2: Summary contains outage
Operator: OR

Result: Rule applies when Priority is Highest
        OR the summary contains "outage"

info

Several values of one field and another condition? One rule can't mix AND and OR. On a select list or radio buttons field, use is one of ("Customer Tier is one of Premium, Enterprise"); on a multi-select list or checkboxes field, use contains any of. For other fields, name the values to leave out instead, joined by AND: "Priority not equals Low" AND "Priority not equals Medium" AND "Current user is in group Managers".

Practical Examples

Example 1: Progressive disclosure

Hide "Please Explain" field when Satisfaction not equals Dissatisfied

Configuration:

• Action: Hide field
• Field: Satisfaction (select list)
• Operator: not equals
• Value: Dissatisfied, picked from the field's options

An empty Satisfaction also matches not equals, so Please Explain stays hidden until the user picks Dissatisfied.

Example 2: Conditional requirement

Require "Business Justification" when Cost band = Over 10,000

Configuration:

• Field: Cost band (select list)
• Operator: equals
• Value: Over 10,000

Example 3: Multi-value trigger

Show "Escalation Contact" only when Priority = Highest OR Labels contain escalation

Configuration: Labels contains has no opposite, so use two rules on the Visibility tab of Escalation Contact:

• Rule 1: Hide field, no conditions
• Rule 2, below Rule 1: Show field, with
  • Condition 1: Priority equals Highest
  • Condition 2: Labels contains escalation
  • Operator between them: OR

Give both rules the same Work type selection: rules on a tab run from top to bottom only among rules with the same work types, so then Rule 2 shows the field again whenever one of its conditions is met.

Example 4: Empty value check

Hide "Assignee Required" message when Assignee is not empty

Configuration:

• Action: Hide field
• Field: Assignee
• Operator: is not empty

The message shows while Assignee is empty and disappears once someone is assigned.

Example 5: Dependent dropdowns

Offer only hardware subcategories when Category = Hardware

Configuration:

• Target field: Subcategory (select list), Options tab (Limit Field Options) showing only the hardware options
• Condition: Category (select list) equals Hardware

Add one such rule per Category value. See Dependent Dropdowns for the full pattern.

info

Work type: To limit a rule to some work types, use the rule's Work type scope rather than an Issue type condition. The scope applies on every screen, while a condition on Issue type needs the field on the screen.

---

User Group Conditions

User group conditions trigger rules based on the user's Jira group membership.

When to Use

Use group conditions when field behavior should vary by team or organizational role.

What it does: Limits the rule to users in specific Jira groups.

When to use:

• Organization-wide roles (Finance, HR, Leadership)
• Department-specific fields
• Compliance steps that only some teams fill in

Configuration:

1. In the rule form, select Add Condition
2. Select User group
3. Choose is in group or is not in group, and one group

Example:

Show "Budget" field only to users in Finance group

Configuration:
- Action: Hide field
- Current user is not in group Finance

Result: Only Finance group members see the Budget field. Other users see the form without this field.

note

Hiding a field isn't access control. The value stays readable outside the form, for example in search, list view, bulk edit, the REST API, Automation and the Jira mobile app. If users must not see the data, use Jira permissions or issue security levels.

Several groups: Each condition names one group. For the Hide field pattern above, add one is not in group condition per group and keep AND: the field is then hidden only from users in none of the groups, so membership in any of them shows it. With OR, the rule would hide the field from anyone missing from at least one group. Switch the rule to OR only with is in group conditions, for example on a Show field or Make required rule.

---

User Role Conditions

User role conditions trigger rules based on the user's project role.

When to Use

Use role conditions when field behavior should vary by project-specific responsibility.

Configuration:

1. In the rule form, select Add Condition
2. Select User role
3. Choose has role or doesn't have role, and one project role

Example: Allow "Release Date Override" only for Release Managers

Several roles: Each condition names one role. With has role conditions, for example on a Show field or Make required rule, switch the rule to OR so that any of the roles is enough. With doesn't have role conditions, for example on a Hide field or read-only rule, keep AND, so that the rule applies only to users who have none of the roles.

---

User Permission Conditions

User permission conditions trigger rules based on Jira permissions.

When to Use

Use permission conditions to adapt the form to what users are allowed to do in Jira. They shape the form, not access to the data: Jira permissions still decide who can see and edit it.

Configuration:

1. In the rule form, select Add Condition
2. Select User permission
3. Choose has permission or doesn't have permission, one permission, and whether it is checked in the project or globally

Example: Hide system configuration fields from users who don't have the "Administer Project" permission

Common permissions: Edit Issues, Delete Issues, Assign Issues, Create Issues, Administer Project

---

Issue Status Conditions

Issue status conditions trigger rules based on the work item's current status. They are available on Issue View and Transition, where the work item already exists.

Configuration:

1. In the rule form, select Add Condition
2. Select Issue status
3. Choose is in status or is not in status, and one or more statuses

Example: Make "Fix Versions" read-only on the Issue View when the work item is in status Closed

info

In a transition dialog, the status is the one the work item is leaving, not the target status. "Issue status is in status Done" doesn't mean "on the transition to Done". To act on one transition, put the field on that transition's screen only: Transition rules run in every transition dialog whose screen shows the field. To act on transitions out of a status, use that status in the condition.

---

Combining Conditions (AND/OR Logic)

The power of Formify comes from combining multiple condition types to create sophisticated rules.

Understanding Condition Logic

• A rule's conditions are joined by one operator, AND by default. With AND, every condition must be met.
• Switch the operator to OR with the AND menu between two conditions. With OR, any one condition is enough.
• The operator applies to all of the rule's conditions, of every type. One rule can't mix AND and OR, or group conditions in brackets.
• The rule's Work type scope always applies on top of the conditions.

Logic Summary

AND (default):  Condition 1 AND Condition 2 AND Condition 3
OR:             Condition 1 OR  Condition 2 OR  Condition 3

For "either of two values and something else", use is one of (select list, radio buttons) or contains any of (multi-select list, checkboxes) and keep the rule on AND. For other fields, name the values to leave out with not equals.

Example: Simple Combination

Requirement: "Show 'Root Cause' field for high-priority Bugs only"

Configuration:

• Action: Hide field
• Field value: Priority not equals Highest
• Work type: Bug

Result: Rule applies when Priority isn't Highest, on Bugs, and hides Root Cause there.

Example: Advanced Combination

Requirement: "For critical production incidents, require executive contact - but only show to the on-call team."

Configuration:

• Work type: Incident
• Conditions, joined with AND:
  • Priority equals Highest
  • Labels contains production
  • Current user is in group On-Call Team
• Rules on "Executive Contact":
  • Visibility tab: a Hide field rule with no conditions and, below it, a Show field rule with these conditions, both with the same Work type selection (Labels contains has no opposite, so the field is hidden first and shown back)
  • Required tab: a Make required rule with these conditions

Result: Executive Contact shows and is required when Priority is Highest AND the labels contain production AND the current user is in On-Call Team, on Incidents. On other Incidents it stays hidden.

Common Combination Patterns

Pattern 1: Field + Work Type

Hide field X when field Y not equals value, on work type T (Work type scope)

Example: Hide "Steps to Reproduce" when Severity (select list) not equals High, on Bugs

Pattern 2: Status + Role

Make field X read-only when Issue is in status S AND Current user doesn't have role R

Example: Make "Fix Versions" read-only on the Issue View when Issue is in status Closed
         AND Current user doesn't have role Administrators

Pattern 3: Field + Work Type + User

Hide field X when field Y not equals value OR user not in group G, on work type T (Work type scope)

Example: Hide "Budget" when Cost band (select list) not equals Over 10,000
         OR Current user is not in group Finance, on Purchase Requests

Budget then shows only to Finance members on purchase requests over 10,000. A Show field rule never hides a field, so "show only when" patterns are written as Hide field rules with the opposite conditions.

Troubleshooting Combined Conditions

Rule not triggering?

Check each condition independently:

1. Are field conditions met? (Check field values)
2. Is the condition's field on the screen? A condition on a field that isn't on the form is never met, except option fields on Transition and Issue View, which read the value saved on the work item.
3. Does context match? (Check project, work type, status; on Transition, the status the work item is leaving)
4. Does user match? (Check group, role, permissions)

With AND, every condition must be met; if one fails, the rule doesn't apply. With OR, one met condition is enough.

Rule triggering too often?

You may have too few conditions. Add context or user conditions to narrow the scope.

Rule triggering too rarely?

You may have too many conditions. Remove unnecessary conditions to broaden the scope.

---

Best Practices for Defining Conditions

1. Start simple, add complexity as needed

Begin with a single condition and verify it works. Add more conditions only if the simple rule doesn't meet requirements.

2. Use the most specific condition type

• If behavior varies by field value → Use a Field value condition
• If behavior varies by work type → Use the rule's Work type scope
• If behavior varies by status → Use an Issue status condition
• If behavior varies by user → Use a User group, User role or User permission condition

3. Test with real users

Conditions involving user groups or roles behave differently for different users. Test with accounts that have the appropriate group memberships or roles.

4. Document complex conditions

For rules with multiple conditions, note the business requirement in your rule management documentation. Future maintainers will thank you.

5. Avoid over-conditioning

Too many conditions make rules fragile. If conditions change frequently, consider simplifying or splitting into multiple rules.

---

Next Steps

Now that you understand conditions:

Learn about actions:

• Defining Actions - What rules can do to fields when conditions are met

See conditions in practical examples:

• Progressive Disclosure - Field-based condition examples
• Field Locking on Transitions - Transition-based condition examples
• Dynamic Required Fields - Combined condition examples

Explore advanced concepts:

• Using Smart Values - Computed values for the Set Field Value action

Manage your rules:

• Managing Rules - Organize, enable, disable, and edit rules

Ready to learn what rules can do? Continue to Defining Actions.