Prerequisites for Fulfillment Workflows

Here, we will give a brief overview of the key concepts required to understand the Fulfillment workflow.

Business Request

A Business Request is a formal submission by users within an organization to request access to resources. It is directed to managers, resource owners, or delegated authorities for approval or rejection. In Empower ID, business requests group lists of actions for approval. These actions may include adding or removing group members, assigning management roles, or performing other tasks. The Business Request serves as a container that organizes related items also known as Business Request Items.

Creating a demo Business Request

First, go to your EmpowerID Web UI. Expand the IAM Shop, and under it, click on Shop for Access and it will take you to the IT Shop

Open

 

Open

On the IT Shop page, click the Request Access button next to any two groups. Make sure you have selected Groups from the dropdown.

When you click the Request Access button, a window will appear. From there, click the Add to Cart button to add the group to your cart.

Now, from the dropdown, select Management Roles. In the grid, click the Request Access button next to any role. A window will appear; click the Add to Cart button.

Click the Cart icon at the top right of the UI. A window will appear, listing your selected groups and a management role. For each group, choose New application roll-out from the dropdown. For the management role, choose New or additional responsibilities, then click the Evaluate Request button.

After clicking the Evaluate Request button, few controls will appear in the window. In the first textbox, enter the Business Request name, e.g., FWTest BR. Click on the Submit button.

Submitting this, EmpowerID API will create a Business Request. A popup will appear; click the name of your business request, which will open another screen where you can track the status of your request and see the requested items.

As you can see, there are three Requested Items (Business Request Items) in this Business Request. These Business Request Items are what need to be fulfilled. Sometimes they are approved, and sometimes they are rejected. Based on that decision, you will need to take the appropriate action.

Now, click the SHOW button next to any Request Item to view the data contained in a Business Request Item. Notice the Action Type for the Business Request Item. Every Business Request Item has Action Type (Item Type Action).

You can also view the Business Request Items created above in the UI by navigating to Business Request and Tasks → Business Request Reports. Go to the Business Request Items tab, type the name of your Business Request in the search box, and it will display all related Business Request Items along with their details. The Approval Engine uses this information to determine who should approve the request, and the Fulfillment Workflow, which is responsible for executing the action, also relies on this data. The Business Request Item must include at least the Requested Resource, which you can find by navigating to the right side of this grid on your UI.

If you scroll to the right side of the grid, you can see additional columns. For example, to add a person to a group, you need both the assignee (the person you want to add) and the group or group name. The workflow will use this information to complete the fulfillment process. All this information can be found in the Business Request Item.

Business Request Item

A Business Request Item is part of a business request that is processed through a fulfillment workflow. Business Request Items (BRIs) are the individual actions within a larger Business Request in the EmpowerID. They represent the specific tasks or changes that need to be made, like adding a user to a group, disabling an account, or sending an email etc.

Imagine you're shopping at an online store:

Business Request: This is like your shopping cart, containing everything you want to order.

Business Request Items (BRIs): These are the individual items in your cart. Each one is a separate request for a product.

Here's how BRIs fit into the bigger picture:

Origin: BRIs can originate from various sources:

1. IT Shop: Users can manually request actions through an interface called the "IT Shop”.

2. Workflows: Automated workflows, such as those triggered by lifecycle events (e.g., employee termination), can generate BRIs.

3. Recertification Processes: BRIs can be created as part of periodic reviews to confirm access rights.

4. Grouping: BRIs are grouped within a Business Request to provide context and allow for collective approval or rejection.

Data Storage: BRIs contain essential data for processing, including:

Target Resource ID: This is typically the GUID of the resource being acted upon, such as the account to be disabled.

Assignee ID: The GUID of the user receiving access or being affected by the action.

Item Type Action

Each Business Request Item (BRI) has an associated Item Type Action that defines the specific change to be made. For example:

• Add Account to Group

• Disable Account

• Send Email to Person etc.

Item Type Actions are linked to Fulfillment Workflows, which are automated processes responsible for executing these actions once the BRI is approved. These workflows are designed to handle multiple BRIs in bulk for greater efficiency.

Click the Edit (pencil) icon for the Add Account to Group item type action. On the edit page, you can view the Fulfillment Workflow that will be triggered if this action is approved.

These types of workflows are different, they are not initiated from the UI like the workflows we have covered so far in this training. Instead, the system initiates them through a job that runs and claims any Business Request Item that is ready for fulfillment. If the conditions are met, it will trigger the Approval Fulfillment Workflow, as shown in the image above.

Fulfillment Job Overview and Execution Process

The job operates in the background, automatically handling the execution of approved actions within the system

Identifying Requests Ready for Fulfillment: The job periodically checks the database for BRIs whose status indicates they are eligible for fulfillment, considering factors such as approval, previous fulfillment attempts, and configured retry intervals.

Workflow Grouping for Efficiency: The job intelligently groups these requests based on their associated fulfillment workflows. This grouping ensures that similar requests, such as disabling multiple accounts, are processed together, optimising resource usage and improving overall efficiency.

Bulk Processing for Scalability: To handle large volumes of requests efficiently, the job processes items in bulk. The default batch size is 100 items, but this can be adjusted based on system capacity. This approach allows the system to scale to accommodate large organisations with thousands of requests without compromising performance.

Asynchronous Workflow Execution: The job launches each fulfillment workflow asynchronously, without waiting for the previous workflow to complete. This parallel processing significantly speeds up the execution of requests and improves system responsiveness.

Workflow Input and Data Extraction: The job provides each workflow (Fulfillment Workflow) with a list of business request items as an input parameter. This list contains all the data required for the workflow to perform its task, including target resource IDs, assignee information, and any additional data stored in JSON format.

Error Handling and Retries: The job has built-in error handling mechanisms to ensure the robustness of the fulfillment process. If a workflow fails to execute or encounters errors during processing, the job logs these errors and updates the status of the affected business request items. It also implements a retry mechanism, attempting to re-execute failed workflows after a calculated delay.

Status Updates and Database Interaction: The job relies on the fulfillment workflow to update the status of each business request item after processing. It also coordinates the final update of the database, ensuring all changes are committed efficiently and avoiding unnecessary database calls.

So this job acts as the engine that drives the execution of approved actions within the system, by intelligently grouping requests, processing them in bulk, and managing workflow execution, it ensures that business processes are carried out effectively and at scale.

Usage Description Textbox

When someone creates an item type action, it is their responsibility to specify what is in the DataRequestTargetResourceID. The Fulfillment Workflow will use this DataRequestTargetResourceID, assuming it contains the ExchangeMailboxGuid. The Fulfillment Workflow will then disable the mailbox's out-of-office.
Think of DataRequestTargetResourceID as the crucial link that allows the Fulfillment workflow to understand precisely which resource needs to be modified, deleted, or acted upon

Examples of DataRequestTargetResourceID in Action:

Disabling Accounts: In a workflow designed to disable accounts, DataRequestTargetResourceID would contain the GUIDs of all the accounts that need to be disabled. The workflow would then use these GUIDs to retrieve the account objects and execute the disable operation.

Adding Users to Groups: For workflows handling group memberships, DataRequestTargetResourceID might store the GUID of the group, while another column, such as DataRequestAssigneeID, would hold the GUID of the user to be added.