Built in triggers

Post triggers

Trigger Description
Post / Created This trigger fires when a post object (post, page, custom post type etc.) is first created. Note that at this stage the post will most likely be in a draft status. Setting a trigger at creation might be too early for many workflows.
Post / Pending This trigger fires when the status of a post object (post, page, custom post type etc.) is changed from any other status to status = pending.
Post / Published This trigger fires when the status of a post object (post, page, custom post type etc.) is changed to published.
Post / Privatized This trigger fires when the status of a post object (post, page, custom post type etc.) is changed to private.
Post / Trashed This trigger fires when the status of a post object (post, page, custom post type etc.) is changed to trash.
Post / status changed This trigger fires when the status of a post object (post, page, custom post type etc.) is changed to a new status
Post / Saved This trigger fires when a post object (post, page, custom post type etc.) is saved. Note! WordPress stores a lot of data as posts which means this trigger will fire often. Make sure to use strict filters, typically including "post type" to make sure your actions only run when you expect them to.

Note that the post object in WordPress are used for many other things than just traditional blog posts or pages. Whenever you use a post trigger, make sure to use the "Post Type" filter to make sure your workflow are only executing actions on the post types you intended.

Post triggers provides the following objects:

Object Description
post The post that had was updated / saved / trashed etc.
user The owner of the post

User triggers

Trigger Description
User / Created This trigger fires when a user account is created.
User / Login This trigger fires when a user logs in
User / Profile updated This trigger fires when a user profile is updated
User / Role changed This trigger fires when a users role is changed

User triggers provide the following objects

Object Description
user The user that was created / updated or logged in

Comment triggers

Trigger Description
Comment / Submitted This trigger fires when a new comment is submitted
Comment / Approved This trigger fires when a comment is approved
Comment / Status changed This trigger fires when the status of a comment is changed

Comment triggers provide the following objects

Object Description
comment The comment that was submitted / approved etc
post The post that the comment is attached to. For a normal comment, this is the blog post or page. For a WooCommerce order note, this is the actual order

The confirmation link triggers all work the same, the only real difference between them is the object types they provide to the rest of the workflow. The type of trigger is really determined when the confirmation link is created and that in turn depends on the confirmation link parameter that was used. The main reason to differentiate between different types of confirmation link triggers is to make the workflow editor UI aware of which filters and parameters that will work.

Trigger Description
Confirmation link / Post Provides a Post object (main) and a user object
Confirmation link / Order Provides a (WooCommerce) order object

WooCommerce order triggers

Trigger Description
Order / Created This trigger fires when an order is first created and is assigned an id. Note that at this stage the order is still editable regarding order items, payment method, payment status, fees etc. Setting a trigger at creation might be too early for many workflows.
Order / On hold This trigger fires when an order status is changed to on-hold
Order / Pending This trigger fires when an order status is changed to wc-pending.
Order / Processing This trigger fires when an order status is changed to wc-processing, meaning that payment is secured but before the order is marked as complete. Note that in some setups, i.e via the plugin ‘ WooCommerce Order Status Control’, order status may change directly from pending to completed which means that this trigger will never fire. If that is the case in your setup, consider using the trigger ‘Order Paid ‘ instead.
Order / Paid This trigger fires when an order is paid, meaning that the actual order status is changed from a non paid status (new, on-hold, pending etc.) to a paid status (processing or completed).
Order / Completed This trigger fires when an order status is changed to completed. This normally happens after payment is secured and the store owner then manually sets the status from processing to completed.
Order / Cancelled This trigger fires when an order status is cancelled and status is changed to wc-cancelled
Order / Failed This trigger fires when an order failed and the status is set to wc-failed.
Order / Refunded This trigger fires when an order status is refunded and status is set to wc-refunded
Order / Saved This trigger fires an order is saved (updated). Note that during the life cycle of an order, this trigger will fire multiple times, for instance every time the status changes.

Order triggers provide the following objects

Object Description
order The order that was updated / saved / had a status change

Order Note trigger

Trigger Description
Order Note Submitted Fires when a new order note is added to an order

Please note that many order notes are created automatically as part of the order management process. Besides the order notes for status changes most payment gateways also add order notes. The only real way to filter different automatic order notes from manually written notes is to filter on the content of the note.

Order note triggers provide the following objects

Object Description
comment The order note is actually a WordPress comment object, so the order note is provided in the form of a comment.
order The order that the note was added to