You can leverage the approval library to enable approvals 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. For more information about creating an approval process, see Adding an approval process to an application.
An approval process defines logic, workflows, and steps required for an approval request to be completed. 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 canceled). 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. You need to build the following approval guidelines into the reimbursement application:
- If a sales representative spends up to USD 40, the request can be self approved.
- If a sales representative spends USD 60 or more on meals, the request can be approved by any sales manager.
- If a sales representative 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 representative spends USD 90 or more, the request must be approved by the direct manager of the sales representative and the finance manager.
Self approval flows
An approval request with self approval flows is 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 rejected.
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. You 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, check 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.
In 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 manager at any level rejects the request, the system completes the request and 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 a manager associated to him, the approval process results in an error and the system rejects 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.
While selecting approvers, users can 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.
You can specify the count of approvers by selecting the following options:
- One Must Approve—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 Approve—Approval requests are created for each approver. After the request is approved or rejected by each approver, the request is closed.
- N% Must Approve— Approval requests are created for each approver. Only after the request is approved or rejected by specified percent of approvers, the request is closed.
For example, if you send the request to five approvers, and you have specified the percent as 60, then the request is closed only after any three approvers completes the approval.
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. 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 of process creation.
Types of approvers
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 users 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. You can find the approvers 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.
In our example where, the request must be approved by the sales manager and the finance manager, you must define two approval processes 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.