Approvals are used to authorize operations, process stages, and validate decisions that require additional control by responsible users (also known as approvers). Approvals are obligatory for normal and emergency changes, absences, vacations, etc. They help to minimize risks, keep high-level service, and conduct secure processes.

Example

The out-of-the-box ITSM application has a predefined approval process for implementing a new request template. Before implementation, it must be approved by the service owner. The owner of the service is identified by a reference in the Service category field.

After filling in the fields, an agent switches the state from New to Waiting for approval.

The approval rules are the following:

  • the approval is created only when the request template is in the Waiting for approval state.
  • the request template is rejected if one of the approvers rejects their ticket.

The service owner decides whether to implement the request template or return it for further improvement.

  • If the template is not approved, it goes to the New state and must be deleted or improved and submitted for approval again.
  • If the template is approved, it goes to the Published state.

Conclusion:

The approval phase ensures the quality and protects the system from implementation of inappropriate elements. The request template cannot be implemented until the service owner or all owners approve it.

You can implement approvals to any table according to your business processes. Approvals are automatically created according to an approval rule or within a workflow with the User-approval activity.

Approvals associate users or groups with a record to be approved. If users reject an approval, they need to give a reason in the comment.

When a new approval is assigned to a user, they are notified via email.

See the My Approvals article to learn how to process approvals via the Self-Service Portal.

If you create a new custom table and set up approvals for it, you need to define the portal approval card appearance from scratch. As this table is new, the system does not have information about the fields to display on the portal. 

Approvals


To view the list of created approvals, navigate to Approvals → All Approvals.

On the approval form, the following elements are displayed:

  1. The summary of the approval item.
  2. The task info.
  3. The Comment field.
  4. The Activity Feed.

Approval states

The approval state flow is as follows: 

But the state flow may differ depending on the abortion rules. For example, if the abortion rule is One of the tickets rejected, when one of the approvers rejects the ticket, the approval changes to the Canceled state.

Other states may depend on issue types and their state models. For example, approvals for a change request have another state flow defined by its workflow. In the approval phase, the change request is in the Authorization state. If the request is approved, its state changes to the Scheduled state; otherwise, it returns to Registered.

Approval tickets


In SimpleOne, submission of a record requiring authorization initiates the transition stage. Approval tickets are sent to all persons responsible for approval. In tickets, every recipient is proposed to approve or reject the request.

An approval ticket is a record in the Approval (sys_approval) table, which the system sends to every user responsible for approval: one ticket per user, that is, one approval may contain several approval tickets. It is the ticket you see on the My Approvals page. In other words, a user approves or rejects a ticket within one approval.

Approval sets 


An approval set is a group of Approval (sys_approval) records created by the same approval rule for the same item. That is, these approvals share the same values in the Item field, same approval rules, and are included into one approval set. There is no set number for the approvals created by a workflow. 

Example:

An approval rule has an abortion rule: one of the approval tickets is rejected. The system creates Approval Set 1 when the approval rule conditions are met. If one of three approvers rejected their approval ticket, some required changes need to be done. When the changes are made, the approval is requested once again. The system creates Approval Set 2, and all three approvers receive approval tickets. This process repeats until the conditions are met (all users approve their tickets).


Create an approval


Approvals cannot be created manually. They are created by the system when the conditions defined in an approval rule or a workflow are met. That is, there are two ways to implement approvals into your processes:

  • via the approval rules.
  • via the Workflow.

Approval rules


An approval rule is a flexible tool that triggers on a predefined event. Once triggered, it sends a set of approval tickets and the process feedback (approves and rejects). Approval rules can also automatically create a set of approvers.

The following diagram illustrates the process of creating an approval based on an approval rule.


Role required: admin.

To create an approval rule, complete the steps below:

  1. Navigate to Approvals → Approval Rules.
  2. Click New and fill in the fields.
  3. Click Save or Save and exit to apply the changes.

Approval Rule form fields

FieldMandatoryDescription
NameNSpecify an approval rule name.
TableYSpecify a table that is processed by this approval rule (for example, Incident).
DescriptionNType the approval rule description in details.
Approve conditionN

Define an approval rule start condition. When the conditions are met, the rule sends approval tickets.

An empty condition always returns true.

ApproverY

Specify the category of users responsible for the request approving. Available choice options:

  • Users
  • Group
  • Script
UsersNIf the Users option is selected in the Approver field, choose one or more users responsible for the approval process.
GroupNIf the Group option is selected in the Approver field, select a group responsible for the approval process. All the group members have the approval tickets to process.
ScriptN

If the Script option is selected in the Approver field, enter a script that extends the approval condition: define the users who will receive approval tickets. You can use SimpleOne server-side API.

Example:

Script
(function approvalRuleScript(current) {
  if (current.assignment_group) {
    return current.assignment_group.getValue('responsible');
  }
})(current);

The approvalRuleScript() function returns data in one of the following formats:

  • return '156956878014585856';
  • return ['156956878014585856', '156956851511250859'];
  • return '156956878014585856,156956851511250859';

Approval abortion rule

Y

Specify the condition for rejecting the approval request. Available choice options:

  • More than half tickets rejected 
  • Set rejected tickets limit
  • All tickets rejected
  • One of the tickets rejected
CountN

Specify the limit of the rejected tickets for the approval request reject.

The field appears if the Approval abortion rule field value is Set rejected tickets limit.

ActiveNSelect this checkbox to activate the approval rule.

The server-side business logic may not work for system tables if the creation or updating of records is initiated by the backend. For example, an Import Set is created as part of loading an Import Source, or an Email is created as a result of a notification rule, and so on.

A list of table examples for which server-side business logic may not work:

  • Main Log (sys_log)
  • Script Log (sys_log_script)
  • Exception Log (sys_log_exception)
  • Record Deletion Log (sys_record_deletion_log)
  • Import Set (sys_import_set)
  • Activity Feed Item (sys_activity_feed_item)
  • Email (sys_email)

Workflow


You can implement automatic creation of approvals using the User-approval activity in your workflow

The following example shows a simple process for approving the inclusion of a new partner to a custom table. The flow begins when a new record is inserted into the Partner table. By default, new records are in the Pending state. To activate the partner record, the approvers should confirm its state. This is when the user-approval activity is used. Before the record state changes to Relevant (the Set Values activity), all approvers must confirm that the new partner is relevant and that its record can be transferred to the Relevant state. If one of the approvers rejects the approval, the state of this partner record is Canceled.

See the Workflow articles to learn more.

When you add an approval via the workflow, there are no related records in the Approval Rule table. Editing the conditions for creating this approval and other attributes is available only through the relevant workflow.

Track an approval

If an approval is created for a particular record, it is displayed in the Approval related list. Custom tables may not have this tab. Use the related list configuration to display all the related approval tickets. After that, all related approval tickets will be displayed.

In the example described above, a new record in the Partner table with the Pending state has the following Approval related list:

See the Related Lists article to learn how to add the Approval tab to the Related Lists area.

  • No labels