Understanding triggers

In WunderAutomation, each workflow have 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 lets users build both simple and advanced workflows.

Trigger groups

When selecting the trigger in workflow, the triggers are grouped into different functionality 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 behaviour of the connected actions and parameters. Different triggers will provide different objects and will affect what kind of filtering and parameters that 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 will are able to 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 allows 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 of special behaviour 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.

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 to order status back 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 be also 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 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 behaviour might change in future versions.