Page Comparison

Workflows and Default Approval routing

At a high level, when users request When a user requests access to resources, they initiate workflows that attempt to execute one or more EmpowerID Operations against those resources in a manner consistent with the workflowEmpowerID initiates a workflow that executes predefined operations on the target resources. For example, if a user requests requesting membership in a Management Role , the triggers a workflow related to that request attempts to execute operations against that updates both the user and the Management Role to update the person’s role membership. In a default configuration of the EmpowerID approval flow engine, if a user has access to initiate a workflow but does not have access to execute one or more operations in the workflow, the authorization engine returns a message that the user does not have the required access. This mode is the default for workflows used by admins where approval is not desired. For processes requiring accordingly.

By default, if the user has the privilege to initiate but not execute all operations within the workflow, the EmpowerID Authorization Engine notifies the user of any missing access rights. This default behavior is suitable for administrative workflows that do not require approval. However, for processes that require approval, EmpowerID offers a powerful workflow engine that can be enabled on a workflow-byper-workflow levelbasis.

Workflow Approval Routing

This default approval process can be overridden to give organizations more control over how the system generates and flows approvals. Each workflow has a property called Do not gererate EmpowerID allows organizations to override default behavior through its robust Workflow Approval Engine, which is configurable on a per-workflow basis. Each workflow includes a property known as "Do not generate a business request (no approval) and most have that property enabledout of the box," which is enabled by default for most workflows.

Image Modified

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

When “Do not generate a business request (no approval)” is True (selected in the UI)
When Do not generate a business request is set on a workflow (as shown in Figure 2), EmpowerID verifies whether the person executing the workflow has the RBAC access needed to perform the workflow’s operations. If the person has access, the workflow continues; if the person does not have access, EmpowerID notifies the person that they do not have access and the workflow exits. Approval routing never occurs. There are several benefits to removing approval routing in this way, including the following:

1. True state: EmpowerID checks if the initiating user possesses the Role-Based Access Control (RBAC) rights needed for all operations within the workflow. If access is sufficient, the workflow proceeds; if not, EmpowerID informs the user of their access insufficiency, and the workflow terminates. No approval routing happens in this case. This method reduces the number of approval tasks generated

1. and removes unnecessary actions from the approval process

1. .

1. False state: The workflow is associated with a specific Business Request Type and

1. will

1. necessitate approval,

1. irrespective of the user's RBAC permissions. The Business Request Type property

1. categorizes workflows, enabling more flexible approval routing and

1. grouping

1. related access requests.

1. This property, used in conjunction with EmpowerID’s Approval Flow and Access Request policies, allows the aggregation of similar access requests into a single

1. "approval bundle,

1. " specifying who should receive approval tasks

Image Removed

1. and determining the number of approvals needed before fulfillment.
   

Image Added

Approval Flow Policies

When users shop for resources in the IT Shop, they put resource items for which they are eligible to receive in their shopping carts. When ready, they submit the items in their cart to the EmpowerID system. These cart submissions are known as “Business Requests.” Each Business Request can contain one or more resource items, depending on the number of items that were in a user’s cart when submitted. The Business Request, including all the items in that request, route for approval based on the configuration of Approval Flow policies. Approval Flow policies are user-defined policies that organizations can create to direct Business Requests through an approval process that can involve multiple levels of approval from numerous designated approvers before users receive the items in a Business Request, known as “fulfillment.” Organizations can create Approval Flow policies that are as simple or as complex as their needs dictate. Approval Flow policies have a number of key components that can be configured to specify how this occurs:

: Structuring Approvals

Business Requests and Approval Flow

EmpowerID’s Approval Flow policies guide the approval routing of access requests, known as "Business Requests," which users submit via the IAM Shop. In EmpowerID, a Business Request is a formalized request that is commonly initiated by end-users for specific actions or access within an organization's IT ecosystem. These requests can vary in nature, ranging from requesting access to particular resources to initiating specific workflows such as account provisioning, role changes, or permission approvals.

The Business Request feature in EmpowerID allows for the customization of request forms and approval workflows. This enables organizations to tailor the request process according to their specific needs, compliance requirements, or governance policies. Once a Business Request is initiated, it undergoes a predefined approval workflow involving one or multiple approvers, depending on the organization's Approval Flow policy configuration.

These policies ensure that each request is processed in a controlled manner, allowing for efficient tracking and auditing. Upon completion of the approval flow, the Business Request is assigned a status, such as 'Approved' or 'Rejected,' which clearly indicates the request's outcome. This feature enhances the organization's ability to maintain compliance and governance standards by providing a structured, auditable trail of all user-initiated actions and administrative decisions.

Key configurable components of Approval Flow policies include:

1. Business Request Type: A workflow property that groups workflows by the type of business request they represent

1. , like the IT Shop Business Request Type.

1. Approval Flow policies can

1. stipulate multiple levels of approval

1. for certain Business Request Types before fulfillment

1. . Approval flow at the Business Request level is sometimes referred to as global

1. -level

1. approval flow.

2. Approval Flow Steps

1. : Define the number of approvals required for fulfillment, with each step 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

1. at that step. Step-level fulfillment is

1. often used to

1. execute an action when the

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

2. Item Level Approval

1. : Each step can

1. allow

1. Item Level approval

1. , enabling the approver to make decisions on each item instead of a single decision for the entire Business Request

1. .

2. Approver Resolver Rules

1. : Dictate who the Approval Flow Step

1. should route for approval. These can be routed to various actors in EmpowerID

1. including the:

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

   • Target Person Manager – If making a request for another person, the request routes to that person’s manager for approval

   • Resource Owner – Owner of the item resource

   • Global Resource Owner – Owner of the resource specified as the subject of the Business Request. This allows items to be routed for approval to the subject of the request, such as the group, instead of to each account being added as a member.

1. • RBAC Approver – Anyone with the RBAC delegations needed to approve the request

1. • Static Approver – Approvers are specific users selected for the step

1. • Fallback Approver – Can select someone to approve in the instance that a specified approver does not exist, such as would be the case if a Management Role was selected as a Static Approver and no one had that role

2. Items Types

1. and Item Type Actions: Item Types are the individual resources that can be requested,

1. and Item Type Actions represent actions that can occur against an item

1. . Examples of Item Type Actions include Add Account To Group or Assign Azure License.

Image Removed

Approval Flow

Multi-level Approval Flow Logic

EmpowerID allows for two levels of approval: Business Request level and Item level. Rejection at the Business Request level (the global level) terminates the entire process. Only items approved at the Business Request Level pass on progress to the next step, where they can optionally go for approval flow 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 the type is defined with any Approval Flow policies per

Access Request policy.

If the Business Request Type is not defined as specified

, nor defined for the Access Request policy of the target resource for the type, then the engine

checks the Business Request itself to

determine the Approval Flow 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 Flow 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 Flow Policy for the item as specified on the

item's Access Request policy

.

Image Removed

Image Added

Figure 4 above depicts from a high level 3 above illustrates how approval flows work in EmpowerID . In the figure, at a high level. This example creates a new Business Request is created to onboard an employee. As part of the The onboarding request , several items are requested, includes a Business Role, an Application Rolea group, and a Management Role. The Approval Policy for the Business Request is configured with two Approval Steps. The first step requires approval by the manager of the employee and the second step requires approval by the finance department. In each of the steps, Item Level approval is configured, meaning that the manager and the finance department can approve individual items and reject others. Items approved by all steps are then fulfilled by the system, while items rejected within any of the steps are not.

Access Request Policies

Access Request policies are used to control access to resources in EmpowerID and can be used to designate different Approval Flow policies for resources based on their Access Request policy. With this model, you create the Approval Flow policies first and then add them to the Access Request policy when you create it. EmpowerID includes a default out-of-the-box Access Request policy that meets most situations.  In the order of priority to determine the proper approval flow policy for an item, the approval flow policy set on the Access Request Policy is evaluated last.

Fulfillment

Fulfillment is the process by which EmpowerID fulfills approved Business Requests. Fulfillment is the completing action of “adding a user to an Application Role” or “provisioning a mailbox in Azure”, etc. When the items in a Business Request pass through all levels of approval, the items are then ready for fulfillment. Fulfillment is handled 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. This job claims , which handles items ready for fulfillment and does one of two things, depending on whether those items have Correlation IDs associated with themin two ways, based on whether they are associated with Correlation IDs.

1. Fulfill in Different Workflow (No Correlation ID)

1. : Items without Correlation IDs are directed to the fulfillment workflow specified for

1. their related Item Action Types. For

1. instance, if a user is to

1. join a Management Role, the

1. designated workflow for that action would fulfill the item. These items

1. never

1. return to the

1. initial workflow operation for resumption

1. ; instead, the calling workflow exits the process.

2. Fulfill in Initial Workflow (Correlation ID)

1. : Items bearing Correlation IDs are routed back to the

1. originating workflow operation, where approval was

1. a prerequisite to proceed.

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

Notification Policies

As mentioned earlier, part of the approval process involves notifications. Approvers and initiators of requests, as well as all delegated users, received notifications of these events. As part of the redesign of the approval process, EmpowerID has reconfigured how notification occurs, giving users the ability to tailor the amount 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 to their personal preferences.  How notifications now work in EmpowerID is as follows:

. Here's how notifications function in EmpowerID:

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

1. a Business Request

1. .

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

3. The

1. engine determines if the event needs to be added to the Business Request Notification Inbox

1. by first examining individual users' notification preferences and defaulting to system notifications if

1. no personalized settings exist.

2. Notifications are then sent to Business Request participants based on

1. these settings.

Notification Policy Components

There are several components to Several components drive the Notification policies and how the Notification Policy engine delivers notifications. These include the following:

• Business Request Events

• : Four levels of

• events where notifications can be

• Created – Occurs when a Business Request is created. This can be used to, for example, create a policy that sends an email notification to managers of users creating a Business Request.

• Open – This is used in Approval Flow Policies with more than one Approval Flow Step to notify progressive approvers that the item is ready for them to review once a previous step has been approved by the person delegated for that step. If the previous step is rejected, then this notification would not be sent out.

• Approver Set – Raised when someone manually assigns an approver to a step.

• Fulfillment Ready and Fulfillment Completed – These are only available at the item level. They are relative to a specific item that has been approved are is now ready to be fulfilled, which creates a notification at that level. Additional notifications occur when fulfillment completes, such as happens when a user is added to a group in response to a Business Request.

• Completed – Completed can be used at the step level and the Business Request Level to send notifications that a particular step is completed and when the Business Request itself is completed.

Levels

• triggered: Created, Open, Approver Set, Fulfillment Ready, and Fulfillment Completed, and Completed.

• Business Request Participant Type: Individuals associated with a specific part of a business request. These can include the Initiator, TargetPerson, InitiatorManager, TargetPersonManager, 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 the efficient management of the requests. It ensures that approvals are completed within specific timelines, helping organizations meet regulatory requirements. Once the business requests have expired, it doesn't appear for any approvers, thus managing the requests better. EmpowerID has two strategies based on expiration dates for handling business request expiration.

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 - Whenever a business request is initiated, it is assigned an expiry date in the "ExpirationDate" field. If a specific number of days is not mentioned for the process, then the default expiry date will be set to 90 days from the date of creation.

Inactivity Expiration Date - The inactivity expiration date for business requests is calculated dynamically based on user activity. It is calculated by adding the number of days specified in the ExpireRequestAfterXDaysOfInactivity field to the current date. Whenever there is an activity, the inactivity expiration date shifts X days into the future.

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:

Image Added

• 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 is passed.

So, if the "Business Request JSON Inbox Processor" finds a business request that meets these two conditions, it will update the status of that request to "Expired." Consequently, the expired request will no longer show up on the list of tasks for approval by any approver, ensuring 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.