Automations Architecture and Data Flow
The two basic building blocks of automations are triggers and actions.
A trigger is an event that the app developer has chosen to expose and report to Wix. This can be any event, such as a visitor landing on a certain site page or an invoice reported overdue.
An action is a single business operation that executes when the automation is triggered. Examples of actions include sending a chat message or updating a database with new customer data.
Users can also add conditions and delays to build more complex automations. These affect the flow of data through an automation by either delaying it for a period of time or directing it down a path based on certain conditions being met.
Basic automation flow
In a simple automation, the app reports an event, and a single action is immediately executed.
When the app reports the event, it passes event data to Wix. This data is defined by a payload schema, which you provide when you add a trigger extension to your app. When the automation runs, Wix makes this event data available to the action.
The action has a schema of its own, called the input schema. This input schema defines the input data that the action requires to run. As with the payload schema in a trigger, the developer who provides the action must define the input schema, which may or may not use the data from the trigger.
In the example shown below, the trigger payload provides 3 values to the action: form name, submitter name, and submitter email. However, the input schema only uses the value of submitter email from the payload. It fills the recipient email field using this value.
Automations with multiple actions
It’s possible to create an automation with more than one action. In this case, actions are chained together and occur in series.
The basic data flow is still the same. The payload data from the trigger is made available to the first action. Every action requires its own input schema. However, actions can also have an output schema that defines their output data. This output acts as a payload to subsequent steps in the automation flow.
The output data is concatenated to the trigger payload, so that a payload reaching an action farther down the chain has “accumulated” data from the trigger and previous actions.
In the example above, Action A defines an output schema that passes on the trigger payload data and adds its own output, a coupon code. This coupon code becomes part of the payload that Action B receives. Action B uses the coupon code as a dynamic value.
Automations with conditions and delays
The fundamental data flow of payload to input schema remains the same even for more complex automations. However, the introduction of conditions and delays changes when and to which actions the data is sent.
Delays
By default, an automation executes immediately when it’s triggered. However, users can configure an automation to wait before the next step by adding a delay. A delay is a period of time that is intentionally inserted between two steps in the automation flow.
For example, let’s say a user has a site automation with the trigger “Customer abandons a cart” and an action “Send an email”, which sends the customer a reminder email about the cart. The user chooses to add a delay of 5 hours between the trigger and the action. When a customer abandons their cart, the automation is triggered. It waits 5 hours from the time of the trigger, then sends the email.
The example below shows the flow of an automation with a delay of 24 hours set between the trigger and the action:
Note that the data flow between the trigger and the action remains the same, but is delayed by 24 hours. The action waits 24 hours to receive the payload data and execute.
Conditions
Users can create complex automation flows by adding conditions. Conditions let users define criteria for conditional logic. A condition includes an if path that determines which steps in the automation path are executed next. Conditions can also include an else path, which specifies what action or set of actions to perform if the initial conditions are not met.
The example below shows the flow for an automation with conditional logic. The payload contains the monetary value of an order a customer has submitted. If that value is greater than $100, Action A executes. Else, Action B executes.
Every action following a condition must have its own input schema defined, even if it never runs. The data from the payload (either from the trigger or a previous action) passes to whichever action is selected. You must make sure that the input schema of each action matches the payload data it can receive.
For a comprehensive glossary of Wix Automations terms, see Terminology.