> 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/about-field-rules-ui-modifications-for-jira.md).

# About Field Rules - UI Modifications for Jira

Make your Jira issue forms smarter. [Field Rules](https://marketplace.atlassian.com/apps/1235577/field-rules-ui-modifications-for-jira?hosting=cloud\&tab=overview) lets you control how fields behave on issue screens - showing and hiding them based on context, pre-filling values, restricting options, and enforcing requirements - all without writing code or modifying workflows. Works on standard Jira screens and the Create Request form on Jira Service Management customer portals.

## The problem it solves

Jira's built-in field configuration applies globally. You can mark a field as required, but only for every project and issue type that shares that field context. You can add a field to a screen, but it shows for everyone in every situation.

Real teams work differently. A "Steps to reproduce" field matters for bugs, not for tasks. A rejection reason should be mandatory only when closing with "Won't Fix". Priority options that are available to all users may not make sense for users without the right role.

Field Rules closes this gap. You define conditions - based on what is in other fields, who the user is, or what project and issue type they are working in - and the app adjusts the screen in real time as users fill in the form.

## What you can do

**Show only what is relevant**

Hide fields that do not apply to the current situation. Keep forms clean by surfacing the right fields at the right time. Jira lets you assign different screens per issue type, but that requires duplicating and maintaining separate screen configurations. Field Rules keeps a single screen and adjusts it dynamically - fields appear or disappear based on what the user is doing, in real time.

**Enforce data quality when it matters**

Make fields required only in the situations where they are meaningful. Require a root cause explanation when an issue is confirmed as a defect. Require a rejection reason when a transition closes an issue as "Won't Fix". Context-aware requirements make data quality a natural part of the workflow, not an obstacle.

**Pre-fill and automate values**

Save users from repetitive selections and reduce errors from manual entry. Pre-fill the component for a project that maps to a single team. Automatically set the resolution on a close transition. Chain pre-fills so that choosing a category automatically sets the sub-category and assignee.

**Restrict options and access**

Hide issue types that should no longer be created. Filter dropdown options so only valid choices appear. Lock fields that should be managed automatically. Restrict who can set certain priority levels or change certain fields.

**Work across all Jira screens**

A single configuration can cover the create issue dialog, the issue view, workflow transition screens, and the JSM Create Request form - all at once. Rules that do not apply to a specific screen are skipped automatically. No scripting, no developer involvement, no Jira admin expertise beyond what you already have.

## How it works

You create a **UI Modification (UIM)** for each context you want to control. A UIM defines:

* **Where** it applies - which projects, issue types, and view type
* **What happens** - an ordered sequence of rules that run when a user opens a matching screen

Rules within a UIM run in sequence. Each rule sees the current state of the form, including values set by earlier rules in the same UIM. This lets you build logic that chains: pre-fill a field, then use its new value as a condition for the next rule, then show a third field based on what the second rule produced.

Multiple UIMs that match the same context run in parallel - useful for separating concerns managed by different teams or configurations.

<figure><img src="/files/V1TXFK7yLUvDQlRNkj5d" alt=""><figcaption><p>Example 1: Different UI modifications for different contexts, utilizing selected rules that modify specific fields.</p></figcaption></figure>

## Supported views

| View                    | What it covers                                                       |
| ----------------------- | -------------------------------------------------------------------- |
| **Global Issue Create** | The create issue dialog, available across all projects               |
| **Issue View**          | The issue detail page where users read and edit existing issues      |
| **Issue Transition**    | Screens shown when moving an issue through workflow statuses         |
| **JSM Request Create**  | The customer-facing request form on a Jira Service Management portal |

## Available rules

| Rule                            | What it does                                                               |
| ------------------------------- | -------------------------------------------------------------------------- |
| **Show field**                  | Show or hide a field based on field or user conditions                     |
| **Make field required**         | Mark an optional field as required when conditions are met                 |
| **Pre-fill field**              | Set a field's value when the screen loads, before the user interacts       |
| **Change field value**          | Update a field automatically when the user changes another field           |
| **Lock field**                  | Make a field read-only for specific users or situations                    |
| **Hide field options**          | Filter the available options in a dropdown or selection field              |
| **Hide issue types**            | Control which issue types are available on the create or transition screen |
| **Enable self-assignment only** | Restrict the Assignee field so users can only assign issues to themselves  |
| **Use description**             | Override a field's hint text based on conditions                           |

Every rule supports optional **preconditions** - conditions based on field values or the current user's identity that determine when the rule applies.

## What teams use it for

**Keep forms clean**

Bug reports need "Steps to reproduce" and "Severity". Tasks and stories don't. Show fields only when they apply - the create form stays uncluttered for most users without maintaining separate screens per issue type.

**Enforce data quality at the right moment**

An issue closed as "Won't Fix" without a rejection reason is a dead end. Make the "Rejection reason" field required only on that transition - mandatory where it matters, invisible everywhere else.

**Control who changes what**

Developers keep touching "Fix Version" even though releases are owned by the release team. Lock the field for the Developer role, set a hint explaining why, and the problem is gone - no workflow changes, no permission schemes.

**Forms that react as users fill them in**

When a user picks a component, the assignee should update to the right person automatically. Change field value rules update fields in real time based on what the user selects - less manual work, fewer wrong entries.

{% hint style="success" %}
**Now on JSM customer portals**\
Field Rules now works on the Create Request form on Jira Service Management portals - the most requested addition to the app. The same rules that control fields on standard Jira screens work on the portal: show and hide fields, enforce requirements, pre-fill values. Scoped to specific portals and request types, with no extra configuration needed.
{% endhint %}

## Runs on Atlassian

Field Rules carries the **Runs on Atlassian** badge on the [Atlassian Marketplace](https://marketplace.atlassian.com/apps/1235577/field-rules-ui-modifications-for-jira?hosting=cloud\&tab=overview). The program identifies Forge apps that meet strict data privacy requirements - giving customers a clear signal before they install.

* **No external data egress.** The app uses exclusively Atlassian-hosted compute and storage. Your data never leaves Atlassian's infrastructure.
* **Data residency alignment.** Data stays in the same region as your Jira instance, respecting the data residency settings of your Atlassian product automatically.
* **Customer-controlled egress.** Any external data egress - such as analytics or logs - can be controlled or fully blocked by your administrators at any time.

## Getting started

See the [Setup guide](/field-rules/jira-administrator/setup-guide.md) to install the app and create your first UI Modification.

To understand how conditions work, see [Conditions](/field-rules/jira-administrator/conditions.md).

For a reference of which fields are supported on each view, see [Supported fields per view](/field-rules/jira-administrator/supported-fields-per-view.md).