Creating a User Approval Task
Users can approve or reject these tasks using the Self Service Portal
If there is a Conditional Branching Task preceding the Customer Approval Task in the workflow and a Forward To recipient is specified on the Conditional Branching Task, then, at run time, the value specified in the Conditional Branching Task will override the value specified in the Customer Approval Task.
Why Use a Customer Approval Task?
Workflow processes often require approvals to be given before a workflow can progress. Approvals are a critical stage in any workflow; they restrict approval permissions to certain individuals or groups and record details of the approval or rejection for auditing purposes. Once an approval task is completed, the workflow progresses down certain dependency paths, based on the approval or rejection decision.
Generally, approvals are completed within the main ASM Core or NANO application with a workflow officer logging into the system, locating the approval and completing it.
The Customer Approval Task provides a similar function with some key differences:
Customer Approval Tasks can only be completed through the Self-Service Portal or via email.
A person flagged as a customer must exist in ASM for the Customer Approval Task to be assigned.
The benefits of using the Customer Approval Task
The approver does not need to know how to navigate the full ASM application interface. Learning how to use the Self-Service Portal interface requires less training than the full application.
The approver does not need a license; this means an unlimited number of customers can be approvers through the Service Portal.
A person can set up as both an analyst and a customer through their person details record, allowing analysts to complete Customer Approvals through the Self-Service Portal. This configuration can free up shared licenses.
User Approval Tasks can also be approved in the main application by full analysts with Approver rights on the Tasks tab of their Workflow Management security role. This may be necessary when a user is unavailable to handle an approval that has been assigned to them.
When a User Approval task is added to a workflow, a user must be linked to the task.
Request managers can assign one or more users to the User Approval task when adding the task to a workflow template or request (if the approval has not yet become active).
If multiple users are added, then when the task is activated, a separate User Approval task is created for each one.
Creating a User Approval Task
Search for the Request Details window, if it is not already on screen.
Select the Update Dependencies explorer option on the Request Details window, or the button from the toolbar. The Task Dependencies window appears with icons for task entity types displayed below the toolbar.
Choose the task icon from the palette, and drag it to the window.
On the dependency diagram, double-click the User Approval task icon to view the User Approval Details window.
To link users to the task, expand the Recipients section and click Add.
In the Recipients window, find and select recipients.
People | Select to find and select users as the approvers. Specify the name and/or organization and click Find. From the results table, select each user you want to approve the task and click Add. |
Other | Select to forward the Approval task to the person selected in a specific field when the task becomes active. This could be the user selected on the request, user who logged the request, and so on. You can then select from the drop-down list of available fields. Alternatively, you can forward a User Approval task to a variable (such as the user selected on the request) using a Conditional Branching task. |
Stakeholders | Select to send the approval task to a request stakeholder. A list of stakeholder roles appears. choose how many levels of available Stakeholders to display in the selection list. The list of Stakeholders has recipients available related to Linked CIs. Notifications can be sent to the stakeholders of CIs linked to the CIs Attached to the current Request. This affects CIs linked up to 2 levels from the current CI. The linked higher/lower options relate to the CI relationship mapping.
Example: CI A is linked to CI B. CI A has stakeholder 1 and 3. CI B has stakeholder 2 and 4. If CI A has a change logged to it, the workflow can be configured to notify stakeholder 1, 2, 3, and 4 using the messaging task. Select the stakeholder role(s), and click Add. To select the stakeholder of the person who authorized the request, select Authorized By/Stakeholder. |
Click OK. The window is closed. The selected recipient(s) are added to the browse table on the Details window.
Repeat to add more recipients, then save the details.
When the User Approval task becomes active in the workflow, a separate user approval task will be created for each recipient. Only one user can be linked to a User Approval task once it has become active in the workflow so if you edit the task from the request, the Recipients tab is disabled.
Once the task is activated (that is, preceding tasks have been completed) the user receives an email, provided the user has an email address specified in their person details record. This email provides information on what needs to be approved and includes a web address. The user can click on the web address to be taken to the User Approval task in Self Service Portal (they may be required to log in before they can see the task) or they can click the Approve or Reject button in the email.
Users can also locate their tasks by logging into the portal and viewing their Approval Summary page, or by selecting the Outstanding Approvals option in the menu. Once the task has been opened, they can approve or reject the task.
If the linked request has been opened by an analyst when a user wishes to approve a User Approval Task, a warning message appears, but the task can still be approved. However, if the task has been set to update the request status and the request has been opened by another analyst, the request cannot be updated.
User Approval tasks are completed automatically as soon as the user approves or rejects the task.
Completing an Approval
Once the task is opened, the customer selects either the Approve or Reject button. They can then enter comments about their decision prior to completing the task (they may be required to re-enter their Service Portal password).
Customers having approval rights can view and action a Customer Approval Task assigned to them through the Service Portal, provided they have access to the portal. If the assigned customer is also flagged as an officer through their Person Details record, they can also view and action a Customer Approval Task assigned to them through the main application.
Customer Approvals can be approved in the main application by full officers with Approver rights on their Workflow Management security role. This may be necessary when a customer is unavailable to handle an approval that has been assigned to them.
Complete the Common Task Fields
Set the Screen Set for the task. By default, the System's default task screen will be used, but you can select Screen Set from the Task Explorer window, and choose a different screen set. Any message templates on the screen set will be used for notifications.
Best Practice: If you want a custom email template to be used for this customer approval, you can:
Create a custom screen set for the User Approval Task linked to the Request Screen Set for your Workflow
Build a message template in the screen set in Screen Designer
Link the new screen set to your User Approval Task (In the Task Explorer window)
Link the new email template in System Admin Message Types: 130: Task - User Approval
Complete the Task Status, Title, Description (this forms the body of the notification email, in many cases), and where present, the Request Status on Rejection (Approval Tasks) and Request Status on Completion.
Updating the Request Status on completion of the task will automatically update the request's overall, or "Completion Status" so that it is easy to tell exactly where the request is at all time. For example, after the Approvals are completed, you might want to automatically change the request status to "In Progress".
Enter the time it should take this task to complete.
OLAs can be applied to tasks by Task Type and Assigned Group. If you are using OLA for tasks, it is important to specify the correct task type and assigned group to get the correct OLA applied to the task.
All CMDB items linked to the request are displayed on this type of task in the Linked CIs and Linked Services fields. If required, you can schedule changes against linked CI the CMDB items and create a planned outage against these items as they will not be available for use when they are being updated.
Outages against a linked CMDB item can be created through a request or task. See Outages and Availability for more information. Also see, Managing Availability.
Complete the Resource Management details, if appropriate.
After you have completed the fields,
forward the task internally - Assign the task to a Group
Save your task's changes
Troubleshooting User Approval Tasks
The Task Never Became Active
Most User Approval Tasks that fail to activate, fail because the intended recipient has no email address or no Portal account with approval rights.
Ensure the User you have assigned the task to has a valid email address in ASM
Ensure your User has a Portal Access role that allows approvals
The Wrong Email is Going Out
ASM will send the email message template linked to the User Approval's Task Screen Set and mapped in Message Type Maps.
Ensure you have linked your desired Screen Set to the User Approval Task
Ensure your Message Template on that screen set (Screen Designer) is the one you intend to send
Ensure the message template is mapped System Admin > Message Types > Message type 130: Task - User Approval
The Wrong Recipient is Being Notified
Primarily, the Customer/User Approval task will notify whoever is listed in the recipients section. Incorrect notification always lie in how the recipients are configured. There are 2 possible reasons why:
The Recipient is set incorrectly on the User/Customer Approval Task itself. Ensure you have specified the correct user to notify on the task in the Recipients section.
Using Distribution Lists as email addresses. Ensure that you have not assigned the approval task to a recipient where the email address is a Distribution List (DL) and if you have, the DL is correct and current.
For example, The E-CAB Spammer
An organization recently implemented Change Management in ASM. They already maintain an E-CAB email Distribution list tied to pagers and other notifications, and they wanted to keep it that way. A former member of the E-CAB was still receiving notification emails even though they left the group. They sent an angry email to the Service Desk Supervisor complaining the the change process was "Spamming" their inbox with notifications. In truth, this individual had only received 4 emails in the last 30 days but to him, it was excessive. These were the original requirements for the E-CAB/CAB:
They do not complete approvals via Email, but they do want the notifications to go to the email address for the E-CAB Group because that triggers other automated actions throughout their organization.
They deployed a special Self Service Portal for the Change Team to complete Approvals and view all of the Changes along with the Change Calendar. Each CAB member has access to the portal with Single Sign On where they can complete their individual approvals, but there is also an E-CAB general user/shared account.
The E-CAB User should be able to see Emergency Changes and approve or reject them. Anyone with the E-CAB credentials can log in as the E-CAB User and complete Emergency Change Request Approvals.
They have assigned the E-CAB user's account in ASM an email address the corresponds to the E-CAB DL.
This way, for emergency changes one approval is created and one email is sent, but it goes to the Distribution list.
Anyone on the E-CAB can log in to the E-CAB Portal and review, approve, or reject Emergency Changes.
Root-Cause of the Spam Problem: In this example, the impacted former E-CAB member left the E-CAB group but was not removed from the Exchange Distribution List by the Exchange Administrators. This means they still received E-CAB emails because ASM is merely emailing the DL, and not the individuals listed within it. In this case, updating the DL solved the problem of unintended emails going to the wrong person.
The correct number of tasks were not created - I have X recipients, but only some of the tasks were created
ASM will aggregate User Approval Tasks and will not create tasks for users with no email address or approval rights.
So for example, if you have the User Approval Task assigned to the User of the Linked CI's, and there are 3 linked CI's, you would correctly assume that 3 approval tasks would be created, except if of the 3 linked CI, the user of 2 of them is the same, then the approval task will consolidate those 2 approvals into one so that the user is only sent one approval for the request.
See also The Task never became Active
The request's completion status shows in progress even though it was rejected and closed
You must set the Request Completion Status on each task in your workflow. This includes Conditional branches, etc. It is likely that you have not configured the "Request Status on Completion" field.
See also, Completing the Common Fields
The Customer Says the Email Doesn't Tell Them Enough About the Request to be Able to Approve Via Email and the Portal isn't Showing any Details Either
ASM ships with many default screens, right out of the box. This includes email templates and Portal Review Screens. However, the data on these templates and screens is limited to just select system field values; Request Number, Task Number, Request Description, Task Description, etc..
Ensure the data needed to be able to understand what has been requested is added to the Message Templates and Review Screens, including any new fields you may have created and added.
Ensure you have written a thoughtful Task Description that will form the body of your email message that tells the Approver what is required. Use the Task Description consistently and map it into the body of the email template(s), then add remaining fields needed for clarity.
Make the Request Description, and Request CI's required fields so that users submitting must give the minimum level of information when submitting and prevent notifications from arriving blank in an email or requests appearing too sparsely populated on your portal screen.
Last updated
