Skip to main content

IMPORTANT - Product End of Life Statement - IMPORTANT

Request RE, Survey, and Calendar 1.5 Support Ending December 31, 2020
Contact Kinetic Data Support with Questions
Kinetic Community

15. Nodes and Connectors

How to Parameters, Deferred Nodes, and Connectors

Node Parameters

The wide variety of available inputs is one of the things that makes the task engine so flexible. Besides just accepting information about the request (answers, attributes, etc) it can accept results and outputs from other nodes in the same and other trees.

Application Config Values - Select the Mid-Tier or web server values

Service Item Answers - answers from your request

Service Item Dataset - attributes of the request

Service Item Template Fields - other fields associated with the request base record

Task Results - returned values from nodes in the tree.

Parameter Expressions

The format of the input in a parameter is called IRB and the values between the <%= and %> get evaluated as Ruby code. This means that you can put basic code (and comments!) inside a parameter field. ne of the most common examples is an if statement. It would look something like this:


# comment - please please comment

if @answers['Status']=="Contractor"

   @answers['End Date']





Notice that the <%= %> only need to be around the entire statement, not each added answer.

Deferred Nodes

Deferred nodes create a pause in processing of the task tree while some other process completes. The most common example is the approval node - it must wait until the approver responds. Another common example is the creation of an Incident. The task tree waits until the Incident gets to a certain status before continuing. In each case the task engine needs a trigger to be created to tell it to continue processing. The trigger identifies the deferred node by a token (unique identifier like a Remedy instanceId) and perhaps passes it some information to be used by other nodes and connectors in the tree.

Deferred nodes have a check in the defer check box on the top right of the node.

This process is discussed more in the Approval chapter.


The arrows that connect nodes have a variety of options. First, they connect the nodes in a set direction. Second, they allow you to use expressions to limit which connectors are used. Lastly, there are three different types of connectors to give you more options when creating trees.

The three types of connectors:

Create - connector fires when a node is first created. Useful to continue a tree when a deferred node first fires.

Update - least used connector, normally used to update a message or send a notification when an update trigger is processed.

Complete - default type - moves to the next node when the current one is complete.

Each different type of connector has a different presentation on the tree, from solid for complete to dashed for create.

You can move connectors from node to node by clicking on the end (either one) and moving into a new node.

Connector Expressions

Placing expressions on connectors allows you to determine what branches of a tree are processed. They use nearly the same format as expressions in parameters. The main difference is you do not need the <%= %> around them. The most common expression is to check far a value. For example, checking the result of an approval.

@results['Approval Node']['Validation Status']=="Approved"

Expressions can be more complex, but it is not as common in Connectors as it may be in node parameters.

If you put an expression on a connector, always put a label on so it is apparent when that connector will fire. It also helps with troubleshooting.



Activity Fourteen - pass results to a deferred node