Actions

Actions are admin-designed sequential workflow operations triggered against individual collection entries. When an action is assigned to a collection, a trigger button appears per row in the entry list. Actions need a MongoDB connection, which is a Pro feature: without one, Data > Actions says so and nothing can be run.

Creating an Action

1. Navigate to Data → Actions and click New Action.
2. General tab - enter a title and select the target collection.
3. Trigger tab - the button label, icon and optional confirmation message. Manual (a button) is the only trigger. An optional transition makes the action a workflow step - see below.
4. Steps tab - add steps in order. Each step runs sequentially; if one fails the action stops.
5. Access tab - which roles can run the action, and an optional row-level rule. See "Who can run an action" below.
6. Click Save Action. The button will appear on the collection's entry list.

Step Types

Template Variables

Step config fields support {{variable}} interpolation:

Example - approve an application and notify by email:

Step 1: updateField  field=status      value=approved
Step 2: updateField  field=approvedAt  value={{now}}
Step 3: email        to={{entry.data.email}}
                     subject=Your application has been approved
                     template=Congratulations {{entry.data.name}}, your application is approved.

Who can run an action

• Any listed role is enough. Ticking admin and hr lets holders of either run it, and everyone more senior than either - the same ladder as page visibility. All the roles a user holds count, not just their primary one.
• No roles ticked - admins only (role levels 0 and 1).
• A role the site does not have (deleted or renamed) admits only the level-0 role. The editor keeps it and flags it so you can fix it.
• Row-level rule - Owner (entries the user created) or Field match (entries that name them in a field), checked on the server every time the action runs. The level-0 role is never limited by it.

Workflows: transitions

Give an action a transition - a state field, the From values it may start from, and the To value - and it becomes a step in a workflow. It is offered only while the entry's field holds one of the From values; your steps (usually an Update a field step) do the actual change.

On the public site, an interactive [collection] with the transitions attribute shows each row the buttons that apply to it right now, for the person looking - roles and the row-level rule included. Add scope="mine" for a "my entries" page where people move their own entries on:

[collection slug="applications" scope="mine" display="cards" title-field="jobTitle" paginate transitions /]

Running an action whose transition no longer applies (the entry has moved on) is refused with 409 and changes nothing. From a scope="mine" block, a row the person did not create is refused with 403. For an action meant only for people's own entries, also give it an Owner row-level rule, so it is refused however it is called.

Partial Execution

Actions are not transactional. If a step fails, the action stops and returns the number of steps completed so far (stepsCompleted). Steps that already ran are not rolled back. Design step order with this in mind - put irreversible steps (delete, email) last.

See also CTA Shortcode for action buttons on pages, and the Actions API.

After a deleteEntry step

If an action contains a deleteEntry step, subsequent steps will fail because the entry no longer exists. Place deleteEntry as the last step.