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

Confirmation link triggers #

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