Use an Execute other action action to run another configured action at a different point in the service journey. It is useful when the same focused operation is needed from more than one route without duplicating its settings.

Use it sparingly. An execution chain can make a service difficult to understand if it hides work behind several layers of indirection. Prefer one clearly placed action when duplication is not a real maintenance problem.

Choose a safe reuse pattern

The target must be another non-execute action in the same service. Give the target a focused responsibility, such as a lookup or assignment, then use an execute action only where a second trigger genuinely needs to call it.

flowchart LR
  A[Different journey event] --> B[Execute other action]
  B --> C[Named target action]
  C --> D[Target result]
  D --> E[Continue current route]

Do not create loops. A target action cannot itself be an execute-other-action action, which helps prevent direct chaining, but you should still keep dependency paths short and obvious.

Configure the action

1. Create and test the target action first.
2. Add an Execute other action action at the second point where the work is needed.
3. Give it a clear ID and name that state both the reason and the target, such as rerun_customer_lookup_on_retry.
4. Choose the Action to execute by its stable Action ID.
5. Decide whether the target’s result should also be stored under the target action’s own ID.
6. Add execution conditions and a trigger for the current route.
7. Test the original route and the reused route independently.

Changing the target action’s ID breaks the reference. Treat it as a dependency change: update every execute action and test every trigger that calls it.

Choose result storage deliberately

By default, the result is stored under the Execute other action action. Turn on Result storage when the service also needs the result under the target action’s identity.

Use one approach consistently. If later templates sometimes read the target result and sometimes the execution result, maintenance becomes error-prone. Document the expected result location and name execute actions accordingly.

Keep ordering and failure paths clear

The target operation still has its own requirements: a lookup needs its input, an API call needs a safe request and a document action needs complete answers. Ensure those prerequisites exist at the execute action’s trigger.

Test skipped conditions, missing input, target failure and returning to the page. If execution repeats an external call or sends a message, make sure the second route cannot create accidental duplicate work.

Use the action description to record why reuse is needed and which routes invoke the target. This helps a future maintainer decide whether changing the target will affect a second, less visible journey path.

Test checklist

• The target action is focused, tested and not another execute-other-action action.
• The execute action names the target and its route purpose clearly.
• All target prerequisites exist when the execute action runs.
• Result storage is consistent with later template and action references.
• The original and reused routes have both been tested.
• Conditions and failure paths behave correctly on the second route.
• Repeated execution cannot create unexpected external side effects.

Related guidance

• Shared action settings
• Assign actions
• API actions
• Write Liquid templates