Overview of Fulfillment Workflows
Fulfillment workflows automate the execution of approved business request actions in EmpowerID. When a business request is approved, fulfillment workflows handle the actual provisioning, de-provisioning, or modification of resources in target systems—disabling accounts, adding group memberships, provisioning application access, and similar operations—all running in the background without manual intervention.
Unlike standard workflows that manage the approval process, fulfillment workflows are specifically designed to process high volumes of approved actions efficiently and reliably. They execute in bulk, track the outcome of each individual operation, and report precise success and failure status back to the originating request items.
The Request Pipeline
Understanding where fulfillment workflows fit in the broader request lifecycle provides the essential context for building them effectively.
A Business Request is a container for one or more discrete actions submitted through the IAM Shop. Each individual action within that request is represented as a Business Request Item (BRI), defined by an Item Type Action that specifies what operation needs to happen—for example, "Disable Account" or "Add Account to Group." Once the Approval Engine processes the request and determines it should proceed, the Business Request Fulfillment Job takes over: it scans for approved BRIs, groups them by their Item Type Action, and invokes the appropriate fulfillment workflow to execute each batch.
For a fulfillment workflow to participate in this pipeline, it must be linked to one or more Item Type Actions in the No Code Flows configuration. This link tells the Fulfillment Job which workflow to invoke when BRIs of that action type are approved.
The Four-Stage Architecture
EmpowerID fulfillment workflows follow a standardized four-stage pattern. This structure is not merely a convention—it is the proven approach for building automations that remain performant and maintainable as request volumes scale into the hundreds or thousands.
Stage 1 — Validate (ValidateClaimedBusinessRequestItems): The workflow opens by fetching the batch of BRIs from the Fulfillment Job and verifying that each item is valid, untampered, and in the appropriate state for processing. This stage also records the Fulfillment Process ID on each item, establishing which workflow instance is handling it.
Stage 2 — Prepare Inputs (SetOperationInputs): This is where the developer implements the bulk data preparation logic. The stage extracts target resource identifiers from the validated BRIs, fetches all required resource objects in a single database call, applies any necessary filtering, and assembles the collection that will be passed to the operation activity. Critically, this stage also populates the BusinessRequestItemDictionary—a lookup table that maps each resource GUID back to its originating BRI, enabling precise status reporting after the operation completes.
Stage 3 — Execute Operation: The developer inserts a pre-built bulk operation activity here—for example, DisableAccountOperation. The activity receives the prepared collection and executes a single bulk operation against all resources, returning an OperationExecutionSummary collection that records the outcome for each individual resource.
Stage 4 — Update Status (SetBusinessRequestItemStatus): Using the OperationExecutionSummary results from Stage 3 and the BusinessRequestItemDictionary created in Stage 2, this stage maps each operation result back to its originating BRI and updates the item's fulfillment status—marking it as succeeded or failed. All status updates are committed to the database in a single bulk write.
Key Design Patterns
Two design patterns underpin the four-stage architecture and are essential to understand before building fulfillment workflows.
The Dictionary Pattern
Bulk operations are efficient precisely because they process all resources in a single call, but this creates a challenge: the operation returns a flat list of results with no inherent link back to the BRIs that requested them. The BusinessRequestItemDictionary solves this by acting as a manifest. During Stage 2, the developer populates the dictionary by mapping each resource's GUID to its corresponding BRI. When Stage 4 processes the operation results, it uses the GUID from each OperationExecutionSummary to look up the exact BRI in the dictionary and update its status. This is what allows a workflow processing 500 accounts to report precise individual outcomes for every single one.
Bulk Operations
Fulfillment workflows are designed to handle enterprise-scale volumes. The architecture requires that data retrieval, operation execution, and status updates all occur in bulk—fetching all required resources in one database call, executing the operation across all of them at once, and committing all status changes in a single write. Iterating through BRIs one at a time and making individual database calls for each is the most common performance anti-pattern in fulfillment workflow development and should always be avoided.
Composite Keys
For operations that involve a relationship between two resources—such as adding an account to a group—a single resource GUID is not sufficient to uniquely identify a BRI, because the same account GUID might appear in multiple BRIs targeting different groups. In these cases, the developer constructs a composite key by combining both relevant GUIDs into a single string identifier. The dictionary is then keyed on this composite value, and the same composite key is reconstructed during Stage 4 to look up the correct BRI from the operation results. The overall pattern remains identical; only the key strategy changes.
Next Steps
For step-by-step guidance on implementing fulfillment workflows using this architecture, see Creating Fulfillment Workflows.