Use the "Approvals" shortcut to switch to a tab with a list of approvals. In this default view, all open approvals for the logged-in user are displayed.
Approvals are releases for tickets. The administrator can define for which ticket types and on which basis approvals are required (budget limits, value overruns, category, etc.). Service requests, change and release management tickets are often subject to approval.
In principle, any person or user stored in the system can be an approver, e.g. hierarchical superiors or subject-related users. In addition to individuals, groups can also be entered as approvers.
|
Application example of a typical approval process: A user of the Self-Service Portal wants to order a new asset from the web store. The administrator has set an approval rule for all asset orders above a certain value limit. This asset exceeds the value limit, so the user's supervisor must first approve this order, provided that the order is within the defined budget limit of the supervisor. So the processing of the ticket waits for the approval first and cannot be processed before. Approvers can be anyone stored in the system (users and persons). The approver (in this case the requestor's supervisor) automatically receives an e-mail from the system with all important information and can make his/her decision either via a confirmation response directly from the e-mail or via a link to the corresponding approval in the SSP. Once the approval has been granted, the ticket is automatically set to the "processing" state, so that the ticket manager can now complete the subsequent tasks directly. |
The administrator can use the following three variants of the approval process for a ticket:
•Single approval (one approver must agree, regardless of how many approvers are registered)
•Majority approval (if there are several approvers, the majority must agree)
•All (all approvers must agree)
The approval form also includes the reference to the original ticket so that the approver can view all information directly in the ticket.
The administrator has to make sure that the tickets are not visible to the approver due to a special setting of permission filters.
More information of the approval form:
•Created (creation date)
•State of approval
•Affected person
•Title of the ticket
•Description of the ticket
•Priority (of the ticket)
•Total price (if available)
•Estimated effort (if available in the ticket)
•Risk (if available in the ticket)
•List of ordered items (if available in the ticket)
•List of questions and answers from ticket surveys (if available in the ticket)
•Overview of the other approvers for this ticket and their approval status
By pressing the corresponding button, the approval can be granted or denied.
The approver can also enter a comment for the approval. If the approval is rejected, it is mandatory to enter a comment and, if possible, briefly document the reason for the rejection so that the ticket processor can pass it on to the ticket reporter, if necessary.
There is also a button in the ticket for the ticket editor to manually resend the approval request as an e-mail to the entered approver. This can be useful if an approval has been pending for a long time and it can be assumed that the approver overlooked the first e-mail. There is no further automatic reminder of a waiting approval.