Automations aren't traditional extensions. Unlike other backend extension types, automation triggers and actions aren't registered in src/extensions.ts, aren't generated by npm run generate, and don't appear on the Extensions page in the app dashboard. For apps, they're configured through the Automations section of the App Dashboard instead.
Automations are no-code workflows Wix users build on their site, pairing a trigger with one or more actions.
For example, a Wix user can build an automation that sends a welcome email whenever a new contact is added to their site.
Every automation is built from a trigger paired with one or more actions. You can create the following building blocks for Wix users to build with:
- Triggers: Events you report to Wix when something happens. Each trigger declares the payload it sends, so downstream actions can use the data. Wix users see triggers in the automations library and pick them as the starting event for their automations.
- Actions: Work that runs as part of an automation. Each action declares an input schema, and Wix generates a configuration UI from that declaration so Wix users can set up the action when they build an automation. Actions can also return data for later actions in the same automation to consume.
- Pre-installed automations: A full automation pairing a trigger with one or more actions.
Triggers and actions have different auth models because of how Wix invokes them.
How a trigger fires depends on whether it was created by an app or by site backend code:
- Triggers created by an app report events using the app's identity. The app must hold the appropriate automations scope in its manifest.
- Triggers created by site backend code must elevate the trigger-fire call. Without elevation, the call runs as the current visitor or member, which doesn't have permission to fire a trigger. Elevation replaces that identity with site authority for the duration of the call.
Actions are invoked by Wix when an automation reaches the action step, with no Wix user, member, or visitor identity attached. To call Wix APIs from the action handler, you must use elevation.
What elevated calls can do is bounded:
- For app-owned actions, elevation runs the call as the Wix app, bounded by the app's permission scopes, declared in the app's manifest.
- For site-owned actions, elevation grants site admin authority.
For app-owned actions, the inbound invocation from Wix is signed so the handler can verify it actually came from Wix. The Wix CLI handles this verification.
The development path determines how you add automation building blocks:
- Sites: Publish custom triggers and custom actions directly from their backend code. See Add a Custom Trigger and Add a Custom Action in Extend Websites.
- Wix-managed headless projects: Don't support automations.
- Self-managed headless projects: Don't support automations.
- Wix-managed apps: Configure triggers, actions, and pre-installed automations through the Automations section of the App Dashboard, and back them with code in the project's backend. Any pre-installed automations are added to a site automatically when an app is installed, ready to run. See Triggers, Actions, and Pre-installed Automations in Build Apps.
- Self-managed apps: Configure triggers, actions, and pre-installed automations through the Automations section of the App Dashboard, and back them with code in the project's backend. Any pre-installed automations are added to a site automatically when an app is installed, ready to run. See Triggers, Actions, and Pre-installed Automations in Build Apps.
- Blocks apps: Don't include automation extensions.