
HaloITSM Guides
Documentation to assist with the setup and configuration of the HaloITSM platform
Approval Processes Overview
In this lesson we will cover:
-What are approval processes and when are they used?
-Creating an Approval Process
-Settings against the approval process step
-Triggering an Approval Process
-Approving
-Overriding Approvals
-Delegate approvals
-Example Approval Process
Associated Administrator Guide:
What are approval processes and when are they used?
Approval processes in Halo 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. Approval processes are used to restrict the progression (workflow) of a ticket i.e. the actions that are available to the agent until this approval has been obtained. Approval processes can be used on any ticket type but are typically used for change management, service requests and opportunities. Approvers do not require a Halo licence, as they can approve from the end user portal or simply via email.
Creating an Approval Process
To create an approval process head to configuration > tickets > approval processes > setup processes, here you can create a new approval process. The 'use' of the approval process determines what this process can be used for.
Fig 1. New approval process
Each process can contain numerous steps, steps are worked through in sequence until they are all complete. To progress to the next step the prior step must be approved, once all steps are approved the approval process is deemed as 'approved' and the ticket will progress. If any of the steps are rejected the approval process is deemed as rejected and ends.
To create a new approval process step add a step to the table.
Fig 2. Approval Step
The 'Approve by' field determines who needs to approve this step. For a breakdown on on each option here see our dedicated lesson here. We will run through some commonly used approver options below:
- A fixed CAB
- Ad-hoc approver
- Determined by Global approval process rules
- Determined by Approval Process rules
What is a CAB?
A 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.
To create/configure a CAB head to configure > ticket > approval processes > Change Advise Boards. Here you can assign users/agents to the CAB, set the CAB to require approvals from all members, if not how many approvals are required from the CAB members for an overall approval.
Fig 3. Example CAB
Ad-Hoc Approver
When this option is selected the agent requesting approval will be able to choose the approver from a list of agents and users that have permission to be approvers. All agents will appear in this list but for users to appear in this list they must be given permission to partake in approvals. To enable this permission head to a user profile > permissions tab, enable 'This User can partake in approvals'.
Fig 4. User permissions to partake in approvals
Determined by Global approval process rules
Global approval process rules are configured separately to the approval process. This allows you to create a set of rules that can be used for any approval process/step. When this option is selected global approval process rules will be checked in sequence, if the ticket meets criteria of the rule this approver will be used in the approval process step.
Global approval process rules can be configured in configuration > tickets > approval processes > process rules.
Fig 5. Approval process rule example
Determined by approval process rules
When this option is selected rules can be configured for this approval step. When the approval process reaches this step the criteria for the rule(s) will be checked, the approver against the first rule in the sequence that the ticket meets criteria for will be used. This differs from global approval process rules as it allows you to create step-specific rules, these rules cannot be re-used in other steps or processes.
Settings against the approval process step
Once you have set who the approver for the step will be there are numerous additional settings against the step that will impact how the approval takes place. We will run through each setting below.
Approver Settings
Fig 6. Ad an ad-hoc approver
These settings impact who needs to approve the step.
Fig 7. Approver settings
Allow ad-hoc approvers to be added at this step - When enabled the agent requesting approval will have an option to add an ad-hoc approver after approval is requested. This approver will be added in addition to the approver set at the step.
Auto-approve if no approvers are found - This is typically used in conjunction with steps that determine the approver using rules. This allows you to skip the approval process if the ticket does not meet any approval process rules. Can also be used when the approver is set to be someone with a particular role, if no one with this role can be found the step will auto-approve.
Auto-approve if approver has already approved in a previous step - When enabled, the step will auto-approve if the person set to approve this step has already approved a previous step in the same approval process.
Auto-approve if approver launched the approval process - When enabled, the step will auto-approve if the agent requesting approval is the approver for the step. If this agent is part of a CAB that requires at least 2 approvals the other agents in the CAB will still need to giver their approval.
Auto-approve if approver is the end-user of the Ticket - When enabled, the step will auto-approve if the agent requesting approval is the end user of the ticket. Useful when approvers are raising service requests or change requests as they will have already given their authority for the change by raising the ticket.
Allow approvers to upload attachments - When enabled users/agents will have the option to add an attachment when approving/rejecting in the agent app or portal. Useful if documents are required to support the approval.
Approver is mandatory - When enabled, the approver determined by this step is mandatory. If any ad-hoc approvers are added approver set against the step will still need to give their approval. When off, if an ad-hoc approver is added the initial approver will not need to give approval too. If off and no ad-hoc approver is added the initial approver will still need to give approval for the approval to progress.
Email Settings
These settings determine if/when emails are sent to the approvers for the step.
Fig 8. Email settings
Send approval Emails to the approvers - When enabled an email will be sent out to approvers requesting approval. Approvers will be able to give approval via email. When enabled you will be able to choose the email template that is sent out to the approvers.
Include all attachments visible to User in approval email - When enabled the approver will be sent all the attachments against the ticket that are visible to the end user. To assist them in their approval decision.
Approval Reminder Template - If approval reminders are set to send this is the email template that will be sent out to approvers to remind them.
Number of working hours between reminder Emails - This setting enables/disables approval reminder emails. When set to 0 approval reminders are disabled. Otherwise enter the number of working hours a reminder email will send after.
Auto-Approval
Here you can set a notification to be sent out when the step is auto-approved. This is only available when the approver is set to be determined by approval process rules.
Auto-Approval Notification - This setting determines who is sent a notification.
- The option 'Send an email where the recipient is determined by approval rules if impact and risk where higher' will allow you to set an impact and risk level. If the ticket exceeds this impact and risk the notification will be sent The notification will be sent to the agent(s) that should have approved the step.
Fig 9. Auto-approval settings
Outcome Settings
These settings determine what changes are made to the ticket when the approval process step has been approved/rejected.
Fig 10. Outcome settings
Status while awaiting Approval - This is the status the ticket will be in after this approval step begins.
Status if Approval not needed - This is the status the ticket will be in after this approval step begins if the ticket is auto-approved.
Status if Accepted - This is status the ticket will be in after the approval step has been accepted.
Status if Rejected - This is status the ticket will be in after the approval step has been rejected.
Status if start date of Ticket has passed - This is status the ticket will be in after the approval step has been rejected.
Status if start date of Ticket has passed - This is the status the ticket will be in is the start date of the ticket has passed. Used to time out approval processes if the requested start date of the change/service request has passed. This requires the 'start date' field to be on the ticket type.
Move to "Unassigned" if approved - When enabled the ticket will be re-assigned to the unassigned agent in the same team when the approval process step is approved.
Assign to the approver if approved - When enabled, the ticket will be re-assigned to the agent who approved this step if the step is approved. Can only be used when an agent is set to be the approver of the step.
Hide approval actions from end-User - When enabled the end-user of the ticket will not be able to see actions logged by approvers to approve the step. Useful if you would like to keep approval reason/notes hidden.
Outcome notifications
Here you can determine if/when notifications are sent out to users/agents to inform them of the outcome of the approval step.
Fig 11. Outcome notifications
Inform the Agent of the outcome - When enabled the agent assigned to the ticket will receive an email notification when the approval step is complete.
Inform the User of the outcome - When enabled the end-user of the ticket will receive an email notification when the approval step is complete. When enabled an additional setting will be available to only notify the end user if they are also an agent (the user profile must have a linked agent).
Accepted Email Template - Here you can set the email template will be sent out to users/agents when the approval step is accepted.
Rejected Email Template - Here you can set the email template will be sent out to users/agents when the approval step is rejected.
Notification Rules - In this table you can configure rules that will notify additional people regarding the approval step outcome when certain criteria are met. Criteria for the rule can be based on fields against the ticket. You can also set this notification to be sent only when the step is approved and/or rejected.
Field List
Here you can set the fields approvers must complete when approving the step. Edit each field to set whether the field is mandatory.
Fig 12. Field list for approvers
Triggering an Approval Process
Once you have created your approval process you will need to configure your workflow to start this approval and move according to approval outcomes.
Approval processes can be started automatically when a certain stage of a workflow is reached or when an action is used.
Starting an approval using an action
To do this create a new action (perhaps called request approval). To have the action start an approval process head to the details tab and choose the approval process you would like this action to start in the 'Start an Approval Process' field. If you would like an existing action to start an approval just set this setting against the action.
Fig 13. Start an approval process on action
Starting an approval process automatically using a workflow
To have the approval begin once a particular workflow stage is reached you will need to configure a workflow automation to run a quick action. Create an action as shown above but set the action to be a 'quick action' this is set under the details tab.
Fig 14. Set action to be quick action
Now head into the workflow you would like the approval to take place on and edit the step you would like the approval to run on. Add an automation to the step actions table and configure as shown in figure 15. Ensure after the automation has run the workflow moves to the next step.
Fig 15. Automation to start approval
Then on the following step of the workflow add the action type 'Approval Process Outcome' and set where the workflow should go for each approval result (accepted/rejected/timed out).
Fig 16. Approval process outcomes for workflow
Then you can configure the rest of the workflow to determine how the ticket behaves for each approval result. Figure 17 shows a approval workflow example.
Fig 17. Workflow with approval process
Workflows can also be progressed based on approval process step outcomes, by adding an 'approval process step outcome' action type to the step. This allows you change how the ticket behaves based on each step of the approval process. Used when you would like different actions to be available to the agent working on the ticket at each step of the approval process.
For more information on configuring workflows see our dedicated lesson here.
Approving
Agents can either approve requests through the agent app, or via email. Users can approve requests through the end user portal or via email.
Approving in the agent app
To approve in the agent app agents can navigate to the ticket that requires approval. When viewing the ticket they will have action buttons to 'accept' or 'reject'.
Fig 18. Accept/reject ticket
Agents can also navigate to the 'my approvals' module.
Fig 19. My approvals module
This module will show all the approvals awaiting input from the agent.
Fig 20. My approvals module
Access to the 'My Approvals' page will need to be added to the agent's permissions using the 'My Approvals Page Access' permission.
Fig 21. My approvals page access
Approving in the Portal
For users to approve requests in the portal you will need to ensure the 'My approvals' button is available in your portal. Head to configuration > self-service portal > see menu buttons section to add this button.
Fig 22. My approvals button
To restrict access to the area, edit the button and add restrictions in the 'Visibility Restrictions' table.
Now users will be able to navigate to this area in the portal and see a list of all tickets that require their approval.
Fig 23. My approvals page
Fig 24. My approvals page
Approving via email
Both agents and users can approve requests via email by replying to the email that is sent out to request their approval. This email is sent out automatically to each approver for each step of the approval process.
To approve or reject via email simply click the approve/reject icons in the email.
To customise the email that is sent out to approvers head to configuration >email > email templates > select template with ID 50. This template is defaulted to be the template that is sent out to approvers, however, you can change the template that is sent out at the approval step.
Overriding Approvals
You can give certain agents the ability to override approvals. Having the ability to override approvals will allow the agent to change the approval result the approver gave (accepted/rejected). This is useful if you need to correct an incorrect approval response.
This permission can be found under the agent's profile under the 'permissions' tab.
Fig 25. Override approval results permission
Delegate approvals
Approvers can also delegate approval if required, we have a separate lesson on how to do this here.
Example Approval Process
In this section we will run through an example of how to create an approval process for a change request. The change request will need to be approved by a CAB then if enough CAB members approvers the site change approver will need to approve too.
First, you will need to create a new approval process. Head to configuration > tickets > approval processes > setup processes > new. Add a step to the approval process.
The first step will require the CAB to approve the request. I will set the 'Approve By' field to be 'A fixed CAB' and then choose which CAB will need to approve.
Fig 26. Approval step for CAB to approve
I have set the CAB here to contain 3 approvers and the 'number of approvals needed' to be 1 and the rejection threshold to be 2. This means only one of these approvers needs to approve the change for the step to be approved, but if 2 approvers reject the change the approval step will be rejected.
Fig 27. Example CAB configuration
I have also set the outcomes for the approval as shown in figure 28, the ticket will have the status of 'awaiting approval' when the approval process has started but not yet been completed. The ticket will have the statuses of approved and rejected when the approval has been accepted and rejected (respectfully).
Fig 28. Outcome of approval step
I have also added a note field to the step, approvers will need to complete this field when accepting/rejecting.
Now I will add a second step in the approval, this step needs to be approved by a set user. This step has the same configuration as the previous step.
Fig 29. Approve by change approver at site
Here is my completed approval process.
Fig 30. Approval process example
Now I will configure the workflow for my change requests, under configuration > tickets > workflows.
Fig 31. change request workflow example
In the first step of my workflow I have allowed the use of the action 'request approval'. This action is configured to start the approval process I have just set up.
Fig 32. Action configured to start and approval process
Once this action is used the approval process will begin and the workflow will move to the step 'approval requested'. At this step I have added the action types 'approval process step outcome'. This moves the workflow on to the next step based on the approval outcome of this step. If the first step in my approval process (CAB approval) is approved the workflow will move the the step 'approval requested part 2'.
Then if the second step of my approval process is approved (site manager approval) the workflow will move to the step 'change approved'. This step will allow the use of actions that will allow the agents to initiate change. If either step of my approval process is rejected the ticket will move to the step 'close request'.
Note: You do not need to have a workflow step for each approval step, you could instead have the workflow only progress when the whole approval process is approved/rejected using 'approval process outcome'. Having a workflow step per approval step just allows you to configure the actions the agent can use and automations that can occur at each approval step.
Now the workflow is configured I will set this workflow to start each time a change request ticket is raised.
Fig 33. Setting workflow against ticket type
Now lets see this in action.
A new change request ticket has been raised.
Fig 34. Change request ticket
The agent uses the action 'Request approval' to begin the approval process. As the first step of the approval process requires CAB approval the agent will need to choose which CAB members approval is needed, as at least one CAB member needs to approve the agent will need to select at least this number of approvers.
Fig 35. Choose CAB members to approve
Once selected the approval has begun and the workflow has moved to the next step.
Fig 36. Approval requested
Now this ticket will appear in the 'my approvals' area for the approvers.
Fig 37. Ticket awaiting approval in my approvals area
Once at least one CAB member has approved the approval process will move to step 2 and approval will be requested from the user 'Ben Castle'.
Fig 38. Ticket awaiting step 2 approval
Approver approvals/rejections and comments will be visible in the action list against the ticket. Allowing the agent to see who approved/rejected, when and any fields the approver had to complete (such as a note).
Fig 39. Action list
Now the approval process is complete the agent can initiate the change.
For an additional example om how to configure a process to be approved by a user's department manager see the lesson here.
Popular Guides
- Asset Import - CSV/XLS/Spreadsheet Method
- Call Management in Halo
- Creating a New Application for API Connections
- Creating Agents and Editing Agent Details
- Departments and Teams
- Halo Integrator
- Importing Data
- Multiple New Portals with different branding for one customer [Hosted]
- NHServer Deprecation User Guide
- Organisation Basics
- Organising Teams of Agents
- Step-by-Step Configuration Walk Through