Actions make a service do work as a person moves through it. They can look up data, calculate or assign values, create documents, send a message, call an external service, change the route, manage a list, or start a review process. Configure an action on the page where its outcome belongs, then test both success and failure before release.

Plan the outcome first

Before adding an action, write down four things: the information it needs, when it should run, what it produces, and what the person should experience if it fails. Keep one action responsible for one clear job. For example, look up a record first, then use a separate assignment action to store a selected result.

The Builder groups actions by purpose. Common categories include data and integrations, output, flow control, cart, and users and review. Choose the action type that fits the job, rather than using a general API action for work the platform already supports.

Choose the right trigger

In a page’s Actions area, actions are organised by when they run.

Build an action in a deliberate sequence

1. Open the page, select Actions, then choose Add action in the required trigger section.
2. Select the action type and give it a purpose-led name and stable ID.
3. Configure its inputs using component answers, action results, conditions or template expressions where needed.
4. Add an execution condition if the action should only run for a particular route or state.
5. Define what happens with the result: store it, display it, use it in a later action, or use it to control the journey.
6. Save the action and test it from a fresh User view journey.

Action IDs are referenced by later settings and templates. Avoid renaming or deleting one without checking every place that uses its result.

Sequence is part of the design

Actions in the same trigger run in their configured order. Put the action that creates or retrieves data before an action that reads that result. Put redirects last: once navigation changes, later actions in the same trigger may no longer be appropriate.

flowchart LR
    A["Valid page answer"] --> B["Look up or prepare data"]
    B --> C["Store or transform the result"]
    C --> D{"Condition met?"}
    D -->|"Yes"| E["Send, create or update"]
    D -->|"No"| F["Continue without that work"]
    E --> G["Move to the next journey step"]
    F --> G

Name the actions so the sequence can be read at a glance, for example: Find account, Store account ID, then Send confirmation. A future editor should not have to inspect template code to understand the intended order.

Use action results safely

An action can make data available to later content, conditions and actions. Only use a result after the source action has completed on the same route. Where an action returns structured data, test the actual result shape in QA before building a template or mapping around it.

Do not place credentials, access tokens or other secrets in a URL, request body, error message, template, sample response or visible page content. Configure protected connection details in the relevant integration settings and use non-sensitive test data when exercising a service.

Design for a dependency being unavailable

External services, file sources and messaging systems can be slow or unavailable. Make the failure state part of the user journey.

• Set a realistic timeout for an external call.
• Use a condition to avoid unnecessary calls.
• Configure failure alerts for work that the team needs to act on.
• Tell the person what they can do next if an essential action cannot complete.
• Ensure repeated attempts do not create accidental duplicate messages, records or payments.

For important operations, test a timeout, an invalid response, missing data, a rejected request and a repeated submission. Check both the action outcome and what the person sees.

Workflows and review

Workflow actions run after submission in the background. They are useful when the person’s part of the journey is complete but the organisation still needs to review, notify, export or perform a follow-up operation. A review step can pause the workflow; remaining dependent work resumes when the review reaches its configured outcome.

Make the hand-off explicit. The completion page should explain what has happened, whether the person can still make changes, and what they can expect next. Reviewers should have only the actions they need, such as accepting, returning for changes, or cancelling a workflow.

Test with a route matrix

Related guides

• Use conditions and branching
• Connect data files and SharePoint
• Write Liquid templates
• Test, deploy and maintain a service