Skip to main content
Planview Customer Success Center

Configuring Gate Approvers

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.

Overview

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. 

gates.png

Who Can Approve?

Full and Stakeholder user types can be approvers. Permission to approve can be granted in two ways:

  • By creating an approval filter that evaluates to one or more users. Users that satisfy the approval filter criteria for a request are displayed in the Pending Approvers field and will receive relevant gate-specific and action-based notifications. This is the most common approach.
  • By assigning a permission profile to one or more users that contains the Approve/Reject/Send Back to Prior Gate permission, for example to a request process manager who may need to move a request along in the workflow process when a gate approver is on vacation. Note that such users will not receive notifications about the request. This is a much less common approach and should be used very carefully and only for a few select users, as it grants permitted users these actions across all request categories and all gates. See Permissions and Gates for more details.

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.

How Are Requests Approved?

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. 

What is an Approval Filter?

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:

ex_complex.png

Filter Elements

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)
  • All - Specifies that each applicable criteria set must have all needed approvals satisfied (all applicable criteria sets below) to result in gate approval and advancement of the request to the next gate.
  • Any - Specifies that satisfying the needed approvals for a single applicable criteria set will result in gate approval (any applicable criteria sets below) and advancements of the request to the next gate. 
These users (Who) - (Required)
  • Specifies the pool of resources from which to draw pending approvers. For example, it could be a deep pool of resources, like All Resources; it could be a shallower pool, for example, like the Admin group or IT unit. However, please avoid using All Resource to optimize performance.

For example:

group_title.png

Who Have (Why) - (Optional)
  • (Optional) Specifies what characteristic(s) qualifies a resource as an approver. For example, an approver might need to be a specific user (such as Pat Smith), a specific Primary Role (such as DBA), or be in a specific Department (like IT), or be a Unit Manager. 

For example:

who_have.png

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

2019-06-13_16-27-22.png

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:

2019-06-19_08-01-48.png

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. 

Using Variables in Approval Criteria

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 the "Who Have" statement, begin the statement with the "Last, First" filter field. Though other attributes might be available on the resource record, we recommend sticking with Last, First as the most common/direct way to return a resource value. 
  • For the "When" statements, also begin with a field that represents a resource - what fields you see will depend on what fields are defined in the request Available Fields.

For example:

2019-06-13_17-54-05.png

After you select the operator, click in the next field to display the variables.

variables.png

The variables are represented in colon-separated values; each variable is prefaced with "Request:" (this keeps all the variables grouped together).

2019-06-13_17-13-15.png

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.

2019-06-13_17-10-05.png

These variables will derive their values based on the value of the Created By field.

2019-06-13_17-09-46.png

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:

2019-06-13_15-57-26.png

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:


2019-06-13_15-58-57.png

2019-06-13_15-57-56.png

2019-06-13_17-22-34.png

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.

Using Named Resources in Approval Criteria

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

2019-06-13_17-54-05.png

...then select resource name...Or

2019-06-20_15-40-42.png

...start typing resource name...

2019-06-20_15-39-13.png

...and then select matching name
2019-06-20_15-39-32.png

How to Build Approval Criteria

Click here for a set of examples of approval criteria, as well as video demonstrations.

When to Use Multiple Approvers

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.

How to Order Approvals

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.

Troubleshooting, Tips, Best Practices

Approvers on Vacation or Out of Office

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.

  • Approve/Reject/Send Back to Prior Gate - This permission grants a user/group/unit the ability to approve, reject, or send a request back to a prior gate (provided that the request category supports the "Allow request to be sent to prior gate" option). The permission can be granted globally or per request category. Note that gate approvers have these permissions implicitly.
  • Place on Hold/Place Back in Progress - This permission grants a user/group/unit the ability to place a request hold, or change a held request back to In Progress. The permission can be granted globally or per request category. Note that gate approvers and the requester have these permissions implicitly.

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.

wildcard.png

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. 

Approvals Out of Sync

Occasionally an action taken outside of the request approval process results in the approval criteria being met without any approval action taken. For example:

  1. imagine an approval criterion that requires 3 members of the Finance group to approve a request
  2. 2 members of the Finance group approve the request
  3. your admin edits the approval criterion and changes the requirement to 2 members of the admin group
  4. all the approval criteria at the gate are now satisfied, but the request does not move to the next gate

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.

Misconfigured vs Invalid Criteria

If an approval criteria is configured in such a way that it will not result in a resource it is considered "misconfigured". For example:

  • If the "These users" criterion produces invalid results (for example, requiring 3 approvals from a group that only has 2 members), then the criterion is considered misconfigured and the request is potentially stuck at that gate. Note that the end user will see a message in the Pending Approvers field directing them to check with their Admin.
  • If the "Who have" criteria produce invalid results (for example, require a Primary Role that no resource has), then the criteria is considered misconfigured and the request is potentially stuck at that gate. Note that the end user will see a message in the Pending Approvers field directing them to check with their Admin.
  • If the "when" criteria is not met (for example, when a boolean value is No but the criteria requires it to be Yes for that criteria set), then the criteria set is ignored (will not block approval).

Making Changes to Request Metadata While Approvals In Progress

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.

Tips, Hints, and Best Practices

  1. Avoid using the All Resources resource pool. Specifically, do not use All Resources with a "who have" criteria of "Group is" - simply use the group title instead of All Resource. 

do_not.png

  1. Approvers can be full or stakeholder users (see User Types/Permissions) who satisfy the approval filter criteria defined in the Gate Approver tab. If you are having trouble getting the correct pending approvers, make sure the approvers you are looking for are full or stakeholder user types.
  2. Avoid using criteria that rely on current user (Can I Score, Current User is).
  3. Existing resource filters cannot be included as subfilters.
  4. Putting a request On Hold and then Back in Progress puts the request back in progress at the gate it was at when put on hold. All approvals will be wiped out and approval criteria re-evaluated. If you think that something has changed on the request that is affecting the list of Pending Approvals (or causing the request to be stuck at a gate with no Pending Approvers), you can put the request On Hold and then Back in Progress to "shake the tree" and revise the list of pending approvers if something has happened to change this original list. See Approvals Out of Sync.
  5. If a request is put on Hold and while on hold a gate is moved/deleted, when the request is put back in progress it will be placed at the first gate, and all approvals will be wiped out.