Skip to main content
Kinetic Community

Create an Incident and Pass Status Updates to Request

Your Business Requirement is to provide the end user with an easy way to Submit an Incident, view the Status updates of that Incident, and receive an Email Notification when the Incident is Closed or Rejected.

Usage

This process will allow you to display the current Incident Status to the end user and also send a notification once the Incident is Closed or Rejected.

Example

The following example will work only if your Business Process is to only create one Incident

To accomplish this you will need to:

  1. Build a Service Item
  2. Create a Filter to Generate a Trigger
  3. Build a Task Tree

Build a Service Item

The Service Item named Incident Create (KURL file:  IncidentCreate.rb) has been exported and attached to this article.  As you can see this Service Item is very simple and easy to use.  This action was done to meet the requirement of an easy way for the end user to Submit an Incident.  The Service Item contains three questions:

Each of these three questions will be pushed into the KS_SAMPLE_Incident form via the Create Incident Node shown in the Task Tree below.

Create a Filter to Generate a Trigger

The Service Item will be pushing data into the KS_SAMPLE_Incident form and now we need to add a Filter to this form in order to push the Status changes back to Kinetic Request/Task.  This action will help to meet the need of displaying the Status updates to the end user.  As the building this Filter is described in detail in another article I highly suggest you review it:

http://community.kineticdata.com/20_Kinetic_Task/Solutions/Passing_a_Message_to_a_Deferred_Task

I will now show how I used the concepts discussed in that article in order to build a Filter against the KS_SAMPLE_Incident form.

The Filter I created is attached to this article and is called KS_SAMPLE_IncidentContinueDeferredTask_StatusUpdate.  Feel free to download and import this Filter into your environment.  This Filter is used to push any Status change back into Kinetic Request/Task so that the Status value can be used by a Task Tree.

This Filter is configured to Execute On any modification of the Record with the following Run If Qualification:

( 'TR.Status' != 'DB.Status') AND ( 'Link Id' !=  $NULL$ )

*Note that the Link Id field is populated only when the KS_SAMPLE_Incident record is created by Kinetic Request/Task.  As you are more than likely not using the KS_SAMPLE_Incident form in your process you will want to use some other Run If Qualification to ensure that this Filter only Fires when the Record was created by Kinetic Request/Task.

This Filter is configured to Push to data into the KS_TSK_Trigger form and create a Record with the following Field Mappings:

action_type = Update

last_message = $Status$

token = $Link Id$

Please take note that the action_type field is being set to Update.  This will create an Update Trigger and will follow the Update Connector coming from the Create Incident Node.

 

Build a Task Tree

The Task Tree will meet the needs of creating an Incident, processing the Status updates from the Incident, and then providing an Email Notification when the Incident is either Closed or Rejected.

The Task Tree built for this process will end up looking like the following:

 

The Node Names used in the Task Tree are using the following Handlers:

Create Incident - (kinetic_sample_incident_create_v2)

Status: Incident created - (kinetic_request_submission_update_status_v1)

Get Status from Incident - (utilities_echo_v1)

Set Status - (kinetic_request_submission_update_status_v1)

Status Closed - (kinetic_request_submission_close_v1)

Notification: Closed - (bmc_remedy_email_message_create_v1)

Complete Create Incident Closed - (utilities_create_trigger_v1)

Status Rejected - (kinetic_request_submission_close_v1)

Notification: Rejected - (bmc_remedy_email_message_create_v1)

Complete Create Incident Rejected - (utilities_create_trigger_v1)

The Tree shown above is fairly simple however, I want to give some explanation around the use of the Nodes and the Connectors in order to give you a better idea of what is occurring.

Create Incident - This Node is taking the Answers populated in the Service Item and using those Answers to populate the KS_SAMPLE_Incident form.  This Node is also configured to be a Deferred Node.  This Node is Deferred because it is waiting for the Status updates from the Incident which are coming from the Filter we built above.

One quick item to note is that the Handler will search the KS_SAMPLE_People form using the value you enter into the AR Login Question and then use that data to populate the Incident Form.  Therefore you will need to create a record in the KS_SAMPLE_Incident form so that it is able to find a matching value.  If you do not create the People record you will have Task Tree Exceptions.  The fields you will need to populate on the KS_SAMPLE_People form are:

AR Login

Name

Phone

Last Name

First Name

Email Address

This Handler was modified in order to include the Deferral Token as a Result of the Handler.  This action is required in order for the Complete Create Incident Closed and Complete Create Incident Rejected Nodes to be able to find and Change the Status of this Handler.  Please note that you will also need to modify the Handler that is creating your "Incident" in order to have the Deferral Token included in your Results.

To make this change you will need to update the <results> section in the init.rb file as shown below in Yellow:

    # Return the results
    <<-RESULTS
    <results>
      <result name="Entry Id">#{escape(entry.id)}</result>
      <result name="Deferral Token">#{escape(@parameters['deferral_token'])}</result>
    </results>
    RESULTS
  end

 

Status: Incident created - This Node is connected to the Create Incident Node with a Create Connector.  The reason for the Create Connector is because we only want the Status:  Incident created Node to be called after the Create Incident Node is created.  By using the Create Connector we are ensuring that the Update Triggers will not call this Node.  The purpose of this Node is to set the initial Validation Status of the Request Submission.  In this example I have set it to Incident created but, you can choose any other value in order to meet your Business Requirements.

Get Status from Incident - This Node is connected to the Create Incident Node with an Update Connector.  The reason for the Update Connector is because we only want the Get Status from Incident Node to be called after the Update Trigger is created from the Filter we built above.  The purpose of this Node is to get the value stored in the Message field on the KS_TSK_Trigger form.  Note that the Trigger form record was created by our Filter and that Filter is pushing the Status from the Incident into the Message field.  Now that we have the Status value we can proceed down the different Branches of our Tree.

Status Closed - This Node is connected to the Get Status from Incident Node with a Complete Connector labeled Closed.  This Connector contains the following Qualification:

<%=@results['Get Status from Incident']['output']=="Closed"%>

As you can see from the image above the Status Closed Node is setting the Validation Status to a hard coded value of Closed.  Whereas the Set Status Node is setting the Validation Status to the Result returned by the Get Status from Incident Node.  I did this to show that you can either set the Validation Status equal to the value in the Incident or you can hard code a value if required.  For example, if your Incident form has a Status value that you don't like you can hard code your own Validation Status to be something more user friendly.  If instead of Closed you wanted the Validation Status to be Completed this is a good way to control the Validation Status.

Notification: Closed - This Node is connected to the Status Closed Node with a Complete Connector.  There is no qualification on this Connector as it should occur each time the Status Closed Node is called.  This Node is used to meet the requirement of sending a Notification when the Incident is Closed.

Complete Create Incident Closed - This Node is connected to the Notification: Closed Node with a Complete Connector.  There is no qualification on this Connector as it should occur each time the Notification: Closed Node is called.  This Node is used in order to change the Status of the Create Incident Node from Work In Progress to Closed.  As the Create Incident Node is Deferred and because our Filter is passing an Update Trigger this Node will never be set to Closed.  Therefore this Node is creating a Complete Trigger which will change the Create Incident Node Status to Closed and complete this process.

Set Status - This Node is connected to the Get Status from Incident Node with a Complete Connector labeled Other.  This Connector contains the following Qualification:

<%=@results['Get Status from Incident']['output']!="Rejected" && @results['Get Status from Incident']['output']!="Closed"%>

The reason for this Qualification is because we only want the Set Status Node to run if the Incident hasn't been Rejected or Closed.  Therefore if Incident hasn't been Rejected or Closed then we are using this Node in order to set the Validation Status to the result returned by the Get Status from Incident Node.

Status Rejected - This Node is connected to the Get Status from Incident Node with a Complete Connector labeled Rejected.  This Connector contains the following Qualification:

<%=@results['Get Status from Incident']['output']=="Rejected"%>

As you can see from the image above the Status Rejected Node is setting the Validation Status to a hard coded value of Rejected.  Whereas the Set Status Node is setting the Validation Status to the Result returned by the Get Status from Incident Node.  I did this to show that you can either set the Validation Status equal to the value in the Incident or you can hard code a value if required.  For example, if your Incident form has a Status value that you don't like you can hard code your own Validation Status to be something more user friendly. 

Notification: Rejected - This Node is connected to the Status Rejected Node with a Complete Connector.  There is no qualification on this Connector as it should occur each time the Status Rejected Node is called.  This Node is used to meet the requirement of sending a Notification when the Incident is Rejected.

Complete Create Incident Rejected - This Node is connected to the Notification: Rejected Node with a Complete Connector.  There is no qualification on this Connector as it should occur each time the Notification: Rejected Node is called.  This Node is used in order to change the Status of the Create Incident Node from Work In Progress to Closed.  As the Create Incident Node is Deferred and because our Filter is passing an Update Trigger this Node will never be set to Closed.  Therefore this Node is creating a Complete Trigger which will change the Create Incident Node Status to Closed and complete this process.

Following the process described above we have now created an easy way to submit an Incident, display Status Updates, and send notifications based on Closed and Rejected Incidents.