Build workflows you can explain to your auditor.
Draw the workflow on a canvas, drop into Python or an expression when the canvas is not enough, and ship it with the governance already attached: budgets, approvals, audit trail and a health check that runs before the first real run.
- Connectors1,000+ providers and 84 trigger types start and feed each run.
- Workflow engineCanvas, expressions, Python, sub-workflows, retries, and Workflow Health on every save.
- AI layerAgent node, tools from the catalog, MCP, and hosted or local models.
- AI budgets
- Approvals
- Roles and permissions
- Audit log
- Encrypted connections
- Documented node types
- 7,600+
- node types · measured · checked 2026-09-22
- Providers in the catalog
- 1,000+
- providers · measured · checked 2026-09-22
- Trigger node types
- 84
- trigger types · measured · checked 2026-09-22
- Dashboard languages
- 21
- UI languages · unverified · checked 2026-09-14
One engine, five things it does for you.
Each pillar has a section below and a page that goes deeper. The proof point under each one is read from our claims registry, with its unit, evidence level and the date it was last checked.
A canvas that goes as deep as you need.
Every node is generated from a schema, so the 1,000+ providers in the catalog get real forms with validation, not a generic request builder. When a form is not enough, write an expression or a Python step in place.
Schema-driven node forms
7,600+ node types across 1,000+ providers, each with typed inputs, defaults and validation drawn from the provider’s schema. Triggers, actions and clouds share the same form engine.
Expressions with a live preview
Reference upstream data with {{ $json.customer.email }}. Autocomplete offers the fields the previous node produced, and the preview shows the resolved value as you type.
HTTP node with cURL import
Paste a cURL command from any API’s docs and the node fills in method, URL, headers, auth and body. Pair it with a saved connection so the secret never sits in the workflow.
Python code node
A real Python step, run on the worker pool, with the input rows in scope and the result table shown beside it. Use it for the transformation the canvas cannot express.
Input and output tables
Every node’s settings sit between the data it received and the data it produced. You never guess a field name: it is on the screen.
Pin, test one step, dry run
Pin a node’s output so downstream steps build against fixed data. Test a single step without running the rest. Dry-run the whole workflow before it touches a live system.
{{ $json.customer.email }}| row | message_id | status |
|---|---|---|
| 1 | msg_01HV… | sent |
| 2 | msg_01HW… | sent |
| 3 | — | skipped (pinned) |
Agents are a node, not a separate product.
Drop an agent into any workflow, give it tools made from other nodes or whole workflows, and read every iteration back as a trace with tokens, latency and cost. The same budgets and approvals that govern the rest of the workflow govern the agent.
Anthropic, OpenAI, Google and DeepSeek through one node, plus local models on a dedicated worker pool. Swap the model without rewiring the workflow.
A tool can be a built-in, an HTTP call, any node in the catalog, a code step, a published workflow, or a remote MCP server.
Controls that are part of the engine, not a plugin.
Budgets, approvals, permissions and the audit trail are enforced by the router on every step. Nothing in a workflow can route around them, and nothing in the UI hides them.
AI budgets with circuit breakers
Monthly token and USD budgets per tenant. When a budget is spent the breaker opens, runs that would exceed it are held, and the dashboard tells you which workflow did the spending.
Human-in-the-loop approvals
The human.prompt node suspends a run and waits for a person. Set a timeout, choose what happens when it lapses, and route on the answer like any other branch.
Role-based permissions
Owner, admin, editor and viewer roles composed from individual permissions, checked on every API route. Viewers see runs and reports without being able to touch a connection.
Scoped API keys
Keys carry a permission scope and an expiry, and can be revoked in one click. Every call made with a key is attributed to it in the audit log.
Audit log on every mutation and run step
Who changed which workflow, which connection was used by which step, and what each step produced. Exportable, so an auditor can take it away.
Encrypted connections and PII crypto-shred
Connection secrets are envelope-encrypted with a per-secret key wrapped by a KMS. Personal data is written under a windowed key, so shredding the key deletes the data everywhere at once.
Sharing that strips credentials
Share a workflow with another workspace and the connections are removed on the way out. The recipient gets a connection request to fill in, never your secret.
What each control does and where it stops, from approvals to dry runs: see controls and operations.
The 0th run: your workflow is checked before it ever runs.
Workflow Health runs static validation, a pre-flight against your live connections and a dry run on every save and every publish. A workflow that would fail at 3am fails on your screen instead.
- STEP 1
Validate
Every node is checked against its schema: required fields, expression syntax, references to nodes that exist, edges that make sense.
- STEP 2
Pre-flight
Each connection is exercised with a harmless call. Expired tokens, revoked keys and missing scopes surface here, not in production.
- STEP 3
Dry run
The graph executes with side effects suppressed, so you see the shape of every step’s output before the first real trigger.
Auto Fix
When Health finds a broken node, the Auto Fix worker repairs that one node, re-runs pre-flight, and moves to the next only if the fix held. Every repair is a version you can inspect and roll back.
Ops center
Status and health are two different columns. An attention tab lists the workflows that need a person, and a failure drawer shows the failing step with its input, output and error.
Retries, timeouts, error workflows
Per-node retries with backoff, per-run timeouts, and an error workflow that receives the failing run’s context. Alerts go where your team already looks.
Sub-workflows
Call a published workflow as a step, with its own versioning and its own permissions. Shared logic lives in one place.
Versions, restore and visual diff
Every publish is a version. Compare two versions on the canvas, see which nodes changed, and restore the one that worked.
Insights
KPIs and sparklines per workflow: runs, failures, duration and AI spend over time, so a regression is visible before anyone files a ticket.
Business reports per workflow
Hours saved, money saved, automation share and reliability, computed from the workflow’s own runs. The report a manager can forward.
See where a run is, and what each step produced.
- Run state
A paused run says what it is waiting for.
- Step status
Each step shows done, waiting or queued.
- Step output
What a step produced, the approver it is waiting on, and the audit record.
Treat workflows like software.
Every workflow is checked on every save, carries its own error handling, and ships through Docker Compose or Helm. Source control, CI and deployment tools are providers in the catalog, so delivery steps are orchestrated in the same workflows.
Checked on every save
Workflow Health validates, pre-flights and dry-runs each workflow before it runs, and Auto Fix repairs a broken node one at a time.
Error workflows, retries and timeouts
Failure paths are part of the workflow, not an afterthought: retries with backoff, timeouts per run, and an error workflow that receives the failing context.
Shipped through Compose or Helm
Self-hosted and embedded deployments run from Docker Compose or a Helm chart. See deployment options.
Scoped engineering tasks run on your own development runner, with your checks and a human review: see software delivery with Task Runs.
Delivery tools are in the integration catalog alongside everything else. Search for the source control, CI or deployment tool your team already runs.
The four pillars next to a typical automation tool.
Most tools do the first pillar well. OCNORA was built so the other three are part of the same engine.
| Pillar | Typical automation tools | OCNORA |
|---|---|---|
| Build | A canvas and a JavaScript node. Node forms are hand-written per integration, so long-tail apps get a generic HTTP step. | A canvas with 7,600+ schema-driven node types, a Python code node, cURL import for HTTP, and input/output tables beside every node’s settings. |
| Agents | An agent node tied to a few vendors. Cost shows up on the vendor invoice at the end of the month. | A provider-neutral agent node with a per-iteration trace: tool, tokens, latency and USD for every step, charged against a budget you set. |
| Govern | Roles per workspace and an execution log. AI spend is a credit balance; a human approval is a webhook you wire yourself. | Per-tenant token and USD budgets with circuit breakers, a native human.prompt node with timeouts, role-based permissions and an audit log on every mutation and run step. |
| Run | You find out a workflow is broken when the first run fails, then read the error and fix it by hand. | Workflow Health validates, pre-flights and dry-runs on every save. Auto Fix repairs one broken node at a time and re-checks. The ops center shows status and health side by side. |
Migrating from another tool? See OCNORA vs n8n and the importer.
See a workflow run on your own use case.
Book a technical demo. Bring an n8n file or pick a template, and we build it with you on the canvas while Workflow Health checks it before it ever runs.