> 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 Hide fields, make them read-only or required, and pre-fill values by condition. Set rules once, run them across spaces in Jira and JSM. No scripting. [Field Rules](https://marketplace.atlassian.com/apps/1235577/field-rules-ui-modifications-for-jira?hosting=cloud\&tab=overview) lets Jira admins hide fields, make them read-only or required, and pre-fill values based on conditions, from one place and with no scripting required. Create a rule once, choose where it runs, and it applies across spaces, work types and views in Jira and Jira Service Management, in both company-managed and team-managed spaces. Screens adjust in real time as users fill them in. Rules run on standard Jira screens (work items), on the agent views of service projects, and on the Create Request screen of Jira Service Management customer portals. See [Where rules run](#where-rules-run) for the exact support per space type. ## Why teams use Field Rules * **Consistent data.** Fields are required only when they matter, values are pre-filled, and only valid options are offered, so the data you report on is cleaner. * **Shorter, relevant screens.** Each team sees only the fields that apply to the work they are doing. * **Less to maintain.** One set of rules replaces duplicated screens, field contexts and custom fields, so there is less configuration to keep in sync. * **Configured in the admin UI.** No scripting required and no developer involved. ## Set rules once, run them everywhere A **UI Modification (UIM)** is a set of rules plus the places where it runs. One UIM can cover many spaces, work types and views at once, so you configure the logic once instead of repeating it in every space. * One set of rules across company-managed and team-managed spaces. * One set of rules across Jira and Jira Service Management, including agent views and the customer portal. * One place to review and change: enable, disable or reconfigure a UIM without touching screens, field configurations or field contexts. * Rules that do not apply to a specific view are skipped automatically. ## Replace workarounds with one rule * **Show and hide fields dynamically instead of duplicating screens.** Keep one screen and let rules decide which fields appear for each work type, user or situation. * **Require a field by condition, or only on a specific transition, instead of stacking workflow validators.** The field shows as required on the screen, so users see what is expected. * **Hide options instead of duplicating field contexts.** Offer only the options that apply, based on field values, work type or user. * **Change a field's name and description instead of duplicating custom fields.** Reuse one field for several purposes, and relabel and explain it in context. ## What you can do ### Hide fields and show only what is relevant Hide fields that do not apply to the current situation and surface the right fields at the right time. A "Steps to reproduce" field can appear for bugs and stay out of the way for tasks. Fields appear or disappear based on what the user is doing, in real time, on a single screen. ### Make a field required conditionally Make fields required only in the situations where they are meaningful. Require a root cause explanation when a work item is confirmed as a defect. Require a rejection reason only on the transition that closes a work item as "Won't Fix". Context-aware requirements make data quality a natural part of the workflow, not an obstacle. ### Make fields read-only Lock fields that should be managed automatically or by a specific team, on screens, on transitions and on the JSM customer portal. Read-only support depends on the field type, see [Supported fields per view](/field-rules/jira-administrator/supported-fields-per-view.md). ### Pre-fill values, including system fields Save users from repetitive selections and reduce errors from manual entry. Pre-fill the component for a space that maps to a single team, set a default priority, or automatically set the resolution on a close transition. Chain pre-fills so that choosing a category automatically sets the sub-category and assignee. ### Filter options and hide obsolete work types Filter dropdown options so only valid choices appear. Hide work types that should no longer be created on the create and transition screens. Restrict who can set certain priority levels or change certain fields. ### Rename and explain fields in context Change a field's name and description based on conditions, so the same field can read differently for different work types, teams or request types. ### React to the user and the transition Rules react to field values, work type, user, group, space role or the transition being performed. Screens update as the user changes a value. See [Conditions](/field-rules/jira-administrator/conditions.md). ## How it works You create a **UI Modification (UIM)** for each context you want to control. A UIM defines: * **Where** it applies - which spaces, work 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 screen, 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.

Example 1: Different UI modifications for different contexts, utilizing selected rules that modify specific fields.

## Where rules run | View | What it covers | Where it runs | | ------------------------------------ | ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | **Global Issue Create** | The create dialog for work items | Company-managed and team-managed Jira Software and Jira Work Management | | **Issue View** | The work item detail page where users read and edit work items | Company-managed and team-managed Jira Software | | **Issue Transition** | Screens shown when moving a work item through workflow statuses | Company-managed Jira Software | | **JSM Request Create** | The customer-facing request screen on a Jira Service Management portal | Company-managed and team-managed Jira Service Management | | **Global Issue Create (Agent view)** | The create dialog opened by an agent from inside a service project | Company-managed and team-managed Jira Service Management | | **Issue View (Agent view)** | The work item detail page an agent sees when working a request inside a service project | Company-managed and team-managed Jira Service Management | | **Issue Transition (Agent view)** | Screens shown when an agent moves a request through workflow statuses inside a service project | Company-managed and team-managed Jira Service Management | Entry points and platform constraints are listed on the [Limitations](/field-rules/jira-administrator/limitations.md) page. ## 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 work types are available on the create or transition screen | | **Enable self-assignment only** | Restrict the Assignee field so users can only assign work items to themselves | | **Use description** | Override a field's hint text based on conditions | | **Use name** | Change a field's label based on conditions | Every rule supports optional **preconditions** - conditions based on field values, the current user's identity, or the transition being performed that determine when the rule applies. ## What teams use it for **Keep screens clean** Bug reports need "Steps to reproduce" and "Severity". Tasks and stories don't. Show fields only when they apply - the create screen stays uncluttered for most users without maintaining separate screens per work type. **Enforce data quality at the right moment** A work item 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. **Screens 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="info" %} **Works on JSM**\ Field Rules runs on the Create Request screen of Jira Service Management portals and on the agent views inside service projects. The same rules that control fields on standard Jira screens work there: 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. Not sure what standard Jira can and cannot do on its own? See [Field Rules vs native Jira](/field-rules/jira-administrator/field-rules-vs-native-jira.md). 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).