Actions

Actions are the work a state does on its own. When a page enters a state, Aura runs the items in that state’s Actions list against the page. They’re how a workflow stops being a diagram and starts changing pages: locking down restrictions on entry to In Review, mailing the author when something is published, copying the approved version into the live space.

Actions are configured in the Workflow Builder under each state’s Actions section. This page describes how Aura runs them; the per-action pages below cover the fields and behavior of each individual type.

When actions run

Actions run on entry to a state. Every transition triggers them, regardless of how the page got there — an approval, a rejection, a manual selection, an expiration, or a page-edit transition. The very first time a workflow is applied to a page, the initial state’s actions run too. There is no on-exit hook; if a state needs to undo something it set up, undo it on entry to the next state.

A transition runs actions only when the target state differs from the current one. Resetting a page to the same state it’s already in counts as a re-entry, so the actions do run again in that case.

The two-tier execution model

Actions on a state run in two phases. Set official version and Remove restrictions always run first. Everything else runs after the first phase finishes. Within a phase there is no guaranteed ordering: if a state has two Send email actions, you cannot rely on which one fires first.

The early phase exists so the rest of the state can build on a clean baseline. Set official version stamps the current page version as the official one before any later action looks at it, so an email or publish action running afterwards can describe or copy the just-stamped version. Remove restrictions clears the existing reader and editor lists before an Add restrictions action in the same state writes a new one, so the two don’t fight over the same page. If you’ve ever had a workflow that needed to swap restrictions and seen old viewers linger, this is what fixes it.

The late phase runs every remaining type together: Send email, Publish page, Add restrictions, Manage labels, and Modify title. They run in parallel, and a failure in one does not cancel the others. All early-phase actions finish — success or failure — before the late phase starts, and an early-phase failure does not hold the late phase back.

No retries

Each action runs once per transition. If it fails, Aura records the error and moves on; the page still completes the transition into the new state. Nothing is automatically retried, so a flaky email or a missing target shows up as a one-shot failure rather than a stuck workflow.

Failures and the history timeline

Action results show up in the page’s workflow history under a Workflow actions entry, with a per-action status of success or error and the error message attached. If an action isn’t there, it didn’t run; if it ran and failed, the message explains why. The history view filters down to the workflow-actions events when you only want to see the automation timeline.

The most common cause of an error is a missing target. Publish page pointing at a space that no longer exists, Send email with a recipient resolved from a variable that wasn’t set, Add restrictions referencing a deleted user — each surfaces as a per-action error in history without affecting the transition itself. The page still moves into the new state. If you change a space, group, or user that an action depends on, expect to see action errors on the next transition into that state.

Actions and variables

Actions read variables at the moment they run, which is the moment the transition completes. A Send email action whose recipients include @reviewers resolves that list against the approval that just ended; a Publish page action with a variable target space resolves against whatever the variable holds at transition time. Changing a variable afterwards has no effect on actions that already ran.

Action types

Each type has its own page covering fields, behavior, and limits.

• Send email — sends a templated email to a chosen audience: author, owner, last editor, reviewers of the previous approval, or specific people. See also Email configuration.
• Publish page — copies the page (and optionally its descendants, attachments, and labels) into another space, using a fixed target or a space variable.
• Add restrictions — sets viewer and editor restrictions on the page for a list of users and groups.
• Remove restrictions — clears all viewer and editor restrictions. Runs in the early phase.
• Manage labels — adds or removes labels.
• Set official version — marks the current version as the official one used by approval emails and the page sidebar. Runs in the early phase.
• Modify title — prefixes, suffixes, or rewrites the page title with a regular expression.

For applying a workflow to pages so any of this runs at all, see Applying workflows. For the approvals that drive most transitions, see Approvals.