Known Platform Limitations
Dynamic Screen Rules is built on Atlassian's UI Modifications API. This API has platform-level limitations that affect all apps using it, including Dynamic Screen Rules. Understanding these limitations helps you design effective rules and troubleshoot unexpected behavior.
These are not limitations of Dynamic Screen Rules itself, but constraints imposed by Jira's platform architecture.
Multiple UI Modifications Apps Limit
Limitation: Maximum 5 UI Modifications apps can run simultaneously for any combination of project, issue type, and screen.
What This Means
If you have more than 5 apps installed that use the UI Modifications API (like Dynamic Screen Rules, ScriptRunner, Jira Misc Workflow Extensions, etc.), only the first 5 apps will apply their changes. Changes from the 6th app onward are disregarded.
Affected combinations:
Project + Issue Type + Screen (Global Issue Create, Issue View, or Issue Transition)
Example scenario:
Project: "Customer Platform"
Issue Type: Bug
Screen: Global Issue Create
Apps configured: 6 UI Modifications apps
Result: Only 5 apps apply changes; the 6th app's rules don't execute
How to Work Around This
Audit installed apps:
Go to Jira Settings → Apps → Manage apps
Check which apps use UI Modifications API
Consolidate functionality into fewer apps when possible
Prioritize Dynamic Screen Rules:
If you hit the 5-app limit, consider whether other apps provide functionality you can replicate with Dynamic Screen Rules
Dynamic Screen Rules is specifically designed for field behavior management
Contact support:
If you need multiple apps and hit the limit, contact our support team for advice on configuration strategies
Conflicts Between Multiple Apps
Limitation: When multiple UI Modifications apps modify the same field using the same method, conflicts occur.
What This Means
If Dynamic Screen Rules and another app (e.g., ScriptRunner) both try to hide the same field, they may conflict. The app that finishes running last "wins" - its changes override earlier apps' changes.
Application order is random - apps run asynchronously, so you can't predict which app will finish last.
User Experience
When conflicts occur:
Users see a notification: "Some changes couldn't be applied due to conflicts"
The final field state reflects whichever app finished last
Unpredictable behavior if multiple apps fight over the same field
How to Avoid Conflicts
Coordinate with other apps:
Document which fields Dynamic Screen Rules manages
Configure other apps to avoid modifying the same fields
Use Dynamic Screen Rules for field visibility/validation; use other apps for different purposes
Test thoroughly:
Test your rules in a staging environment with all apps installed
Verify that rules work consistently with other apps present
Consolidate where possible:
If two apps do similar things, choose one to avoid conflicts
Dynamic Screen Rules provides comprehensive field management - consider migrating field logic here
Flash of Unmodified Fields (Global Issue Create)
Limitation: UI modifications load after the Create issue dialog finishes loading. Users briefly see fields before modifications are applied.
What This Means
When a user opens the Create issue dialog:
Dialog loads with all fields visible (unmodified state)
Dynamic Screen Rules evaluates and applies rules
Fields hide/show/lock/change according to rules
This happens very quickly (typically under 1 second), but users may notice:
A field briefly visible before being hidden
Default field labels before they change
Unmodified dropdown options before being limited
Visual indicator: Small spinner icon appears next to field labels while modifications are loading.
User Experience Impact
Minimal for most users:
Loading happens fast on modern browsers
Spinner icon indicates changes are in progress
Final state is correct once loading completes
Noticeable on slow connections:
Users with slow internet may see longer flash duration
Mobile users may experience more noticeable delays
Cannot Be Eliminated
This is a platform limitation - all UI Modifications apps experience this behavior. The Atlassian API doesn't support pre-loading modifications before the dialog appears.
Workaround: Design rules with this in mind. Don't rely on hidden fields for security - use Jira permissions for sensitive data.
"Show Fields" and "Find Your Field" Limitations
Limitation: Jira's native "Show fields" feature doesn't interact well with UI Modifications apps.
Show Fields Behavior
Users can hide fields individually using Jira's "Show fields" button. When a user hides a field this way:
Data for hidden fields is not sent to Dynamic Screen Rules
Rules cannot evaluate conditions based on user-hidden fields
Rules cannot show/hide/modify user-hidden fields
Example problem:
Rule: "Show Root Cause when Priority = High"
User hides Priority field using "Show fields"
Dynamic Screen Rules doesn't receive Priority value
Rule cannot evaluate condition
Root Cause field doesn't appear even when it should
Find Your Field Behavior
Jira's "Find your field" search doesn't know about fields hidden by Dynamic Screen Rules.
Example problem:
Rule hides "Internal Notes" field for external users
External user searches "Find your field" for "Internal"
"Internal Notes" appears in search results
User clicks field but it doesn't appear on form
Confusing user experience
How to Work Around This
Communicate with users:
Educate users not to use "Show fields" to hide fields that rules depend on
Explain that Dynamic Screen Rules manages field visibility automatically
Design resilient rules:
Don't create complex dependencies on user-controllable fields
Use required fields in conditions (users can't hide required fields)
Consider field permissions:
For sensitive fields, use Jira field configurations instead of dynamic rules
Combine Dynamic Screen Rules with native Jira permissions
Image Previews During Issue Creation
Limitation: Image previews may show "Preview unavailable" during issue creation.
What This Means
When users add images to Description or rich text fields during issue creation:
Images upload successfully
Preview shows "Preview unavailable" message
Preview displays correctly after issue is created and page is refreshed
Why this happens: Permissions to display images aren't available until the issue exists in Jira's database.
User Experience Impact
Not a blocker:
Images still upload and save correctly
Preview appears after issue creation
Users can continue creating issues normally
Slightly confusing:
Users may think upload failed
"Preview unavailable" message isn't very explanatory
Workaround
Communicate expectation:
Inform users that image previews appear after issue creation
Add help text to rich text fields explaining this behavior
This affects all UI Modifications apps - not specific to Dynamic Screen Rules.
Required User Permissions
Limitation: Users must have specific Jira permissions to see UI modifications work.
Permission Requirements by Screen
Global Issue Create
"Create issues" permission
User sees error: "We couldn't load the UI modifications configuration for this form"
Issue View
"Browse projects" permission
Rules don't apply; user sees unmodified fields
Issue Transition
"Transitions issues" permission
Rules don't apply on transition dialogs
What This Means
If a user lacks the required permission:
Dynamic Screen Rules cannot run
Fields appear in default state (no modifications)
User may see error message (Global Issue Create only)
How to Handle This
Verify user permissions:
Ensure users have appropriate permissions for their role
Check project permission schemes in Jira Settings
Error message troubleshooting:
If users report seeing the error message, check their permissions
Grant "Create issues" permission if they should be creating issues
Design for permission levels:
Don't rely on Dynamic Screen Rules for security enforcement
Use Jira permissions for actual access control
Use Dynamic Screen Rules for UX improvements (hiding irrelevant fields)
Screen-Specific Limitations
Some actions don't work on certain screens due to API constraints.
Issue View Screen
"Make Field Required" not supported:
API doesn't allow dynamic required validation on Issue View
Use this action only on Global Issue Create or Issue Transition
Empty read-only fields are hidden:
Jira automatically hides empty read-only (locked) fields
If you lock a field with no value, users won't see it at all
This is Jira platform behavior, not Dynamic Screen Rules limitation
See Screen-Specific Limitations for complete details.
Scope Requirements
Limitation: Apps using UI Modifications must declare specific API scopes.
What This Means
Dynamic Screen Rules requires these Jira API scopes to function:
read:jira-work- Read issue data, field valueswrite:jira-work- Modify field values (Set Value action)manage:jira-configuration- Modify field labels, descriptions, visibilitymanage:jira-project- Manage screen tabs, project-level configurationread:jira-user- Access user information (for user-based conditions)
These scopes are required for the app to work. They expose customer data to the app, which is why Atlassian requires explicit scope declarations.
User Privacy and Data Access
Dynamic Screen Rules accesses:
Field values - to evaluate conditions (e.g., "Priority = High")
User information - for user-based conditions (e.g., "User in group Managers")
Project and issue type data - for scope filtering
Field metadata - names, descriptions, visibility settings
Data is not stored or transmitted outside of rule evaluation. Dynamic Screen Rules processes data in real-time to determine field behavior, then discards it.
Known Field Issues
Story Points Field
Issue: Story Points field has known platform bugs affecting modification reliability.
Symptoms:
Rules targeting Story Points may not work consistently
Set Value action may fail to apply
Field visibility changes may not persist
Workaround: Use alternative fields for estimation if Dynamic Screen Rules support is critical. Follow Atlassian issue tracker for updates.
Supported Project Types
Dynamic Screen Rules works with:
Company-managed Jira Software projects ✅
Team-managed Jira Software projects ✅
Company-managed Jira Work Management projects ✅
Team-managed Jira Work Management projects ✅
Company-managed Jira Service Management projects ✅ (with JSM-specific features)
Not supported:
Very old Jira versions (pre-UI Modifications API)
Jira Server/Data Center (cloud-only app)
Entry Point Limitations
Global Issue Create
Supported entry points:
✅ Global Create button (top navigation)
✅
ckeyboard shortcut✅ "Add a child issue" button (from Issue View)
✅ "Create subtask" button (from Issue View)
✅ Custom UI apps using
CreateIssueModal
Important: "Add a child issue" and "Create subtask" only trigger Global Issue Create with UIM if the summary and at least one other field is set as mandatory for the issue type.
Getting Help with Limitations
These are platform limitations - they affect all UI Modifications apps, not just Dynamic Screen Rules.
If you encounter issues:
Check if it's a documented limitation on this page
Contact Dynamic Screen Rules support for configuration advice
Report bugs to Atlassian if you discover platform issues
Vote for improvements:
Atlassian tracks feature requests for the UI Modifications API
Search Jira issue tracker for existing requests
Vote for features you need to increase priority
Related Pages
Screen capabilities:
Screens & Contexts - What works where
Screen-Specific Limitations - Detailed screen constraints
Field support:
Supported Field Types - Which fields are supported
Troubleshooting:
Common Issues - "Rule not working" debugging
Debugging Rules - Troubleshooting strategies
Best practices:
Designing Effective Rules - Work within limitations
Testing Rules - Verify rules work with constraints
This page documents known limitations as of the latest Atlassian UI Modifications API version. Limitations may change as Atlassian enhances the platform.
Last updated