Approval Engine

When a user requests access to certain resources, a workflow is initiated. This workflow attempts to execute one or more EmpowerID Operations on the requested resources in a consistent manner. For example, if a user requests membership in a Management Role, the corresponding workflow tries to perform operations on both the user and the Management Role to update the person's role membership.

By default, if a user is authorized to initiate a workflow but lacks access to execute one or more operations, the authorization engine returns a message indicating that the required access is missing. This default mode is suitable for admin workflows that do not require approval.

However, for processes that require approval, EmpowerID offers a robust Approval engine that can be enabled on a per-workflow basis.

Workflow Approval Routing

Organizations can customize the approval process to have more authority over how the system handles approvals. Each workflow has a default setting called "Do not generate a business request (no approval)," which is typically enabled for most workflows.

Open

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

When it comes to the "Do not generate a business request (no approval)" property on a workflow, the approval process logic works as follows:

If the property is set to True, EmpowerID checks if the person executing the workflow has the necessary RBAC access to carry out the operations within the workflow. If the person has the access, the workflow proceeds. If not, EmpowerID informs the person of their access insufficiency, and the workflow is stopped. In this case, no approval routing takes place. This method helps minimize the number of approval tasks generated and removes unnecessary actions from the approval process.

If the property is set to False, the workflow must be associated with a Business Request Type, and it 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 and new Access Request and Approval Flow policies enable 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.

Open

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

Approval Flow 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 Flow policies, which can be adjusted to create multi-tiered approval processes based on the organization's requirements.

Key components of Approval Flow policies that can be configured include:

1. Business Request Type: A workflow property that groups workflows by the type of business request they represent, like the IT Shop Business Request Type. Approval Flow 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.

2. Approval Flow Steps: 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.

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

4. Approver Resolver Rules: Dictate who the Approval Flow Step should route for approval. These can be routed to various actors in EmpowerID, including the following:

   • Initiator Manager – The step routes to the manager of the person initiating the request

   • Target Person Manager – The step routes to the manager of the person for whom the request is being made on behalf of.

   • Resource Owner – The step routes to the owner of the resource

   • RBAC Approver – The step routes to anyone with the RBAC delegations needed to approve the request

   • Static Approver – The step routes to specific users for approval

   • Fallback Approver – The step routes to the selected approver if a specified approver does not exist. This scenario could occur if a Management Role was chosen as a Static Approver and no individual is assigned to that role.

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

6. Item Type Action Form Policies:

Approval Flow

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 stage, the Approval engine examines the Business Request Type to verify if it is associated with any Approval Flow policies as per the Access Request policy. If the Business Request Type is not specifically designated for the Access Request policy of the relevant resource type, then the engine will assess the Business Request directly to ascertain the Approval Flow policy.

Item Level

At this stage, the Approval engine initially verifies the Item Type Action in accordance with the Access Request policy to ascertain whether distinct Approval Flow policies are assigned based on the item's Access Request policy. In cases where there is no specific Access Request policy defined for the Item Type Action, the engine examines the Item Type Action itself to identify if a particular Approval Flow Rule has been established. If no specific Approval Flow Rule is configured, the Approval engine defaults to the designated Approval Flow Policy for the item outlined in its Access Request policy.

Figure 4 above illustrates how approval flows work at a high level in EmpowerID. This example creates a new Business Request to onboard an employee. The onboarding request includes a Business Role, an A"” 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.

The fulfillment process, according to the existence of Correlation IDs, is depicted in Figure 5.

Notification Policies

EmpowerID sends notifications to request approvers, initiators, and delegated users as part of the approval process. The approval process allows users to customize the frequency and type of notifications they receive. Here's how notifications function in EmpowerID:

1. A Business Request Event is created each time a user submits a Business Request.

2. Business Request Events are submitted to the Business Request Notification Policy engine.

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

4. 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 important for their efficient management. It ensures that approvals are completed within specific timelines, helping organizations meet regulatory requirements. Once the business requests have expired, they don't appear for approvers, thus improving their management. EmpowerID has two strategies for handling business request expiration based on expiration dates.

The first is a fixed 90-day policy, based on an expiration date, which automatically expires any incomplete requests after 90 days. The second strategy is more dynamic based on the inactivity expiration date, calculating the period of inactivity based on user actions. The types of expiration dates in EmpowerID are

Expiration Date – When a business request is created, an expiration date is assigned in the "ExpirationDate” field. If a specific number of days is explicitly provided for the process, that will be used. Otherwise, the default expiration date will be 90 days from the creation date.

Inactivity Expiration Date – The expiration date for inactivity is not fixed, but it varies based on the user's activity on the generated business requests. The calculation of this date involves adding the number of days specified in the "ExpireRequestAfterXDaysOfInactivity" field of the Business Request Type to the current date. Whenever someone interacts with the process, such as approving, rejecting, setting a new approver, triggering an escalation, etc., the inactivity expiration date shifts X days into the future. Therefore, every time there is an activity in a business request, the inactivity expiration date gets recalculated by adding the days specified in the business request type of the business request item.

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 mentioned earlier has passed.

If the "Business Request JSON Inbox Processor" discovers a business request that satisfies the following two conditions, it will modify the status of that request to "Expired." As a result, the request that has expired will no longer appear on the list of tasks for any approver to approve. This guarantees that no further actions are taken on a request that is no longer valid.

Approval Flow Demo

The following video demonstrates how to configure approvals and approval routing in EmpowerID.