In WunderAutomation, each workflow has a defined trigger. The workflow trigger tells WunderAutomation what type of event to wait for. Out of the box, WunderAutomation has a lot of built-in triggers that let users build both simple and advanced workflows.
Trigger groups
When selecting the trigger in the workflow, the triggers are grouped into different functional groups to make it easier to find the correct trigger. Out of the box, WunderAutomation has four groups with a total of about 25 individual triggers. If you install addons to WunderAutomation, they might add more triggers.
Objects provided
When a trigger fires, it will always provide one or more objects. The objects are used to run filters on and to modify the behavior of the connected actions and parameters. Different triggers will provide different objects and will affect what kind of filtering and parameters can be used. When selected, each trigger clearly explains what objects they provide.
In the above example, the trigger Post saved provides two objects, "post" that represents the actual post that was published and "user" that represents the owner of that post.
Built-in triggers
Post triggers
WordPress uses the internal post object to represent a lot of different things. Besides being used to manage the blog post (obviously), post objects are also used to represent pages, media (images, etc), menu items, etc. You could say that the post object is the most important internal building block in WordPress.
This means that the built-in post triggers are very versatile and can catch a lot of different events in WordPress. This also means that you need to handle them with care. It’s recommended that any post-trigger is always combined with a filter that checks for the correct post type so that the associated actions are only executed when you expect them to.
Filter checking for the "product" post type
Read more about each post-trigger here.
User triggers
WunderAutomation provides four different triggers for user-related events in the User triggers group. The user triggers are used to start workflows when something happens to a user. The most common trigger to use is probably when a new user is created.
Comment triggers
As with the post object, comments in WordPress are used for more than one thing. Besides the obvious blog post comment, they are also used for things like order notes and product reviews in WooCommerce. The comment triggers group contains three different triggers that allow you to start workflows when new comments are submitted or approved. Just as when working with post triggers, we recommend that any workflow that uses a comment trigger also uses a filter that checks for the correct comment type.
WooCommerce order triggers
WunderAutomation comes with built-in support for working with WooCommerce orders. Internally, a WooCommerce order is represented using a post object, but they have some special behaviors that made us decide to treat them as a special object type.
When using any of the WooCommerce order triggers, the object provided will be the "order" object type that allows for some order-specific filters and parameters. Handling orders as a specific type also allows WunderAutomation to provide triggers for some very specific status changes, like when an order transitions from a non-paid state to a paid one.
Run once workflows
A very common use case is that you want to restrict a workflow to only run once for a specific user/post/order. For instance, you might want to send a welcome email to a user that logs in for the first time.
Another example is when you want to call an external API when an order is set to Completed. But it’s technically possible for a website administrator to manually change the order status back to something else, then again change it back to Completed. To avoid problems, you might want to ensure that the external API isn’t called again for the same order.
On (most) WunderAutomation triggers it’s possible to make sure that a workflow is only run once per object (order/post/user/comment etc.). Just check the "Only run once per [object]" checkbox.
Note. This can also be achieved by filters and actions checking and setting a custom field on the post/user/object that is triggering the workflow. Using the built-in checkbox is just a more convenient way to achieve the same thing.
Delayed workflows
Most workflows are meant to run immediately when the triggering event fires. But in some cases, it’s useful to delay the workflow a little bit. This is commonly used for various marketing automation workflows where you can ask a customer for a review after a set number of days after order completion. Another scenario is to send an auditing remainder email to the website administrator 30 days after a new user registers.
A workflow can be delayed by a set number of minutes, hours, days, or weeks after it was initially triggered. Please note that when the time comes to execute the workflow, the filters ARE NOT reevaluated again, the workflow actions are just executed directly. This behavior might change in future versions.