Use an Assign action to calculate, copy or reshape a value for later use in the service. It is the clearest way to take an action result or Liquid expression and place the value where a page, condition, template or later action needs it.

An Assign action is particularly useful after a lookup or API action, where it can turn a raw result into a named value with a clear business purpose.

Choose an assignment purpose

Before configuring the action, be able to finish this sentence: “This action sets this target to this value so that this later step can use it.” If the sentence is unclear, split the work into smaller actions.

flowchart LR
  A[Field value or earlier action result] --> B[Liquid assignment template]
  B --> C[Assign action]
  C --> D[Named target value]
  D --> E[Condition, page, document or later action]

Examples include copying a confirmed email address to a notification target, combining fields into a display name, saving one value returned by a lookup, or adding an item to a repeating collection.

Configure an assignment

1. Open Page actions and add an Assign action.
2. Set a stable Action ID and a name that describes the business result, such as set_area_name.
3. Choose a trigger that runs after the source value exists. When it depends on submitted answers, this is commonly after validation.
4. Write the Assignment template using the required fixed value or Liquid expression.
5. Set the Assign to field ID for the target.
6. Select the appropriate assignment mode.
7. Test the source value, target value and every later feature that relies on it.

Use a small, readable template. Put complex transformation logic in an intentional sequence of assignments rather than one long expression that is difficult to diagnose.

Write the assignment template

The Assignment template supplies the value to save. It can be fixed text, a Liquid expression that reads a field, or a structured value where the target expects one.

For example, an action that stores a person’s chosen contact route can use the corresponding field or an earlier action result. Keep the target’s expected format in mind: storing a whole record where a later template expects a single label creates avoidable errors.

Test templates with blank input, optional fields omitted, long text and unexpected characters. A template that works only with ideal data is not ready for a live journey.

Select the target field and mode

Assign to field ID identifies the target. It can address a property within a structured field using dot notation. Only target fields whose meaning and expected shape you understand; a seemingly simple overwrite can destroy a value that another step still needs.

The assignment mode controls how the value is applied:

If the target is part of a repeating group, use Assign to field iteration to identify the relevant row. The first row is numbered 0. Test more than one row and test adding, removing and reordering rows before relying on an iteration expression.

Keep assignment order explicit

An assignment can consume an earlier action’s result, and a later action can consume the assigned value. Put those actions in that order under the same trigger. Give each a name that describes its hand-off:

1. find_account
2. set_account_name
3. send_account_confirmation

This pattern is easier to test than hiding the transformation inside the sending action. It also lets you inspect each decision point when an external dependency returns incomplete data.

Preserve compatibility deliberately

For new services, use an Assign action rather than placing an action result directly into a result field through older configuration. The explicit assignment records what is being taken from the result and where it is stored.

When maintaining an existing service, do not replace legacy behaviour merely for consistency. First identify the current consumers, reproduce the live behaviour in QA, then make and test a controlled change.

Test checklist

• The trigger runs only after all source values exist.
• The template produces the expected value for normal, blank and unexpected input.
• The target field ID is correct and has the expected format.
• Replace, append or merge matches the intended data behaviour.
• Repeating-group assignments have been tested across multiple rows.
• Actions consuming the target run afterwards.
• Re-entering a page or resuming a draft does not create unwanted duplicates or overwrite important data.

Related guidance

• Shared action settings
• Feed lookup actions
• Write Liquid templates
• Group components