Actions

Actions are the work a state does on its own. When a page enters a state, Aura Workflows 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 Workflows 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 three-tier execution model

Actions on a state run in three phases. Remove restrictions always runs first. The main phase runs everything else in parallel. Publish page runs last, after the main phase has finished and a one-second settle. Within a phase there is no guaranteed ordering: if a state has two Send email actions, you cannot rely on which one fires first.

%%{ init: { "flowchart": { "padding": 6, "nodeSpacing": 20, "rankSpacing": 24, "useMaxWidth": false } } }%%
flowchart TB
    subgraph T1 ["Tier 1 · Early"]
        RR["Remove restrictions"]
    end
    subgraph T2 ["Tier 2 · Main · in parallel"]
        direction TB
        subgraph t2row1 [" "]
            direction LR
            SE["Send email"]
            AR["Add restrictions"]
            ML["Manage labels"]
        end
        subgraph t2row2 [" "]
            direction LR
            MT["Modify title"]
            OV["Set official version"]
        end
    end
    subgraph T3 ["Tier 3 · Publish"]
        PP["Publish page"]
    end

    T1 --> T2
    T2 -- "1-second settle" --> T3

    style t2row1 fill:transparent,stroke:transparent
    style t2row2 fill:transparent,stroke:transparent

The early phase exists so the rest of the state can build on a clean baseline. 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 main phase runs every other type together: Send email, Add restrictions, Manage labels, Modify title, and Set official version. They run in parallel, and a failure in one does not cancel the others.

The publish phase runs last and contains only Publish page. Any Set official version, Modify title, Manage labels, or Add restrictions action on the same state has already finished by the time the publish runs, so the published copy reflects the fully-applied post-transition state of the source page. A one-second pause between the main phase and the publish phase lets Confluence settle the writes from the main phase before the publish reads them.

A failure in any phase does not hold up the next one. The early phase finishes, success or failure, before the main phase starts, and the main phase finishes before the publish phase starts.

No retries

Each action runs once per transition. If it fails, Aura Workflows 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. Runs last, after every other action on the state has finished.
• 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, before everything else.
• 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.
• 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.