Task Engine processing of tree branches continues until it runs out of nodes or encounters a deferred task. Deferred tasks are used when you want to pause processing in order to wait for another process to do something.
An example of this would be an approval. The process creates the approval (deferred) and waits until the approver responds with a choice of Accept or Deny (or something in-between). Another example is an Incident that is created and you want to pause processing to wait for some type of action/resolution on the Incident.
Deferred task processing will wait indefinitly until the destination process communicates back to Kinetic Task through it’s triggering mechanism. If you want to pause for a specified amount of time, there is a Wait node in the System Controls category.
Setting a Node to Deferred
When you configure a node to be deferred, make sure that the Defers box is checked.
When this box is checked, tree processing will stop on this branch, and the task instance will be put into a waiting status.
To have the engine keep processing, you need to create a trigger that the task engine processes to set the task instance into a completed status.
However, using different connectors, you can get around the requirement of having a Task Instance completed.
The arrows that connect the nodes on your task tree have a variety of options. First and most importantly, they provide direction for your task tree. Connectors, by default when a node is complete will move to the next node in line.
Highlighted connectors are in blue, while the rest are orange. To change any of the parameters of a connector just select and double click.
You can add a label to a connector, so that it is more descriptive when you look at the tree.
The default type is Complete, which means the connector progresses to the next node when the current node is set to complete. The other options are Update & Create.
Update – Normally only used with a defer task. The connector fires when the defer node is updated.
Create – This connector fires immediately when the node is created. Also normally used with defer nodes.
Besides the type, you can also limit connectors to operations involving data from the request and results from other nodes. For example an approval node that goes down on tree for “Approves” and another for “Denied”.
The Task Engine relies on triggers to communicate that something needs to be processed. Triggers identify the specifics of what needs to be processed, they are:
- Kinetic Submission
- The Node within the tree (specifically, when resuming processing for a deferral this identifies where to start again)
- Deferred Variables
- Action Type (directly corresponds to the types of connectors)
To identify which Tree/Node to affect, triggers need a token that uniquely identifies the deferred node. All deferred nodes provide a token. It is up to the handler for the specifics of how the token is communicated and stored. For example, the token for the approval handler is stored in the ng_EndpointSecret field on the base record for an approval (see the approval chapter for more details on use).
Triggers are created from a number of different sources.
- After a Kinetic Request submission is completed (creates a Root trigger)
- Create Trigger Handler
- Custom Remedy Workflow – Filter(s)
Sample Remedy Workflow
The Matrix training VM contains some sample workflow to help you understand how to create your own Triggers.