Add restriction

The Add restriction action locks a page down to a chosen audience using Confluence’s native page-restriction model. On entry to a state with this action, Aura writes a viewer or editor restriction made up of the people and groups you selected, plus the page author, the page owner, and Aura itself so the workflow can keep operating on the page.

The action is configured under a state’s Actions section in the Workflow Builder. It runs in the late phase, after Remove restrictions and Set official version have finished.

Fields

Restrict page to is the audience: a multi-select that takes any combination of users, groups, and users-typed variables. Variables resolve at the moment the action runs, so a workflow used across many pages can carry an audience that varies per page — @reviewers_group, @page_owner_group, or whatever the workflow declares.

Access type is View or Edit. View gives the listed audience read-only access to the page. Edit gives them both read and write — a Confluence edit restriction implies a view restriction, so editors automatically count as viewers as well.

Two behaviors are always on and shown as fixed bullets in the form, not as toggles. Author has access at all times keeps the page author (and the page owner, where Confluence tracks one separately) in both the view and edit lists, regardless of what you put under Restrict page to. Without this you could lock yourself or the original author out of a page mid-workflow. Reviewers get access during reviews adds the current approval’s pending reviewers to the view list, so anyone who needs to read the page to vote on it can. The reviewer list is captured when the action runs, against the approval that triggered the transition; later reviewer changes are picked up separately by the reviewer-assignment hook and do not require the action to run again.

Replace versus append

Pair with Remove restrictions for a clean swap

Add restriction appends to the page’s existing restrictions. It does not clear what is already there. To replace the audience cleanly on a state transition, put Remove restrictions on the same state — it runs in the early phase and wipes the slate before Add restriction writes the new list.

This is the single most important behavior to know. Confluence’s restriction API merges the entries you submit with the entries already on the page. If a previous state restricted the page to Group A and the new state’s Add restriction lists Group B, a page entering that state ends up restricted to both A and B unless something cleared A first. That something is Remove restrictions in the early phase of the same state. The execution model is built for this pairing: early-phase actions finish before late-phase actions start, so the wipe always happens before the new list is written.

If you genuinely want to add to an existing audience — broaden a published page’s editor list as it moves through a final approval, for instance — leave Remove restrictions off and Add restriction layers on top. Most workflows do not want this; reach for it deliberately.

What gets written

For an Edit restriction, the selected users and groups go onto both the read list and the update list, and the page author, owner, and the Aura app user are added to both as well. For a View restriction, the selected users and groups go onto the read list only; the update list still receives the author, owner, and app user so the page is not orphaned, but selected entities cannot edit. In either case the current approval’s reviewers are added to the read list so they can open the page they are voting on.

User-typed variables expand at run time into their underlying users and groups. A variable holding two users and one group contributes two users to the user list and one group to the group list of the resulting restriction.

Failure modes

A reference to a deleted user or a group that no longer exists surfaces as a per-action error in the page’s history timeline. The transition still completes — the page moves into the state — but the restriction may be partial or missing depending on where in the call the failure landed. Variables that resolve to an empty list do not fail; the action simply contributes nothing from that variable, and the author, owner, and app user still get written.

Restrictions are visible to admins through Confluence’s own restriction dialog on the page. If a workflow’s restriction behavior is not what you expect, opening that dialog is the fastest way to see what Aura wrote and what was left over from before.