This topic includes common examples of approval criteria, a brief description and a video of how each was built. If you prefer to see screenshots, the topic Gate Approval Example - Screenshots includes one example that includes screenshots of all the menu options.
As described in Configuring Gate Approvers, you build your approval criteria using the following attributes:
- Gate approval needed by - (required) specifies whether all the criteria sets must be satisfied, or any one set
- These users - (required) a resource pool, such as a group or unit, or simply All Resources
- Who have - use to qualify or identify specific approvers from "These users".
- resource attributes that have nothing to do with the request, such as Primary Role, Office, or Region
- resource attributes that are related to the request, such as the requester's unit manager
- Example: you want approvers from All Resources who have a Primary Role "Analyst" or who have the property of being the Requester's Unit Manager
- When - data from the request itself, such a numeric values, checkbox selections, or list values
Also, don't forget about the special resource variables for creating dynamic criteria. See Using Variables in Gate Approval Criteria.
The following examples illustrate how to build approval criteria. Each example is accompanied by a short video (less than 1 minute unless otherwise indicated) that shows how the criteria were built. Click the "Click here for demo" link in the Description column of each example.
Multiple approvers from specific Unit/Group
3 members of the PMO group must approve.
|You can use a Unit instead of a Group.|
Multiple approvers from specific Unit/Group who have specific Primary Role resource attribute
Approvers are 3 resources in the PMO group who have the primary role of Executive
You can use any attribute on the resource record to further refine the resource criteria. For example, primary role, is active, who their unit manager is, and so on. As many resource attributes are optional, you will want to make sure you only use attributes that are completed across your pool of resources you want to be approvers.
Approver is single resource Who has specific name
Approver is True, Frank
This is static, literal criteria. The resource attribute "Last, First" is used to hold the value of the resource required to approve (Frank, True).
Approver is single resource determined dynamically using variable (Requester: Unit Manager) based on the Requester
Approver is requester's unit manager
Both the requester and the requester's unit manager are dynamic because they are variables.
You use a combination of a resource attribute (Last, First) and a variable based on the the value of the requester, which is a request attribute.
You don't need to know who the requester is (the system knows that), and then the unit manager resolves to a value based on the resource the requester resolves to.
Use any request field, such as "Reviewer", that points to a list of users that produce a valid resource. See Example Request.
Approver is resource who has the value in the Reviewer field.
In this example, "Reviewer" is a UDF based on Picklist: All Active Users. The approver resolves to the resource selected in the Reviewer field in the request. The resource attribute "Last, First" will hold the value of the Reviewer variable.
Be sure to use a list that will produce a valid result. For example, if you use the list of Request Users, the result will be invalid because request users cannot approve.
Be sure that the request field will be completed (consider making it a required field on the request). In this example, if the Reviewer field is left incomplete, then the approval filter will never be met and the request may not be able to advance to the next gate. If a request is at this gate and there is no other criteria set that satisfies, then the gate will be considered to be misconfigured, and a message will appear in the Pending Approvers field instructing the user to see their Admin; the request will effectively be stuck at this gate until the approval logic is corrected or the request field is changed to satisfy the criteria.
Use a combination of resource attribute and request data - the approver is determined from the value of the Cost field. See Example Request.
Approver(s) selected who have the specified resource attributes when criteria based on data on the request is met.
Click here for demo (1 min 24 sec)
If you're using a comparison, make sure to include at least one criteria set that ensures the "when" criteria is satisfied. In this example if it was configured for Budget < $1000 and Budget > $10,000, then the middle range would not be covered.
That is, for values from $1000 to $9,999, the approval filter will never be met and the request may not be able to advance to the next gate. If a request is at this gate and there is no other criteria set that satisfies, then the gate will be considered to be misconfigured, and a message will appear in the Pending Approvers field instructing the user to see their Admin; the request will effectively be stuck at this gate until the approval logic is corrected or the request field is changed to satisfy the criteria.
If the requester is in the PMO group, then the requester's Unit Manager is the approver.
If the requester is in the Product Management unit, then the requesters Unit Manager is the approver.
If the requester is NOT in either Product Manager or PMO units, then 1 person in the Request Reviewers group is the approver.
Click here for demo (2 min 42 sec)
Use information about the requester in combination with the requester's Unit Manager variable to derive who the approver is.
Notice the use of "is not" and "or" in the final criteria set. This criteria set along with the two above account for all possible units that the requester could belong to. This completeness and the use of "any" for Gate approval needed by ensures that the request will not get stuck at the gate because the first criteria that is satisfied will cause it to progress in the workflow.
The following screenshot is an example request form that several of the above examples are based on (they make use of fields on the request):