Page Comparison

Image Added

The logic that occurs in the approval process in relation to the Do not generate a business request (no approval) property on a given workflow is 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:

  • This

  keeps

  • significantly reduces the number of approval tasks generated by the system and removes actions from the approval process that should not be there in the first place.

  • The workflows and the operation base

  no longer

  • do not generate Business Process Tasks (Business Process is a workflow and all the operations in it are Business Process Tasks) when a person does not have the RBAC delegations to execute the workflow.

• When “Do not generate a business request (no approval)” is False (not selected in the UI)
  If the setting is false, the workflow must be configured with a Business Request Type and it will always go for approval, even if the person has access to execute the workflow operations. The Business Request Type property allows workflows to be classified for the purpose of providing greater flexibility in approval routing and the grouping together of related access requests. Rather than having a default approval routing that simply routes unrelated approvals to all users with the delegations to approve requests, organizations can

• this property along with new Access Request and Approval Flow policies to group together related access requests into a single

• consolidated “approval bundle,“ specify to whom approval tasks should go, and how many approvals need to occur before fulfillment occurs.

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 was 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 “fulfilment“fulfillment.” Organizations can craft create Approval Flow polices 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.These components include the following:

• Business Request Type – As mentioned above, a Business Request Type is a workflow property used to group workflows by the type of business request they represent. An example of a Business Request Type is the IT Shop Business Request Type. This type represents anything that is published to the IT Shop, such as Application and Business Roles, Management Roles, and Azure Licenses. Approval Flow policies can be configured to specify that requests of a certain Business Request Type must go through three multiple levels of approval, for example, before fulfillment occurs. Approval flow at the Business Request level is sometimes referred to as global level, versus item level, approval flow.

• Approval Flow Steps – Approval Flow Steps are added to Approval Flow policies to specify how many approvals are required for fulfillment. Approval Flow policies can have as many Approval Flow Steps as needed. Each step is a sequential step that must be approved at that level to proceed to the next step. Each step can have its own approval flow as wellapprover resolver logic, and steps can optionally be configured for “step-level” fulfillment. This means that a step can run a workflow and perform some action based on the decision made for the step. Step-level fulfillment is most often used to perform an action when the approver’s decision was one that was a rejection that stopped 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 be configured to allow for Item Level approval. Item Level represents This setting is specific to the global or Business Request level approval and allows the approver to make decisions on each item instead of a single decision for the entire Business Request. Item Level refers to the individual items in a business request, such as requesting an Office 365 mailbox or an Application Role. With Item Level approval enabled for a Business Request level step, the step approver can elect to make item-by-item approvals rather than being forced to approve or reject the entire request in toto. These items. Only those items not rejected at an approval step in the Business Request level for a Business Request that is approved, move forward for item-level approval evaluation.

  • Approver Resolver Rules – Approver Resolver rules specify to whom the Approval Flow Step needs to route for approval. These can be routed to various actors in EmpowerID to include the:

    Initiator Manger – The request routes to the manager of

    those listed below:

    • 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 requestTarget Person

    • Initiator Manager – If making a request for another person, the request routes to that person’s manager for approvalResourse Owner – Owner of the resourceThe 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 –

  • 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. Fallback Approver options include those listed above for Approver Resolver Rules.

  • Items Types – Item Types are the individual resources that can be requested, such as membership in an Application Role or access to an Office 365 mailbox. The Item Type is where the template for viewing an item is defined to specify which properties to show.

  • Item Type Actions – Item Type Actions are in essence EmpowerID Operations and represent actions that can occur against an item (resource). Examples of Item Type Actions include Add Account To Group or Assign Azure License. Item Type Actions are where the final fulfillment workflow is defined which knows how to complete the requested action.
    

    Image Added

Approval Flow

While there are several pieces involved with how approvals flow in EmpowerID, the logic is straightforward. 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 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 Business Request is rejected at any of the steps in this approval flow, the process ends. Only items approved at the Business Request Level pass on to the next step, where they can optionally go for approval flow at the individual item level.

Business Request Level

1. The Approval engine first looks at Business Request Type to see if the type is defined with any Approval Flow policies per Access Request policy. In other words, the engine looks to see if the target resource at the Business Request level is in a specified Access Request policy; if so, the engine then gets the Approval Flow policy specified for the Access Request policy.

2. If the Business Request Type is not defined as specified in Step 1 above nor defined for the Access Request policy of the target resource for the type, then the engine looks at the Business Request itself to see what is specified as the Approval Flow policy.

Item Level

1. The Approval engine first looks at the Item Type Action per the Access Request policy to see if the policy designates different Approval Flow policies for the resource of the item based on its Access Request policy.

2. If there is not an Access Request policy defined in this way for the Item Type Action, the engine looks at the Item Type Action itself to see if there is a specific Approval Flow Rule set for it. For example, an action like Add Account To Group can have a different Approval Flow Rule than the Remove Account From Group action.

3. Finally, if there is not a specific Approval Flow Rule set on the Item Type Action, the Approval engine falls back to the Approval Flow Policy for the item as specified on the item’s Access Request policy.

Image Added

Figure 4 above depicts from a high level how approval flows work in EmpowerID. In the figure, a new Business Request is created to onboard an employee. As part of the onboarding request, several items are requested, a Business Role, an Application Role, 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 Access Request policy 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 by the Business Request Item Fulfillment Job. This job claims items ready for fulfillment and does one of two things, depending on whether those items have Correlation IDs associated with them.

1. Fulfill in Different Workflow (No Correlation ID) – Sends items without Correlation IDs to the fulfillment workflow specified for the related Item Action Types. For example, if a user is to be added to a Management Role, the item would be fulfilled by the workflow specified for that action. These items are never sent back to the calling workflow operation for resumption. The calling workflow exits the process.

2. Fulfill in Initial Workflow (Correlation ID) – Returns items with Correlation IDs back to the calling workflow operation where approval was required to proceed.

Figure 5 below visually depicts from a high level how fulfillment occurs based on whether Correlation IDs exist for an executed workflow.

Image Added

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 and type of notifications they receive to their personal preferences.  How notifications now work in EmpowerID is as follows:

1. Each time a user submits a Business Request a Business Request Event is raised.

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

3. The Business Request Notification Policy engine determines if the event needs to be added to the Business Request Notification Inbox. To determine this, the engine first performs a granular scan of each person’s notification preferences, then falls back to the default system notifications if there are no personal notification preferences set.

4. Notifications are then sent to Business Request participants based on those notification settings.

Notification Policy Components

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

1. Business Request Events – There are four levels of Business Request Events where notifications can be raised.

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

   • Fulfilment Fulfillment Ready and Fulfillment Completed — – These are only available at the item level. They are relative to a specific item . These items have that has been approved and are is now they are ready to be fulfilled. This , which creates a notification at that level. Once fulfilled, notification events are raised. You added someone Additional notifications occur when fulfillment completes, such as happens when a user is added to a group in response to a request, for exampleBusiness 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.

2. Business Request Participant Type — – Individuals related to a specific part of a business request. are fields in the BusinessRequestParticipantType table.

   • 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

3. Levels

   • Business Request— – Shopping cart submission

   • Business Request Item— – Individual items submitted

   • Business Request Approval Step — – TheBusiness request is approved or rejected globally. The decision here if is final.

   • Business Request Item Approval Step— – Each item in the business request can be approved or rejected on a case-by-case basis.

4. Messages — – Email message messages delivered by the notification engine to Business Request participants.

Approval Flow

While there are several pieces involved with how approvals flow in EmpowerID, the logic is straightforward. Approval flow begins at the Business Request level and then flows the items in the Business Request. If the Approval Flow Policies are configured to grant approval at the Business Request level, Item level approval is not necessary as all items in the request are approved.

Business Request Level

1. The Approval engine first looks at Access Requests policies to see if there is a policy for a specific Business Request Type defined with a particular Approval Flow policy.

2. If there is not an Access Request policy defined in this way, then the engine looks for the Approval Flow Policy of the Business Request Type.

3. If there is not an Approval Flow Policy specified for the Business Request Type, the engine then looks for the Approval Flow Policy of the resource from its Access Request Policy.

Item Level

1. The Approval engine first looks at the Item Type Action per the Access Request policy to see if the policy designates different Approval Flow policies for the resource of the item based on its Access Request policy.

2. If the there is not an Access Request policy defined in this way for the Item Type Action, it the looks at the Item Type Action itself to see if there is a specific Approval Flow Rule set for it. For example, an action like Add Account To Group can have a different Approval Flow Rule than the Remove Account From Group action.

3. Finally, if there is not a specific Approval Flow Rule set on the Item Type Action, the Approval engine falls back to the Approval Flow Policy for the item as specified on the item’s Access Request policy.

Image Removed

Figure 2: Approval Flow at the Business Request and Item Levels

 Figure 2 above depicts from a high level how approval flows work in EmpowerID. In the figure, a new Business Request is created to onboard an employee. As part of the onboarding request, several items are requested, a Business Role, an Application Role, 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.

Fulfilment

Fulfilment is the process by which EmpowerID fulfils approved Business Requests. Fulfilment 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 fulfilment. Fulfilment is handled by the Business Request Item Fulfilment Job. The job claims items ready for fulfilment and does one of two things, depending on whether those items have Correlation IDs associated with them. (Items with Correlation IDs were started in a workflow and need to be sent back to the workflow at the operation waiting for approval.) based on the mode of the workflow:

1. Mode 1 (No Correlation ID) — Sends items without Correlation IDs to the fulfilment workflow specified for the related Item Action Types. For example, if a user is to be added to a Management Role, the item would be fulfilled by the workflow specified for that action.

2. Mode 2 (Correlation ID) — Returns items with Correlation ID to the workflow operation where approval was required to proceed.point in the workflow where approval was required.

EmpowerID executes the operations of the associated fulfilment workflows to perform those actions against the appropriate target systems.

Demo

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