Defining Actions

Actions determine what happens to the target field when rule conditions are met. They control field visibility, validation, editability, values, labels, descriptions, and available options.

Formify provides seven actions:

1. Show / Hide Field - Control field visibility
2. Make Field Required - Add conditional validation
3. Lock Field (Read-Only) - Prevent editing
4. Set Field Value - Auto-populate values
5. Change Field Label - Modify field names
6. Change Field Description - Update help text
7. Limit Field Options - Control dropdown options

Each action solves specific problems and has particular use cases where it excels.

---

Choosing the Right Action

Use this quick reference to select the appropriate action:

Goal	Action	Example
Hide irrelevant fields	Show / Hide Field	Hide "Root Cause" for low-priority bugs
Enforce data entry in specific contexts	Make Field Required	Require "Business Justification" when Cost band = Over 10,000
Prevent accidental edits	Lock Field	Lock "Fix Versions" when Status = Done
Auto-fill values	Set Field Value	Set Due Date = 3 business days from today for Bugs
Clarify field meaning	Change Field Label	Change "Description" to "Steps to Reproduce" for Bugs
Provide context-specific guidance	Change Field Description	Add help text explaining SLA expectations
Prevent invalid selections	Limit Field Options	Show only P1/P2 priorities for critical bugs

Decision tree for choosing the right action based on your goal

---

Show / Hide Field

Control field visibility based on conditions: Hide field hides a field while its conditions are met, and Show field shows it.

When to Use

Use Show/Hide Field for:

• Progressive disclosure - Reveal fields only when relevant
• Clean forms - Keep forms simple by hiding unnecessary fields
• Context-aware interfaces - Show fields only in appropriate situations
• Reducing cognitive load - Users see only what they need

How It Works

A rule's action applies only while its conditions are met. When they aren't, the field is shown as Jira shows it, and a field on the screen is visible.

• Hide field hides the field while its conditions are met. To show a field only in some cases, hide it with the opposite conditions: not equals instead of equals, is not empty instead of is empty, is not in group, doesn't have role, doesn't have permission or is not in status instead of their positive forms. Join several opposite conditions with AND: "not equals A" AND "not equals B" instead of "is one of A, B", and "is not in group A" AND "is not in group B" to show the field to members of either group.
• Show field only shows. It never hides the field when its conditions aren't met, so on its own it changes nothing on a field that is already visible. Use it to bring back a field that another rule hides.
• When a condition has no opposite, such as contains or contains any of, add two rules on the field's Visibility tab: a Hide field rule with no conditions, which always applies, and below it a Show field rule with your conditions. Give both rules the same Work type selection: rules on a tab run from top to bottom only among rules with the same work types, so then the Show field rule wins whenever its conditions are met.

Important behaviors:

On Global Issue Create:

• Hidden fields retain values if filled before hiding
• If user fills a field, then conditions change and field hides, the value persists and saves when issue is created
• This prevents data loss during form filling

On Issue View:

• Fields can show/hide during inline editing
• Hidden fields don't display in view mode

On Issue Transition:

• Fields show/hide on transition dialogs based on conditions

Supported Screens

Screen	Supported
Global Issue Create	Yes
Issue View	Yes
Issue Transition	Yes

Configuration

1. Select Action: on the field's Visibility tab, add a rule with Hide field or Show field

2. No additional parameters required

Practical Examples

Example 1: Progressive disclosure

Business need: "Show 'Root Cause' field only for high-priority bugs to reduce form clutter."

Configuration:

• Target field: Root Cause
• Screen: Global Issue Create
• Work type: Bug (rule scope)
• Conditions, joined with AND:
  • Priority not equals High
  • Priority not equals Critical
• Action: Hide field

Result: Root Cause is hidden on Bugs unless the priority is High or Critical, so it appears only when creating high or critical priority bugs.

Why it works: Users working on routine bugs get a clean form. When they select high priority, the form adapts to show Root Cause without them needing to know when it's required.

Example 2: Conditional field visibility

Business need: "Show 'Please Explain' text field when the user selects 'Dissatisfied' in the Satisfaction field."

Configuration:

• Target field: Please Explain
• Screen: Global Issue Create
• Conditions:
  • Satisfaction (select list) not equals Dissatisfied, picked from the field's options
• Action: Hide field

Result: Explanation field appears only when user indicates dissatisfaction. An empty Satisfaction also matches not equals, so Please Explain stays hidden until the user picks Dissatisfied.

Why it works: Satisfied users don't see unnecessary fields. Dissatisfied users automatically get an explanation field without requiring manual navigation.

Example 3: Role-based field visibility

Business need: "Show 'Budget' field only to Finance team members."

Configuration:

• Target field: Budget
• Screen: Issue View
• Conditions:
  • Current user is not in group Finance
• Action: Hide field

Result: Finance team members see Budget field; others don't.

Why it works: Finance sees the field it works with, and everyone else gets a shorter issue view. Hiding a field isn't access control: the value stays readable outside the form, for example in search, list view, bulk edit, the REST API, Automation and the Jira mobile app. If users must not see the data, use Jira permissions or issue security levels.

Good to Know

Native-required fields

If a field is marked as required in Jira's screen configuration, you can't hide it. Hiding required fields creates validation conflicts (users can't submit forms because they can't fill required fields they can't see).

Solution: Remove native required status from the field in screen configuration, then use "Make Field Required" action with conditions instead.

Hidden fields on Issue View

On Issue View, empty hidden fields don't display. If a field is hidden and has no value, it simply doesn't appear—users won't see a blank space.

Field must be on screen

You can only show/hide fields already added to the Jira screen. Add fields through Project Settings → Screens first.

---

Make Field Required

Add conditional validation—make fields required only when specific conditions are met.

When to Use

Use Make Field Required for:

• Context-specific validation - Require data only when needed
• Data quality - Ensure critical information is captured in important scenarios
• Workflow gates - Prevent progression without necessary information
• Flexible forms - Avoid forcing users to fill fields that aren't always relevant

How It Works

When conditions are met, the field displays a red asterisk and becomes required. Users must fill the field before submitting the form.

When conditions are not met, the field is optional.

Important behaviors:

Validation happens client-side:

• Users see the required indicator immediately when conditions are met
• Form won't submit until required fields are filled
• Real-time feedback as users fill the form

Required fields must be visible:

• You can't require a hidden field
• If using Hide field and Make Required together, make sure no Hide field rule applies when you want the field required

Supported Screens

Screen	Supported
Global Issue Create	Yes
Issue View	No (API limitation)
Issue Transition	Yes

warning

API Limitation: The "Make Field Required" action is not supported on Issue View due to Atlassian's UI Modifications API constraints. Use this action only on Global Issue Create or Issue Transition screens.

Configuration

1. Select Action: Make Field Required

2. No additional parameters typically required

3. Ensure field is visible when conditions are met (use Show/Hide action if needed)

Practical Examples

Example 1: High-priority validation

Business need: "Require 'Root Cause' field for high-priority incidents to ensure proper documentation."

Configuration:

• Target field: Root Cause
• Screen: Global Issue Create
• Work type: Incident (rule scope)
• Conditions, joined with OR:
  • Priority equals High
  • Priority equals Critical
• Action: Make Field Required

Result: Root Cause becomes required when creating high or critical priority incidents.

Why it works: Routine incidents stay simple with optional Root Cause. High-priority incidents enforce data quality by requiring root cause analysis.

Example 2: Option-based validation

Business need: "Require 'Business Justification' when the cost is over 10,000."

Configuration:

• Target field: Business Justification
• Screen: Global Issue Create
• Conditions:
  • Cost band (select list) equals Over 10,000
• Action: Make Field Required

Result: Business Justification becomes required when the requester picks the highest cost band.

Why it works: Low-cost items don't need justification documentation, keeping the process lightweight. High-cost items automatically require justification without manual oversight.

Example 3: Transition validation

Business need: "Require 'Test Results' field before transitioning Bug issues to 'Done' status."

Configuration:

• Target field: Test Results (on the Done transition's screen only)
• Screen: Issue Transition
• Work type: Bug (rule scope)
• Conditions: none
• Action: Make Field Required

Result: Test Results becomes required on the transition dialog when moving Bugs to Done.

Why it works: Creates a workflow gate—bugs can't be marked Done without test results. Other transitions don't require this field, maintaining flexible workflow for other cases.

Combining with Show/Hide

Often you'll want to both show AND require a field in the same context. Each rule has one action, so create two rules for the same field:

• Rule 1 (Visibility tab): Hide field when the opposite of conditions X
• Rule 2 (Required tab): Make field required when conditions X

For example, hide Root Cause when Priority not equals High, and require it when Priority equals High.

Best practice: Make the Hide field rule's conditions the exact opposite of the Required rule's. If they overlap, users can't submit because a required field is hidden; if they leave a gap, users see an optional field that should be required.

Good to Know

Native required fields stay required

If a field is marked required in Jira's screen configuration, it's always required. Rules can only ADD required validation, not remove it.

Solution: Remove native required status, then use rules for all required validation.

Required field must be visible

If a field is hidden, making it required creates validation issues. Users can't submit because a required field is hidden.

Solution: Always show fields before requiring them.

info

Related: Field Validation Rules - For more sophisticated validation beyond "has value," see Defining Field Validations. Validation rules support threshold checks (dates, numbers, text length), custom error messages, cross-field consistency, and 15+ validation types—all with real-time feedback as users type.

---

Lock Field (Read-Only)

Make fields read-only to prevent editing. Users can see the field value but can't change it.

When to Use

Use Lock Field for:

• Guard rails - Prevent accidental edits in certain workflow stages
• Status-based protection - Lock fields when issues reach final states
• Role-based restrictions - Prevent edits by users without proper authority
• Audit trail protection - Preserve historical data by locking fields after certain points

How It Works

When conditions are met, the field displays in read-only mode. Users can see the value but can't edit it.

When conditions are not met, the field is editable (unless natively read-only).

Important behaviors:

On Global Issue Create:

• Locked fields can still be set by "Set Field Value" actions
• Users see the pre-filled value but can't change it
• Useful for controlled defaults

On Issue Transition:

• Locked fields appear on transition dialog but can't be changed
• Users can see current value without ability to modify

On Issue View:

• Locked fields show their value, but users can't edit them inline. This covers the full issue page and the side panels opened from the board, backlog, list and search
• The lock follows its conditions live: when the issue status changes, the field locks or unlocks without a page reload
• Jira hides locked fields that have no value
• The lock applies 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 the field

See Locking fields on the Issue View for a complete example.

Supported Screens

Screen	Supported
Global Issue Create	Yes
Issue View	Yes (Jira Software projects)
Issue Transition	Yes

info

Issue View: rules on the Issue View run in Jira Software projects (company-managed and team-managed). Status, Due date, Issue type, Resolution, Target start, Target end and Request type can't be locked on the Issue View, so the Read-only tab doesn't appear for them there. Due date, Target start and Target end can be locked on Global Issue Create only, and Resolution on Issue Transition only; Status, Issue type and Request type can't be locked on any screen. A Read-only rule on Due date in a transition dialog has no effect, although the editor lets you create it.

Configuration

1. Select Action: on the field's Read-only tab, add a rule with Make read-only

2. No additional parameters typically required

Practical Examples

Example 1: Lock auto-filled field during creation

Business need: "Lock 'Assignee' after auto-filling it based on issue type."

Configuration:

• Target field: Assignee
• Screen: Global Issue Create
• Conditions:
  • Issue Type = Backend Bug
• Action: Lock Field

Result: Assignee becomes read-only when creating Backend Bugs (combined with a Set Field Value rule that fills in the backend team lead).

Why it works: Auto-filled values shouldn't be changed. Locking the field prevents users from overriding the pre-selected assignee.

Example 2: Lock field during transition

Business need: "Keep 'Story Points' unchanged in the dialog of the transition to In Review."

Configuration:

• Target field: Story Points (on the In Review transition's screen only)
• Screen: Issue Transition
• Conditions: none
• Action: Lock Field

Result: Story Points is shown but read-only in the In Review transition dialog.

Why it works: The estimate is agreed during planning. Showing it in the dialog gives reviewers context without letting them re-estimate on the way.

Example 3: Role-based locking on transition

Business need: "Lock 'Release Date' during transitions for all users except Release Managers."

Configuration:

• Target field: Release Date
• Screen: Issue Transition
• Conditions:
  • User NOT in role = Release Manager
• Action: Lock Field

Result: Release Date is read-only on transition dialogs for non-Release Managers.

Why it works: Only Release Managers can modify release dates during transitions.

Combining with Set Field Value

Lock Field works well with Set Field Value for controlled auto-population.

Example: "Auto-fill and lock 'Verified By' when transitioning to Verified"

Put Verified By (a user picker field) on the screen of the transition to Verified only. Transition rules run in every transition dialog whose screen shows the field, so no status condition is needed (an Issue status condition would check the status the work item is leaving, not Verified).

Rule 1 - Set value:

• Target field: Verified By
• Screen: Issue Transition
• Conditions: none
• Action: Set Field Value = {{currentUser()}}

Rule 2 - Lock field:

• Target field: Verified By
• Screen: Issue Transition
• Conditions: none
• Action: Lock Field

Result: Verified By fills with the user who makes the transition and becomes read-only.

Good to Know

Which fields lock where

On the Issue View, locking works in Jira Software projects, and some fields can be locked on some screens only. See Field-Specific Limits.

Locked fields can still be set by automation

Locking prevents manual editing on the form but doesn't prevent:

• Jira Automation rules from updating the field
• Formify's own Set value rules from setting a value
• API updates
• Inline editing in list view cells, bulk edit and the Jira mobile app (for Issue View locks)

Lock applies to UI only, not to all update mechanisms. To protect data everywhere, use Jira permissions or workflow properties.

---

Set Field Value

Automatically populate field values based on conditions. Reduce manual work and ensure consistency.

When to Use

Use Set Field Value for:

• Pre-fill defaults - Auto-populate fields based on selections
• Computed values - Calculate dates, copy values from other fields
• Consistency - Ensure standard values are used in specific contexts
• Workflow automation - Auto-fill fields during transitions
• Reduce manual entry - Save users time by filling predictable values

How It Works

When conditions are met, the field value is set to your specified value (static or Smart Value).

Users can typically edit the value unless the field is also locked.

Important behaviors:

On Global Issue Create:

• Value is set when conditions are met
• User can override the value (unless field is locked)
• Value saves when issue is created

On Issue Transition:

• Value is set when transition dialog opens (if conditions met)
• Value saves when transition completes
• Due Date can't be set in a transition dialog: Jira doesn't let apps change Due Date there, so no rule on Due Date can change it in a transition dialog. Set it on Global Issue Create. Don't add a Must not be empty validation on Due Date to a transition either: it always fails there and blocks the transition (the same goes for Components, People, Target start and Target end in a transition, and Original Estimate on Global Issue Create; see the gotchas in Defining Field Validations)

A value the user changes by hand is kept. When the rules run again because another field changed, they don't overwrite it. The rule sets its value again only when its smart-value source field, or a field used in its own conditions, changes. Two cases replace the user's value:

• On Global Issue Create, changing the work type starts the rules over, so a Set Field Value rule that applies to the new work type sets its value again.
• When the rule's smart-value source field or one of its condition fields changes, the field first goes back to the value it had before the rule set it. The rule then sets its value again only if its conditions are still met; otherwise the value from before the rule stays, not the user's.

Supported Screens

Screen	Supported
Global Issue Create	Yes
Issue View	No
Issue Transition	Yes

warning

Formify doesn't offer the "Set Field Value" action on Issue View. Use this action on Global Issue Create or Issue Transition screens.

Configuration

1. Select Action: Set Field Value

2. Choose value type:

• Static value - Fixed text, number, date, user or options
• Smart Value - Computed expression for date, date-time and user fields and Labels (see Using Smart Values)

3. Enter the value:

• For text, URL and number fields: Enter the value
• For Priority, Issue Type, multi-select, checkboxes and cascading select fields: Choose from the field's options
• For date fields: Pick a date, or click Use smart values and enter an expression
• For user fields: Select the user, or click Use smart values and enter an expression

Fields You Can Set

Set Field Value works on these fields:

• System fields: Summary, Description, Issue Type, Priority, Assignee, Reporter, Labels, Due Date
• Custom fields: single-line text, URL, number, date picker, date time picker, user picker, multi user picker, multi-select list, checkboxes and cascading select

Other fields, such as Components, Fix Versions, Resolution, Sprint, Parent, single-choice select lists, radio buttons and paragraph fields, can't be set by Formify. Guide them with Make Field Required or Limit Field Options instead.

Value Types

Static Values

Fixed values that don't change.

Examples:

• Text: "Please contact support for urgent issues"
• Number: 5
• Priority: High
• Multi-select option: "Backend"
• Date: 2026-03-15
• User: John Smith

Smart Values

Computed expressions that calculate values dynamically.

Examples:

• Date calculation: {{today().plusBusinessDays(1)}} - The next business day
• Field reference: {{field("duedate")}} - Copy the Due Date entered on the form
• Current user: {{currentUser()}} - The person filling in the form

Smart Values have no if() or comparisons. To fill in a different value depending on the situation, create one rule per value, each with its own conditions.

See Using Smart Values for detailed Smart Value syntax and examples.

Practical Examples

Example 1: Context-based pre-fill

Business need: "Auto-fill Labels = 'backend' when creating Backend Bug issues."

Configuration:

• Target field: Labels
• Screen: Global Issue Create
• Conditions:
  • Issue Type = Backend Bug
• Action: Set Field Value
• Value: backend (static)

Result: Labels auto-fills with "backend" when creating Backend Bugs.

Why it works: Users don't need to remember to add the label. It's filled automatically based on issue type, ensuring consistency and saving time.

Example 2: Computed date value

Business need: "Set Due Date to the next business day when creating P1 incidents."

Configuration:

• Target field: Due Date
• Screen: Global Issue Create
• Conditions:
  • Priority = Critical
  • Issue Type = Incident
• Action: Set Field Value
• Value: {{today().plusBusinessDays(1)}} (Smart Value)

Result: Due Date auto-fills with the next business day for critical incidents. Set Due Date on Global Issue Create: it can't be set in a transition dialog.

Why it works: Critical incidents have a standard 24-hour SLA. The Smart Value calculates the next business day automatically, ensuring consistent SLA tracking.

Example 3: Transition-based value

Business need: "Set Priority = Highest when a Bug is escalated."

Configuration:

• Target field: Priority (on the Escalate transition's screen only)
• Screen: Issue Transition
• Work type: Bug (rule scope)
• Conditions: none
• Action: Set Field Value
• Value: Highest (static)

Result: Priority switches to Highest in the Escalate transition dialog for Bugs.

Why it works: Escalated bugs almost always need the top priority. Pre-filling saves a step while still allowing a different choice for edge cases.

Example 4: Value based on another field

Business need: "Set 'Review Due' to 3 business days before the Due Date."

Configuration:

• Target field: Review Due (a date picker field)
• Screen: Global Issue Create
• Conditions: none
• Action: Set Field Value
• Value: {{subtractBusinessDays(field("duedate"), 3)}} (Smart Value)

Result: When the user picks a Due Date on the create screen, Review Due fills with the date 3 business days earlier.

Why it works: The review deadline always follows the due date. Both fields must be on the create screen; when Due Date changes, the rule sets Review Due again.

Combining with Lock Field

Set Field Value + Lock Field creates controlled auto-population where users can't override.

Example: "Auto-fill and lock 'Approved Date' on the transition to Approved"

Put Approved Date on the screen of the transition to Approved only, so both rules run in that dialog alone.

Rule 1 - Set value:

• Target field: Approved Date
• Screen: Issue Transition
• Conditions: none
• Action: Set Field Value = {{today()}}

Rule 2 - Lock field:

• Target field: Approved Date
• Screen: Issue Transition
• Conditions: none
• Action: Lock Field

Result: Approved Date fills with today's date and becomes read-only.

Use case: Audit trails where the date must reflect when approval occurred, not when someone manually fills it.

Good to Know

Smart Values that can't be calculated

If an expression has a typo or refers to a field that is not on the screen or is empty, the rule leaves the field unchanged. Test Smart Values on a test project first.

See Using Smart Values for troubleshooting.

Copying between fields

Copy with field() between fields of the same kind: a date into a date field, a user into a user field.

---

Change Field Label

Modify the displayed label (name) of a field based on conditions. Provide context-specific field names.

When to Use

Use Change Field Label for:

• Context-aware naming - Clarify field purpose in different situations
• User guidance - Make field purpose obvious based on context
• Workflow-specific terminology - Adapt field names to workflow stages
• Reduce confusion - Use precise names for different use cases

How It Works

When conditions are met, the field label changes to your specified text.

The field remains the same—only the displayed name changes. The field ID and stored data don't change.

Important behaviors:

Label changes are cosmetic:

• Changes appear only on the UI
• Field data and configuration remain unchanged
• Users see different labels in different contexts

Multiple rules can't conflict:

• If multiple rules try to change the same field's label, last-applied rule wins
• Avoid conflicting label changes for the same field in the same context

Supported Screens

Screen	Supported
Global Issue Create	Yes
Issue View	Yes
Issue Transition	Yes

Configuration

1. Select Action: Change Field Label

2. Enter new label text:

• Plain text (no formatting typically)
• Keep it short and descriptive
• Use consistent terminology

Practical Examples

Example 1: Issue-type-specific labels

Business need: "Change 'Description' field label to 'Steps to Reproduce' for Bug issues."

Configuration:

• Target field: Description
• Screen: Global Issue Create
• Conditions:
  • Issue Type = Bug
• Action: Change Field Label
• New label: Steps to Reproduce

Result: Description field shows as "Steps to Reproduce" when creating Bugs.

Why it works: Bugs need reproduction steps, not just descriptions. The label change guides users to provide the right information without changing the underlying field.

Example 2: Status-based labels

Business need: "Change 'Description' to 'Resolution Details' when Status = Done."

Configuration:

• Target field: Description
• Screen: Issue View
• Conditions:
  • Status = Done
• Action: Change Field Label
• New label: Resolution Details

Result: Description field label changes to "Resolution Details" for Done issues.

Why it works: Fields serve different purposes in different workflow stages. In Done status, Description becomes Resolution Details, clarifying what information belongs there.

Example 3: Priority-based labels

Business need: "Change 'Due Date' to 'SLA Deadline' for Critical priority issues."

Configuration:

• Target field: Due Date
• Screen: Global Issue Create
• Conditions:
  • Priority = Critical
• Action: Change Field Label
• New label: SLA Deadline

Result: Due Date field shows as "SLA Deadline" for Critical priority issues.

Why it works: Critical issues have strict SLA deadlines, not just due dates. The label change emphasizes the urgency and importance.

Good to Know

Keep labels short

Long labels may be truncated or cause layout issues. Keep labels concise and clear.

Maintain consistency

Don't change labels too frequently or unpredictably. Users should understand what each label means in context.

Plain text

The new label is plain text, typed in a single-line box: no bold, colors or other formatting.

---

Change Field Description

Modify the help text (description) shown below the field label. Provide context-specific guidance.

When to Use

Use Change Field Description for:

• Context-specific guidance - Provide relevant instructions based on situation
• User education - Explain what's expected in different contexts
• Policy enforcement - Remind users of rules or requirements
• Reduce support requests - Answer common questions inline

How It Works

When conditions are met, the field description (help text) changes to your specified text.

The field description appears below the field label, providing additional context or instructions.

Important behaviors:

Descriptions support basic formatting (varies by field type):

• Plain text always works
• Some fields support basic HTML or markdown (check platform support)

Multiple rules can't conflict:

• If multiple rules try to change the same field's description, last-applied rule wins

Supported Screens

Screen	Supported
Global Issue Create	Yes
Issue View	Yes
Issue Transition	Yes

Configuration

1. Select Action: Change Field Description

2. Enter new description text:

• Can be longer than labels
• Provide helpful guidance or instructions
• Use basic formatting if supported

Practical Examples

Example 1: Priority-specific guidance

Business need: "Provide SLA guidance for priority field based on issue type."

Configuration:

• Target field: Priority
• Screen: Global Issue Create
• Conditions:
  • Issue Type = Incident
• Action: Change Field Description
• New description: "P1/P2 for production incidents have 4-hour and 24-hour SLAs respectively. Use P3+ for non-urgent issues."

Result: Priority field shows SLA guidance for Incident issues.

Why it works: Users creating incidents see SLA context immediately, helping them choose appropriate priority without consulting documentation.

Example 2: Status-specific instructions

Business need: "Explain what's required before transitioning to Done."

Configuration:

• Target field: Description (on the Done transition's screen only)
• Screen: Issue Transition
• Conditions: none
• Action: Change Field Description
• New description: "Provide final resolution details, including root cause and actions taken."

Result: Description field shows completion guidance on Done transition.

Why it works: Users see exactly what to document before completing the issue, improving data quality at the critical moment.

Example 3: Role-specific help

Business need: "Provide budget guidelines to Finance team when filling budget field."

Configuration:

• Target field: Budget
• Screen: Issue View
• Conditions:
  • User in group = Finance
• Action: Change Field Description
• New description: "Enter approved budget code. Contact finance-ops@company.com for new codes."

Result: Finance team sees budget help text; others don't see the field at all (add a Hide field rule with the condition Current user is not in group Finance).

Why it works: Targeted help text appears only for users who need it, reducing clutter for others.

Good to Know

Description length

Very long descriptions may be truncated or cause layout issues. Keep descriptions focused and concise.

Plain text

The description is plain text, typed in a single-line box: no formatting or line breaks.

Don't replace documentation

Descriptions are helpful hints, not complete documentation. Link to full documentation for complex topics.

---

Limit Field Options

Control which options appear in select fields, multi-select fields, and other option-based fields. Show or hide specific options based on conditions.

When to Use

Use Limit Field Options for:

• Clean dropdowns - Remove irrelevant options
• Prevent invalid selections - Hide options that don't apply
• Context-specific options - Show different options in different situations
• Simplify choices - Reduce cognitive load by limiting options

How It Works

When conditions are met, only the specified options appear in the field's dropdown or option list.

Options not in the "show" list are hidden—users can't select them.

Important behaviors:

Existing values are preserved:

• If a field already has a value that's hidden by the rule, the value persists
• This prevents data loss when rules change option visibility

Field must support options:

• Only works for fields with predefined options (selects, multi-selects, checkboxes, etc.)
• Doesn't apply to free-text fields

Options are picked from a list:

• You select the options from the field's list, so nothing has to be typed or spelled
• The rule keeps the options themselves, not their names, so renaming an option in Jira doesn't break it

Supported Screens

Screen	Supported
Global Issue Create	Yes
Issue View	Yes (Priority and select fields)
Issue Transition	Yes

info

Issue View: Limit Field Options works on Priority and on single select, multi select, radio button and checkbox fields.

Supported Field Types

System fields:

• Priority
• Issue Type
• Fix Versions

Custom fields:

• Single Select
• Multi-Select
• Checkboxes
• Radio Buttons

Configuration

1. Select Action: Limit Field Options

2. Configure option visibility:

• Show only these options: Select which options should be visible
• Hide these options: Select which options should be hidden (alternative approach)

3. Select the options from the available list

Practical Examples

Example 1: Priority limiting for Bugs

Business need: "Show only 'P1' and 'P2' priorities for Bug issues—lower priorities aren't allowed for bugs."

Configuration:

• Target field: Priority
• Screen: Global Issue Create
• Conditions:
  • Issue Type = Bug
• Action: Limit Field Options
• Show options: P1 (Critical), P2 (High)

Result: Only P1 and P2 appear in Priority dropdown for Bugs.

Why it works: Prevents users from creating low-priority bugs. All bugs must be P1 or P2, and limiting options enforces this policy at input time.

Example 2: Status-based closure reasons

Business need: "Offer different closure reasons depending on where the work item is closed from."

The Issue status condition checks the status the work item is leaving, so the rules key on the starting status.

Configuration:

Rule 1 - Closing reviewed work:

• Target field: Closure Reason (select list, on the closing transitions' screens)
• Screen: Issue Transition
• Conditions:
  • Issue status is in status In Review
• Action: Limit Field Options
• Show options: Fixed, Done, Completed

Rule 2 - Closing work that never started:

• Target field: Closure Reason
• Screen: Issue Transition
• Conditions:
  • Issue status is in status To Do
• Action: Limit Field Options
• Show options: Won't Fix, Duplicate, Cannot Reproduce

Result: Closing a reviewed work item offers completion reasons; closing one that was never started offers termination reasons.

Why it works: Different workflow outcomes need different reasons. Limiting options prevents a "Fixed" on work nobody did.

Example 3: Hide obsolete options

Business need: "Hide deprecated module options to prevent selection on new issues."

Configuration:

• Target field: Module (select list)
• Screen: Global Issue Create
• Conditions: (none - always apply)
• Action: Limit Field Options
• Hide options: Legacy Module A, Deprecated Module B

Result: Legacy modules don't appear in the dropdown for new issues.

Why it works: Existing issues keep their legacy module values (visible on view), but users can't select obsolete options for new work. Gradual deprecation without data loss.

Example 4: Context-specific options

Business need: "Show different area options for Frontend vs Backend issue types."

Configuration:

Rule 1 - Frontend areas:

• Target field: Area (multi-select list)
• Screen: Global Issue Create
• Work type: Frontend Bug, Frontend Task (rule scope)
• Action: Limit Field Options
• Show options: UI, API Client, Dashboard, Mobile App

Rule 2 - Backend areas:

• Target field: Area
• Screen: Global Issue Create
• Work type: Backend Bug, Backend Task (rule scope)
• Action: Limit Field Options
• Show options: Database, API Server, Authentication, Queue

Result: Frontend issues see frontend areas; backend issues see backend areas.

Why it works: Users can't accidentally select the wrong area. The form adapts to show relevant options based on issue type, preventing errors and reducing dropdown clutter.

Example 5: Dependent dropdowns

Business need: "Show only the subcategories that belong to the selected category."

Configuration:

Rule 1 - Hardware:

• Target field: Subcategory (select list)
• Screen: Global Issue Create
• Conditions:
  • Category (select list) equals Hardware
• Action: Limit Field Options
• Show options: Laptop, Monitor, Peripherals

Rule 2 - Software:

• Target field: Subcategory
• Screen: Global Issue Create
• Conditions:
  • Category equals Software
• Action: Limit Field Options
• Show options: Installation, License, Bug

Result: Subcategory offers only the options that match the selected Category, and changes as soon as the user picks another Category.

Why it works: Whenever the user changes a field used in a condition, the rules run again, also when that field's own options are limited by another rule. A subcategory picked before Category changed stays selected, so the user should pick again. See Dependent Dropdowns.

Good to Know

Existing values persist

If an issue already has a value that's later hidden, the value remains. Users see the value but can't select it again if they clear it.

Combining multiple Limit Options rules

If multiple rules try to limit the same field's options, the options don't combine: the rule applied last wins. Among rules with the same Work type selection, that's the lower rule on the field's Options tab; between rules with different work type selections, the order isn't guaranteed.

Best practice: Avoid overlapping Limit Options rules for the same field. Use mutually exclusive conditions.

---

Combining Multiple Actions

You can create multiple rules targeting the same field with different actions to achieve complex behaviors.

Common Combinations

1. Hide + Require

Show a field and make it required in the same context.

Example:

• Rule 1: Hide "Root Cause" when Priority not equals High
• Rule 2: Make "Root Cause" required when Priority equals High

Result: Root Cause appears and is required for high-priority issues.

2. Set Value + Lock

Auto-fill a field and prevent editing.

Example:

• Rule 1: Set "Approved Date" = today on the transition to Approved
• Rule 2: Lock "Approved Date" on the transition to Approved

Result: Approved Date fills automatically and can't be changed.

3. Hide + Change Label + Change Description

Show a field with custom label and description in specific context.

Example:

• Rule 1: Hide "Custom Field 1" when Issue Type not equals Bug
• Rule 2: Change label to "Steps to Reproduce" when Issue Type = Bug
• Rule 3: Change description to "Provide detailed reproduction steps" when Issue Type = Bug

Result: Field appears with bug-specific label and help text.

4. Limit Options + Set Value

Limit options and set a default from the limited set.

Example:

• Rule 1: Limit Priority to [P1, P2] when Issue Type = Production Bug
• Rule 2: Set Priority = P1 when Issue Type = Production Bug

Result: Priority dropdown shows only P1/P2, with P1 pre-selected.

Best Practices for Multiple Actions

Use consistent conditions

If combining actions for the same field, use identical conditions to ensure actions apply together.

Test interactions

Verify that multiple actions work together as expected. Some combinations may have unexpected results.

Keep it simple

Don't over-engineer. Use multiple actions only when necessary for your business requirements.

---

Action Support Matrix

Quick reference for which actions work on which screens:

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

info

Make Field Required doesn't work on Issue View because Atlassian's UI Modifications API doesn't support it there. Set Field Value is a Formify choice: the app offers it only on Global Issue Create and Issue Transition. Rules on Due Date work on Global Issue Create only: Jira doesn't let apps change Due Date in a transition dialog or on the Issue View, so any rule on it there (show, hide, required, lock, label, description, value) has no effect, although the editor lets you create it. The exception is a Must not be empty validation on Due Date in a transition dialog: it always fails and blocks the transition, even when Due Date is filled, so don't add one. The same blocking applies to Components, People, Target start and Target end in a transition dialog and to Original Estimate on Global Issue Create (see the gotchas in Defining Field Validations). On Issue View, Limit Field Options covers Priority and select fields, and rules run in Jira Software projects only.

---

Next Steps

Now that you understand all available actions:

Learn advanced techniques:

• Using Smart Values - Computed values and dynamic expressions for Set Field Value

See actions in practice:

• Progressive Disclosure - Show/Hide examples
• Dynamic Required Fields - Make Required examples
• Field Locking on Transitions - Lock Field examples
• Pre-fill Values - Set Field Value examples
• Clean Dropdowns - Limit Options examples

Manage your rules:

• Managing Rules - Organize, enable, disable, and edit rules

Understand field support:

• Supported Fields per Screen - Detailed field compatibility matrix
• Screen-Specific Limitations - Known limitations and workarounds

Ready to learn about computed values? Continue to Using Smart Values.