Key Features
Dynamic Screen Rules brings sophisticated field behavior to Jira screens without requiring custom development. Here's what you can do with the app.
Rule-Based Field Behavior
Control how fields appear and behave on your Jira screens using conditional rules that execute in real-time as users interact with forms.
Display fields only when relevant
Show or hide fields based on context, keeping forms clean and focused.
What you can do:
Show "Root Cause Analysis" field only for high-priority bugs
Display "Customer Impact" section only when issue affects external users
Hide internal fields from external contributors
Reveal additional detail fields based on initial selections
Business value: Shorter, cleaner forms that don't overwhelm users with irrelevant fields. Users see only what they need, when they need it.
Example: A support team shows "Escalation Contact" field only when Priority is set to Critical, keeping the form simple for routine tickets while ensuring critical issues get proper attention.
Enforce validation conditionally
Make fields required only in specific situations, not universally.
What you can do:
Require "Affected Versions" only for Bug issue types
Make "Business Justification" mandatory when estimated cost exceeds threshold
Enforce "Root Cause" field when closing high-priority incidents
Require approval fields only for changes affecting production
Business value: Collect complete information when it matters without burdening users with unnecessary required fields. Validation happens at the right time, in the right context.
Smart validation: Users only see red asterisks when fields are actually needed, reducing form fatigue.
Prevent accidental edits
Make fields read-only based on status, role, or other conditions.
What you can do:
Lock "Fix Versions" when issue status isn't "In Development"
Make fields read-only for users outside specific groups
Prevent editing of critical fields after approval
Protect fields from modification during certain workflow stages
Business value: Implement guardrails that prevent common mistakes without completely blocking users. Protect data integrity while maintaining flexibility.
Fields locked on the Global Issue Create screen will be read-only but visible. On the Issue View screen, empty read-only fields are automatically hidden by Jira.
Auto-fill field values
Pre-fill or compute field values to reduce manual work and ensure consistency.
What you can do:
Auto-populate Component based on issue type or project
Set default Assignee based on priority or category
Pre-fill dates, labels, or custom field values
Copy values from one field to another
Business value: Eliminate repetitive data entry. Users spend less time filling forms and more time on meaningful work. Consistent data across issues improves reporting accuracy.
Use Smart Values to compute dynamic values like "next Monday" or "Due Date - 2 business days".
Context-aware field labeling
Provide labels and help text that adapt to the situation.
What you can do:
Change "Description" label to "Steps to Reproduce" for Bug issues
Update field descriptions based on issue type or status
Provide different guidance for different user groups
Clarify field meaning in specific contexts
Business value: Guide users with relevant instructions. The same field can serve different purposes in different contexts with appropriate labeling.
Clean up dropdown selections
Show only relevant options in select fields, preventing invalid selections.
What you can do:
Show only P1/P2 priorities for Bug issues
Limit components based on project or issue type
Hide deprecated resolutions or statuses
Filter versions, labels, or custom field options
Business value: Users can't select inappropriate values because they're not visible. Fewer mistakes mean less cleanup work and better data quality.
Prevent errors before they happen: Invalid options simply don't appear, making it impossible to select wrong values.
Multiple Condition Types
Rules trigger based on comprehensive conditions - not just field values, but also context and user identity.
Field-Based Conditions
Trigger rules based on values in other fields on the form. Supports operators like equals, contains, greater than, is empty, and more. Works with text, select, number, date, checkbox, and custom fields.
Competitive advantage: Unlike competitors that focus only on field values, Dynamic Screen Rules offers field-based AND context-based AND user-based conditions, giving you complete control over when rules apply.
Examples by Condition Type
Show "Database Schema" when Component contains "Backend"
Condition: Component contains "Backend" AND Issue Type equals "Technical Task"
Action: Show "Database Schema" field
Use case: Technical fields appear only for backend work
Supported operators:
Equals, not equals
Contains, doesn't contain
Is empty, is not empty
Greater than, less than
In list, not in list
Supported field types: Text, select, multi-select, number, date, checkbox, user picker, and most custom fields.
Require "Release Notes" in production projects
Condition: Project = "Customer Platform" AND Issue Type = "Feature" AND Status = "Ready for Release"
Action: Require "Release Notes" field
Use case: Ensure documentation before releasing customer-facing features
What you can filter on:
Project - Apply rules only in specific projects
Issue Type - Different behavior for Bugs vs Stories vs Epics
Status - Lock or show fields based on workflow stage
Show financial fields to Finance team only
Condition: User in group "Finance Team"
Action: Show "Budget Information" field
Use case: Protect sensitive data from unauthorized access
What you can filter on:
Group membership - e.g., only for "Developers" group
Project role - e.g., only for "Administrators" role
Permissions - e.g., only users with "Edit Issues" permission
Complex multi-condition rules
Mix and match condition types using AND/OR logic to create sophisticated rules.
How it works:
Multiple conditions within the same type have OR relationship
Multiple condition types have AND relationship
Example: Show "Executive Summary" field when:
(Priority = High OR Priority = Critical) AND
(User in Group "Managers")
Result: Only managers see the Executive Summary field, and only for high-priority issues.
Smart Values - Computed Field Values
Go beyond static values with expressions that calculate field values automatically.
Date Math - Set dates relative to today or other date fields
Automatically calculate dates without manual input. Perfect for SLAs and deadlines.
Examples:
Set Due Date =
next business daySet Start Date =
next MondaySet Review Date =
today + 7 daysSet Deadline =
Due Date - 2 business days
Business value: Consistent SLA handling. No manual date calculations. Dates automatically adjust based on when the issue is created.
Date math respects business days and weekends, ensuring realistic deadlines.
Field References - Copy or derive values from other fields
Keep related fields in sync automatically. Reduce manual data entry and copy-paste errors.
Examples:
Set Summary =
copy from Parent issueSet Component =
same as Linked Issue componentSet Custom Field A =
value from Custom Field B
Business value: Ensure related fields stay in sync. Reduce errors from manual copying.
Common use cases:
Copy epic details to child stories
Inherit team assignments from parent tasks
Sync related custom fields across linked issues
Conditional Expressions - Calculate values based on logic
Implement business rules directly in forms. Make smart decisions based on field values.
Examples:
If Priority = High, set Assignee = Team Lead, otherwise leave emptyIf Story Points > 5, set flag = 'Needs Breakdown'Set label based on combination of project and issue type
Business value: Implement business logic directly in forms. Complex decision trees become simple automated rules.
Advanced patterns:
Multi-level conditionals (if-then-else chains)
Calculations based on multiple fields
Dynamic assignments based on workload
Smart Values use an expression language similar to Jira Automation's smart values. Learn more in Using Smart Values.
Multiple Screens Support
Rules work across three key areas of Jira where users interact with fields.
Global Issue Create
All actions supported The dialog that appears when creating new issues. Perfect for progressive disclosure, pre-filling values, dynamic required fields, and cleaning up dropdown options.
Common Use Cases by Screen
Perfect for guiding users during issue creation
Supported actions: Show/hide, required, lock, set value, change labels/descriptions, limit options
Best use cases:
Progressive disclosure - Show fields only when relevant selections are made
Pre-filling values - Auto-populate Component based on issue type
Dynamic required fields - Require "Affected Versions" only for Bugs
Cleaning dropdowns - Show only P1/P2 priorities for critical issue types
Example: When a user selects Issue Type = "Bug" and Priority = "Critical", automatically show and require the "Root Cause Analysis" field while pre-filling Due Date to next business day.
Perfect for protecting data and adapting to workflow
Supported actions: Most actions (with some API limitations for certain fields)
Best use cases:
Locking fields based on status - Make "Fix Versions" read-only when Status = "Done"
Role-based field visibility - Show financial fields only to Finance team
Setting values when fields change - Auto-update labels when priority changes
Context-aware field labels - Change "Description" to "Resolution Notes" in Done status
Example: When an issue moves to "Done" status, automatically lock all fields except "Resolution" and "Time Spent", preventing accidental edits to closed work.
Perfect for enforcing workflow gates
Supported actions: Most actions
Best use cases:
Transition-specific validation - Require "Test Results" before moving to "Ready for Release"
Status-based field visibility - Show "Deployment Notes" only when transitioning to "Deploy"
Pre-filling resolution fields - Auto-fill "Resolved" and "Fix Versions" on close
Ensuring data completeness - Require all necessary fields before status change
Example: When transitioning from "In Progress" to "Done", require "Resolution", "Time Spent", and "Work Log" fields, ensuring complete closure documentation.
Some field types have limited support on certain screens due to Atlassian's UI Modifications API limitations. See Field Support & Limitations for details.
Scoping and Targeting
Control exactly where rules apply for precise field behavior.
Per-Project Scoping
Each rule is configured for a specific project, giving you complete control over field behavior without affecting other projects.
What you can do:
Configure rules that match each project's unique workflow
Experiment in one project before rolling out
Maintain different validation rules for different teams
Keep project configurations independent
Project isolation: Changes in one project never break another. Each team gets exactly the form behavior they need.
Per-Issue-Type Scoping
Rules can target specific issue types (Bug, Story, Epic, custom types).
What you can do:
Different field behavior for Bugs vs Features vs Tasks
Issue-type-specific validation and required fields
Tailored forms for different work types
One size doesn't fit all: Bugs need different fields than feature requests. Configure accordingly.
Combined Scoping - Maximum Precision
Combine project and issue type scoping with field, context, and user conditions for highly targeted rules.
Example rule with combined scoping:
Result: Only developers in the Customer Platform project will be required to fill Root Cause Analysis, and only for critical bugs. All other combinations are unaffected.
Surgical precision: Target exactly the scenarios that need special handling without affecting normal workflows.
Real-Time Execution
Rules evaluate instantly as users interact with forms, providing immediate feedback.
Business value:
Smooth user experience - No page refreshes or delays. Forms respond instantly to user input.
Immediate feedback - Users know instantly if they need to fill additional fields. Context-aware forms adapt as users provide information.
Example in action: User creates a Bug issue. Initially only Summary and Description are visible. When they select Priority = "Critical", the Root Cause field appears instantly. When they change Priority to "Low", the field disappears just as quickly. No waiting, no confusion.
Next Steps
Now that you understand what Dynamic Screen Rules can do, choose your path:
See How It Compares
Understand what you can't do with standard Jira configuration and how Dynamic Screen Rules goes beyond native capabilities.
Quick Start Guide
Create your first rule in under 10 minutes with our step-by-step tutorial. Perfect for hands-on learners.
Last updated