About the EmpowerID Approval Engine

Owned by Phillip Hanegan
Last updated: Nov 22, 2024
8 min read

When users request access to resources, they initiate workflows that execute one or more EmpowerID Operations on those resources in a manner consistent with the workflow. For example, when a user seeks to join a Management Role, the corresponding workflow initiates operations targeting both the user and the Management Role to update the user's role membership. By default, if a user initiates a workflow but does not have the necessary permissions to execute certain operations within it, the authorization engine issues a notification indicating the lack of required access. This default mode is suitable for admin workflows that do not require approval. EmpowerID offers a robust workflow engine for processes needing approval that can be enabled per-workflow basis.

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.

 

Figure 1: Do not generate a business request (no approval) workflow property

The approval process logic, in relation to the "Do not generate a business request (no approval)" property on a given workflow, occurs as follows:

  1. True state: EmpowerID checks if the person executing the workflow possesses the necessary RBAC access to carry out the operations within the workflow. If the person does have access, the workflow proceeds; if not, EmpowerID informs the person of their access insufficiency, and the workflow is terminated. No approval routing happens in this case. This method reduces the number of approval tasks generated and removes unnecessary actions from the approval process.

  2. False state: In this case, the workflow must be associated with a Business Request Type and will always require approval, even if the individual has the authority to execute the workflow operations. The Business Request Type property categorizes workflows, enabling more flexible approval routing and grouping related access requests. This property, coupled with new Access Request and Approval Flow policies, permits organizations to consolidate related access requests into a single "approval bundle," specifying who should receive approval tasks and determining the number of approvals needed before fulfillment.

Figure 2: Workflow Approval Routing based on the state of the 'Do not generate a business request' property on a given workflow

 

Approval Policies

When users shop for resources in the IAM Shop and submit their orders, these items are sent as "Business Requests" to the EmpowerID system. These requests are routed for approval based on Approval policies, which can be adjusted to create multi-tiered approval processes based on the organization's requirements.

Key components of Approval policies that can be configured include:

  • Business Request Type: This is a workflow property that groups workflows by the type of business request they represent, like the IT Shop Business Request Type. Approval policies can stipulate multiple levels of approval for certain Business Request Types before fulfillment. Approval flow at the Business Request level is sometimes called global-level approval flow.

  • Approval Flow Steps: These define the number of approvals required for fulfillment, each representing a sequential stage that must be approved before progressing. Each step can be optionally configured for "step-level" fulfillment. This means that a step can run a workflow and perform some action based on the decision made at that step. Step-level fulfillment is often used to execute an action when the approver's decision results in a rejection, stopping the forward processing of the approval flow. The normal fulfillment process for an item request only executes if all steps are approved.

  • Item Level Approval: Each step can allow Item Level approval, enabling the approver to make decisions on each item instead of a single decision for the entire Business Request.

  • Approver Resolver Rules: These dictate who the Approval Flow Step should route for approval.

  • Items Types and Item Type Actions: Item Types are the individual resources that can be requested, and Item Type Actions represent actions that can occur against an item. Examples of Item Type Actions include Add Account To Group or Assign Azure License.

Approval Flow Logic

Despite its multiple components, EmpowerID's approval flow follows straightforward logic. Items have two opportunities to be approved: at the Business Request level and the individual item level. The process ends if a Business Request is rejected at any step in this approval flow. Only items approved at the Business Request Level progress to the next step, where they can optionally be approved at the individual item level.

Business Request Level

At this level, the Approval engine looks at the Business Request Type to see if it is defined with any Approval policies per the Access Request policy. If the Business Request Type is not defined as specified or for the Access Request policy of the target resource for the type, then the engine checks the Business Request itself to determine the Approval policy.

Item Level

At this level, the Approval engine first checks the Item Type Action per the Access Request policy to see if the policy designates different Approval policies for the item based on its Access Request policy. If there isn't a specific Access Request policy defined for the Item Type Action, the engine checks the Item Type Action itself for a specific Approval Flow Rule. If there isn't a specific Approval Flow Rule set, the Approval engine falls back on the Approval Policy for the item as specified on the item's Access Request policy. 

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.

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

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

Â