> 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-issue-types.md).

# Hide issue types

Field Rules can control which issue types (work types) a user is offered when creating or transitioning a work item, based on who they are - their group or role - or the value of another field. Hide obsolete work types entirely, or restrict certain ones (like Epic) to specific roles, with no code.

**Supported contexts:** Global Issue Create, Issue Transition. Not supported on Issue View or JSM Request Create.

***

## How to set it up

1. Open the **UI Modification** for the context you want to control (space and view - Global Issue Create or Issue Transition).
2. Add a **Hide issue types** rule.
3. Choose a **Mode**: "Hide selected" hides the work types you list; "Hide all except" shows only the work types you list.
4. Pick the work types under **Options** (at least one is required).
5. *(Optional)* Add **preconditions** - field values and/or user identity - so the restriction only applies when they match. Leave empty to always apply.
6. Save. The work type picker on the screen reflects the rule immediately.

<figure><img src="/files/2PlGvtLyXkl0Nc689IHM" alt="Configuring a Hide issue types rule that hides Epic for everyone except the Developer role"><figcaption><p>Hiding "Epic" for everyone except the Developer role, so only leads and managers can create Epics.</p></figcaption></figure>

| Option            | Description                                                                                      |
| ----------------- | ------------------------------------------------------------------------------------------------ |
| **Mode**          | "Hide selected" hides the chosen types; "Hide all except" shows only the chosen types.           |
| **Options**       | The issue types to hide or allow, depending on the selected mode. At least one must be selected. |
| **Preconditions** | Optional field and/or user conditions. Leave empty to always apply the rule.                     |

***

## How it works

Configure a list of issue types and choose one of two modes:

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

If the currently selected issue type becomes hidden when the rule runs, the selection is automatically switched to the first available visible issue type.

***

## Automatic value switching

When a rule runs and hides the currently selected issue type, the app automatically selects the first visible issue type as a replacement. This prevents the form from being submitted with a hidden issue type.

In **Hide all except** mode, the first issue type from the configured list is selected as the replacement.

In **Hide selected** mode, the first available issue type not in the hidden list is fetched from the space's allowed issue types and selected.

***

## Examples

**Restrict issue types by user group**\
Hide the "Incident" and "Problem" issue types for all users except members of the "ITSM Team" group. Developers and other users will only see standard work types like Task, Bug, and Story.

**Restrict issue types by role**\
On the Create Issue screen, hide "Epic" for users with the "Developer" role. Only project leads and managers can create Epics.

**Hide obsolete issue types**\
Some issue types exist only for historical or audit reasons and should no longer be used for new work items. Hide them with no preconditions so they are never available for selection, while the underlying data remains intact for reporting purposes.

***

## When to use it

Use Hide issue types when the set of work types someone can create should depend on who they are, not just on the space they are working in:

* **Role or group restrictions** - reserve certain work types (Epic, Incident) for the people who should manage them.
* **Retiring work types gradually** - hide an obsolete work type from new selections without deleting it or touching existing data.

If a work type should never be used in a space at all, regardless of user, Jira's own work type scheme already covers that - see [Doing this without Field Rules](#doing-this-without-field-rules).

***

## Doing this without Field Rules

Standard Jira Cloud restricts which work types are available in a space through the space's work type scheme - a static, space-wide allow list. It removes a work type from the space entirely, for every user, on every screen; it cannot hide a work type just for certain users or roles, or only when another field has a particular value, because work type schemes are not user-aware or value-aware.

Conditional, user-aware issue type restrictions require a UI Modifications app like Field Rules or a scripting app.

See [Field Rules vs native Jira](/field-rules/jira-administrator/field-rules-vs-native-jira.md) for the full comparison across every rule.

***

## Supported fields

This rule always targets the Issue Type field. It cannot be applied to other fields - use [Hide field options](/field-rules/rules/hide-field-options.md) for other option-based fields.

***

## Issue View is not supported

The Issue Type field on Issue View cannot have its options controlled via UI Modifications - this is a platform constraint. Once a work item is created, hiding issue type options on the view screen has no effect.

To prevent users from changing the issue type on existing work items, use one of these native Jira approaches instead:

* **Remove the Issue Type field from edit screens** and deny the "Move Issue" project permission.
* **Use a workflow validator** on the Create issue transition to block creation of specific issue types. The Jira Expression Validator from the [Workflow Building Blocks](https://marketplace.atlassian.com/apps/1233642/workflow-building-blocks-for-jira) app is a good option for this. Note this only prevents creation - it does not hide the option from the screen, so users will still see the issue type and only receive an error after submitting.

These approaches can be combined for stronger coverage: use this rule to hide issue types on the screen, and add a workflow validator as a safety net to block creation even if the restriction is bypassed (for example via the API or from a view type not supported by this rule).

***

## Limitations

* **Issue View is not supported.** The `setOptionsVisibility` operation is not available for the Issue Type field on Issue View.
* **JSM Request Create is not supported.**

***

## Related rules

* [Hide field options](/field-rules/rules/hide-field-options.md) - filter the options of other selection fields.
* [Show field](/field-rules/rules/show-field.md) - show or hide a field based on conditions.
* [Make field required](/field-rules/rules/make-field-required.md) - make a field mandatory based on conditions.