Screens & Contexts
Rules apply to specific locations in Jira where users interact with fields. These locations are called screens. Each screen has different capabilities and use cases based on how Jira's UI Modifications API works.
Understanding which screen to use helps you apply rules in the right context and work within platform limitations.
The Three Screens
Formify works on three screens:
- Global Issue Create - The create issue dialog
- Issue View - The issue detail page (inline and full page edit)
- Issue Transition - Status transition dialogs
Each screen supports different actions and has specific use cases where it works best.
Global Issue Create
The create issue dialog that appears when users create new issues.
When Users See This Screen
- Click Create button in top navigation
- Use quick create shortcut
- Create issue from backlog or board
Supported Actions
All actions are supported on Global Issue Create:
- Show / Hide Field
- Make Field Required
- Lock Field (Read-Only)
- Set Field Value
- Change Field Label
- Change Field Description
- Limit Field Options
This is the most flexible screen with full action support.
Best Use Cases
Progressive disclosure: Show fields only when relevant (e.g., "Show Root Cause when Priority = High")
Pre-fill values: Auto-populate fields based on selections (e.g., "Set Component = Backend when Issue Type = Backend Bug")
Dynamic required fields: Require fields only in specific contexts (e.g., "Require Business Justification when Cost > $10k")
Clean dropdowns: Limit options to prevent invalid selections (e.g., "Show only P1/P2 priorities for Bugs")
Important Behaviors
Hidden fields retain values
If you show a field, user fills it, then conditions change and field hides, the value is still saved when the issue is created. The field was filled, so the value persists even though it's no longer visible.
Required fields must be visible
You can't require a field that's hidden. If a required field is hidden by another rule, users can't submit the form (they can't fill a required field they can't see). Ensure your required field rules also show the field.
Issue View
The issue detail page where users view and edit existing issues.
When Users See This Screen
- Open any issue to view details
- Edit fields inline (click field to edit)
- Edit in full-page view
Supported Actions
Only visual actions are supported on Issue View:
- Show / Hide Field ✅
- Change Field Label ✅
- Change Field Description ✅
- Make Field Required ❌ (API limitation)
- Lock Field (Read-Only) ❌ (API limitation)
- Set Field Value ❌ (API limitation)
- Limit Field Options ❌ (API limitation)
API Limitation: On Issue View, only visibility and display actions (Show/Hide, Label, Description) are supported due to Atlassian's UI Modifications API constraints. Actions that modify field behavior or values (Required, Lock, Set Value, Limit Options) work only on Global Issue Create or Issue Transition screens.
Best Use Cases
Role-based visibility: Show sensitive fields only to authorized users (e.g., "Show Budget only to Finance group")
Context-aware labels: Adapt field names to the situation (e.g., "Change Description to Resolution Details when Status = Done")
Dynamic help text: Provide context-specific guidance (e.g., "Change Description help text based on Status")
Important Behaviors
Empty read-only fields are hidden
Jira automatically hides empty read-only fields on Issue View. If you lock a field that has no value, users won't see it at all. This is Jira platform behavior, not a Formify limitation.
Example:
- Field "Approval Comments" is empty
- Rule locks the field when Status = Approved
- Result: Field disappears from view (hidden because it's empty and read-only)
Fields must be on the screen
Rules only work for fields already added to the Edit screen in Jira's screen configuration. If a field isn't on the screen, rules can't show or modify it.
Issue Transition
Status transition dialogs that appear when moving issues between workflow states.
When Users See This Screen
- User clicks workflow transition button (e.g., "Start Progress", "Done", "Close")
- Transition dialog appears with fields configured for that transition
Supported Actions
Most actions are supported on Issue Transition:
- Show / Hide Field ✅
- Make Field Required ✅
- Lock Field (Read-Only) ✅
- Set Field Value ✅
- Change Field Label ✅
- Change Field Description ✅
- Limit Field Options ✅
Field availability depends on your workflow's transition screen configuration. Only fields added to the transition screen in Jira's workflow settings can be affected by rules.
Best Use Cases
Transition-specific validation: Require fields only for specific transitions (e.g., "Require Root Cause when transitioning to Done on Incidents")
Status-based visibility: Show fields relevant to the transition (e.g., "Show Resolution when transitioning to Done/Closed")
Pre-fill transition fields: Auto-populate fields during transitions (e.g., "Set Resolution = Fixed when Bug → Done")
Workflow gate validation: Ensure data completeness before progression (e.g., "Require Test Results when → Ready for Release")
Important Behaviors
Transition screens control field availability
Rules can only affect fields that are already on the transition screen. If your workflow's transition screen doesn't include a field, rules can't show or modify it.
Check your workflow configuration: Project Settings → Workflows → Edit workflow → Select transition → View screen
Rules evaluate for the target status
When creating a rule with a Status condition on the Transition screen, the rule evaluates against the target status (where the issue is going), not the current status (where it's coming from).
Example:
- Rule: "Require 'Release Notes' when Status = Ready for Release"
- Applies to: Transition that moves issue TO "Ready for Release"
- Does not apply to: Transitions FROM "Ready for Release" to other statuses
Choosing the Right Screen
Use this guide to select the appropriate screen for your rule.
| Goal | Best Screen |
|---|---|
| Show fields conditionally during creation | Global Issue Create |
| Require field before creating issue | Global Issue Create |
| Pre-fill values during creation | Global Issue Create |
| Lock field based on status | Issue Transition |
| Hide sensitive fields from certain users | Issue View |
| Change field labels contextually | Issue View |
| Require field before specific transition | Issue Transition |
| Pre-fill resolution when closing | Issue Transition |
| Show transition-specific fields | Issue Transition |
Screen Limitations Summary
| Action | Global Issue Create | Issue View | Issue Transition |
|---|---|---|---|
| Show / Hide Field | ✅ | ✅ | ✅ |
| Make Field Required | ✅ | ❌ | ✅ |
| Lock Field | ✅ | ❌ | ✅ |
| Set Field Value | ✅ | ❌ | ✅ |
| Change Field Label | ✅ | ✅ | ✅ |
| Change Field Description | ✅ | ✅ | ✅ |
| Limit Field Options | ✅ | ❌ | ✅ |
These limitations come from Atlassian's UI Modifications API, not Formify. All limitations are platform-level constraints that affect any app using the API.
Next Steps
Now that you understand screens:
Learn about condition types:
- Condition Types - Field-based, context-based, and user-based conditions explained
Start configuring:
- Creating Your First Rule - Step-by-step rule creation
- Defining Actions - Detailed action reference
See practical examples:
- Progressive Disclosure - Show fields conditionally
- Field Locking on Transitions - Lock fields based on workflow
Ready to learn about conditions? Continue to Condition Types.