Automated Approvals - Reference Document


Table of contents


Octopus’ Automated Approvals Solution enables you to effectively implement the global execution process of a request when an approval is required. 

This document will run you through the concepts that support this solution. It was developed in order to consider several approval modes that fulfill the organizational approval process and automate it through the Octopus request types, in this case service request, problem or change. 

We have written this document to introduce the approval concepts for service requests (SR), because of the constant challenge that they represent for the IT organizations. Approvals are also available in the Problem and Change modules, but they may work differently in these contexts. 

General Concepts

Overall, all the tasks required to complete an SR represent the global execution process of the SR (workflow). This process begins when a SR is submitted and ends when all tasks have been completed. 
In Octopus, it is split in two (2) phases: 

Initial Approval Phase

The objective of this phase is to obtain the approval(s) of all necessary parties before the request execution begins. If an approval is refused during the Initial Approval Phase, the SR is automatically canceled and the requester is advised by email.

This phase is optional and is not necessary when a SR does not require an approval. 

Execution Phase

The Execution Phase contains all required tasks to fulfill an SR and may also include approval tasks, by example when an approval is necessary before initiating some other tasks. Approval tasks inside the Execution phase will not automatically cancel the SR. 


Note: At least one (1) task must be active when creating a SR, and you must ensure that the automatic task sequence is running correctly to prevent the SR from blocking in the system. Otherwise, the task will require a manual intervention by the Service Desk, which could affect the processing targets.

Types of task

There are two (3) types of tasks : Approval, notification and Standard. They can be created : 

  • from an existing SR; or
  • from a SR type in Tools > Reference Data Management....

A task, regardless of its type, can be activated along with another (parallel tasks) or after another task is completed (task with dependencies).  

Visual explanation

Approval task

Task designated to an approver with the goal of authorizing work for an SR, whether in the initial phase or during the execution phase. See the Options section to learn about the available options for this type of task.  

Standard task

Task designated for a workgroup / assignee

There is an option (under Tools > Options) to automate the resolution of an SR once the last standard task is completed. This avoids over-target caused by manual resolution.

Approval Modes

In order to present the different approval modes, we will use the hierarchical model below, that will be the reference for the rest of this document. 

Hierarchical Approval Mode

Hierarchical Approval Mode is used in requests needing an approval from the requester’s manager. 

The requester's manager can be a department manager, or a manager identified directly in an Octopus user profile.

Visual explanation
In the example below, Carole is designated as the manager of the "Accounting" department. As Eduardo works in the same department, Carole is automatically designated as Eduardo’s direct supervisor in his profile. She will receive all the approval tasks for SR submitted by him, for himself.

Department Manager

User's profile

When an hierarchical approval task is activated, Octopus verifies who is the designated manager in the requester user profile and sends an approval request email. If the requester is an employee of the user (for example, an assistant who is applying on behalf of his boss), the system applies the rule as usual and sends an email notification to the immediate superior of the user, unless the "auto-approval allowed" option is checked in the approval task of this SR type. In this case, auto-approval will apply.

If someone is associated to a department but his manager is not the one designated in the Octopus department structure, you can identify a specific manager in the user profile (field below Department Manager radio button).

Hierarchical Approval Mode to a Group of Users

The Hierarchical Approval Mode to a group of users identifies an approver hierarchically higher than a user's manager that is a member of the same organizational unit. 

When a hierarchical approval task specifies a group, Octopus looks for an approver by going up the departmental structure of the user (sub-department, then department). When Octopus finds an approver who is a member of the designated group, an approval request email is sent to him. If no approver is found, the approval task is designated as being "without approver". 

The Hierarchical Approval Process is forced to respect the two level department structure of Octopus. 

Visual explanation
A service request is configured to be sent to a group called "Managers", whose members are department Managers. A user group was created in the Reference Data Management of Octopus and a hierarchical approval task designated to a group is created in an SR.  

"Managers" User Group  

Hierarchical task with "Managers" Group 

Octopus will apply the following logic to figure out whom to send the approval request to. 


If Octopus finds no one, the request will be flagged as without an approver and the request remains suspended. The Service Desk can monitor tasks without approver through a list to make sure that the delivery process is not blocked. The Service Desk can manually identify and assign an approver directly in the task. 

There are two (2) lists related to the approvals : 

  • Tasks Without Approvers
  • Tasks Pending Approval

These lists are available in the Library of Lists. To find out how to proceed, click on List Customization

Direct Approval Mode

The Direct Approval Mode sends the approval task to a group of users that are outside the departmental structure of Octopus. The designation of a group when this mode is invoked is mandatory. There are several approaches:

  • The group acts as an approver "pool" : Upon activation of an approval task, a notification email is sent to all group members. When one of them takes charge of the task, the other members are notified by email.
    • Check the option Approver Pool from Tools > Data Reference Management... > General > User Groups
    • Uncheck the option The user must select the approver from the approval task of the SR type
  • Select the approver from a Web form : The user will need to select the approver from a drop down list.
    • Check the option The user must select approver in the approval task of the SR type

    • Uncheck the option Approver Pool from Tools > Reference Data Management... > General > User Groups

  • Task is sent to all members of the group without email notification : All members see the approval task only from the Web Portal. 
    • Uncheck the option The user must select the approver in the approval task of the SR type
    • Uncheck the option Approver Pool from Tools > Reference Data Management... General > User Groups

If the group contains only one member, the approval request will be automatically sent to him. Using a group allows modeling of an approval to a "role" rather then to a specific person. If the group contains several members, it provides redundancy. 


What you need to know

A single approver who receives a request for approval with MailIntegration deployed, can approve by answering "yes" or "no" to the email. 

This option also works when the approval was first sent to a pool of approvers with these conditions:
  • The task has been assigned in Direct mode to an approver pool type group.

  • The task has not yet been assigned to a specific approver. 

  • The action of approving or denying the request will automatically assign the task to the respondent.

The Notifications section bellow will give more details on how this options works. 


Parallel Approvals

Parallel Approvals aim multiple approval tasks activated simultaneously; they allow combining the Hierarchical and Direct approval modes when required. Note that Parallel Approvals may be part of the Initial Approval, as long as all approval tasks are executed prior to the activation of the first standard task. 

Here is an example an approval task list that is part of the Initial Approval. Note that the first two tasks are activated, without preconditions. They are parallel tasks, and are activated at the same time. During the approval process, the request remains suspended and the first standard task is activated when both approval tasks are accepted. If at least one of the two approval tasks is refused, the request is canceled and a refusal notice is sent to the requester. 

Approval Task List - Initial Approval Phase


There are a maximum of four (4) approval task options, depending on the approval type chosen : 

Approval Task Options

Auto-Approval Allowed

Auto-approval is a concept reducing the hierarchical level required for approval. By example, a supervisor designated as an approver could be authorized to submit and approve some requests for himself without requiring his manager's approval. 

Here is an example to illustrate this function. Let’s assume that all procurement requests need the approval of a supervisor. A SR type "Procurement" is configured with an approval task under Hierarchical mode.

Eduardo submits a procurement request for himself. The system assigns an approval task to Carole.

But what happens if Carole, who is the Accounting department supervisor, submits a procurement request for herself ? Is an approval from her manager required? 

  • If the answer is yes, do not activate the Auto-Approval Allowed option. Octopus will send an approval request to Carol’s supervisor.
  • If the answer is no, activate the Auto-Approval Allowed. Octopus will auto-approve Carole's request.
Visual explanation

In the example below, Carole is designated as Accounting department manager. As Eduardo is part of that department, Carole is automatically designated as Eduardo's supervisor in his profile. She will receive all approval tasks of service requests that are submitted by him, for himself.

The Auto-Approval effects during the Execution Phase

The Auto-Approval works differently if the approval task is part of the Execution Phase. The system will not take into account the auto-approval option because it is estimated that decision-making is sometimes necessary for the continuation of the request. Therefore, the system sends an approval notification regardless of auto-approval option. 

Suspend the request during approval

Automatically suspends when an approval task is activated. This option is available for all types of approval tasks. 

The execution target (SLA) configured in Octopus for each type of SR determines the time allocated to the IT organization to deliver a SR. When the SR is suspended while pending approval, the counters are stopped and the time taken to approve the request is excluded in the SLA calculation. 

For example, the requester’s supervisor approval is required in the purchase of a computer, without it, no standard task can begin. The IT performance measurement will only start after the SR approval. 

The user must select the approver

Option allowing the requester to select the approver from a drop-down list, when submitting a request via the Web Portal. This option is only available with Direct Approval Tasks

When submitting his request, the requester is advised that an approval is required and that he must select the approver from a drop-down list: 

Visual explanation

This option is valuable when requesters know who can approve the request.

Cancel the dependent tasks upon refusal

Automatically cancels standard task(s) that have dependent approval task(s). Take note of the following behaviors: 

  • This option is the default selection when the approval task if part of the Initial Approval Phase; at this stage, a refusal to approve cancels the request and its tasks, whatever the dependencies are, and a "Request refused" notice is sent to the requester
  • The option is optional for task(s) outside the Initial Approval Phase; if the approval is refused, the system will send a notice to the Workgroup / Assignee of the request
Visual explanation

Approval task with the "Cancel the dependent tasks upon refusal" option


Automated email sent to an approver (or approver group) to advise him that a request is waiting for his approval or to the requester to advise him on the approval results. The notification templates can be modified from the Octopus Options. An Octopus assignee may also receive a notification about an approval; he must ensure to configure its notification preferences to receive it (see Wiki article Notification Type Definition). 

The various notifications are described below :

Approval request

This notice is sent to the designated approver during the Initial Approval Phase. Note that the email template is customizable in section Emails to users from Tools > Options...

Visual explanation

As described in the email, the approver can answer two (2) ways:  

  • In the Web Portal, he will directly access the Approval Task tab. He may approve, refuse or exchange comments with the requester before rendering his decision.
Visual explanation
  • ​By replying "yes" or "no" to the email, alone on a line. Adding a comment or a refusal reason must be entered below the answer. The proper functioning of an approval email requires that:
    • You have deployed Octopus MailIntegration program
    • The permission "Modify the approval fields of a task" is selected in the Octopus system account
Visual explanation

Request approved

This notice is sent to the requester to advise him that his request has been approved. 

Visual explanation

Request refused

This notice is sent to the requester to advise him that the request has been refused. The Approver can add a comment to explain the refusal. 

Visual explanation

Approver required

This notice is sent to all members of a user group when a Direct Approval Task is activated. The notice requires that one of the members take charge of the Approval Request. 

Visual explanation

Approval taken in charge

This notice is sent to members of a direct approval user group to inform them that the Approval Request has been "Taken in charge" by another group member.  

Visual explanation

Approval refused in a request in progress

As an approval task may be part of a request execution phase and being a prerequisite for one or more standard tasks, it may be useful to inform the group or the assignee of the request about a refused approval that could affect the process of the request. This notification must be configured by the assignee in his notification preferences. 

Note: It is important to understand Octopus behavior when an approval task is part the Execution Phase of a request (request in progress); a refusal will only affect the standard tasks having a prerequisite to an approval task, the request remains active, and only the "Approval refused in a request in progress" notification will apply. But when an approval that is part of the Initial Approval Phase is refused, Octopus cancels the request and notifies the requester with the "Request refused" notification. 

Approver required reminder

An automated reminder is sent to the approver until the task is completed. This reminder is sent by default every two (2) working daysContact us if you wish to set a different delay.

Visual explanation

Delegation of approvals

Allows delegating to another person the responsibility of responding approval requests that are normally submitted to an approver. 

The delegation can be configured by:  

  • The Service Desk, in the User tab of the Approver's user record
Visual explanation
  • The Approver himself, by changing his profile in the Web Portal.
Visual explanation

Note that the delegate will only be able to approve new requests. If there are pending approval requests at the moment of the delegation, they will have to be manually taken in charge and approved by the Service Desk. 
Forward an email of an Approval Request to a delegate will not enable the request approval again. 

Task Form

An Approval tab is added to the task form when a task is an approval task. The following illustration shows an approved task form.  

  • Upper Section:
    • Status: An action (approve or refuse) is required to modify the status of a task. This is true for all types of task
    • Type : The task type is specified. An approval task show the response status (Pending, Approved or Refused)
    • Approver: The approver identity is indicated, as well as the method of selection. In the example above, Pierre Lamoureux was selected by Octopus System.
  • « Approval » Tab 
    • Options Area : The mode (hierarchical or direct), the group (if applicable) as well as the selected options for this type of task are indicated
    • Response  Area : Describes the response status, the approver, the approval date and the source


In its Automated Approvals Solution, Octopus relies on the identity and role of the requester, not the user. Therefore, you should know that : 

  • If the requester is subordinate to the user (an assistant who is submitting a request on behalf of his boss, for example), an approval will be required even if 1) the user is an authorized approver; and 2) if an auto-approval is permitted for this type of SR.
  • If the requester is an authorized approver, submits a request on behalf of an employee and the auto-approval is permitted for this type of SR, he will not receive any task for approval and an approval activity will be automatically added in the activity log.

  • If the requester is an authorized approver and submits a request for himself, the same behavior applies.

  • If the requester is not an authorized approver and submits a request for himself, Octopus sends an approval task to his immediate superior.

See examples of different scenarios below.

Scenario #1

Hypothesis :

  • Sandra is Chantal's immediate superior.
  • David is Sandra's immediate superior.
  • Auto-approval is not permitted for this task. 

Chantal submits a request for Sandra. She is then the requestor. The web form confirms that an approval will be sent to David, because Chantal is not an authorized approver for Sandra. 

Result : 

  • The approval task is sent to David
Visual explanation

Scenario #2

Hypothesis :

  • Sandra is Chantal's immediate superior
  • Sandra has not immediate superior identified in her Octopus profile
  • Auto-approval is not permitted for this task

Chantal submits a request for Sandra. The web form confirms that an approver is necessary; Chantal cannot be designated, as she is not an authorized approver for Sandra. As Sandra has not immediate superior in her profile, Octopus could not identify any approver. 

Result : 

  • The approval task is generated without any approver. It will be visible in the "Task without approver" list.
Visual explanation

Scenario #3

Hypothesis :

  • Sandra is Chantal's immediate superior
  • David is Sandra's immediate superior
  • Auto-approval is not permitted for this task

Chantal submits a request for Sandra; the web form confirm that an approval will be sent to David, because he is Sandra's immediate superior. 

Visual explanation

Scenario #4

Hypothesis :

  • Sandra is Chantal's immediate superior
  • David is Sandra's immediate superior
  • Auto-approval is permitted for this task

Sandra submits a request for herself. Because she is the requester and the auto-approval is permitted for the task, no approval window appears in the web form.

Result : 

  • Octopus auto-approves the request. An auto-approval activity is added in the request activity log. 
Visual explanation



The Automated Approvals Solution requires good preparation so that the results of different approval scenarios are in line with expectations. Before going live, we recommend that you : 

  • Inform and train approvers in advance
  • Test in an environment other than production
  • Make sure that immediate superiors and department managers in Octopus are updated, in a manual or automatic manner
  • If a link is established with a HR system, work with the HR department to ensure integrity of the information that will be transferred in Octopus
  • Establish clear corrective procedures if anomalies are reported

If you want someone to help you with this solution, do not hesitate to Contact us.

Help us improve our articles

Help us improve our articles