As an app developer, you can separately provide triggers and actions to sites. Using pre-installed automations, you can also provide a full automation that combines a trigger and an action that you choose.
Pre-installed automations let you combine triggers and actions into a single automation, and include it as part of your app. When users install your app on their site, your automation is included as part of the app.
If there’s a particular trigger-action combination that you believe is very helpful to your app’s functionality, adding a pre-installed automation is a good choice. This way, you don’t have to suggest to users to create the automation themselves because it’s already set up and available to them from installation, with only some possible action configuration required.
To create a pre-installed automation, you first create the automation on a site, then export it to the app dashboard. You can use a trigger from any Wix app when creating the automation, including your own. Keep in mind that if you use a trigger from another app, the user must also have that app installed on their site in order for the automation to work.
You can only select certain actions, including actions from your own app. You can configure the action when you create the pre-installed automation. Users will see the same action configuration on their site when they install your app.
Users will see your automation listed in their Automations dashboard page under the Installed for you tab after they install your app. They are able to activate or deactivate the automation as needed.
The automation you create is global, and is applied to all sites that install your apps. You can think of a global automation as a master version. Every time a user installs your app, this master version is installed on their site.
If a user modifies the automation’s action configuration, the site creates a copy that contains their changes. This copy overrides the global automation. This means that when the automation is triggered, the site runs this override automation instead of the global one.
The creation of the override automation when a user changes the action configuration ensures that the global automation is not altered. For example, imagine users A, B, and C install your app on their site. Users A and B accept the default action configuration in your pre-installed automation. However, User C modifies the action configuration. Therefore, User C’s site creates an override automation that runs in place of the global pre-installed automation. But the changes that User C makes do not affect the automation for Users A or B.
The following graphic illustrates this:
Users can’t do the following to your pre-installed automation: