Workflow processing only stops for a few reasons:
- A branch (or connector expression) resolves to
- There are no more nodes to process
- The engine encounters a Deferred Node
Deferred nodes are used in workflow to wait for a response from another process. A common example is an Approval. An approval node should create the approval, but then wait for the decision before continuing processing.
Most nodes that are meant to be deferred are already setup to default that way as Handlers. If you need to make a choice to set the node as deferred, or not be deferred, the selection is made on a checkbox on the node itself. This is managed after (not during) node creation.
The above is the Defer node from the System Controls category in Task.
Deferred nodes show a blue corner on the node. It makes them easy to find on trees.
When the Task Engine encounters a deferred node, it completes the function of the node (approval, record create, notification, etc), and then it stops and waits for a trigger to complete the node. In a Run, the node (shown as a Task) has a Status of "In Progress" until a Trigger completes it.
Once a node has stopped workflow processing, there is only one way to get it to resume, a Trigger. Resuming a deferred node takes two pieces of information:
- Token. Unique identifier that allows the engine to find the specific instance of the node.
- Action Type. Choice of Update or Complete. This determines the action the workflow engine takes on the deferred node instance.
- Update. Used to fire Update connectors attached to the deferred node instance. It can also pass specific messages.
- Complete. Used to complete the deferred node instance, and fire attached Complete connectors.
Here is a screenshot of the Create Trigger Node from the Tree Builder.
You can also use the Task API to update or complete deferred nodes (tasks).
One of the benefits of a deferred node is passing information from the system that is creating the trigger to restart the deferred node instance. Information can take the form of either Results or Messages. In general, Results are used in the workflow, and Messages are simple statements used to notify an interested party.
Results have a specific XML structure:
<results> <result name="Approval Decision">Denied</result> <result name="Approver Name">Anakin Skywalker</result> <result name="Date">1999-05-19</result> </results>
The outer tag must be results, and all the inner tags are the singular result. The name is what is used to identify the result in a parameter in a node or connector farther down the tree.
<%[email protected]['Approval Create']['Approval Decision']%> returns Denied if the results above were used.
Messages are simpler because the format is plain text. You can also put the message directly in the parameters for it on the node (and take advantage of all the other options available to nodes like values or results).
The different options (Create, Update, and Complete) match when Connectors fire. See below.
As mentioned above, Update and Complete actions on deferred nodes can fire different types of connectors. The default connector between nodes is a complete connector, firing when the node is complete. But there are two other types of connectors to use with deferred nodes.
The first type is the Create connector. This connector fires when the deferred node first completes its action (an approval, or record creation for example) and then waits for a response (defers). Many workflows want to fire another action at this time and the Create Connector allows them to do this.
The second type of connector is the Update connector. It fires when an Update action is sent to an instance of a deferred node. This connector is often used to send messages or keep customers informed of changes to a process that was started by a deferred node.
Below is a simple example tree using all three typoes of connectors, Create, Update, and Complete. You can distinguish them by the makeup of the arrow.
Create is dotted. Update is dashed. Complete is a solid line.
Updated 11 months ago