These govern who can accept or reject any processes that require approval by either an internal or external user or agent and the manner of the way this approval is carried out.
When a change request is raised, this should be assessed according to your change management process, often this will require approval before any changes are implemented or scheduled for implementation.
Your workflows should govern how these are treated. Often, these follow one of two routes depending on whether the approval is requested for a change resulting from an incident or from a colleague requesting.
The processes are set up under Configuration > Tickets > Approval processes.
Modifying Approval Processes
Each approval process follows a sequence, these give multi-level approvals their order, single step approvals obviously don't continue after the first step.
Click into any process or click new in the top right:
Give this a name.
Click the ⊕ symbol to add a new step or the pencil to modify an existing step.
Give the sequence a number:
Lower numbers occur earlier in the process chain.
Select the approver.
Designate the appropriate template for sending approval emails of this type.
Under outcome, select the statuses as required and the actions afterwards:
Save again to return to the list of processes.
Approval Process Rules
These are automatic rules that when a given field on a ticket matches some value, similar to ticket rules, an approval email will be sent off to the specified email or person. Approval process rules can be defined 'globally', which means any approval process step, in any approval process, can use them as approval criteria, or they can be defined individually on any step, allowing more granularity to the approval process.
Amended in a similar fashion to ticket rules the rule will only trigger when all values listed in criteria are matched. You can add one as below:
Give the rule a name.
Set the precedence:
The lower the precedence, the higher the priority for checking.
Add in the relevant criteria.
Select the approver as above.
You can now also use the criteria "service includes" and "service doesn't include" alongside the standard filter types.
At approval process step level, if the step approver is determined by rules you'll see there is a new option for Auto-Approval. This allows you to configure an email to be sent to a fixed email address or based on rules to notify individuals that a step has been automatically approved.
The recipient of the email can be determined by the same approval process rules with an overriding Impact level and Risk level. This allows you to notify people who would have been asked to approve if the change was higher impact or had higher risk about low impact/risk changes that are auto-approved. A custom email template can be used for the email.
Additionally, there is a system action to 'Email Approvers'. This can be set in action configuration. It will automatically populate the 'to' address of your email to anyone that has previously approved a step of the approval process which the ticket is using.
The first type of approver is an end-user. An approval process of this type will send an email to the end-user asking for their response to an approval request. This could be related directly to services that you provide or assets they are associated with.
The second type of approver is a manager. When you're using the Active Directory integration this will sync your managerial structure through to Halo. This means that the system will have a record of who manages whom, and can therefore use this information to send approval messages to the end-user's manager or even manager's manager if selected.
The third type of approver is a Team Leader, which is configured in the agent's permissions.
The fourth type of approver is a CAB. CAB (Change Advice Board) is the term for a collection of people of whom a given number of accept votes is required for successful approval. If the number of accept votes does not meet the required number, the approval is rejected. This number is listed in the configuration for the CAB.
The final type of approver is an ad-hoc approver. This will ask you to select a user or agent from the list of all available approvers. This option can also be used in combination with the above options by checking the below option on the approval step.
There are now a further three approval types for all users who are change approvers at site, client and all levels.
Halo also allows users to delegate approval privileges. This can be configured against the relevant user settings under the 'Approval Processes' area:
Here, you can specify to whom the delegation goes to and the time period for which the delegation takes place.
You can change the status of a ticket and move it along the workflow if it was not approved before the start date. You can set this status to change at the approval process step: