It is fairly straightforward to have a node on a task tree create a record in a Remedy form. However, it is often desirable for activity on the record to cause an update back in the Kinetic Request system. For example, an incident is created via Kinetic Request, and part of your business process is to have updates to that incident passed back to the original request so they can be shown in a web portal to the customer.
Passing information from a record in a Remedy form back into a Task tree requires a few things. First, you need to pass a key (token) to the record in Remedy, so it knows what record to update in Kinetic Request. Second, you need to create a filter on the Remedy form that recognizes when the Remedy record has been changed and information should be passed to Kinetic Request. Lastly, you need a deferred node in your task tree to accept the information from the Remedy record.
For example, you might update the ValidationStatus on a request to inform a group it is now assigned to an Incident or to display a change in the Incident's Status.
There are examples of bits and pieces of these kinds of updates in the out-of-the-box product. In the next section I'll go through the specifics with our Kinetic Sample Incident form.
Note: A token uniquely identifies a node on a running task tree.
Below are the individual parts to set up passing a message from a Remedy form entry to a deferred node.
Passing a Token to the Remedy Form
The first step in updating a node in a task tree is to locate the correct node. When you create a deferred node in a task tree, the system automatically creates a unique token that is used to interact with the instance record (KS_TSK_Instance) of that node related to an individual request. With the token, you can create a KS_TSK_Trigger record that will interact with the specific instance record.
For this example, I'll be passing the token into a field called Link Id. On the KS_SAMPLE_Incident form this field is on the Integration Fields tab. If you have a homegrown system, you may need to add a specific field. It needs to be optional and length 128 (more than you need, but just in-case). It is normally hidden on the form. If you are using ITSM and use the Incident Interface Create form, you can normally use one of the SRM fields.
If you use our out-of-the-box Incident Create form we automatically put the token in the SRMSAOIGuid field which is passed directly to the same field on the HPD:Help Desk form.
Creating the Remedy Filter
Now that you have the token, you need to create a filter that creates an entry in the form KS_TSK_Trigger.
Things to consider:
- What conditions on the Remedy form should cause the filter to fire?
- What information will you send to the task tree?
Your filter must include two pieces of information at a minimum: the token value and the action_type you want to send to the node (usually "Update" or "Complete"). In addition, you will almost certainly want to send some sort of message to downstream nodes in order to let them know what kind of event has occurred in the deferred node. To do that, you'll need to send a message. To pass message information, you need to push data into the last_message field. This is a free-text field; it requires no special formatting.
In the example below, we're passing the Status of the Incident in the last_message field with an action_type of "Update".
If the action_type is "Complete" (which, of course, takes the node out of deferred status and forces it to complete), you can send much more information to the trigger entry in the form of structured result values, or what we call "deferred_variables."
To pass information to the deferred_variables field, which can then be used as a result set for other nodes and connectors it must appear in the following XML format:
<results> <result name='Validation Status'>Approved</result> <result name='Denial Reason'></result> </results>
Note: You cannot send deferred_variables to the trigger form when the action_type is "Update".
Sample Filter Settings:
Description - add a descriptive ID, reason, etc.
Creating the Task Tree Connectors and Nodes
Now that we have the filter pushing the message, the task tree needs to recognize and use the value to update the ValidationStatus. The easiest way is to hook an Update connector to an Echo handler that receives the message and then passes the value as a result to a submission update handler.
Here is the full tree:
Here is the configuration of the Echo node. It shows the correct syntax to get the message passed by the filter in Remedy.
With the message from the trigger now in the echo node, it can be referenced in the ValidationStatus field of the submission update node:
You can also see the correct syntax to reference the output of the Echo node.
One other possibility is to use the message as a qualification on an update connector. This allows you to pass a "variable" from your Remedy form and influence the path that a task tree takes. This is also possible with results passed to a completed deferred node.