About the EmpowerID Approval Engine
The EmpowerID Approval Engine manages the authorization of access requests submitted through workflows. When users request access to resources, the Approval Engine routes these requests to appropriate approvers based on configurable policies, tracks approval decisions, and coordinates multi-level approval processes. This article explains how the Approval Engine evaluates workflow permissions, applies approval policies, and routes requests through approval workflows.
Workflow Approval Routing
Organizations can override the default approval process for greater control over how the system generates and manages approvals. Each workflow has a property called "Do not generate a business request (no approval)," which is enabled by default for most workflows.
Direct Execution Mode
When the "Do not generate a business request (no approval)" setting is enabled, EmpowerID evaluates whether the person executing the workflow possesses the necessary RBAC access to perform the operations. If authorized, the workflow proceeds immediately. If not authorized, EmpowerID informs the person of insufficient access and terminates the workflow.
No approval routing occurs in this mode. This approach reduces approval task volume and streamlines workflows where the user's existing permissions provide sufficient authorization.
Approval-Required Mode
When the "Do not generate a business request (no approval)" setting is disabled, the workflow must be associated with a Business Request Type and will always require approval—even if the individual has sufficient RBAC authority to execute the workflow operations directly.
Operations within the workflow that generate Business Request Items must have an appropriate Business Request Item Type Action associated with them. The Business Request Type categorizes workflows and enables flexible approval routing by grouping related access requests. This configuration, combined with Access Request and Approval Policies, allows organizations to consolidate related access requests into a single approval bundle, specify approval routing, and define the number of approvals required before fulfillment.
Approval Policies
When users shop for resources in the IAM Shop and submit their orders, EmpowerID sends these items as Business Requests to the approval system. Approval Policies route these requests and define multi-tiered approval processes in line with organizational requirements.
Policy Components
The Approval Policy architecture consists of interconnected components that work together to control approval routing and decision-making. The diagram below illustrates how these components relate to each other and integrate with workflows and access policies.
Key policy components include:
Business Request Type
Identifies the type of business request and specifies a global approval policy to apply to the entire Business Request. Examples include "IT Shop Request," "Role Assignment Request," or "Privileged Access Request." Approval policies can stipulate multiple approval levels for specific Business Request Types before fulfillment. Approval flow at the Business Request level is sometimes called global-level approval flow.
Approval Policy
Defines the steps required to approve an action. Approval Policies can be applied at the Business Request level (global) or at the item level for specific Item Type Actions. Policies specify the approval workflow, the number of steps, and escalation behavior.
Approval Steps
Sequential stages that define the approval levels required for fulfillment. Each step represents an approval stage that must be completed before the request progresses. Steps can be configured for step-level fulfillment, which executes a workflow based on the approval decision at that step. Step-level fulfillment is commonly used to trigger actions when an approver rejects a request, halting the approval flow's forward processing. Standard fulfillment only executes when all steps are approved.
Approver Resolver Rules
Logic that determines who receives approval tasks for each step. Rules can route tasks based on organizational relationships (manager, resource owner), specific roles, or other criteria. Multiple resolver rules can be configured, with fallback options if the primary resolver yields no results.
Fallback Approver
Identifies who the approval should be sent to if the approval step has no primary approver. This ensures that approval tasks are always routed to someone who can make a decision, preventing requests from stalling when standard resolver rules produce no results.
Pre-Approved For
Identifies assignees who can be automatically approved for the approval step. When a request involves pre-approved assignees, the system bypasses manual approval and proceeds directly to the next step or to fulfillment. This reduces approval burden for routine, low-risk requests.
Escalation Policy
Defines the action that should be taken if an approver does not respond within a specified period of time. Escalation actions can include notifications, adding additional approvers, auto-closing steps, or other interventions to prevent approval delays.
Escalation Actions
Specific actions to take when an escalation policy is triggered. Actions include notifying the approver or their manager, adding assignees to the approval step, auto-closing the step with a specific decision, or executing custom workflows. Each action can be configured with timing and conditions.
Access Request Policy
Assigned to resources and defines various aspects of how requests for that resource are handled. The Access Request Policy includes the Approval Policy for requests involving the resource, eligibility rules, risk levels, and other request-processing parameters.
Note: EmpowerID includes a Default Access Request Policy that most resources use automatically. This policy enables time-restricted access, allowing users and approvers to set access durations per request. Custom Access Request Policies are primarily used for privileged access management scenarios that require enforced time restrictions, MFA requirements, or specialized credential management. For information on configuring Access Request Policies for privileged access scenarios, see the Privileged Access Management documentation.
Item Type Action
The action that can occur against a business request item. Examples include "Add Account to Group" or "Assign Azure License." Each Item Type Action can have its own approval requirements, allowing different operation types to follow different approval paths even within the same Business Request.
Workflow Operation
An activity in a low-code workflow that performs an action against a protected resource. The workflow definition designates the Business Request Type to be used for global approval processing and specifies which operations generate Business Request Items requiring approval.
Item Level Approval
A configuration that allows approvers to make decisions on individual items within a Business Request rather than approving or rejecting the entire request. This enables granular control when requests contain multiple unrelated resources. When enabled, approvers can approve some items while rejecting others based on individual merit.
Approval Flow Logic
EmpowerID's approval flow evaluates requests at two levels: the Business Request level and the individual item level. Requests must pass through both evaluation stages to reach fulfillment.
If a Business Request is rejected at any step during approval, the process terminates. Only items approved at the Business Request level progress to item-level evaluation, where they can be approved or rejected individually.
Business Request Level Evaluation
The Approval Engine examines the Business Request Type to determine which Approval Policy applies. The policy determination follows this hierarchy:
Check for Approval Policies defined for the Business Request Type in the Access Request Policy
If no type-specific policy exists, check the Approval Policy directly on the Business Request
Apply default system policies if neither of the above are configured
Business Request level approval applies to the entire request. Rejection at this level terminates all items in the request.
Item Level Evaluation
After passing Business Request level approval, the Approval Engine evaluates individual items. The item evaluation follows this hierarchy:
Check the Item Type Action for Approval Policies defined in the Access Request Policy
If no policy-specific configuration exists, check the Item Type Action for a specific Approval Flow Rule
If no Approval Flow Rule is set, apply the Approval Policy specified in the item's Access Request Policy
Item-level approval enables different approval requirements for different operation types within the same Business Request. For example, adding a user to a standard group might require manager approval, while adding them to a privileged group requires security team review.
Fulfillment Process
Once all levels of approval are cleared, items in a Business Request can proceed to fulfillment. This process is managed by the Business Request Item Fulfillment Job, which handles items ready for fulfillment in two ways, based on whether they are associated with Correlation IDs.
Fulfill in Different Workflow (No Correlation ID): Items without Correlation IDs are directed to the fulfillment workflow specified for their related Item Action Types. For instance, if a user is to join a Management Role, the designated workflow for that action would fulfill the item. These items never return to the initial workflow operation for resumption; instead, the calling workflow exits the process.
Fulfill in Initial Workflow (Correlation ID): Items bearing Correlation IDs are routed back to the originating workflow operation, where approval was a prerequisite to proceed.
The presence of Correlation IDs within a workflow is a user-controlled setting that can be enabled or disabled for any workflow within the EmpowerID UI as needed. The "Return to WF for Fulfillment" setting governs this behavior and can be adjusted on the "Edit One" page of any workflow.
Notification Policies
As part of the approval process, EmpowerID sends notifications to request approvers, initiators, and delegated users. The approval process allows users to customize the frequency and type of notifications they receive. Here's how notifications function in EmpowerID:
A Business Request Event is created each time a user submits a Business Request.
Business Request Events are submitted to the Business Request Notification Policy engine.
The engine determines if the event needs to be added to the Business Request Notification Inbox by examining individual users' notification preferences and defaulting to system notifications if no personalized settings exist.
Notifications are then sent to Business Request participants based on these settings.
Notification Policy Components
Several components drive the Notification policies and how the Notification Policy engine delivers notifications. These include:
Business Request Events: There are four levels of events where notifications can be triggered: Created, Open, Approver Set, Fulfillment Ready, Fulfillment Completed, and Completed.
Business Request Participant Type: Individuals associated with a specific part of a business request. These can include the Initiator, Target Person, Initiator Manager, Target Person Manager, Approver, Approver Manager, Potential Approver, and Commenter.
Levels: Several levels can be designated for notifications, including Business Request, Business Request Item, Business Request Approval Step, and Business Request Item Approval Step.
Messages: Email messages delivered by the notification engine to Business Request participants.
Business Request Expiration
Setting expiration dates for business requests is crucial for efficient request management. This practice ensures that approvals are processed within specified timelines, enabling organizations to comply with regulatory requirements. After the expiration of business requests, they no longer appear for any approvers, streamlining request management processes. EmpowerID employs two strategies based on expiration dates to handle the expiration of business requests.
Fixed 90-day policy: Automatically expires any incomplete requests after 90 days from the creation date.
Inactivity expiration date: Calculates the period of inactivity based on user actions, adding the number of days specified in the "ExpireRequestAfterXDaysOfInactivity" field of the Business Request Type to the current date. This date shifts with each user interaction, extending the expiration based on ongoing activity.
Known areas for improvement: There is room for improvement in the current expiration logic for business requests that may be implemented in the future. Known areas for improvement are
Ability to define distinct expiration dates (in days) based on the types of business requests.
A notification or event should be triggered when a business request expires and ensure an action is associated with it.
The job “Business Request JSON Inbox Processor“ is responsible for finding expired business requests and setting their status as expired. For a business request to be considered "expired," it must meet two conditions:
Status: The request should be in an "Open" or "In Progress" status, indicating that it is still active and has not been completed or canceled.
Expiration Dates: Either the expiration date or the inactivity expiration date has passed.
If the "Business Request JSON Inbox Processor" finds a business request that meets these two conditions, it will update its status to "Expired." Consequently, the expired request will no longer appear on the list of tasks for approval by any approver, ensuring that no further actions are taken on a no longer valid request.
Approval Flow Demo
The following video demonstrates how to configure approvals and approval routing in EmpowerID.