Creating an Approval Task
You may want to create approvals at various stages of the request and create dependencies such that certain tasks are not released until each approval is approved by the request manager.
Last updated
You may want to create approvals at various stages of the request and create dependencies such that certain tasks are not released until each approval is approved by the request manager.
Last updated
Analysts with Approver selected in the Tasks tab of their Workflow Management security role can approve or reject Approval Tasks. If an analyst does not have approval rights, they will be able to view and take action on Approval Tasks but they will not be able to complete them.
Approval tasks are automatically scheduled to run when released in a request workflow.
If you want the user to complete the approval, you should create 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 Approval task icon from the palette, and drag it to the window.
On the dependency diagram, double-click the Approval task icon to view the Approval Details window.
The Task Type field displays values that have been defined for approval types on the Approval Types window.
Complete the Resource Management details, if appropriate.
After you have completed the fields, save or defer the task. If you are creating the task as part of a workflow template, assign it to another analyst or manager and initiate the appropriate action necessary for completion of the approval.
Approvals cannot be approved or rejected when the associated request is being actioned by another analyst and you have modified fields in the request.
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 your agents will primarily be working from Tasks, as is the norm, you might well want to consider creating a task screen for your new workflow that looks just like, or very nearly the same as the request screen. This will allow agents to see everything from the request on the task, and they will not need to bounce around in ASM to see all that they need to see for a given task (this applies only to Standard Tasks and Internal Approval screens).
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
Most Approval Tasks that fail to activate, fail because the intended recipient has no email address or no account with approval rights.
Ensure the Analyst/Agent you have assigned the task to has a valid email address in ASM
Ensure your Analyst/Agent has a Workflow Management Security Role that allows approvals and allows them to see other's Requests as Request Manager
Ensure Your Analyst/Agent belongs to an Approval Group.
ASM will send the email message template linked to the Approval's Task Screen Set and mapped in Message Type Maps.
Ensure you have linked your desired Screen Set to the 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 102: Approval - Forward Internal and Message Type 104: Approval - Forward to Group
Primarily, the Approval task will notify whoever is listed in the Assignment. Incorrect notification always lie in how the Approval is assigned. There are 2 possible reasons why:
The task is assigned incorrectly. Ensure you have specified the correct Analyst(s)/Groups to notify on the task.
Using Distribution Lists as email addresses. Ensure that you have not assigned the approval task to a recipient or team where the email address is a Distribution List (DL) and if you have, the DL is correct and current.
Ensure the Group or team the Approval is assigned to has the correct members listed.
ASM will aggregate Approval Tasks and will not create tasks for people with no email address or approval rights.
So for example, if you have the 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
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
ASM ships with many default screens, right out of the box. This includes email templates, Approval Review Screens, 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.
