Skip to main content
Kinetic Community

7. Approvals

Many requests require some form of approval before they can be completed. Kinetic Request allows an approval process to be added to a service item to manage this process. In this chapter, you will add an approval service item and task process.

Parts of the Process

There are many different ways to use approvals in Kinetic Request and Kinetic Task. However, most break down into a similar process, a submission triggers a tree that has an approval included, an approval form with information about that original submission is sent to a designated approver, the approver responds, and the response is sent back to the original tree for follow-up actions.

The first part of the approval process is the original form. Important to make sure you have all the information needed for and about approvers.  The original requester needs to be able to both accurately define what they want, and the approver needs enough information to make their best judgment. Most of the information about approvers is collected in the task tree, so make sure that it is available and can be accessed. An approvers Id or perhaps a group of Ids is often enough.

The second part is to add the approval routine (and any accompanying process) to your task tree. This is often the most difficult part of the process because it involves both business and technical inputs.

The third part is determining how to display information to the approver. Our "normal" process is to use a generic approval form. It includes a review submission section and all of the questions an approver needs to indicate if the request is approved or denied. Be prepared to modify this form for your specific needs.

The fourth part of the approval process is the approval task tree creation. While normally a small tree, it can include some business processes.

The last part of the process is notifications.  Will showing the approval on a portal page be enough for your customers, or will they need email or some other form of notification?

Designating Approvers

Designating occurs through a variety of ways.  Normally, the approver is identified by the person filling out the request. It could be their manager or someone selected from a list. Alternately, it could depend on a site or product or process.

Basic Approval Tree

Because everyone has a different process everyone's tree is going to look very different. Below is a very basic tree that includes an approval routine and a choice of paths depending on the response of the approver.

Example of basic approval process

Add tasks to perform lookups to establish who the approver should be. 

On occasion, a Task Handler may need to be created to accommodate complex approval routing rules.

Adding the Approval Routine

Here is an example of the approval routine.

This is a basic approval routine that sends a notification to the designated approver.

At the most basic, an approval creates a submission that is designated for a specific person. The routine was created specifically so that pieces can be changed out and customized to your process.

Description of Nodes

Retrieve Approver - collects approver information (notification and other specifics). Default is for the User record in Request Ce, but can be altered for other systems as needed.

Retrieve Kapp - collects Kapp information for notifications and review on the Approval Template.

Web Server URL - this URL is used to create the review link on the Approval Template.

Defer - pause the routine while approval submission is created.

Create Approval - creates an submission record in Request CE using information from previous nodes. See more details below.

Email Approver - standard notification to approver. Can substitute other methods, but may need to update previous nodes to collect appropriate information.

Retrieve Approval Answers - used to both get the approvers decision, and to add some extra detail to put in notifications to users or pass back to the parent tree.

Close Approval - sets the State of the approval to Closed, and sets a Status to Approval decision (Approved/Denied).

Return - passes information back to the parent process for notifications or process.

Inputs to the Approval Routine

The current Approval Routine needs the following inputs (optional unless marked):

Space Slug, Kapp Slug, Form Slug (required) - used to both define the approval form, and get information on the environment

Approver Id (required) - pass in the key to lookup information on the approver

Summary (required) - short description for the approver in case you don't want to use a review link

Details (required) - longer description for the approver

Originating System - Used to determine some lookups

Originating ID - Id of the parent (I would consider this one required)

Review URL - url used for the review of the originating submission

System Input - type of System

Outputs from the Approval Routine

These are the values passed back to the parent tree:

Decision - response from the approver

Approver ID - ID of the approver (sometimes this changes)

Denial Reason - often a reason is required for denials

Comment - additional comments/information

Approval ID - submission ID of the approval

Create Approval Node (Submission Create Handler)

Space Slug - can be set from input - or leave blank if the same

Kapp Slug - identifies the Kapp that holds the approval template

Form Slug - slug of the approval template

Values - set answers on the approval template - set as a json map

Current Page Name, Current page Navigation - normally blank based on a one page template

Origin ID, Submission ID - ID of the parent submission (these are Kapp fields)

Approval Template

The approval template has a couple of generic sections used in the approval process.

Request Details:

A section that pulls in the Summary and details from hidden questions. It also includes a button that will open a review version of the original submission.

Approval Details:

Section that holds the actual approval question and denial and other comments.

Hidden Fields:

Hidden section holding values passed from the Create Approval node. These values are used for display and processing workflow.


Basic text thanking the approver. You normally overwrite the default confirmation page for approvals.

Creating the Approval Submission Branch

While the Approval Node will create an approval record, once the approval is complete you are responsible for creating a trigger that prompts the original tree to complete the approval node and continue processing.

A typical Approval Tree is just the node that creates a trigger based on the deferral token from the Create approval node.



There is a wrap up activity to create a service item and the approval.