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 objects 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 is only executing actions on the post types you intended.

Post triggers provide 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 user’s 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 / Canceled This trigger fires when an order status is canceled and the status is changed to wc-canceled.
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 when 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.