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:
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:
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:
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:
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:
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:
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.
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
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.
Last updated