Condition Types - Competitive Advantage
Conditions determine when a rule should execute its action. Formify supports multiple condition types that you can combine to create sophisticated field behavior.
Understanding the available condition types helps you design rules that trigger exactly when needed, adapting field behavior to user input and context.
Available Condition Types
Formify offers five types of conditions:
- Field Value Conditions - Trigger based on values in fields (including Issue Type)
- User Group Conditions - Trigger based on group membership
- User Role Conditions - Trigger based on project role
- User Permission Conditions - Trigger based on user permissions
- Issue Status Conditions - Trigger based on the work item's status (Issue View and Transition)
Each type serves different purposes. You can combine multiple conditions to create complex logic.
Compared to alternatives: Many Jira field management solutions only support field value conditions. Formify also includes user-based conditions (group, role, permission), enabling role-based field visibility and user-specific validation that other solutions can't achieve.
Field Value Conditions
What they do: Rules trigger based on values users enter or select in fields.
When to Use
Use field value conditions when field behavior should change based on what users have filled in.
Common scenarios:
- Hide follow-up fields until a user selects the option they belong to
- Require documentation when a "Cost band" select list is set to its highest band
- Lock fields based on the options ticked in a checkboxes field
- Limit dropdown options based on another field's value
How They Work
Field value conditions evaluate the current value of a field and compare it to your criteria using operators like equals, contains, is one of, or is empty. The rules check again whenever the user changes a field that a condition uses.
Example:
Condition: Priority equals High
Result: When user selects Priority = High, condition is met
Practical Example
Scenario: Show Root Cause field for high-priority bugs only.
Rule: Conditions (AND): Priority not equals High, Priority not equals Critical → Action: Hide Root Cause field
The rule hides Root Cause for every other priority. When the user picks High or Critical, its conditions are no longer met, the rule applies nothing, and Root Cause is on the form again. A Show field rule with "Priority equals High OR Priority equals Critical" would change nothing: a field on the screen is already visible. See Rule-Based Approach.
Issue Type as Field Value
Issue Type is treated as a field value condition in Formify. You can create rules that trigger based on the selected issue type.
Example:
Condition: Issue Type not equals Bug
Action: Hide "Steps to Reproduce" field
This is different from scope. Scope filters which issue types a rule can apply to at all. Issue Type conditions filter when the rule triggers within that scope.
Scope vs Issue Type Condition:
- Scope: Bug - Rule can only apply to Bug issues
- Condition: Issue status is in status Done - Within Bugs, rule triggers when the status is Done
- Condition: Issue Type = Bug - Used when scope includes multiple types but you want to trigger only for specific ones
Supported Operators
Field value conditions work on 14 field types. The operators depend on the field type:
| Field type | Operators |
|---|---|
| Summary, single-line text, URL | equals, not equals, contains, is empty, is not empty |
| Description | 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 |
Comparisons ignore upper and lower case. Number fields compare exact values. Conditions read Description as rich text, so equals and not equals don't work on it (the editor still offers them), and contains can also match words Jira uses to store the formatting, such as "paragraph" or "text": check for a distinctive word. For select lists, radio buttons, multi-select lists and checkboxes, you pick the options from a list, and renaming an option in Jira doesn't break the rule.
See Defining Rule Conditions - Operators by Field Type for what each operator checks, and for option fields that aren't on the screen.
User Group Conditions
What they do: Rules trigger based on the user's group membership.
When to Use
Use group conditions when field behavior should vary by team or organizational role.
Common scenarios:
- Hide fields that only specific teams need from everyone else
- Require approval fields only for non-manager groups
- Hide internal fields from external contributors
- Display team-specific fields for relevant groups
How They Work
User group conditions check if the current user belongs to one or more specified Jira groups.
Example:
Condition: User in group "Finance Team"
Result: Rule applies only when Finance Team members view/edit the form
Practical Example
Scenario: Show Budget field only to Finance team and Project Managers.
Rule: Conditions (AND): Current user is not in group "Finance Team", Current user is not in group "Project Managers" → Action: Hide Budget field
Hiding a field tidies the form; it doesn't protect the data. Jira still shows the value in search, list views, the REST API and the mobile app. Data that some users must not see needs Jira permissions or issue security levels.
Configuration
When adding a user group condition:
- Select Add Condition, then User group
- Choose is in group or is not in group, and one group from your Jira instance
- For several groups, add one condition per group. With is in group, switch the rule to OR, so a member of any of the groups matches. With is not in group on a Hide field rule, keep AND: the rule then hides the field only from users who are in none of the groups (with OR, it would hide the field from anyone missing from at least one group)
Important: Groups are defined in Jira administration. Formify uses existing Jira groups - it doesn't create or manage groups itself.
User Role Conditions
What they do: Rules trigger based on the user's project role.
When to Use
Use role conditions when field behavior should vary by project-specific responsibility.
Common scenarios:
- Lock fields except for users with specific project roles
- Require additional validation for non-administrators
- Hide release management fields from everyone except Release Managers
- Display different help text for different roles
How They Work
User role conditions check if the current user has a specific project role in the current project.
Example:
Condition: User has role "Administrators"
Result: Rule applies only when project administrators view/edit the form
Practical Example
Scenario: Lock Fix Versions field in Testing status, except for Release Managers.
Rule: Conditions (AND): Issue status is in status Testing, Current user doesn't have role "Release Managers" → Action: Lock Fix Versions on the Issue View
Configuration
When adding a user role condition:
- Select Add Condition, then User role
- Choose has role or doesn't have role, and one project role
- For several roles, add one condition per role. With has role, switch the rule to OR; with doesn't have role on a Hide field rule, keep AND, so the rule hides the field only from users who have none of the roles
Important: Project roles are configured per project in Jira. The same user may have different roles in different projects.
User Permission Conditions
What they do: Rules trigger based on whether the user has specific Jira permissions.
When to Use
Use permission conditions when field behavior should follow what users are allowed to do in Jira.
Common scenarios:
- Lock fields for users without a specific permission
- Require additional information from users with certain capabilities
- Hide administrative fields from users without admin permissions
- Display different validation for different permission levels
How They Work
User permission conditions check if the current user has a specific Jira permission in the current project context.
Example:
Condition: User has permission "Administer Projects"
Result: Rule applies only when users with project admin permission view/edit
Practical Example
Scenario: Show System Configuration field only to administrators.
Rule: Condition: Current user doesn't have permission "Administer Projects" → Action: Hide System Configuration field
Configuration
When adding a user permission condition:
- Select Add Condition, then User permission
- Choose has permission or doesn't have permission, one Jira permission, and whether it is checked in the project or globally
- For several permissions, add one condition per permission. With has permission, switch the rule to OR; with doesn't have permission on a Hide field rule, keep AND, so the rule hides the field only from users who have none of the permissions
Common permissions:
- Edit Issues - User can edit issues
- Delete Issues - User can delete issues
- Administer Projects - User can configure project
- Assignable User - User can be assigned issues
Issue Status Conditions
What they do: Rules trigger based on the work item's current status.
When to Use
Use status conditions when field behavior should change as the work item moves through the workflow. They are available on the Issue View and Transition screens, where the work item already exists.
Common scenarios:
- Lock fields once the work item is Done or Closed
- Hide review fields unless the work item is in review
How They Work
Issue status conditions check the status saved on the work item: is in status or is not in status, with one or more statuses.
In a transition dialog, this is the status the work item is leaving, not the target status. To act on one transition only, put the field on that transition's screen; Transition rules run in every transition dialog whose screen shows the field.
Example:
Condition: Issue status is in status Closed
Action: Lock Fix Versions on the Issue View
Combining Condition Types
You can combine multiple conditions to create sophisticated rules.
How Combining Works
One operator per rule:
- All of a rule's conditions are joined by one operator, AND by default: the rule applies when every condition is met
- The AND menu between two conditions switches the rule to OR: the rule then applies when any one condition is met
- The operator covers every condition of the rule, whatever its type, so one rule can't mix AND and OR
- Example with AND: Priority equals High AND Current user is in group "Managers"
- Example with OR: Priority equals High OR Priority equals Highest
Practical Example: Multi-Condition Rule
Scenario: Require Executive Contact for critical incidents, except for Leadership group.
Rule:
- Scope: Incident
- Conditions (AND): Priority equals Highest, Current user is not in group "Leadership"
- Action: Make Executive Contact required
This combines scope filtering (Incident) + field condition (Priority) + user condition (not Leadership) - all must be true.
See Defining Rule Conditions - Combining Conditions for detailed combination logic.
Choosing the Right Condition Type
Use this guide to select appropriate condition types for your rules.
| Goal | Condition Type | Example |
|---|---|---|
| Show field based on user input | Field Value | Hide Root Cause when Priority is not High |
| Show field based on issue type | Field Value (Issue Type) | Hide Steps to Reproduce when Issue Type is not Bug |
| Show field to specific teams only | User Group | Hide Budget when user is not in Finance Team group |
| Lock field except for project role | User Role | Lock for all except Release Managers role |
| Lock field after a status | Issue Status | Lock Fix Versions when the work item is Closed |
| Show admin fields to admins only | User Permission | Hide config fields when user doesn't have Administer Projects |
| Require field for external users | User Group (negation) | Require for users NOT in Internal Staff group |
| Combine value and role | Multiple types | Require signature when Cost band = Over 10,000 AND user doesn't have role Administrators |
Condition Types Comparison
| Aspect | Field Value | User Group | User Role | User Permission | Issue Status |
|---|---|---|---|---|---|
| Triggers based on | What users enter or select | User's groups | User's project role | User's permissions | The work item's status |
| Changes during editing | Yes (as users fill the form)* | No (user groups are fixed) | No (project roles are fixed) | No (permissions are fixed) | No (the saved status) |
| Use for | Progressive disclosure, dynamic validation | Team-based visibility | Role-based control | Permission-based behavior | Status-based locking |
| Example | Priority = High | User in Developers | User has PM role | Has Edit Issues permission | Work item in Closed |
* An option field that isn't on the Transition or Issue View screen is read from the work item, so it keeps its saved value while the user edits the form.
Next Steps
Now that you understand condition types:
Start configuring:
- Defining Rule Conditions - Complete guide to creating and combining conditions
- Creating Your First Rule - Step-by-step rule creation
Learn about actions:
- Defining Actions - All seven actions explained
See practical examples:
- Progressive Disclosure - Field value conditions in action
- Field Locking on Transitions - Protecting fields during transitions
Ready to configure conditions? Continue to Defining Rule Conditions.