Page Comparison

Workflows and Default Approval routing

At a high level, when When users request access to resources, they initiate workflows that attempt to execute one or more EmpowerID Operations against on those resources in a manner consistent with the workflow. For exampleinstance, if a user requests membership in a Management Role, the associated workflow related to that request attempts to execute operations against tries to perform operations on both the user and the Management Role to update the person’s person's role membership. In a default configuration of the EmpowerID approval flow engineBy default, if a user has access to can initiate a workflow but does not have lacks access to execute one or more operations in the workflowwithin it, the authorization engine returns a message stating that the user does not have the required access is missing. This default mode is the default suitable for workflows used by admins where approval is not desiredadmin workflows that do not require approval. For processes requiring that need approval, EmpowerID offers a powerful robust workflow engine that can be enabled on a workflowper-by-workflow levelbasis.

Workflow Approval Routing

This Organizations can override the default approval process can be overridden to give organizations more for greater control over how the system generates and flows manages approvals. Each workflow has a property called "Do not gererate generate a business request (no approval) and most have that property enabledout of the box," which is enabled for most workflows by default.

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:

1. True state: EmpowerID checks if the person executing the workflow

1. possesses the necessary RBAC access

1. to

1. carry out the

1. operations within the workflow. If the person

1. does have access, the workflow

1. proceeds; if

1. not

1. , EmpowerID

1. informs the person

1. of their access insufficiency, and the workflow

1. is terminated. No approval routing happens in this

1. case. This method reduces the number of approval tasks generated

1. and removes unnecessary actions from the approval process

1. .

1. False state: In this case, the workflow must be

1. associated with a Business Request Type and

1. will always

1. require approval, even if the

1. individual has

1. the authority to execute the workflow operations. The Business Request Type property

1. categorizes workflows, enabling more flexible approval routing and

1. grouping

1. related access requests.

1. This property, coupled with new Access Request and Approval Flow policies, permits organizations to

1. consolidate related 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 IAM 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 and submit their orders, these items are sent as "Business Requests" 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 requests are routed 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:

, 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

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

1. Business Request

1. .

2. Approver Resolver Rules

1. : Dictate who the Approval Flow Step

• Custom Approver Code – Custom code generated by the

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

• Global Risk Owner – If the request would violate a risk policy, approval routes the step to the owner of the global risk for approval.

• Initiator – The request to the person initiating the request

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

• Local Risk Owner –

• PBAC Approver –

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

• Resource Allowed Nation –

• Resource Owner – Owner of the item resource

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

• Target Person –

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

• Target Resource Line Manager –

1. should route for approval.

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

1. .

Image Removed

Approval Flow

While there are several pieces involved with how approvals flow in EmpowerID, the logic is straightforwardEmpowerID's approval flow, despite the multiple components, follows a straightforward logic. Items have two opportunities to go for approval. first optionally at the Business Request or global level. Not all requests will be routed for approval be approved: at the Business Request level. Business Request Level approval is best explained as order- level approval. Business Requests contain multiple items, and the Business Request Type can be configured to have a global or order level approval flow. If the and at the individual item level. If a Business Request is rejected at any of the steps step in this approval flow, the process ends. 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.

Figure 4 above depicts from a high level illustrates how approval flows work in EmpowerID at a high level. In the figurethis example, a new Business Request is created to onboard an employee. As part of the The onboarding request , includes several items are requested, : a Business Role, an Application Role, and a Management Role. The Approval Policy for the Business Request is configured with has two Approval Steps. The first step requires approval by the manager of the employee and the employee's manager's approval, while the second step requires approval by the finance department's approval. In each of the both steps, Item Level approval is configured, meaning that allowing the manager and the finance department can to approve individual items and reject others. Items approved by all steps are then fulfilled by the system, while rejected 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 describes how EmpowerID concludes approved Business Requests. Fulfillment is the completing action of “adding , such as "adding a user to an Application Role” Role" or “provisioning "provisioning a mailbox in Azure”, etc. When the items in a Business Request pass through Azure". Once all levels of approval are cleared, the items are then ready for fulfillment. Fulfillment is handled 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 5.

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. 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 user's notification preferences,

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

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

• Initiator – Person requesting the resource

• TargetPerson – Person receiving the resource assignments

• InitiatorManager – Manager of the request initiator

• TargetPersonManager – Manager of the person receiving the resource

• Approver – Person who approves or rejects a step

• Approver Manager – Manager of the person who approves or rejects a step

• Potential Approver – Selected people who could approve or reject a step (delegated)

• Commenter – Person who adds comments to a request

Levels

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

Approval Flow Demo

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