Procurify's Approval Routing provides account administrators the tools needed to better tailor their approval pathways by utilizing the key details of the requests.
To understand how Approval Routing works, we're first going to breakdown all of the components. Following that, you will find a detailed video walkthrough at the end of this article. Feel free to follow along with Jacob within your own account.
- Approval Groups
- Group Sequence
- Final Approver
- Setting Up (video)
Approval Groups are made up of one or more Approvers appointed within that group. The purpose of an Approval Group is to review Requests and provide sign off on Order, Expense, and Travel Requests. Since different parties within an organization may need to approve certain Requests, but not every single Request, it's vital to understand how you can trigger certain groups for different orders, as well as which approval group will be active first if more than one group has been assigned to a Request.
To Make a new Approval Routing Group please view: How to make an Approval Routing Group.
Conditions are specific requirements that must be met in order for an Approval Group to be triggered, and assigned to a Request.
Configuring Conditions provides greater flexibility for your Approval routings, automatically looping in certain approvers based on the details of the Request.
Note: It's important to be aware when multiple groups are being triggered to ensure it is intended, and not create extra work for your Approvers.
Types of Conditions
Using the Request Type Condition allows you to select which types of Requests an Approval Group will be responsible for. If a Request Type Condition is not selected, the group will be responsible for any, or all Request Type(s) by default.
- Request for Order
- Request for Expense
- Request for Travel
- Request for Fund
When the same Approvers are needed within multiple Departments or Locations, creating a Condition to include all of these Departments within a single Approval Group can simplify changes, and save time. Similar to the Request Type, if a Department Condition is not selected, the Approval Group would apply to any or all, Department(s).
The Account Code condition is best utilized when trying to create an additional level of approval for certain types of order items, or if you only need an Approval Group to review Requests when certain budgets are being affected. The Approval Group will be triggered if there is an item within the Request with an Account Code that matches the Condition. When an RFO includes multiple Account Codes belonging to two or more advanced triggers for approval groups, the RFO will need to be approved by each group. If you do not want to utilize the Account Code Condition it can be left as is in order to include any, or all, Account Codes.
Likely the most flexible of all, the Custom Field Condition creates the ability to trigger certain Approval Groups when specific Custom Field options have been selected within an Order Request. Currently, the "dropdown" and "checkbox" Custom Field types are supported. To opt-out of using this Condition within a group, the field can be left as "Any", in order to include all Custom Field possibilities.
Within the example below, we can see that an employee, Shelby, has submitted an Order Request. This Request has met the Conditions of the Finance Approvers Group as well as the Final Approver group. The Request must be "final" approved within each of these groups before it is fully approved.
As seen within this example, it is possible for a Request to trigger multiple Approval Groups. Take a look at Group Sequence below for more information on these scenarios.
Since it is possible for multiple approval groups to be triggered for a single request, it is a common scenario to have a request pass through more than one group before it is approved. Similar to how the approver levels work, the sequence determines which group must approve the request before it can move through to the next approval group. These sequence numbers range from 1 to 10. In a case where both Approval Groups have the same sequence number, the order will be based on which Approval Group had been created within the system first. In our scenario above, since the Finance Approvers Group sequence number is 1, the Request needs to be approved by this group before it can be reviewed and approved by the Final Approver group, which has a sequence of 10.
In order for a request to be fully approved, it must be "final" approved within all groups that have been triggered.
Now that we have discussed Approval Groups as a whole, let's focus on the people within the Groups.
Approval Groups are made up of one or more Approvers appointed within that group. Each approver is also assigned a level as well as a threshold. In order for a Request to be approved, it must be approved by all levels of the group. There is an exception to this, which will be explained within the threshold details below.
An Approval Group will have at least one approval level. The level determines which approver(s) will need to 'ok' the pending Request first before it can move to the next level. Once it is approved, the Request moves into the queue of the next approver, within the next level. If the Request is denied, it will not be sent to the next approver and will exit the Approval Routing, as the status of the Request has now changed to "denied". Based on the example group above, we can see that this approval group contains 3 levels. Being within the first level, Susan will be the first approver to be notified of the pending request within her queue.
When there are two approvers within one level, the user submitting or approving the Request will choose one of the approvers from a drop-down provided. In this example, if Susan chooses to approve the request, she will have the option to send the request to Jordan or Sarah.
The threshold is intended to provide an approver greater power within their group. If the total cost of the Request does not exceed the approver's threshold, after they approve the request, it will be fully approved by the group and will not require further review by the next approver within that group. Continuing on with our same example, if a request that costs $500.00 or less is sent to Sarah, she can approve the Request for her group without requiring Andrew's approval. If the $500.00 Request had been sent to Jordan instead of Sarah, he will still be able to approve the Request, but since Jordan's threshold is $0, it will be sent to Andrew afterward for final approval.
A member of an approval group may be the final approver for their group if they are assigned to the last, or highest approval level, regardless of what their threshold is. A member of the group may also be the final approver if they approve a request with a total cost that falls within their approval threshold, as mentioned above. This means that Andrew is likely to be the final approver for their group, but Sarah can also be the final approver if the request total is within her threshold.