Configuring Conditional Subfields in RTF
Use Update Rules to show, hide, or require fields dynamically based on a user's earlier selections.
What this covers: How to configure Update Rules on a Rich Ticket Filing (RTF) form so that fields show, hide, or become required/optional dynamically — based on values the user has already entered.
Update Rules evaluate a condition against the current field values in the form. When that condition is met (or not met), Moveworks applies a set of field updates — toggling visibility or required state — in real time as the user fills out the form.
Each rule has three parts:
Supported update types: Only REQUIRED / NOT REQUIRED and VISIBLE / NOT VISIBLE are currently supported for dynamic field updates.
Rule execution order matters. Rules are executed in the order they are defined. If two rules target the same field, the last rule wins. Design your rules accordingly.
Use Update Rules when the answers a user gives earlier in a form should change what fields they see or are required to fill out next. Common scenarios include:
RTF Update Rules work by toggling the visibility and required state of named fields. This means that to present a user with different options for the same question, you need to model it as two separate fields — one per option set — and show only the relevant one at a time.
For example: if users in different departments should see different priority options, you’d create priority_it and priority_hr as separate fields (both labeled “Priority”), and use an Update Rule to show only the one that matches the user’s department. The user sees a single “Priority” question; the form handles the branching behind the scenes.
This example walks through a form where a user orders a shirt by selecting a Size (Small, Medium, or Large) and a Color. The business constraint: Medium Blue and Large Blue shirts are not available, so the color options must change based on the size selected.
The form presents two visible labels — Shirt Size and Shirt Color — but the color field is actually implemented as two separate fields with different option sets:
This lets you offer Red/Green/Blue for Small, but only Red/Green for Medium and Large.
The form as the user sees it — initial state:
Depending on which size is selected, the correct color field appears:
Before opening Moveworks Setup, confirm the exact field names for every field involved — both the field driving the condition and the fields being updated.
size field:
color_options_small_size field:
color_options_medium_or_large_size field:
The field label (what the user sees) and the field name (used in rules) are different. Always use the field name — not the label — in your condition expressions and update targets.
Before touching the UI, write out the intended behavior. For this example:
In Moveworks, this becomes two Update Rules — one for each condition branch.
Enter the condition expression. Always prefix field names with field_ when referencing them in expressions.
field_size == 'Small'size)
Always use the field_ prefix in condition expressions. To reference the size field, write field_size — not size.
Each field update entry in the UI has two parts:
field_ prefix (e.g., field_color_options_small_size)Property Required or Property Visible), followed by a checkbox that sets the value: checked = true, unchecked = falseWhen size is Small, add four entries — two per field:
Setting a field to Required (checkbox checked):
Setting a field to Not Visible (checkbox unchecked):
When size is not Small, reverse the visibility and required state:
Adding a description helps future editors understand what the rule is doing at a glance.
Follow the same steps to create a second rule for the Medium and Large case:
field_size == 'Medium' or field_size == 'Large'color_options_medium_or_large_size to VISIBLE + REQUIRED, set color_options_small_size to NOT VISIBLE + NOT REQUIREDIn this example, Rule 1’s “when False” branch already handles the Medium/Large case. Whether you add a second explicit rule or rely on the False branch is a design choice — either works. Adding the explicit rule makes the intent clearer and is recommended for maintainability.