Going Beyond Native Jira
Jira's native screen configuration provides basic field layout and required field settings. While this works for simple scenarios, it quickly becomes limiting when you need context-aware field behavior. Dynamic Screen Rules extends native Jira capabilities to give you the flexibility modern teams need.
What Native Jira Screen Configuration Offers
Jira's standard screen management lets you:
Add or remove fields from screens
Mark fields as required or optional
Create different screen schemes for different projects
Use different screens for create, view, and edit operations
This works well when your requirements are static - when the same fields should always be visible and the same fields should always be required, regardless of context.
Where Native Configuration Falls Short
Problem 1: Long Forms with Irrelevant Fields
The native approach: Include all possible fields on the screen since you can't show them conditionally.
The result: Users scroll through long forms filled with fields that don't apply to their current task. A Bug report form includes Feature-specific fields. An internal task shows customer-facing fields. Users get overwhelmed, adoption suffers, and data quality drops because people rush through forms or skip optional fields.
What Dynamic Screen Rules adds: Progressive disclosure - show fields only when relevant based on issue type, project, priority, or other field values.
Example: Native Jira can't show "Steps to Reproduce" only for Bugs. You either include it for all issue types (cluttering Feature and Task forms) or omit it entirely (losing data quality on Bugs). Dynamic Screen Rules shows it only when Issue Type = Bug.
Problem 2: No Context-Aware Validation
The native approach: Fields are either always required or always optional.
The result: You can't enforce "Root Cause is required for high-priority incidents" - you have to make it required for all incidents (annoying for low-priority items) or never required (losing data quality on critical issues). Teams resort to training, documentation, or manual checking to enforce conditional requirements.
What Dynamic Screen Rules adds: Conditional required fields based on any combination of field values, context, or user attributes.
Example: Native Jira can't require "Business Justification" only when estimated cost exceeds $10,000. Dynamic Screen Rules can make fields required based on values in other fields, issue status, user role, or any combination.
Problem 3: Manual Data Entry for Repetitive Values
The native approach: Use field defaults or ask users to fill everything manually.
The result: Users repeatedly enter the same values (like Component for bug types, or Assignee based on priority). Default values help but don't adapt to context - a default applies to all issues, not just relevant ones. Teams waste time on data entry instead of solving problems.
What Dynamic Screen Rules adds: Context-aware field pre-filling and computed values, including date math and field references.
Example: Native Jira can't auto-set Component = "Backend" when Issue Type = "Backend Bug" while setting Component = "Frontend" for frontend bugs. You can only have one default value, or no default. Dynamic Screen Rules sets values based on context and can even compute dates like "next business day" or "next Monday."
Problem 4: Can't Limit Dropdown Options Conditionally
The native approach: All options in select fields are always visible to all users.
The result: Priority dropdowns show P1-P5 for all issue types, even when only P1-P2 make sense for incidents. Users select inappropriate values, requiring cleanup. Resolution lists include deprecated options users shouldn't choose. Long dropdown lists slow down selection and increase errors.
What Dynamic Screen Rules adds: Conditional option visibility - show only relevant choices based on context.
Example: Native Jira can't show only "Critical" and "High" priorities for Bug issues while showing all priorities for Tasks. All issue types see all options. Dynamic Screen Rules filters options based on issue type, project, status, or any other condition.
Problem 5: No Role-Based Field Visibility
The native approach: All users with "Edit Issues" permission see all fields on the screen.
The result: You can't hide sensitive fields (like budget, contract details, or internal notes) from contractors or external contributors while showing them to internal staff. You either expose fields to everyone or create separate projects with different permissions - a management nightmare.
What Dynamic Screen Rules adds: User-based conditions that show/hide fields based on group membership, project role, or permissions.
Problem 6: Static Field Labels and Help Text
The native approach: Field names and descriptions are the same in all contexts.
The result: Generic labels like "Description" don't guide users toward providing the right information. Bug reports need "Steps to Reproduce" while features need "User Story" - but the same field serves both purposes with a generic label that doesn't help either audience.
What Dynamic Screen Rules adds: Context-aware field labels and descriptions that change based on issue type, status, or other conditions.
Problem 7: Can't Lock Fields Conditionally
The native approach: Use workflow validators or field configurations to make fields read-only.
The result: Fields are either editable by everyone or locked for everyone. You can't lock "Fix Versions" only when issue isn't in "In Development" status. You can't prevent editing except for Release Managers. Teams resort to post-edit cleanup or complex workflow validators that block transitions.
What Dynamic Screen Rules adds: Conditional field locking based on status, role, or any other criteria.
Side-by-Side Comparison
Show field only for specific issue types
❌ Create separate screen schemes
✅ Single rule with condition
Require field only when priority is high
❌ Can't do - always required or never required
✅ Conditional required rule
Auto-fill component based on issue type
❌ Can only set one default value
✅ Set value based on conditions
Show "Root Cause" only to managers
❌ Can't do - same fields for all users
✅ User-based condition
Hide deprecated priority options
❌ Options always visible
✅ Limit options based on context
Lock fields when status = Done
❌ Use workflow validators (blocks transitions)
✅ Make fields read-only conditionally
Change "Description" label to "Steps to Reproduce" for bugs
❌ Can't change labels conditionally
✅ Change label based on issue type
Set due date to "next business day" automatically
❌ Can't compute dates
✅ Smart Values with date math
What Dynamic Screen Rules Doesn't Replace
Dynamic Screen Rules extends native Jira - it doesn't replace it. You'll still use Jira's screen configuration for:
Basic field layout: Adding fields to screens, organizing field order, creating screen schemes - all handled by native Jira.
Always-visible, always-required fields: If a field should be visible and required in all contexts, use native required field settings. No need for a rule.
Field-level permissions: If a field should be completely hidden from certain users (not just conditionally), use field configurations and permission schemes.
Workflow transitions: Dynamic Screen Rules works on screens, not workflow logic. Use Jira workflows and validators for transition rules.
Best practice: Use native Jira for static configuration (layout, always-required fields) and Dynamic Screen Rules for conditional behavior (show/hide based on context, conditional required, dynamic values).
Competitive Advantage: Comprehensive Condition Types
Many field behavior apps on the Atlassian Marketplace focus exclusively on field-based conditions - showing or requiring fields based on values in other fields.
Dynamic Screen Rules goes further with three types of conditions:
1. Field-Based Conditions
Like competitors: trigger rules based on field values.
"Show field A when field B = X"
"Require field C when field D contains Y"
2. Context-Based Conditions ⭐
Unique to Dynamic Screen Rules: Trigger rules based on project, issue type, or status.
"Show field only in Project X"
"Require field only for Bug issue types"
"Lock field when status = Done"
3. User-Based Conditions ⭐
Unique to Dynamic Screen Rules: Trigger rules based on who is viewing the form.
"Show field only to users in Managers group"
"Require field only for users with Administrator role"
"Lock field for everyone except Release Managers"
Why this matters: You can create rules like "In the Customer Platform project, for Bug issues, when Priority is Critical, and user is in Developers group, require Root Cause Analysis field." No competitor offers this level of targeting.
When to Use Each Approach
Use Native Jira When:
Field should always be visible on the screen
Field should always be required (or always optional)
Field layout is simple and doesn't vary by context
You're setting up basic screen schemes
Use Dynamic Screen Rules When:
Field visibility depends on other field values, issue type, status, or user
Fields should be required only in specific contexts
You need to pre-fill values based on context
You want to limit dropdown options conditionally
You need role-based field visibility
You want to lock fields based on status or role
You need to compute field values (dates, field references, expressions)
Use Both Together (Recommended):
Native Jira defines the base screen layout and always-required fields
Dynamic Screen Rules adds conditional behavior on top
This combination gives you the best of both worlds: simplicity for static needs, power for dynamic requirements
Next Steps
Ready to see Dynamic Screen Rules in action?
Start using it: Jump to Quick Start Guide to create your first rule in under 10 minutes
Learn the concepts: Read Key Concepts to understand how rules, conditions, and actions work
See examples: Explore Use Cases & Examples for ready-to-use configurations
Already convinced? Begin with Installation & Setup.
Last updated