> For the complete documentation index, see [llms.txt](https://docs.forgappify.com/field-rules/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.forgappify.com/field-rules/rules/hide-field-options.md).

# Hide field options

Field Rules can filter the options shown in a Jira dropdown or selection field based on conditions - hiding some choices or allowing only a specific set. Restrict the available options by the current user, their group or role, the work type or request type, or the value of another field, so users only ever pick from valid choices. It works on standard Jira screens and JSM portals, with no code.

**Supported contexts:** Global Issue Create, Issue View, Issue Transition, JSM Request Create.

***

## How to set it up

1. Open the **UI Modification** for the context you want to control (space, work type, and view).
2. Add a **Hide field options** rule and choose the field under **Field name**.
3. Choose a **Mode**: "Hide selected" hides the options you list; "Hide all except" shows only the options you list.
4. Pick the **Options** to hide or allow (up to 100).
5. *(Optional)* Add **preconditions** - field values and/or user identity - so the filtering only applies when they match. Leave empty to always apply.
6. Save. When the rule runs, the field's option list is filtered accordingly.

<figure><img src="/files/SiOfLaxjMnnJcyKCfJ8P" alt="Configuring a Hide field options rule on a JSM portal that shows only Website, Mobile app, and API in the Affected area field for the Report a bug request type"><figcaption><p>Showing only the relevant "Affected area" options for the "Report a bug" request type on a JSM portal.</p></figcaption></figure>

| Option            | Description                                                                                |
| ----------------- | ------------------------------------------------------------------------------------------ |
| **Field name**    | The field whose options will be controlled.                                                |
| **Mode**          | "Hide selected" hides the chosen options; "Hide all except" shows only the chosen options. |
| **Options**       | The options to hide or allow. Up to 100 options can be selected.                           |
| **Preconditions** | Optional field and/or user conditions. Leave empty to always apply the rule.               |

***

## How it works

Configure a list of options and choose one of two modes:

* **Hide selected** - the listed options are hidden, all others remain visible.
* **Hide all except** - only the listed options are visible, all others are hidden.

When the rule runs and the currently selected value becomes hidden, the selection is automatically cleared. This behaviour applies on Global Issue Create, Issue Transition, and JSM Request Create. On Issue View, the selected value is not changed - only the visible options are updated.

***

## Value clearing when options are hidden

When the rule hides the currently selected value, the behaviour depends on the field type and view:

When the selected value becomes hidden, it is cleared from the field. For multi-value fields, only the hidden selections are removed. Priority is an exception - it cannot be cleared, so it is switched to the first available visible option instead.

This only applies on **Global Issue Create**, **Issue Transition**, and **JSM Request Create**. On **Issue View**, the saved value is never modified.

***

## 100 options limit

On Issue View and Issue Transition, the number of options passed to `setOptionsVisibility` cannot exceed 100 per update. The option picker in the admin form enforces this limit - additional selections are disabled once 100 options are chosen.

***

## Examples

**Filter options by request type on the JSM portal**\
On a Jira Service Management portal, show only the relevant "Affected area" options for each request type. Use Mode "Hide all except", list the areas that apply (for example Website, Mobile app, API), and add a precondition on Request Type. Add one rule per request type in the same UIM to branch the option list - Request Type is available as a condition only on JSM Request Create.

**Filter resolutions by work type**\
On the Issue Transition screen, show only "Fixed" and "Cannot reproduce" resolutions when the Issue Type is "Bug". For other work types, show the full resolution list.

**Restrict priority options by role**\
Hide "Critical" and "Blocker" priorities for users with the "Developer" role. Only team leads and above can set those priority levels.

**Dynamic checkbox filtering**\
When a "Confirmed" checkbox option is selected, hide the "Needs investigation" option. This prevents contradictory selections in the same checkbox field.

**Limit fix versions on transition**\
On a "Release" transition screen, show only the current active fix version and hide all past versions. This prevents accidentally stamping a resolved work item with an old version.

***

## When to use it

Use Hide field options to keep dropdowns free of invalid or irrelevant choices:

* **By role or group** - hide high-impact options (such as Critical or Blocker priority) from users who should not set them.
* **By work type** - show only the resolutions or versions that make sense for the current work type.
* **By another field's value** - narrow one field's options based on an earlier selection, for dependent dropdowns.

Use "Hide all except" when it is easier to list what should remain; use "Hide selected" when you only need to remove a few options.

***

## Doing this without Field Rules

Standard Jira Cloud controls a field's available options through field contexts. A context can scope options to specific spaces or work types, but it applies to all users in that scope and cannot vary the options by who the user is or by the value of another field on the screen - field contexts are not user-aware or value-aware.

Even getting work-type-specific option sets this way means creating a separate context for each and maintaining an almost identical option list in every one. A single change to a shared option then has to be repeated across every context, and the lists drift out of sync over time. Field Rules filters one shared option list with conditions instead, so there is no context to duplicate and nothing to keep in sync.

Filtering options dynamically by user, role, or another field's value requires a UI Modifications app like Field Rules or a scripting app. Field Rules does it through a visual interface, with no code and no workflow changes.

***

## Supported fields

| Field type       | Global Issue Create | Issue View | Issue Transition | JSM Request Create |
| ---------------- | ------------------- | ---------- | ---------------- | ------------------ |
| Checkboxes       | Yes                 | Yes        | Yes              | No                 |
| Single select    | Yes                 | Yes        | Yes              | Yes                |
| Multi select     | Yes                 | Yes        | Yes              | Yes                |
| Radio buttons    | Yes                 | Yes        | Yes              | No                 |
| Priority         | Yes                 | Yes        | Yes              | Yes                |
| Affects versions | No                  | No         | Yes              | No                 |
| Fix versions     | No                  | No         | Yes              | No                 |
| Parent           | No                  | No         | Yes              | No                 |
| Resolution       | No                  | No         | Yes              | No                 |

To control Issue Type options, use the dedicated [Hide issue types](/field-rules/rules/hide-issue-types.md) rule.

***

## Limitations

* **Affects versions, Fix versions, Parent, and Resolution** are only supported on Issue Transition.
* **Issue Type** is not available in this rule - use [Hide issue types](/field-rules/rules/hide-issue-types.md) instead.
* **100 options maximum** per update on Issue View and Issue Transition.
* **Value clearing on Issue View is not supported.** The currently saved value is never automatically changed when options are hidden on Issue View.
* **JSM Request Create** only supports single select, multi select, and priority for option visibility control.

***

## Related rules

* [Hide issue types](/field-rules/rules/hide-issue-types.md) - control which issue types are available on Create and Transition screens.
* [Change field value](/field-rules/rules/change-field-value.md) - set a field's value when another field changes; pairs with option filtering for dependent dropdowns.
* [Show field](/field-rules/rules/show-field.md) - show or hide the whole field rather than individual options.
* [Lock field](/field-rules/rules/lock-field.md) - make a field read-only.