Automation inside your own product, on your own terms.
Ship a workflow builder to your customers without building one. OCNORA runs in an iframe behind your product and runs each tenant’s workflows; your product signs users in, sets up each tenant and supports your customers.
Three workflows teams build here first.
- 01
A workflow tab in your product where each tenant builds and runs their own automations against their own data.
- 02
Product events that fan out to your customers’ tools: CRM updates, invoices, notifications, webhooks to their systems.
- 03
Vertical automations you ship as templates, so every tenant starts from a working workflow instead of a blank canvas.
What runs, step by step.
One tenant’s workflow: an event from your product, normalised, then sent to the tenant’s own endpoint or to the tenant’s CRM and chat.
- 01Product event
- 02Normalise payload
- 03Route by tenant setting
- 04Forward to tenant endpoint
- 05Update tenant CRM
- 06Notify tenant channel
Every step is a node type in the catalog. Diagram only: no data, no live run.
Before you start
- A page in your product that hosts the builder iframe.
- A backend endpoint that signs a short-lived tenant token for the host page to pass over postMessage.
- An embedded partner licence for each tenant.
- Connections for the tools each tenant’s workflows call, added by the tenant or by you on their behalf.
What you get
Once you have set a tenant up, its users build and run workflows inside your product under your brand, against the tenant’s own connections, with its own AI budget and plugins, and without a second login.
Limitations
- Signing the tenant token is your product’s job. OCNORA creates users from that token; it does not sync them from your directory, so removing a user’s access is yours to handle too.
- Tenant setup is not automatic. Creating a tenant, issuing its licence and setting its budget and plugins when one of your customers signs up is a step you wire into your own onboarding.
- Tenants are separated in software: tenant scope is applied in the data layer of one installation, and tenants share its infrastructure. A tenant that needs infrastructure of its own needs an installation of its own.
- A tenant’s workflows reach only the tools that tenant has connections for.
- Every tenant needs its own licence, so adding a tenant means issuing one.
- The Postgres integration is a single query node: reads and writes are written as SQL.
Source: coax-backend api/auth/routes.py (password and MFA login, OIDC login and token exchange, login/saml/{tenant_slug}/start, /acs and /metadata, login/sso/{tenant_slug}/protocol), api/auth/saml.py, api/scim/routes.py (/scim/v2), JIT SSO token handoff for embed hosts · implemented · checked 2026-10-20.
Source: coax-backend AI cost ledger, budget router and circuit breaker (evidence register C12, C13, C16; E07 (OCNORA_WEBSITE_IMPROVEMENTS task WEB-033)) · unverified · checked 2026-09-28.
Source: coax-backend deployment manifests: Docker Compose file and Helm chart (evidence register C14, C15, C22; E08, E09, E17 (OCNORA_WEBSITE_IMPROVEMENTS task WEB-036)) · unverified · checked 2026-09-28.
Source: coax-backend deployment manifests and offline licence check; evidence register C22 (OCNORA_WEBSITE_IMPROVEMENTS task WEB-037) · unverified · checked 2026-09-28.
Who does what, and where the token goes.
Your host page asks your backend for a short-lived tenant token, passes it to the OCNORA builder iframe over postMessage, and OCNORA verifies it, creates the user on first arrival and opens that tenant’s workspace.
What you build
- The page in your product that hosts the builder iframe and passes the token to it over postMessage.
- A backend endpoint that signs a short-lived token for each user and tenant, and keeps the signing key secret.
- Tenant setup in your onboarding: creating the tenant, issuing its licence and setting its AI budget and plugins.
- Which of your users get which OCNORA role (owner, admin, editor or viewer) in their tenant, and removing access when they leave.
- How connections are added: by each tenant for its own tools, or by you on their behalf with their consent.
- Your logo, colours, domain and its certificate for white-label.
What OCNORA provides
- The builder, the run engine and the node catalog, inside the iframe.
- Verification of your token and a user created on first arrival (JIT SSO).
- Tenant scope applied in the data layer on every query, with per-tenant budgets, plugins and licences.
- Run history, the audit log and Workflow Health for each tenant’s workflows.
Operations and support
- The installation runs in your cloud account from the Docker Compose file or the Helm chart. The cluster, database, Redis, backups and upgrades are yours to run.
- Your customers come to you for support. You are their first line, not OCNORA.
- OCNORA supports you, the partner, over a partner support channel. Terms are set in your agreement; no response time is published here.
Webhook transform and forward
Receive any JSON, normalise a few fields, reshape it and forward to another endpoint — the smallest useful glue workflow.
See each step's output, and approve the risky ones.
Illustrated with a support workflow; the run view and the approval request look the same for every workflow.
Built for this, not adapted to it.
Embed with an iframe and a token handoff
The builder mounts in an iframe; your host page passes a short-lived tenant token over postMessage. No shared cookies, no second login.
JIT SSO for your users
Users are created on first arrival from the token your product signs. No user sync job, no double invitation flow.
Per-tenant plugins and images
Enable a private node for one tenant and not the others. Each tenant can run its own plugin image on the same installation.
Per-tenant AI budgets
Monthly token and dollar budgets per tenant and per provider, checked before each model call, with a circuit breaker that holds further calls when a tenant’s budget is used up.
White-label
Your logo, your colours, your domain, once you supply them and point the domain at the installation. The dashboard ships in 21 languages, so your customers can use the builder in theirs.
Licensed per tenant
Embedded partners hold one licence per tenant, signed offline with Ed25519 and checked without a phone-home. Add a tenant, add a licence.
Start from one of these.
Each one imports into a workspace; swap the connections and run it.
- Webhook transform and forwardReceive any JSON, normalise a few fields, reshape it and forward to another endpoint — the smallest useful glue workflow.
- Fan out a list to an APIReceive a list of items by webhook and call an API once per item, five in parallel, continuing past individual failures.
- Delay, retry and dead-letterCall a flaky endpoint with backoff retries; on final failure wait, try a fallback endpoint, and if that also fails email an operator.
Apps this kind of workflow usually touches.
Each one has its own page with operations, triggers and auth.
HubSpot
Salesforce
Stripe
Slack
PostgreSQL
SendGridRead before the first live run.
- How to test a workflow before it touches anything realStatic validation, a dry run against real config with side effects held back, then a first live run on one record. A practical order for shipping automations safely.
- How much a dry run actually proves before you trust it liveA dry run executes your workflow with side effects suppressed and shows each step’s output shape. That shows the path resolves, not that the result is right.
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.