Note: Full and Stakeholder user types can approve requests (provided the resource satisfies the approval criteria or has the explicit profile permission Can Approve/Reject/Send Back to Prior Gate).
Topics covered:
See also, Configuring Request Notifications.
Gated requests require at least one approver at each gate. PPM Pro offers a robust facility for configuring 1-n approvers for any request gate. Please be sure you are familiar with how to create a gate, as you can't configure approvers until the gate is created. Gates, including approval criteria, are configured on Admin/Setup/All Entities/Requests/Categories. As shown in the screenshot below, select a category and then configure gate approvers below when you create a new or edit an existing gate.
Creating approval criteria is an iterative process; you can update your approval criteria in response to changes you might make in your request forms, or in response to your business needs.
Full, Stakeholder, and Time user types can be approvers. Permission to approve can be granted in two ways:
So as long as a resource is a full or stakeholder user type, they are eligible to be a request approver, provided they have permission to approve.
A request is approved to move to the next gate, or becomes fully approved at the last gate, when all conditions for Gate Approvers listed in the Multiple Approvers logic are satisfied. The gate's Multiple Approvers logic identifies which users have implicit permission to approve the request at that gate. An explicit/wildcard approver can also approve and help satisfy the Multiple Approvers logic at a gate.
An approval filter is a set of criteria that evaluates to one or more approvers. The approval filter is located in the Gate Approver tab of the Create/Edit Gate modal (see above). Configure approval logic to define how many approvers need to approve before the request goes to the next gate, or becomes fully approved at the last gate, as well as who the approvers should be (user, group members, unit members). In addition, a set of variables is provided that are based on request fields and allow you to derive your approval list from specific, real-time request data. See Using Variables in Approver Criteria.
An approval filter is comprised of one or more criteria sets, which themselves are comprised of filter elements (statements) that describe the approver. The entire approval filter is prefaced with a directive that specifies whether all the criteria sets must be satisfied, or any one set. The result of the approval filter is a list of one or more "pending approvers" - the end user can see the list of pending approvers if you have put the Pending Approvers field on the request details or on the requests grid.
The following is an example of an approval filter that displays the different filter elements (These users, Who have, When) and multiple criteria sets:
The filter elements - statements that comprise a criteria set - are labeled to make them more readable. Each element is defined below:
Element | Description |
---|---|
Gate approval needed by (all/any) - (Required) |
|
These users (Who) - (Required) |
For example: |
Who Have (Why) - (Optional) |
For example: In addition, there is a set of variables that can be used to specify criteria using fields from the request itself that resolve to resources. You typically start these statements with the "Last, First" filter field (other values will be accepted, such as Unit Manager, but we recommend sticking with Last, First). In the example below, the "Last, First" filter field will resolve to the Unit Manager of the creator of the request. See Using Variables in Approver Criteria. |
When (When) - (Optional) |
Specifies request metadata that determines when a resource can be an approver. For example, imagine a request has a user-defined Cost field. The value of the Cost field is request metadata that can be used to qualify when specific resources can approve: If the Cost > $150,000 then a member of the Finance group must approve. For example: Note that in the example above, you'd also want to add a criteria set that handle Cost < = 150000 to ensure that the request does not get stuck at a gate. The When statement can also take advantage of variables mentioned above. |
PPM Pro provides a set of variables for building approval filters that are derived from attributes on the request. Variables let you build generic, dynamic statements rather than hard-coded values.
You use these variables in the "Who have" and the "When" elements.
For example:
After you select the operator, click in the next field to display the variables.
The variables are represented in colon-separated values; each variable is prefaced with "Request:" (this keeps all the variables grouped together).
The next segment of the variable is any resource list available to the request. For example, the screenshots below show the Requester and the Created By standard request list fields. Any variable for "Requester" will resolve to a resource relative to the resource who is the requester. Any variable for "Created By" will resolve to a resource relative to the resource who created the request.
Note that while the list of variables includes every combination of resource and request fields that resolve to resources, there will be options that are not ever going to be relevant or necessary. For example, the "Placed Back in Progress By" field resolves to a resource, but you will probably never need to create approval criteria based on that resource.
These variables will derive their values based on the value of the Requester field. |
These variables will derive their values based on the value of the Created By field. |
You can also use UDF lists that point to resource lists. For example, the Reviewer field is a UDF that points to Picklist: Current Resource/Active. The variables are based on the value of the Reviewer field on the request, as shown below:
Finally, the third segment of the variable is an attribute that resolves to a resource. The same set of attributes is available for each resource list. For example:
As mentioned earlier, while the list of variables includes every combination of resource and request fields that resolve to resources, there will be options that are not ever going to be relevant or necessary. For example, the "Last Modified By" field resolves to a resource, but you will probably never need to create approval criteria based on that resource.
An alternative to building dynamic criteria is to use a named resource. After specifying your resource pool (These users), create a Who Have statement and select the "Last, First" resource attribute. Click "(enter text or click here to view all)" to display the Edit Gate dialog that was shown above in the discussion of variables. This same dialog contains a list of resources - below the list of variables - from which you can choose a resource name. If you know the name of the resource, you can start typing it into the field until the matching name appears. This way you can avoid the long list in the dialog altogether. The resource names are not prefixed with "Request:" as they are not request metadata, but part of the resource pool.
Click to invoke dialog... |
...then select resource name...Or |
...start typing resource name... |
...and then select matching name |
Click here for a set of examples of approval criteria, as well as video demonstrations.
If you need or it is acceptable to have more than one person provide information or approve a request, then you will want to configure multiple approvers for those users. Having multiple approvers at a single gate effectively simulates parallel gates; each approver may be providing information that they alone are responsible for, but they can do this at the same gate as the other approvers.
If you need to have users approve in a specific order, for example Bob needs to approve before Maria, or two people from Finance need to approve before one person from Security, then you will want to set up separate gates where the first approver(s) is at one gate and the second approver(s) is at the next gate. This will ensure that the workflow progresses in the correct order.
There are two gate-specific profile-based permissions for users who are not approvers or who are requesters but require additional permissions. These permissions are typically granted to accommodate a request manager's desire to ensure that a request is not held up at a gate due to a gate approver being out on vacation.
We refer to these as explicit permissions.
An explicit approver is slightly different than an implicit approver in that an explicit approver can satisfy any one approval requirement for each criteria set. For example, if an approval filter specified "one user from All Resources, who is the requester's unit manager" a user who is an explicit approver could approve at that gate (without being the requester's unit manager, that is why the explicit approver is also referred to as a "wildcard"). If an approval filter specified "two users from Group Finance," then one explicit approver (who isn't necessarily in the Finance group) could satisfy the requirement of one of the two users. The second user from Group Finance can be satisfied by either a member of Group Finance, or another (different) wildcard approver. Remember, if you have multiple criteria sets, the explicit approver is evaluated for each set and can satisfy 1 approval for each set.
Note that an explicit/wildcard approver can also be an implicit approver if they happen to satisfy a filter criteria. However, an approval can only decrease any count requirement by 1 for each criteria set - meaning that if an approval filter has one set of criteria that requires 2 members of Group Finance to approve a request, and one user is a member of Group Finance and a wildcard approver, that user can satisfy only one approval for that criteria set.
Occasionally an action taken outside of the request approval process results in the approval criteria being met without any approval action taken. For example:
When this situation occurs the user will see the following message in the Pending Approvers field:
"Approvals out of sync. To reset the approvals, place the request on hold and then put it back in progress. If the Approve button is inactive, contact your PPM administrator. Otherwise, approve the request."
We informally refer to the above as "shaking the tree". Shaking the tree will rejigger the approvals and the request should move to the next gate.
In general, avoid making changes to approval logic while a request is in flight.
If an approval criteria is configured in such a way that it will not result in a resource it is considered "misconfigured". For example:
Approver criteria are re-evaluated each time an approval happens. For example, imagine a scenario where a request is required to have 2 approvers, with each approver determined by a field value on the request (like Cost > $10 Approver A, Cost < = $10 Approver B). Before the first approver approves, the field value changes. The first approver approves based on the original criteria/field value. Now the approval criteria are re-evaluated; the request field value has changed and impacted/revised the list of approvers. Now only the one approver is required (and this approver already approved BEFORE the field value changed), and thus the request has met all approval criteria and moves on to the next gate.