Triggers
Triggers are responsible for starting a workflow execution and inserting one or more objects into the runtime context. Trigger listens for various events that can happen on your WordPress site, for instance when a post is created or when a user logs in to the site.
Standard triggers
Most of the built-in triggers in WunderAutomation are tied to one of the core objects.
| WordPress object | Example events |
|---|---|
| Post | Created, Saved, Published, Saves, Trashed |
| User | Created, Logged in, Profile updated |
| Comment | Submitted, Approved, Status changed |
(for a full list of triggers, see the reference section)
Since WordPress uses the post object type to handle a lot of different things, like posts, pages, menu items etc, the post triggers can be used to handle a lot more than just blog posts.
WooCommerce triggers
WunderAutomation has built-in support for WooCommerce which uses the WordPress post object type to represent orders. But because a WooCommerce order has a lot of very specific behaviors and uses post comments in a very specialized way, there is an additional group of triggers for WooCommerce events:
| WooCommerce object | Example events |
|---|---|
| Order | Created, Completed, Cancelled, Paid, Saved |
| Order note | Order note submitted |
Incoming Webhooks
WunderAutomation supports using an incoming webhook (HTTP request) as a trigger. Each webhook has a URL that is used to start the trigger. Whenever an HTTP request is sent to the URL, the trigger fires and a workflow is started.
A webhook has some built-in security mechanisms, currently, Basic Auth, an HTTP header key or an HMAC signed header key. You can select to have all of the security mechanisms enabled, none of them or perhaps the most common, just one.
Note that webhook triggers are disabled by default but can be enabled either in the activation wizard when the plugin is first activated or directly on the WunderAutomation settings page.
Objects and the runtime context
Besides being responsible for starting a workflow, the triggers also insert the original objects into the workflow's runtime context. WunderAutomation automatically adds the relevant objects into the runtime context depending on the trigger. Each trigger type inserts different object types into the runtime context. For example, the Order Note submitted trigger fires when a new order note is added to a WooCommerce order and inserts a comment object and an order object into the runtime context.

Run once
Sometimes it can be useful to know that a certain workflow only ever runs once on a specific object. For instance, imagine a workflow that sends out emails to a certain group of people when the post is published. If the site administrator for any reason needs to put the post back into the draft status to fix a few issues and then re-publishes the same post 2 hours later, it's quite likely that you wouldn't want the same email to be sent out again.
To support this, WunderAutomation supports Run once:

WunderAutomation keeps track of when a certain post, user, or order has triggered a certain workflow. By using the Run once per [object type] checkbox, the specific workflow will only ever run once for the same WordPress object. Note that the Run once checkbox only applies to the primary (first) object that the trigger provides and that it only works with standard objects