No Code Flows Overview

No Code Flows is an event-driven automation framework for designing, managing, and automating business process workflows without coding. Built on a component-based architecture with queue-backed reliability, No Code Flows uses predefined elements that connect stages of a business process, from event triggers to approval mechanisms and task execution.

This article explains the core components, execution architecture, and relationships between Flow Events, Flow Policies, Flow Definitions, and Flow Items that comprise the No Code Flows framework.

Why No Code Flows

Traditional workflow automation creates operational challenges that impact security, agility, and compliance:

Security gaps - Custom code increases attack surface and requires separate security assessments for each workflow implementation.

Lack of agility - Coded workflows create barriers to rapid change, making it difficult to adapt to evolving business requirements without developer intervention.

Poor visibility - Custom scripts become "black boxes" where tracking who changed what, when, and why becomes a critical compliance failure.

No Code Flows addresses these challenges through a declarative, component-based architecture where administrators configure what should happen rather than coding how to execute it. The queue-backed execution model provides reliability and scalability, while the separation of business logic (policies) from execution logic (definitions) supports flexible adaptation to changing requirements.

Architecture Overview

No Code Flows implements an event-driven automation model where triggers initiate workflows through a series of interconnected components. The architecture separates configuration (what should happen) from execution (how it happens), allowing administrators to build complex workflows by assembling pre-built, audited components.

Component relationships:

• Flow Events serve as triggers that initiate the automation pipeline
• Flow Policies act as routing rules that determine which workflows to execute
• Flow Definitions function as blueprints containing the sequence of actions
• Flow Items represent atomic, reusable actions within the workflow
• Business Requests provide trackable execution records for audit and compliance

Core Components

No Code Flows consists of interconnected components organized into two categories: configuration components that define automation logic, and runtime components that handle execution.

Configuration Components

These components define the automation logic and are configured by administrators before workflows execute.

Flow Events

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

Common Flow Event examples:

• Person Leaver — Triggered when an employee or contractor's status changes to terminated. Initiates actions such as disabling accounts, removing group memberships, archiving emails, and revoking access to resources.
• Mailbox Discovered — Triggered when a new mailbox is detected during system discovery. Initiates verification processes, distribution list additions, and security control setup.
• Account Takeover — Security-related trigger indicating potential unauthorized access. Initiates account suspension, security team notifications, and investigation procedures.

Figure 1: Flow Events page showing the Person Leaver event configuration

Flow Policies

Flow Policies connect Flow Events to Flow Definitions, serving as the routing logic that determines which automated workflows to trigger in response to specific events.

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

• An "internal employee departures" policy might trigger a comprehensive offboarding flow with extended access retention
• An "external consultant departures" policy might trigger immediate access revocation without archival procedures

This flexibility allows organizations to adapt automated responses to specific circumstances and requirements without creating redundant workflow definitions.

Figure 2: Flow Policy linking a Flow Event to its corresponding Flow Definition

Key principle: Flow Policies implement the business logic layer—determining what should happen based on organizational rules—while Flow Definitions specify how the automation executes. This separation allows administrators to change business rules without modifying the underlying workflow implementation.

Flow Definitions

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

For example, a "Person Leaver" Flow Definition might contain Flow Items for:

1. Disabling the person's account (execute immediately)
2. Removing group memberships (execute after 24 hours)
3. Archiving the mailbox (execute after 48 hours)
4. Sending manager notification (depends on account disable completion)

Figure 3: Flow Definition showing multiple Flow Items and their execution sequence

Flow Definitions control timing, dependencies, and order of operations for entire processes, supporting complex orchestration without custom code.

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 and is configured through three key parameters:

Parameter	Purpose	Example
Item Type Action	Specifies the exact task to execute	"Bulk Remove Person Group Membership", "Person Disable"
Item Scope Type	Determines the range within which the action executes	"All Accounts for Person", "Remove All Non-RBAC Group Accounts"
Item Collection Query	SQL statement that retrieves resources related to the Flow Item	Query 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.

Reusability principle: The separation of action (Item Type Action) from scope (Item Scope Type) supports reuse. For example, the "Remove Account from Group" action can be reused with different scopes ("All Non-RBAC Groups", "SAP Groups", "Application Responsible Parties") without creating multiple workflows.

Runtime Components

These components are generated automatically during workflow execution and provide tracking, approval routing, and fulfillment capabilities.

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 and serves as the trackable execution record.

Purpose: Business Requests convert a sequence of configured actions into a single, auditable unit of work. Instead of tracking individual script executions, auditors can review Business Requests to see the complete workflow execution history.

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.

Execution model: 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. This dependency management supports complex orchestration patterns while maintaining auditability for each discrete action.

Approval Flow Policies

Approval Flow Policies route Business Requests to appropriate approvers based on organizational rules. For example, when a person changes locations, the request might route to their manager for approval before resource allocation occurs.

Flexibility: Requests can be configured to execute automatically without approval when appropriate, supporting both human-gated and fully automated workflows depending on business requirements.

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. Fulfillment Workflows are pre-built, audited components linked to each Item Type Action, ensuring consistent execution across all automation.

Flow Execution Process

No Code Flows uses a queue-based execution pipeline to ensure reliability, scalability, and auditability. Events do not execute immediately; instead, they progress through a series of queues where business logic is applied, workflows are selected, and actions are tracked.

Execution steps:

1. An event occurs (e.g., "Person Leaver" when employee status changes to terminated)
2. The event is added to the Event Inbox queue
3. The Policy Matching engine evaluates applicable Flow Policies to determine which Flow Definitions should run
4. Matching Flow Definitions are added to the Flow Inbox queue
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's timing configurations and dependencies
8. Items requiring approval are routed to appropriate approvers via Approval Flow Policies
9. Upon approval or auto-approval, items are sent to the Business Request Fulfillment engine for execution

Queue-based advantages:

Reliability - Asynchronous queues prevent event loss if systems are temporarily unavailable. Events persist in queues until successfully processed.

Scalability - Centralized SQL-based queue processing handles high event volumes without performance degradation.

Auditability - Every step in the pipeline creates trackable records, providing complete visibility into workflow execution for compliance requirements.

Key Benefits

Separation of concerns - Flow Policies (business rules) are separate from Flow Definitions (execution logic). Administrators can change routing rules without modifying the underlying workflow, and vice versa. This dramatically reduces the scope and risk of configuration changes.

Complete visibility - Every workflow execution creates a trackable Business Request containing all actions as line items. Auditors can review exactly what happened, when, and why without analyzing custom code or log files.

Component reusability - Flow Items are atomic, pre-audited actions that can be combined in different ways. The "Remove Account from Group" action works with multiple Scope Types, eliminating the need to create dozens of similar workflows.

Declarative configuration - Administrators define what should happen (disable accounts for leavers) rather than how to code it (SQL queries, API calls, error handling). The system handles implementation details through secure, tested fulfillment workflows.

Enterprise reliability - Queue-backed architecture ensures workflows survive system outages, process events at scale, and maintain execution state across infrastructure changes.

Next Steps

To build automated workflows:

• Create Flow Definitions — Build workflow templates for your business processes
• Create Flow Items — Define specific actions for your workflows
• Create Flow Policies — Connect events to automated responses
• Email Flow Items — Configure automated email notifications