Runtime context ​

When a trigger is fired and a workflow is started. WunderAutomation creates a runtime context that holds all the relevant information about the workflow. WunderAutomation automatically adds the relevant objects into the runtime context.

For instance, when the User login trigger starts a workflow a user object is added to the context that can be used by filters and actions. If the workflow was started by the WooCommerce Order created Trigger, an order object is added to the workflow context. But another trigger, for instance, the Order Note submitted will insert other objects.

When selecting a trigger type in the workflow editor. the object types and names are described in the section Objects provided by this trigger:

Besides the objects added by the trigger, objects can also be added to the runtime context manually or as a side effect of some actions.

Automatically added objects ​

Besides the objects that are added by each trigger, WunderAutomation always adds a user object named currentuser. The currentuser object always represents the currently logged-in WordPress user.

For instance, when the site administrator edits a post object and saves it, the Post saved trigger may start a workflow and add a post object representing the post and a user object representing the post author. But the currentuser object will represent the user that just clicked the Save button in the WordPress admin UI. This makes it possible to change the workflow behavior based on who made the change and therefore triggered the workflow.

A workflow can be started without a user being logged in, this is most often the case when a workflow was started by a webhook, in those cases, the currentuser** object is still added but is empty. For instance, asking for the ID of the current user will return 0.

Manually added objects ​

You can manually add objects to the runtime context via the Add objects action that adds objects based on something that uniquely identifies it. Different object types can be identified by different parameters:

Objects added as a side effect ​

Objects can also be added to the runtime context by actions. For instance, the Create Post and Create User actions will add a post object and a user object respectively to the runtime context.

Actions that add objects to the runtime context will clearly indicate that at the bottom of the action step in the workflow editor UI. Here is what it looks like in the Create Post action.

Accessing objects ​

The objects that are added to the runtime context control the list of filters that are available in the following steps further down in the workflow. In the above example where the Order note submitted trigger inserted a comment and an order object, the UI will make it possible to use filters that work on the comment at any step in the workflow, because they will be added even before the first step is executed.

But when an object is added because of an executed action, only subsequent filters and actions can access that object. In short, you can't access an object before it's created.

Object naming ​

Most of the time, the objects in the runtime context will be named the same as their type. A Post object will have the name/id "post" and a User object will be named "user".

Note that since it's possible to have more than one object of the same type it's important to be careful when adding new