Condition Types - Competitive Advantage
Conditions determine when a rule should execute its action. Dynamic Screen Rules 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
Dynamic Screen Rules offers four 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
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. Dynamic Screen Rules 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:
- Show additional fields when a user selects a specific option
- Require documentation when an estimate exceeds a threshold
- Lock fields based on checkbox selection
- 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, greater than, or is empty.
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: Condition: Priority = High OR Critical → Action: Show Root Cause field
Issue Type as Field Value
Issue Type is treated as a field value condition in Dynamic Screen Rules. You can create rules that trigger based on the selected issue type.
Example:
Condition: Issue Type equals Bug
Action: Show "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: Status = Done - Within Bugs, rule triggers when 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 support various operators depending on field type:
| Operator | Description | Field Types |
|---|---|---|
| Equals | Value matches exactly | All field types |
| Not equals | Value doesn't match | All field types |
| Contains | Value includes text | Text fields, multi-select |
| Doesn't contain | Value doesn't include text | Text fields, multi-select |
| Is empty | Field has no value | All field types |
| Is not empty | Field has any value | All field types |
| Greater than | Numeric comparison | Numbers, dates |
| Less than | Numeric comparison | Numbers, dates |
| In list | Value is one of multiple options | Select fields |
See Defining Rule Conditions - Field-Based Conditions for detailed reference.
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:
- Show sensitive fields only to specific teams
- 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: Condition: User in "Finance Team" OR "Project Managers" → Action: Show Budget field
Configuration
When adding a user group condition:
- Select "User in group" condition type
- Choose one or more groups from your Jira instance
- Multiple groups have OR relationship (user in ANY of the selected groups)
Important: Groups are defined in Jira administration. Dynamic Screen Rules 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
- Show release management fields only to 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: Condition: Status = Testing AND User NOT "Release Managers" → Action: Lock Fix Versions
Configuration
When adding a user role condition:
- Select "User has role" condition type
- Choose one or more project roles
- Multiple roles have OR relationship (user has ANY of the selected 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 for fine-grained access control based on what users are allowed to do in Jira.
Common scenarios:
- Show fields only to users with specific permissions
- 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: User has "Administer Projects" permission → Action: Show System Configuration field
Configuration
When adding a user permission condition:
- Select "User has permission" condition type
- Choose one or more Jira permissions
- Multiple permissions have OR relationship (user has ANY of the selected 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
Combining Condition Types
You can combine multiple conditions to create sophisticated rules.
How Combining Works
Within the same type (OR logic):
- Multiple conditions of the same type have OR relationship
- Example: Priority = High OR Priority = Critical
- Rule triggers if ANY condition is true
Across different types (AND logic):
- Conditions of different types have AND relationship
- Example: (Priority = High) AND (User in group "Managers")
- Rule triggers only if ALL condition types are satisfied
Practical Example: Multi-Condition Rule
Scenario: Require Executive Contact for critical incidents, except for Leadership group.
Rule:
- Scope: Incident
- Conditions: Priority = Critical AND User NOT in "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 | Show Root Cause when Priority = High |
| Show field based on issue type | Field Value (Issue Type) | Show Steps to Reproduce when Issue Type = Bug |
| Restrict field to specific teams | User Group | Show Budget only to Finance Team group |
| Lock field except for project role | User Role | Lock for all except Release Managers role |
| Show admin fields to admins only | User Permission | Show config fields to Administer Projects permission |
| 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 Amount > $10k AND user NOT administrator |
Condition Types Comparison
| Aspect | Field Value | User Group | User Role | User Permission |
|---|---|---|---|---|
| Triggers based on | What users enter | User's groups | User's project role | User's permissions |
| Changes during editing | Yes (as users fill form) | No (user groups are fixed) | No (project roles are fixed) | No (permissions are fixed) |
| Use for | Progressive disclosure, dynamic validation | Team-based visibility | Role-based control | Permission-based access |
| Example | Priority = High | User in Developers | User has PM role | Has Edit Issues permission |
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.