Skip to main content

No Code Flows Overview

EmpowerID's No Code Flows provides administrators with a framework to design, manage, and automate business process workflows without traditional coding. Built on a component-based architecture, No Code Flows offers predefined elements that connect stages of a business process, from data acquisition to approval mechanisms and task execution.

This article introduces the core components and execution flow of No Code Flows, providing the foundation needed to build automated workflows in your organization.

Core Components​

No Code Flows consists of interconnected components that work together to automate business processes. Understanding these building blocks is essential for creating effective workflows.

Flow Events​

Flow Events are triggers that initiate workflows. When an event occurs, it is added to the Flow Event Inbox, where it awaits processing by the system.

Common Flow Event examples:

  • Person Leaver — Triggered when an employee or contractor leaves the organization. May initiate actions such as disabling accounts, removing group memberships, archiving emails, and revoking access to resources.
  • Mailbox Discovered — Triggered when a new mailbox is detected. May initiate verification, distribution list additions, or security control setup.
  • Account Takeover — Security-related trigger indicating potential unauthorized access. May initiate account suspension, security team notifications, or investigation procedures. Flow Events Configuration Figure 1: Flow Events page showing the Person Leaver event configuration

Flow Items​

Flow Items are specific tasks or actions performed in response to Flow Events. Each Flow Item handles a particular aspect of the event response.

Flow Item parameters:

ParameterPurposeExample
Item Type ActionSpecifies the exact task to execute"Bulk Remove Person Group Membership", "Person Disable"
Item Scope TypeDetermines the range within which the action executes"All Accounts for Person", "Remove All Non-RBAC Group Accounts"
Item Collection QuerySQL statement that retrieves resources related to the Flow ItemQuery to retrieve all user accounts owned by a person

Together, these parameters define what action to take, where to apply it, and which resources to affect. Multiple Flow Items can be combined within a Flow Definition to create complex automated workflows.

Flow Definitions​

Flow Definitions are containers that hold one or more Flow Items. They serve as templates for business processes, defining how Flow Items are orchestrated in response to specific Flow Events.

For example, a "Person Leaver" Flow Definition might contain Flow Items for disabling accounts, removing group memberships, and archiving emails, executed in a specific sequence.

Flow Definition Structure Figure 2: Flow Definition showing multiple Flow Items and their execution sequence

Flow Policies​

Flow Policies connect Flow Events to Flow Definitions. They specify which Flow Definitions to trigger in response to particular events.

Organizations can create multiple Flow Policies for a single event to handle different scenarios. For example:

  • An "internal employee departures" policy might disable access to internal systems
  • An "external consultant departures" policy might revoke temporary access permissions

This flexibility allows organizations to adapt automated responses to specific circumstances and requirements.

Flow Policy Configuration Figure 3: Flow Policy linking a Flow Event to its corresponding Flow Definition

Flow Policies and Flow Definitions work together: Policies determine what should happen in response to an event, while Definitions specify how it should happen.

Business Requests​

When an event triggers a Flow Definition, the system generates a Business Request. This represents a formal request to execute the actions defined in the Flow Definition.

Business Request Items​

Business Request Items are the individual tasks generated from Flow Items within a Business Request. Each item holds data such as request details, assignee ID, and resource ID. Items are processed independently in the order defined by the Flow Definition. If an item depends on another item's completion, it waits until the dependency is satisfied.

Approval Flow Policies​

Approval Flow Policies route Business Requests to appropriate approvers. For example, when a person changes locations, the request might route to their manager for approval before resources are allocated. Requests can also be configured to execute automatically without approval when appropriate.

Fulfillment Workflows​

Fulfillment Workflows define the procedures followed when a Business Request Item is approved, auto-approved, or rejected. These workflows are triggered after the Approval Flow Policy completes. Based on the approval outcome, different workflow branches execute specific tasks such as updating systems of record, sending notifications, or performing post-decision activities.

Flow Execution Process​

The following steps describe how No Code Flows execute from event trigger to completion:

  1. An event occurs (e.g., "Person Leaver")
  2. The event is added to the Event Inbox
  3. Applicable Flow Policies determine which Flow Definitions to run
  4. Flow Definitions are added to the Flow Inbox
  5. Each Flow Definition is processed and creates a Business Request
  6. The Business Request generates Business Request Items based on the Flow Items in the definition
  7. Business Request Items are sequenced according to the Flow Definition timing and dependencies
  8. Items requiring approval are routed to appropriate approvers
  9. Upon approval or auto-approval, items are sent to the Business Request Fulfillment engine for execution

Flow Execution Process Figure 4: Complete flow execution process from event trigger to fulfillment

Next Steps​

Now that you understand No Code Flows components and execution, you can begin building automated workflows: