What is RuleFlow
RuleFlow is a platform for modeling, governing, executing and auditing decisions and workflows in one product. It replaces the fragmented setup most enterprises end up with: a rules engine, a separate workflow/BPM engine, custom authentication and gateway glue, and hand-rolled audit logging — four or five systems wired together, none of them sharing a model or a version history.
RuleFlow — where decisions become workflows.
The shape of the product
A RuleFlow project holds:
- Decisions — decision tables, expressions and switches that turn input data into a typed output (a risk tier, an approval, a price).
- Workflows — a graph of steps (decision calls, human tasks, service calls, gateways, waits) that orchestrates a process end to end.
- Releases — immutable, versioned snapshots of a project’s decisions and workflows, diffable and deployable to an environment.
- Environments — named deployment targets (
dev,staging,prod); promoting to a protected environment requires anapproverrole. - Audit — every write (create, update, delete, deploy, rollback, task completion) is recorded with actor, action and detail.
Everything above is scoped to a tenant: every API call acts only as the tenant in the caller’s verified token, and cross-tenant access is indistinguishable from “not found” (see Tenancy & isolation).
How a decision runs
A decision is authored once, as JSON (studio users never see this directly), and evaluated by the same engine everywhere: in a browser via WASM for instant feedback while authoring, over HTTP for ad-hoc simulation, and in-process inside an AWS Lambda when a deployed workflow calls it. Same binary, same semantics, three surfaces — a decision that passes its tests in the studio behaves identically in production.
Decision inputs and outputs are typed against a schema; the logic inside a decision is written in a small, deterministic expression language — not a general-purpose scripting language — so a stored rule can be replayed forever and always produce the same answer.
How a workflow runs
A workflow compiles to an AWS Step Functions state machine. Authors never write Step Functions JSON directly; the compiler is the only thing that touches it. Each step type maps to a concrete execution mechanism:
| Step type | Executes as |
|---|---|
decision_task | in-process call into the Rust decision engine (Lambda) |
service_task | a connector call via a queued, task-token callback |
human_task | a paused execution waiting on a task token, resumed by an API call |
gateway | a branch on prior decision/task output |
wait / end | timer / terminal state |
Decision and task results accumulate into the workflow’s state under
reserved namespaces ($.decisions.<step>, $.tasks.<step>), so a later step
can read any prior step’s output. See Workflows for
the full model.
Who uses it
- Business analysts author and update decision tables and workflow logic without waiting on a code release.
- Backend engineers integrate RuleFlow via the control-plane API — starting executions, resuming human tasks, wiring service-task connectors.
- Compliance/auditors review who changed what, which version ran, what the trace was, and whether the required approval happened.
- Operations/SRE monitor executions, retries and failures.
Where to go next
- New to the platform? Start with the quickstart — model and simulate a decision in a few minutes.
- Building an integration? Jump to the API reference.
- Evaluating for a regulated environment? Read Security.