You can leverage the approval library to enable an approval process and functionality in an application. When enabled, end users can submit approval requests and manage them in the Approval Console. Get started by understanding approval processes and approval flows. See also Adding an approval process to an application.
An approval process defines logic, workflows, and required steps required for an approval request to get approved. It facilitates the end-to-end execution of events from the time a user makes a request until the request is addressed (either approved, rejected, or cancelled). Typically, for an approval process, a request record is the input and an approval status is the output.
BMC Helix Platform supports cancellation of approval process for user-driven approval requests that are in pending state.
For information about creating an approval process, see Creating an approval process.
Approval flow types and example
An approval flow defines the overall completion criteria for the approval process. The completion criteria can include simple or complex expressions that execute the approval process. Based on the business requirements, you can create one or many approval flows of the following types:
- Self approval flows, which are system-driven
- Approval flows, which are user-driven
For example, consider an example where you need to configure a self-approval flow or an approval flow for meal reimbursement requests from the sales representatives of your company. The following approval guidelines need to be built into the reimbursement application:
- If a sales representatives spends up to USD 40, the request can be self approved automatically.
- If a sales representatives spends USD 60 or more on meals, the request can be approved by any sales manager.
- If a sales representatives spends USD 80 or more, the request must be approved by the direct manager of the sales representative and two other sales managers.
- If a sales representatives spends USD 90 or more, the request must be approved by the direct manager of the sales representative and the finance manager.
An approval request with self-approval flows are automatically approved by the system without requiring an approver to approve it. You configure self-approval flows when no user intervention is needed. Self-approval flows evaluate preconfigured expressions and optionally call a self approval process before approving the request automatically.
You can configure self-approval flows in the following ways:
- If you want the system to approve the request automatically without executing the self-approval process, configure expressions, and set the precedence. The approval flows evaluates the expressions which when true, the system automatically approves the request.
To evaluate additional expressions, such as whether the requester's position is allowed to self approve the request, or to perform some additional tasks, such as updating a record, create a self approval process. You add additional logic in the approval process and select it in the self approval flow. The system first evaluates the expressions and then executes the self approval process. If the outcome of the self approval process is true, the request is approved. If the outcome is false, the self approval flows continue to match rest of the self approval processes until the request is approved or terminated.
For configuring self approval flows, see Configuring self approval flows.
Approval flows determine the specific person or group of people to approve a request. In approval flows, you can configure expressions to validate conditions and select a single approver or a group of approvers. The approval flow can select approvers from the Foundation data by functional roles or by the relationships defined between people, location, or support groups. When you define an approval flow, you specify the type of approval: level up or general approval. And, you can combine them in an approval flow group.
Level-up approval flows
Level-up approval flows evaluate the preconfigured expressions to validate conditions, checks approver levels, and route the approval request to each approver in the hierarchy. These are also called as manager approvals. In the hierarchy, you can specify the number of approver levels that approve the request. A requester's managerial hierarchy is determined from the Foundation data for the organization. When the request is submitted, it goes through a series of approvers in the hierarchy before getting approved.
Returning to our example where the request must be approved by the manager of the sales representative and two more manager's in the hierarchy, a request would be handled as follows by a level-up approval flow:
- Level-up approval case 1: If you specified the number of levels as three, the approval request is sent to the requester's manager. After the request is approved, it is sent to the manager's manager, and then the next level. If the requester's manager rejects the request at any level, the system terminates the request and further approval requests are not generated for the next levels.
- Level-up approval case 2: If you specified the number of levels as three, and, if either the requester is not defined correctly or the requester does not have any manager associated to him, the approval process results in an error and the system does not approve the request.
- Level-up approval case 3: If you specified the number of levels specified as three, the approval request is first sent to the requester's manager. If the requester's manager approves it, then the request is routed to the next subsequent level. If there is no manager for the first-level manager or no manager at the next levels, the request is still approved.
General approval flows
In general approval flows, you configure expressions and select a single approver or a group of approvers. These approvers can be selected from the foundation data. With use of foundation data, the approvers can be found either by functional roles or by the relationships defined between people, location, or support groups.
In general approval flows, while selecting approvers, users can now filter approvers from the foundation data. Users can apply filters to the functional roles, business units, support groups, person, location, and so on.
This helps in narrowing your selection to an approver belonging to a business unit or functional role, instead of the whole business unit or functional role
For a general approval flow, you specify whether one or all approvers must sign as follows:
- One must sign—One approval request is created where all approvers have permissions to approve or reject. As soon as the request is approved or rejected by any one of the approvers, the request is closed.
- All must sign—Approval requests are created for each approver. After each approver approves the request, the request is closed.
For configuring Approval Flows, see Configuring approval flows.
Approval flow group
Approval flow groups are a collection of approval flows—level up and/or general approval flows. Each approval flow group can have one or many flows. You can create one or many flow groups. Each flow group is tied up with an approval process and is specified in the approval process definition at the time process creation.
You can specify one of the following type of users as the approver:
- Individual user—Select an individual approver from the Person Foundation data, or select a field from the record definition.
For more information about Person Foundation data, see Creating or modifying Person data.
- Group of users—Select approvers that belong to an application role or a functional role; all user account that are a part of the selected role are designated as approvers. Group configuration is beneficial when new users are added or existing users' roles are modified frequently in your organization. Use of foundation data is supported so that users can select approvers from the foundation data instead of using exact values. The approvers can be found either by functional roles or by the relationships defined between people, location, or support groups.
For more information, see Creating and modifying application roles and Functional role.
In approval chaining, when one approval process is complete, another process is triggered based on the outcome of the first process. You configure the chaining of processes using the approval wizard. Chaining requires you to configure two or more approval flow groups and configure processes for each of these flow groups. The processes can be approval processes or any other processes.
Returning to our example where, the request must be approved by the sales manager and the finance manager, you must define two approval process and two flow groups, one for the sales manager and one for the finance manager. When the sales representative submits an approval request, first the sales manager approval process is executed. If the request is rejected, the process is terminated. If the request is approved, the finance approval process is executed.