At a high level, when users request access to resources, they initiate workflows that attempt to execute one or more EmpowerID Operations against those resources in a manner consistent manner with the workflow. For example, if a user requests membership in a Management Role, the workflow related to that request attempts to execute operations against 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 approval engine generates the approval tasks for each missing delegation. It sends them to each person within the organization with the RBAC delegations to approve the request (i.e., execute the operations in the workflow). The workflow then goes into an idle state, waiting for a decision. If approved, the workflow resumes, and EmpowerID fulfills the request; if rejected, the workflow exits.
...
When Never Send for Approval is True (selected in the UI)
When Never Send for Approval 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 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 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 Never Send for 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.
...
Business Request Type – As mentioned above, 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 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, and steps can 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.
Item Level Approval – Each step can be configured to allow for Item Level approval. Item Level represents 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 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.
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 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 resource
RBAC Approver – Anyone with the RBAC delegations needed to approve the request
Static Approver – Approvers are specific users selected for the step
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
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.
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.
...