> 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/make-field-required.md). # Make field required Field Rules can make a Jira field required based on conditions, so a field is mandatory only when it actually matters. Convert an optional field to required based on the value of another field, the current user, their group or role, or the space and work type - a conditional or dynamic required (mandatory) field, with no scripting. When the conditions stop matching, the field returns to optional. **Supported contexts:** Global Issue Create, Issue Transition, JSM Request Create. Not supported on Issue View. *** ## 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 **Make field required** rule and choose the field under **Field name**. 3. Add **preconditions** - field values and/or user identity - that determine when the field is required. Leave preconditions empty to always make the field required. 4. Save. When the screen loads or a watched field changes, the rule re-evaluates: if the conditions pass the field becomes required, otherwise it stays optional.
Configuring a Make field required rule that makes Steps to reproduce mandatory when Issue Type is Bug

Making "Steps to reproduce" required only when the Issue Type is Bug.

| Option | Description | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Field name** | The field to make required. | | **Preconditions** | Optional field and/or user conditions. When conditions are met the field is required; when not met it remains optional. Leave empty to always make the field required. | *** ## How it works When the screen loads or the user changes a watched field, the rule re-evaluates the preconditions. If they pass, the field is marked as required. If the field is currently hidden, it is automatically shown - a required field must always be accessible to the user. If the field is already required (by Jira system configuration or another rule), the rule is skipped. *** ## Examples **Conditional required field**\ Make a "Steps to reproduce" paragraph field required when the Issue Type is set to "Bug". For all other work types the field remains optional. **Required field for a specific group**\ Make the "Severity" field required for users in the "Support" group. Other users can leave it empty. **Required field based on another field's value**\ Make the "Root cause" text field required when a "Defect confirmed" checkbox is selected. The field only appears and becomes required after the user checks the box - combine with the [Show field](/field-rules/rules/show-field.md) rule for the full effect. **Required field based on resolution**\ When transitioning a work item and the Resolution is set to "Won't Fix", make a "Rejection reason" paragraph field required. This ensures that whenever a work item is rejected, the team must document the reason before the transition completes. *** ## When to use it Use Make field required to enforce data quality exactly where it matters, without making a field mandatory everywhere: * **Value-driven** - require a field only when another field takes a certain value, such as a rejection reason when Resolution is "Won't Fix". * **Per work type** - require work-type-specific fields (a bug's "Steps to reproduce") without building a separate field configuration scheme. * **Per user or group** - require a field only for certain teams. If a field should always be required for a whole scheme, Jira's field configuration already handles that. Reach for this rule when the requirement is conditional. *** ## Doing this without Field Rules To make a field required only for certain work types without an app, Jira's traditional approach was separate Field Configurations: create one Field Configuration with the field marked required, another with it optional, and map each to its work types through a Field Configuration Scheme. Because a Field Configuration bundles the required/optional/hidden state for every field at once, a single field that needs to vary by work type could mean creating and maintaining a whole extra configuration just for that one difference. A Field Scheme's "Required on" setting replaces that: choose "Required on selected work types" (or "all except selected") directly on the field, in the scheme, with no separate configuration objects to create or keep in sync. This is effectively the same idea as the Make field required rule with an Issue Type condition - a field that's mandatory for some work types and optional for others - except it's a static setting an admin configures ahead of time, not a rule. The difference is what the condition can be based on. "Required on" only varies by work type. Make field required can react to work type too, but also to the value of any other field on the screen, or to who the user is - their group, role, or identity - and it re-evaluates live as the user fills in the form. Native Jira has no equivalent for those cases. Conditions beyond work type, and real-time reactivity, require a UI Modifications app like Field Rules or a scripting app. Field Rules closes this gap with a no-code, visually configured rule - no developer required. 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 The rule is not supported on Issue View - the `setRequired` operation is a platform limitation on that screen. On the supported views, not all fields support this operation. Key exceptions: * **Issue Type, Resolution, Status, Summary, Original estimate** - not supported on any view. * **Assignee, Components, Multi user picker, People, Project picker, Reporter, URL, Target start, Target end** - only supported on Global Issue Create. * **Affects versions, Fix versions, Checkboxes, Radio buttons, Parent** - supported on Global Issue Create and Issue Transition only. * **Select, Multi select** - supported on all three views. * **Priority** - supported on all three views. * **Date picker, Date time, Due date, Number, Text field, Paragraph, Description, Labels, User picker, Cascading select** - supported on Global Issue Create and JSM Request Create. *** ## Interaction with Show field If a field is hidden by the [Show field](/field-rules/rules/show-field.md) rule and then made required by this rule, the field is automatically shown. This prevents creating a state where a required field is inaccessible. Conversely, the Show field rule will not hide a field that is currently required. Whichever rule runs first, required fields remain visible. *** ## System-required fields Fields already marked as required by Jira's screen or field configuration cannot be made optional by removing or disabling this rule. The rule only works in one direction - it can make optional fields required, but cannot override system-level requirements. *** ## Limitations * **Issue View is not supported.** The `setRequired` operation is not available on Issue View - this is a platform constraint. * **System-required fields cannot be made optional.** The rule only converts optional fields to required, not the other way around. * **Many fields have limited view support.** Several field types only support this operation on Global Issue Create. See the exceptions list above. *** ## Related rules * [Show field](/field-rules/rules/show-field.md) - show or hide a field based on conditions; pairs with this rule for fields that appear and become required together. * [Change field value](/field-rules/rules/change-field-value.md) - update a field when another field changes. * [Lock field](/field-rules/rules/lock-field.md) - make a field read-only instead of required. * [Use description](/field-rules/rules/use-description.md) - explain to users why a field is required.