Back to Blog Series
Part 1: System MapStep 1 of 15ArchitectureSystem DesignFluxo

Complete Feature Map: How I Built Every Major Fluxo Capability

A consolidated engineering map of Fluxo's full feature surface, from nodes and triggers to governance, agency ops, white-label, and developer APIs.

Why this part is here in the storyline

Start with the full architecture map before diving into subsystems.

Artem Moshnin, Lead Software EngineerJanuary 23, 202617 min
Series Progress1/15

Fluxo is a review-first workflow automation platform. You build workflows as a visual graph: a trigger starts execution, nodes transform data or call integrations, and a Human Review step can pause the run until someone approves what will happen next.

I built Fluxo as a personal project and treated it as an enterprise-grade architecture challenge. This post is the system map: a consolidated view of the major capabilities and how the pieces connect. If you are completely new to Fluxo, start here.

Section 1

Product principle

#product-principle

I designed every major feature around one invariant:

  • A workflow graph is the single source of truth.

That means the editor, the execution engine, analytics, governance, and templates all operate on the same underlying model. When UI and runtime share a contract, correctness becomes enforceable and evolution becomes safer.

Section 2

Core platform layers

#core-platform-layers

Fluxo is not one feature. It is a stack of platform layers that reinforce each other:

  • Visual graph editor and schema-driven node configuration.
  • Typed node registry and executor registry so UI and runtime stay aligned.
  • Event-driven runtime and trigger dispatch for durable execution.
  • Human Review governance as a system of record, not a UI checkbox.
  • Templating and expression engine so nodes can share data safely.
  • Multi-tenancy and RBAC for teams and agencies.
  • Billing, limits, and strict entitlement enforcement.
  • White-label and custom domain support as a platform layer.
  • Analytics and agency operations for measuring reliability and quality.
  • Programmable interfaces: APIs, webhooks, and embedded review.
Section 3

Node surface I ship

#node-surface-i-ship

Nodes are the product surface: the vocabulary you use to express automation in Fluxo.

Triggers

MANUAL_TRIGGER, GOOGLE_FORM_TRIGGER, STRIPE_TRIGGER, SCHEDULE_TRIGGER, EMAIL_TRIGGER, FILE_WATCHER_TRIGGER, WEBHOOK_TRIGGER, RSS_TRIGGER

AI and action nodes

OPENAI, ANTHROPIC, GEMINI, HUMAN_REVIEW, SLACK, DISCORD, TELEGRAM, EMAIL_SEND, HTTP_REQUEST, GOOGLE_SHEETS, NOTION, AIRTABLE, GOOGLE_DRIVE, DATABASE

Logic and transformation nodes

CONDITIONAL, FILTER, TRANSFORM, DELAY, CODE, MERGE, SWITCH, LOOP, MARKDOWN_HTML

Section 4

Governance and reliability features

#governance-and-reliability-features

Fluxo is “review-first” because governance is how automation becomes deployable. The platform includes:

  • deterministic risk checks (PII, links, numeric claims, forbidden terms)
  • confidence scoring with model self-eval support
  • policy routing (standard, auto-approve, escalate, block)
  • public review links with collector identity modes
  • review reminders, digests, and multi-channel notifications
  • audit logs and webhook events for every key transition
Section 5

Team and agency features

#team-and-agency-features

Fluxo is built for multi-workspace operations, not just solo automation:

  • organizations and role hierarchy
  • selected permission modes for participants
  • reviewer-only constrained access mode
  • invitation lifecycle controls
  • linked-client agency graph
  • cross-workspace benchmark analytics
  • alert rule engine and acknowledgment feed
Section 6

Platform and developer features

#platform-and-developer-features

Governance becomes much more valuable when it integrates with other systems. Fluxo exposes:

  • API keys with scopes and revocation
  • review REST API endpoints
  • webhook endpoint management and signed delivery
  • embed tokens with origin and capability restrictions
  • white-label branding and domain lifecycle tools
Section 7

How to read the rest of the series

#how-to-read-the-rest-of-the-series

The rest of the series walks the stack in a deliberate order: node platform, data flow DSL, editor UX, triggers, runtime, governance, learning loops, analytics, tenancy, security, billing, white-label, external interfaces, and templates.

I wrote this map because architecture is easier to evaluate when feature ownership is explicit. Fluxo is not a thin orchestration wrapper. It is a complete review-first automation platform with end-to-end product and infrastructure decisions I implemented intentionally.