Conflux Stack

Platform
Pricing
docs

Layer 06 · Automation Layer

Business processes and rules without custom orchestration

Automate multi-step business processes and declarative rules without custom orchestration code. Workflows and rules engine run on Conflux runtime primitives.

WorkflowRules

Why this layer

Built into the platform, not bolted on

Every module in this layer solves the same class of problem the same way — regardless of who implements it.

01

Workflows on platform runtime

Multi-step processes run on queues, functions, and notifications you already have — not a separate BPM engine with its own deployment model.

02

Rules that react to data

Declarative business rules evaluate on data changes and platform events. Version rule sets through CLI and deploy alongside application code.

03

Human steps built in

Approval flows and human-in-the-loop steps trigger notifications and wait states through platform modules — not custom state machines per process.

Canonical implementation

One path for every author

Junior developers, senior engineers, and AI agents produce the same standard output.

How Conflux does it

Automation composes existing platform capabilities

Workflows are not a parallel stack. They orchestrate auth checks, data writes, communications, and runtime jobs through the same canonical APIs.

Canonical path

Workflow definitions versioned in platform config

Rules evaluated automatically on schema-backed data changes

Human-in-the-loop steps use notification and auth modules

Execution history visible in platform observability

What you get

Automate approvals and multi-step processes without BPM sprawl

Encode business logic as deployable, versioned rules

Reduce bespoke orchestration code in application repos

Audit automation runs alongside other platform events

01 · Automation Layer

Multi-step processes without BPM sprawl

Workflows MVP — sequenced rpc / communications / webhook / delay steps via platform_jobs. Manual start from Console; encode contested domain logic in fn(), use workflows for orchestration.

Workflow · One canonical path

SDK

await client.workflows.start(workflowId, { tenantId })

CLI

# use Console or management API

Config

# steps defined via POST /projects/:id/workflows

What's possible with Workflow

01

Sequenced rpc / communications / webhook / delay steps

02

Manual start from Console; runs via platform_jobs

03

Encode contested logic in fn(); workflows orchestrate

02 · Automation Layer

Business rules that react to your data

Rules MVP — event + optional when → then.invoke a project handler. Console CRUD and evaluate via /projects/:id/rules.

Rules · One canonical path

SDK

await client.rules.evaluate({ event, tenantId, payload })

CLI

# use Console or management API

Config

# { name, event, when, then: { invoke } }

What's possible with Rules

01

Event + when → then.invoke handler rules

02

Evaluate on demand; 24h eval/trigger counts in Console

03

CRUD via GET/POST/PATCH/DELETE /projects/:id/rules

Explore

Continue through the platform

Nine layers, one cohesive stack. Browse adjacent layers or return to the full registry.

01 · Identity

02 · Data

03 · Runtime

04 · Communication

05 · Intelligence

06 · Automation

07 · Integration

08 · Experience

09 · Platform Operations

Previous layer

Intelligence Layer

Next layer

Integration Layer

View full platform registryTalk to the team