> 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/change-field-value.md). # Change field value Automatically update or clear a Jira field when the user changes another field - build dependent fields, cascading dropdowns, and reactive defaults with no scripting. Field Rules can automatically update a Jira field when the user changes another field on the screen. Watch one or more fields and, when they change to a matching value, set a target field's value or clear it - the basis for dependent fields, cascading dropdowns, and reactive defaults, with no scripting. Unlike [Pre-fill field](/field-rules/rules/pre-fill-field.md), which runs once when the screen loads, this rule is reactive: it fires each time the user changes a watched field. *** ## 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 **Change field value** rule and choose the field to update under **Field name**. 3. Choose the **Action**: **Set a value** to assign a value, or **Clear the value** to empty the field (see [Clearing a field](#clearing-a-field)). 4. If you chose **Set a value**, enter the **Field value** to assign when conditions are met. For Description or Paragraph fields this is a rich text editor (see [Rich text editing](#rich-text-editing)). 5. If you chose **Set a value**, choose whether to **Override not empty value**. Enabled (default) always updates the field; disabled only sets it when the field is empty, so manual entries are preserved. 6. Add **preconditions**. At least one field precondition is required - the rule needs a watched field to know when to fire. Add user conditions too if needed. 7. Save. Each time the user changes a watched field, the rule re-evaluates and updates or clears the target field when the conditions pass.
Configuring a Change field value rule that sets Priority to High when the Labels field contains overdue

Setting Priority to High whenever the user adds the "overdue" label.

| Option | Description | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Field name** | The field whose value will be set. | | **Action** | Whether the rule sets a value or clears the field. Set a value by default. | | **Field value** | The value to assign to the target field when conditions are met. Only with Set a value. | | **Override not empty value** | When enabled, the rule replaces the current value even if the field is already populated. When disabled, the rule only runs if the target field is empty. Enabled by default. Only with Set a value. | | **Preconditions** | Field and/or user conditions that must be true for the rule to apply. At least one field precondition is required. | *** ## How it works The rule watches the fields you define in its preconditions. Whenever a user manually changes one of those fields, the rule re-evaluates the conditions and, if they pass, updates or clears the target field. Changes made by other rules (cascading effects) do not trigger this rule - only direct user input does. *** ## Override not empty value This setting controls what happens when the target field already contains a value at the moment the rule fires. | Setting | Behaviour | | ----------------- | ------------------------------------------------------------- | | Enabled (default) | The target field is always updated to the configured value. | | Disabled | The rule only applies if the target field is currently empty. | *** ## Clearing a field With **Clear the value** selected, the rule empties the target field when its preconditions are met, whatever its current value. When the field is already empty, the rule does nothing. On create and transition screens, clearing a field that is required on the screen means the user has to fill it in again before submitting. **Fields that can't be cleared** * **Priority** and **Issue type** can't be cleared. * **Summary** can't be cleared on Issue View, including the JSM Agent view. On other views the rule clears it as usual. *** ## Rich text editing When the target field is **Description** or a **Paragraph** custom field, the value input changes to a rich text editor. Supported formatting: * **Text styles** - Normal text, Heading 1 through Heading 6 * **Inline** - Bold, Italic, Underline, Strikethrough, Inline code, Subscript, Superscript, Text color * **Blocks** - Bullet list, Ordered list (nested up to 6 levels), Blockquote, Code block, Horizontal rule * **Tables** - insert a table, add or remove rows and columns, and resize columns * **Links** - inline hyperlinks with `http`, `https`, or `mailto` URLs *** ## Examples **Dependent field update**\ When a user selects a value in a "Department" single-select field, automatically set the "Category" field to the corresponding default value. **Escalate priority when a label is added**\ When the Labels field contains "overdue", automatically set Priority to "High". **Pre-select a cascading select based on another field**\ When a user sets the "Component" field to "Mobile", automatically set a "Platform" cascading select to "Mobile / iOS". **Reset a dependent field**\ When a user changes the "Product" select field, clear the "Product version" field, so a version picked for the previous product isn't kept. **Conditional assignee**\ When the "Component" field is set to "Backend", automatically assign the work item to the on-call backend engineer. Disable "Override not empty value" so that manually assigned work items are not overwritten. *** ## When to use it Use Change field value to keep fields in sync as the user fills in the form: * **Dependent fields and cascading dropdowns** - set or narrow one field based on the choice in another. * **Reactive defaults** - update a value when a triggering field changes, such as escalating Priority when a label is added. * **Resetting dependent fields** - clear a field whose value no longer fits after the user changes another field. * **Auto-assignment** - set the assignee based on component or category, with override off to respect manual choices. Use [Pre-fill field](/field-rules/rules/pre-fill-field.md) instead for a value that should be set once on load rather than in response to user input. *** ## Doing this without Field Rules Standard Jira Cloud cannot set one field's value based on another field's value while the user fills in the form. Field defaults are static and configured per field context, permission and workflow schemes do not touch field values, and there is no native reactive or dependent-field behaviour on the create, edit, or transition screen. Dependent fields, cascading value updates, and reactive defaults 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. *** ## Difference from Pre-fill field Both rules set a field's value, but they serve different purposes: | | Change field value | Pre-fill field | | --------------------------- | ------------------------------------------ | ------------------------------------------ | | **When it runs** | Each time the user changes a watched field | Once, when the screen loads | | **Preconditions required** | At least one field precondition required | Optional | | **Supported on Issue View** | Yes | No | | **Typical use** | Cascading selections, reactive defaults | Static defaults, transition pre-population | Use **Pre-fill field** to seed a value before the user interacts with the form. Use **Change field value** to update a field in response to what the user is doing. *** ## Supported fields | Field type | Global Issue Create | Issue View | Issue Transition | JSM Request Create | | ----------------- | ------------------- | ---------- | ---------------- | ------------------ | | Assignee | Yes | Yes | Yes | No | | Affects versions | Yes | Yes | Yes | No | | Cascading select | Yes | Yes | Yes | Yes | | Checkboxes | Yes | Yes | Yes | No | | Components | Yes | Yes | No | No | | Date picker | Yes | Yes | Yes | Yes | | Date time | Yes | Yes | Yes | Yes | | Description | Yes | Yes | Yes | Yes | | Due date | Yes | No | No | Yes | | Fix versions | Yes | Yes | Yes | No | | Issue type | Yes | No | Yes | No | | Labels | Yes | Yes | Yes | Yes | | Multi select | Yes | Yes | Yes | Yes | | Multi user picker | Yes | Yes | Yes | No | | Number | Yes | Yes | Yes | Yes | | Original estimate | No | Yes | Yes | No | | Paragraph | Yes | Yes | Yes | Yes | | Parent | Yes | Yes | Yes | No | | People | Yes | Yes | No | No | | Priority | Yes | Yes | Yes | Yes | | Project picker | Yes | Yes | Yes | No | | Radio buttons | Yes | Yes | Yes | No | | Reporter | Yes | Yes | Yes | No | | Resolution | No | No | Yes | No | | Select | Yes | Yes | Yes | Yes | | Status | No | Yes | No | No | | Summary | Yes | Yes | Yes | Yes | | Target end | Yes | No | No | No | | Target start | Yes | No | No | No | | Text field | Yes | Yes | Yes | Yes | | URL | Yes | Yes | Yes | No | | User picker | Yes | Yes | Yes | Yes | ### Cascading select When the target field is a cascading select, configure both a **parent value** and an optional **child value**. If a parent is set without a child, only the parent option is applied. If a configured option no longer exists in the field, the rule skips it. For multi-value fields, the remaining options are still applied. *** ## Limitations * **Changing the Issue type doesn't trigger this rule.** A precondition on the Issue type field doesn't fire when the user changes it, on any view. * **A field cannot watch itself.** The target field cannot also be used as a precondition field. It is not possible to trigger the rule based on changes to the same field being set. * **Clearing:** Priority and Issue type can't be cleared, and Summary can't be cleared on Issue View. See [Clearing a field](#clearing-a-field). *** ## Related rules * [Pre-fill field](/field-rules/rules/pre-fill-field.md) - set a value once when the screen loads instead of reactively. * [Show field](/field-rules/rules/show-field.md) - show or hide a field based on conditions. * [Hide field options](/field-rules/rules/hide-field-options.md) - filter the available options within a field. * [Make field required](/field-rules/rules/make-field-required.md) - make a field mandatory based on conditions.