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.

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.

Creating an Approval Task

1. Search for the Request Details window, if it is not already on screen.

2. 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.

3. Choose the Approval task icon from the palette, and drag it to the window.

4. On the dependency diagram, double-click the Approval task icon to view the Approval Details window.

5. The Task Type field displays values that have been defined for approval types on the Approval Types window.

6. Complete the common task fields on this task. See Also: Creating a Task

7. Complete the Resource Management details, if appropriate.

8. 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.

9. Approvals cannot be approved or rejected when the associated request is being actioned by another analyst and you have modified fields in the request.

Creating Time Limited Approvals

Often, approvals need to be time limited, meaning that they need to completed in a specified number of days or weeks. You can create a time limited approval task in ASM by utilizing a conditional branch to evaluate the Request's completion status and a delay task. Below is an example of setting up an approval task with a 5 day time limit and an email notification at day 3.

Part 1: Outline Your Expected Behavior

It's never a bad idea to have a good idea of what you want to configure before you start.

1. Approval must be completed in 5 days

2. An Email notification should go out on Day 3

3. If approval is not complete after 5 days, activate an alternate approval task and start the time loop again.

Part 2: Set up the loop

Your loop will run in parallel to the approval workflow.

• This is because at any time the approval is completed, the loop is no longer needed and can be abandoned.

• This is why your conditional branches evaluate the Request's completion status value. Example:

1. Add the Delay Task to the task preceding the Approval Task.

   1. We want to add the delay task to the task preceding the approval. This way it is activated at the right time/Start time.

   2. If you will want an email to go out before the expiration date as in this example, set the value for this delay to 3 days.

   3. See also Delay Tasks

2. Add a Conditional Branch to evaluate for the Request's completion Status when the approval is completed or Rejected (indicating it has been attended to).

   1. See also Conditional Branching Tasks

3. Add a Messaging task

   1. If the request status does not equal either of the request completion statuses configured on your approval task, then activate the messaging task.

   2. See also Messaging Tasks

4. Repeat Step 1 through 3 until you have completed as iterations as you need.

5. If you will seek an alternate approval than at this point, add the alternate approval task and configure.

Complete the Common Task Fields

1. 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).

1. 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".

1. Enter the time it should take this task to complete.

2. 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.

3. 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.

1. Complete the Resource Management details, if appropriate.

2. 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 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.

The Wrong Email is Going Out

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

The Wrong Recipient is Being Notified

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.

The correct number of tasks were not created - I have X recipients, but only some of the tasks were created

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

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 Email Doesn't Tell Enough About the Request to be Able to Approve Via Email and the Portal and Task Screens are not Showing any Details Either

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..

1. 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.

2. 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.

3. 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.