Introduction

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 phases: 

Initial Approval Phase

The objective of this phase is to obtain the approval(s) of all necessary parties before the request execution begins. All tasks in the execution phase must be dependent on those in the initial approval phase. 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. 


 

Types of Task

There are two 4 types of tasks : Approval, Notification, Execution and Standard. They can be created : 

• From an existing SR
• 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).  
 

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.
 

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. 

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
  • This type of approval can work with MailIntegration. See the Using MailIntegration with approvals section below for more details. 
• 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 which is not a manager of the group, 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. 

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

Options

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.

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.

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 an approval task has the following options and the requester is considered a potential approver, the system will select the requester by default:

• Auto-approval allowed
• The user must select the approver

If necessary, the requester can review the selection and modify it, or do nothing and leave the value assigned by the system. In the latter case, the task will be auto-approved by the requester. In the scenario where the requester is not authorized to approve the request himself, then an approver will have to be selected from the available list.

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: 
 

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

The User Must Select the Approver - With Multiple Approvals

If a request has more then once approval with the xxx option, they will be visible on the Portal to allow the requester to make the selection. Except if a group has only one member, in which case that person will automatically be designated as approver. 

If a group is empty, the request to select the approver will be visible, but none will be available. This will result in the requester's need to communicate with the appropriate Service Desk since he will not be able to complete the request. 

Tasks will be presented to the requester according to their level, so if there are two sets of approval, the first level approval will be followed by the second levels, and so on. 

If the request is completed directly in Octopus a message will indicate to the Octopus user that a selection of approvers is required. 

In this context the subject of the tasks are very important as they indicate to the request the approval reason he is selecting an approver for. 

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

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

How to respond to an Approval?

There are three ways to process an approval:

• Directly connected to the Web Portal to respond. 
• When the method using links is configured, by clicking the corresponding link in the approval email.

• When MailIntegration is configured, by replying to the approval email with yes or no. In this case, the comment will not be sent to the applicant.

It is also possible for the approver to communicate directly with the Service Desk to process the approval manually.

But this option is considered a workaround when there is a problem and not a method to use on a regular basis.

Directly from the Web Portal 

The approver can login to the Web Portal and directly access the Approvals section.

He can approve, refuse or exchange comments with the requester before making his decision.

Using Links in the Approval Email

If MailIntegration is not configured or if users prefer to use links in the email to respond, this method can be used.

It consists of adding tags to the approval email that are presented to the approver in the form of links. 

When the link that represents the Approve or Refuse tag is clicked, the approval processing is automatically completed and a window opens to allow the approver to enter a comment as needed. The approver can choose to send the comment to the requester or to send it only to the Service Desk. 

An approval confirmation email is then sent to the approver to indicate that the approval has been completed.

For more information on this method, see the Approval Emails section of the Email Configuration and Improvement Wiki. 

By Responding to the Approval Email Using MailIntegration

If MailIntegration has been configured, it is possible to reply to the email received with Yes or No on the first line. More text can be added after as long as yes or no are on the first line of the reply. 

• Yes thanks.
• No, we will be replacing the whole system soon. 
• Yes, add to cost centre 1245. 

Please note that the response and comments will not be visible via the Web portal.

Using MailIntegration With Approvals

MailIntegration is an Octopus tool that allows to receive emails directly in the Octopus requests. Using this tool greatly increases the effectiveness of approvals, because most of the time, even if approvers are not at their desks, they have access to their email and it's very easy to respond to an approval by email.

The proper functioning of an email approval requires that:

• You have deployed the Octopus MailIntegration program.
• The Modify the approval fields of a task permission has been granted to the Octopus system's account.

Things to know about email approvals

• It is quick and easy.
• Approvers only need to respond in the required format. 
  • By default, the accepted responses are Yes, No, Oui, Non. 
  • Additionnal text can be added to the response, as long as an acceptable answer is provided on the first line of the email, Octopus will process it. 
• It is possible to add other acceptable responses to an approval. 
  • For example, if in your invironment people always respond sure or OK, these items can be added to the list of accepted responses.
  • All you need to do is contact us to have them added to your list. 
• It is possible to respond by email to an approval request sent to an approval pool. 
  • To find out more about this option see the Direct Approval Mode section above. 
• An approval sent to a pool of approvers will work in 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.
• Octopus recongnizes when an approver has delegated the responses from his email box. 
  • This is the case when the person who is the approver designated someone to respond in his name from his email box (Outlook or Lotus Notes).
  • A message will be added to the response in Octopus. 
  • For example if Diane delegates her email box to Martin, a note will indicate "Martin Brown on behalf of Diane Forest" with the rest of the response after. 

Notifications

These automated emails are sent to an approver or an approval group to advise them that a request is waiting for an approval. The requester and the user receive a message with the approval results. The notification templates can be modified from the Tools > Options menu. 

An Octopus assignee can also receive a notification about an approval; he must ensure to configure his notification preferences to receive it. 

Please note that attachments added to the SR by the requester are not sent in the approval request email. However, they are accessible by approvers via the Web portal.

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
 

Confirmation of Approval by Email

This notice is sent to the person assigned to an approval, when the answer was made by replying to an email or by using the method of links in the approval email.

It is intended to confirm that a response has been recorded and warns the approver in case the email was inadvertently forwarded to another person who responded.

Although it is recommended to leave this option in place for security reasons, it is possible to disable it if necessary.

• From the Tools > Options menu. 
• In the Emails to users section. 
• Unckeck the Confirmation of Approval by Email option. 

Approval request reminder

This notice is sent to the approver to remind him that an approval is still waiting. 

By default this reminder is set to 48 hours from the approval request, but this delay can be modified by our Service Desk is required. 

Request Approved

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

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. 
 

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. 
 

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.  
 

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. 
 

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 days. Contact us if you wish to set a different delay.
 

Approval Delegation

This option allows the delegation of approvals to another person. 

The delegation can be configured by:  

• The Service Desk, in the User tab of the Approver's file.
• The approver himself, by changing his profile on the Web Portal.

Delegation Methods

There are several methods for delegating approvals:

• Add a delegate
  • If you only add the name of a delegate, this person will receive all new approvals until further notice. 
• Add a delegate + When I'm not available

  • Adding a delegate's name and the When I'm not available option works in conjunction with the unavailability section.

  • When the person is unavailable, the new requests go to the delegate. 

  • When the approver is once again available, the new requests will come back to him.

• ​Add a delegate + the From field of the delegation section

  • From the From date, the new requests will go to the delegate until futher notice. 

• Add a delegate + the From and To fields of the delegation section

  • New requests go to the delegate between the dates in the From and To fields.

  • After this period, the delegation will no longer be in effect, but it is possible that the information will remain in the user's file.

• All new approval tasks will be received directly by the delegate and the response will be in his name. However, the approval task will indicate that the person was a delegate.

Double Approval Delegation

Octopus does not allow double delegation of approvals. We consider that this practice carries a risk of sending approvals at an inadequate hierarchical level.

Here is a scenario of a double approval and the description of the Octopus behaviour.

Hypothesis:

• Diane - is the Director of a department.
• Louis - is the Assistant Director, Diane is his manager.
• Rachel - is the Service Desk Team Lead, Louis is her manager.

Results: 

• Diane delegates her approvals during her vacation to Louis.
  • Louis receives all the new approvals of Diane during her absence.
• Louis must also be away and delegates his approvals to Rachel. 
  • Rachel will only receive the new approvals from Louis.
  • The ones of Diane will still be sent to Louis, but will remain in his list of approvals to complete.

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

Examples

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. 

Results: 

• The approval task is sent to David

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. 

Results : 

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

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. 

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.

Results: 

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

Conclusion

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.