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
- Press
con the keyboard - Click Add a child issue or Create subtask on the Issue View. Jira opens this dialog from these buttons only when Summary and at least one other field are required for the issue type; otherwise rules don't run
- Create an issue from another app that opens Jira's create dialog
Inline create doesn't run rules. Issues created inline, by typing a summary straight into a row on the board, backlog or list view, skip this dialog. Create rules don't apply to them, so fields your rules show, require or pre-fill are not enforced there. Use the Create button or c when an issue must go through your Create rules.
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: Hide fields until they become relevant (e.g., "Hide Root Cause when Priority not equals High")
Pre-fill values: Auto-populate fields based on selections (e.g., "Set Labels = backend when Issue Type = Backend Bug")
Dynamic required fields: Require fields only in specific contexts (e.g., "Require Business Justification when the Cost Band select list = Over 10,000")
Clean dropdowns: Limit options to prevent invalid selections (e.g., "Show only P1/P2 priorities for Bugs")
Important Behaviors
Hidden fields retain values
If a user fills in a field and a rule then hides it because the conditions changed, 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). Make sure no Hide field rule hides the field under the conditions where another rule requires it.
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
Most actions are supported on Issue View:
- Show / Hide Field
- Change Field Label
- Change Field Description
- Lock Field (Read-Only)
- Limit Field Options (Priority and select fields)
Not available on Issue View: Make Field Required (Atlassian's UI Modifications API doesn't support it there) and Set Field Value (Formify offers it only on Global Issue Create and Issue Transition). Limit Field Options works on Priority and on single select, multi select, radio button and checkbox fields. Issue View rules run in Jira Software projects (company-managed and team-managed).
Best Use Cases
Role-based visibility: Hide fields that only some users need (e.g., "Hide Budget when the current user is not in group Finance Team"). Hiding tidies the page; it doesn't protect the data, which stays readable in search, list views, the REST API and the mobile app. Data that some users must not see needs Jira permissions or issue security levels.
Status-based locking: Keep fields visible but stop inline edits once work is done (e.g., "Lock Fix Versions when Status = Closed for everyone outside the release team")
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 the Root Cause 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)
Jira Software projects only
Issue View rules run in Jira Software projects, company-managed and team-managed. In other project types, rules on the Issue View tab have no effect.
Locks follow their conditions live
When the issue status changes on Issue View, a locked field becomes editable again (or a field becomes locked) without a page reload.
Some fields can't be locked
Status, Due date, Issue type, Resolution, Target start, Target end and Request type can't be locked on Issue View, so the Read-only tab doesn't appear for them there.
Some fields can't be hidden, renamed or given new help text
On Issue View, Summary and Status can't be hidden or renamed, and the help text of Description and Priority can't be changed. Where the editor still offers these rules, they have no effect there.
Due date rules work on Create only
Jira doesn't let apps change Due date on Issue View or in a transition dialog. Rules on Due date there have no effect, although the editor lets you create them. The one exception is a Must not be empty validation on Due date in a transition dialog: Formify can't read Due date there, so the validation always fails and blocks the transition, even when Due date is filled. Don't add one to the Transition tab.
Locks apply to the issue page only
Inline editing in list view cells, bulk edit, the REST API, Automation and the Jira mobile app can still change a locked field. Use Jira permissions or workflow properties if the data must be protected everywhere.
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.
Conditions can still check an option field (select list, radio buttons, multi-select list, checkboxes) that isn't on the screen: the condition editor lists it under Other fields, and the condition reads the value saved on the issue.
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: Hide fields that don't apply to the status the work item is leaving (e.g., "Hide Rollback Plan when the work item is not in status Deployed")
Pre-fill transition fields: Auto-populate fields during transitions (e.g., "Set Verified By = current user on the transition to Verified")
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
Due date can't be changed in transition dialogs
Rules on Due date on the Transition tab have no effect, although the editor lets you create them, with one exception: a Must not be empty validation on Due date always fails there, even when Due date is filled, and blocks the transition. Don't add one. Due date rules work on Global Issue Create only.
Company-managed Jira Software projects only
Transition rules run in company-managed Jira Software projects. Team-managed projects have no Transition tab, and in other project types rules on the Transition tab have no effect.
Status conditions read the status the work item is leaving
A rule on the Transition tab runs in the dialog of every transition whose screen shows the field. Its Issue status condition checks the status the work item is in when the dialog opens: the status it is leaving, not the one it is moving to. To target one transition, keep the field on that transition's screen only.
Example:
- Goal: "Require 'Release Notes' on the transition to Ready for Release"
- Put Release Notes on the "Ready for Release" transition's screen only, and make it required with a rule on the Transition tab
- A condition "Issue is in status Ready for Release" would do the opposite: it applies to transitions out of Ready for Release
Option fields not on the transition screen hold their saved value
A condition can check an option field (select list, radio buttons, multi-select list, checkboxes) that isn't on the transition screen; the condition editor lists it under Other fields. Such a condition reads the value saved on the issue, which is the value from before the transition, and it doesn't change while the user fills in the dialog. A field that is on the transition screen gives the value the user is choosing in the dialog.
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 |
| Stop inline edits after a status change | Issue View |
| Hide fields that certain users don't need | Issue View |
| Change field labels contextually | Issue View |
| Require field before specific transition | Issue Transition |
| Pre-fill a sign-off date when closing | Issue Transition |
| Show transition-specific fields | Issue Transition |
Screen Limitations Summary
| Action | Global Issue Create | Issue View | Issue Transition |
|---|---|---|---|
| Show / Hide Field | Yes | Yes | Yes |
| Make Field Required | Yes | No | Yes |
| Lock Field | Yes | Yes | Yes |
| Set Field Value | Yes | No | Yes |
| Change Field Label | Yes | Yes | Yes |
| Change Field Description | Yes | Yes | Yes |
| Limit Field Options | Yes | Yes | Yes |
Make Field Required on Issue View is an Atlassian API limit that affects any app. Set Field Value on Issue View is a Formify choice. Issue View rules run in Jira Software projects; Issue Transition rules run in company-managed Jira Software projects.
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.