Accounts and workspaces
Multi-tenant from the first request: a sign-up wizard, workspace slugs in the URL, memberships, invitations and external sign-in providers.
Customers, catalog, expenses and approvals, on a foundation where accounts, permissions, audit and workspace isolation already work. Describe a new process and it becomes a module.
npm create flowdular@latest| Order | Customer | Status | Total |
|---|---|---|---|
| SO-1041 | Acme Industries | Pending approval | 12 400.00 |
| SO-1040 | Northwind Trading | Approved | 3 180.00 |
| SO-1039 | Globex Logistics | Draft | 860.00 |
Flowdular owns the shared concerns every business platform needs, so each capability you add stays a small, explicit module that people and agents can read, test and replace.
Multi-tenant from the first request: a sign-up wizard, workspace slugs in the URL, memberships, invitations and external sign-in providers.
Roles built from module.entity.action scopes, API tokens and per-module settings. A module endpoint declares the permission it needs and denies by default, and agent, workflow and automation actions append to a trail that cannot be edited unnoticed.
Enable a module with one command. The CLI writes the composition, installs the package, grants scopes, and the running app reloads without a rebuild.
Reusable agents run against registered tools with leases, recovery, idempotency and durable run history. Tools reach data only through approved endpoints.
Typed pipelines on a visual canvas: agent, action, validator, gate, input and output nodes, with dry runs and run history.
Users, roles, modules, settings and audit in one place. Module settings live in the module drawer. Two locales out of the box.
Dry run by default, --apply to write, --json for machines. Modules add their own namespaced commands with declared risk and approval.
A decision your team keeps making by hand becomes a process you can draw, test on sample data, and only then let near the real thing. Some steps are a rule, some are a person, and some are an agent reading the case and deciding.
Before we pay a new supplier, somebody should check them. Right now it depends on who opens the invoice.
Finance lead
Five steps, named the way your team already says them out loud.
It runs on sample data first. No agent is called and nothing is written.
Going live is a separate confirmation.
Then it runs on a schedule you set, or when another system calls in.
Publishing checks every permission the process needs against the person publishing it, and checks again before each live run.
What runs live is the revision you confirmed. Editing it creates a new draft that has to be tested and confirmed again.
A schedule fires at most once per slot, and a slot missed while the platform was down is skipped, never replayed. A webhook needs a fresh, valid signature.
Every run opens step by step in an inspector, and the record is chained so an entry edited later stops matching.
No badges and no promises for a later release. Every line below is a property of the running system, and the file that implements it is in the public repository.
Every workspace-owned table has row-level security enabled and forced, bound to the workspace identifier set for the current transaction. The database refuses a row from another workspace even when application code asks for it.
The role the application connects with is neither a superuser nor allowed to bypass row-level security, and the platform proves that on the live connection through its readiness check.
Scheduled and recovery work connects as a separate read-only role granted only the few columns it needs to find a job. Payloads, inputs and permission snapshots stay unreadable on that connection.
Each module declares its permissions in one file, and its endpoints refuse a request that does not carry the matching one. A route is never open because someone forgot to close it.
Agent, workflow, automation and sandbox actions append to a hash-chained trail where each entry covers the one before it. A verify call walks the chain and reports the first entry that no longer matches.
Provider credentials and stored run payloads are encrypted with keys the deployment supplies from its own secret store. A database dump on its own reveals nothing readable.
The sandbox ties design and implementation to an approved specification. One session, one preview, one delivery, whether the change touches one module or five.
We need customer orders with an approval step above 10 000.
Planner routed the brief to
Rendered inside the real shell, with real permissions
A separate application that turns a business brief into a reviewed module. It drives the coding agent your team already uses, in an isolated workspace, against the same gates the platform runs.
A module is a package with a spec. The scaffold derives endpoints, permissions, migrations and client entry points from it, and validation keeps them in sync for as long as the module lives.
A process can hand a case to an agent. What that agent may reach is not a matter of trust: your workspace binds it to a model provider, narrows its tools, and every run is recorded at a pinned version.
Eighteen skills in .ai/skills load into your coding agent, and AGENTS.md carries the contract, so the rules are the same in the sandbox and in your terminal.
Flowdular is developed publicly on GitHub. The core is MIT licensed, the roadmap lives in issues, and a change lands only through the same gates the sandbox runs.
Use the foundation freely, in any company, forever. Add an enterprise agreement when your organization needs support, guarantees and integrations.
The complete foundation in the repository.
For companies running Flowdular in production at scale.
Yes. The core is MIT licensed. Build and sell products on it, modify it and keep your changes private.
Commercial terms, support with response times, help with deployment and upgrades, and the integrations larger organizations require. The code you run stays the same core.
Agents run through model providers configured per workspace. The default local provider simulates runs without calling any external service, so you can start offline.
Yes. A module is ordinary code in your repository, delivered as files or as a pull request. There is no runtime dependency on a hosted service.
Walk through what the platform already does, or start a working app on your machine in one command.
The product tour, the module contract and the code behind every claim on this page.
See demoBrowse the source on GitHub