Shared action settings

Actions carry out work at defined points in a service journey: looking up data, setting a value, sending a message, generating a document or moving a person elsewhere. Every action type has its own settings, but the shared settings decide its identity, timing and whether it is allowed to run.

On a page, open Page actions and choose Add action. Sign-in actions are configured separately in the service settings. Give each action a focused responsibility and test it through the same journey that a person will use.

Plan the action before configuring it

Write down four things before adding an action:

1. The event that should cause it to run.
2. The values it needs.
3. The result it creates or the change it makes.
4. What the service should do if it does not run successfully.

flowchart LR
  A[Person reaches or submits a page] --> B{Chosen trigger}
  B --> C{Action conditions pass?}
  C -- Yes --> D[Run one focused action]
  C -- No --> E[Skip action]
  D --> F[Use its result or continue the journey]

For a multi-step integration, keep the work in separate, clearly named actions. It is easier to understand and test a lookup, then an assignment, then a message than one opaque action attempting all three.

Use a stable action ID and a descriptive name

The Action ID uniquely identifies the action. Other templates and actions can depend on its result, so use a short stable ID such as lookup_customer, set_case_reference or send_confirmation.

Do not rename an ID casually after another setting refers to it. Instead, assess every template, action and condition that depends on it, update those references, and test the entire route.

The Action name is the label shown to builders, not to service users. Make it readable and specific enough to distinguish similar actions. The Action description is a useful place to record the purpose, prerequisites and owner, for example: “Loads the current account record after the account number has passed validation.”

Choose the right trigger

The trigger defines when the action runs. Select the earliest point at which the action has the information it needs, without doing work unnecessarily.

Trigger timing is part of the service design. For example, do not send a confirmation message before the answers it describes have passed validation.

Control whether an action runs

Use Action execution conditions to run an action only when named conditions pass. These conditions decide execution only; they do not hide a page, show a component or replace validation rules.

When several conditions are selected, choose whether all conditions (AND) or any condition (OR) must pass. Use Inverse of action execution condition only when the business rule is genuinely “run unless…”. Inversion can make complex rules hard to reason about, so a plainly named positive condition is usually clearer.

Example: run send_priority_notification only when is_priority and has_contact_permission are true. Keep the condition names readable enough that the action configuration explains itself.

Restrict a search or export action to its button

For a page that has more than one submission button, use Search or export action to associate the action with the relevant button. This prevents a search or export operation from running when a person selects a different page button.

Leave this setting empty when the action should run for the normal page submission. Test each button separately; a working search button does not prove that the standard continuation path is unaffected.

Use action results safely

An action can produce a result for later templates or actions. For new services, use a dedicated Assign action to put the value you need into the appropriate field or context. This makes the transformation explicit and easier to maintain.

Avoid Action result field ID in new work. It remains for compatibility with older services, but an Assign action gives a clearer, testable hand-off between the action result and the next step.

Use Flow simulation value only to explore possible paths in Builder flow simulation. It is a design-time aid; it does not supply a value in a live service.

Order and test actions deliberately

Actions sharing a trigger run as a sequence. Put any redirect action last: once navigation begins, an action placed after it may not run. More generally, place a prerequisite action before the action that consumes its result.

Test a successful route, a condition that skips the action, missing or invalid input, and the effect of revisiting the page. For external services, use safe representative data in QA and check both the result and the journey that follows.

Important: Do not place secrets, credentials or personal data in action names or descriptions. Keep those fields useful to people maintaining the service without exposing sensitive information.

New action families and saved results

Connectors, Summarise with AI and Categorise with AI use the same action timing and condition model. Service payments are configured in Service settings → Payment, rather than as an action.

Use Add result to form to save selected outputs into calculated fields. Post-view actions run after content is rendered but before the response is sent; their result cannot change already-rendered content.

Run only for a search or export control

runActionForButtonId can restrict an action to a text-search field ID or a Results Table export control: results:page for current-page export or results:all for all results. The table ID alone is not an export button. An unmatched ID skips the action; empty applies to ordinary submissions, with normal action conditions still checked.

Related guidance

• Add actions and workflows
• Use conditions and branching
• Assign actions
• Write Liquid templates