Platform6 min read

Embed workflow automation in your product: where identity, tenants and support sit

Embedding a workflow builder is mostly a question of boundaries. Before you write the iframe tag, you should be able to say who signs your users in, who creates each tenant, whose credentials the workflows use and who answers when a customer’s run fails.

The OCNORA team · 28 September 2026

Reviewed on 28 September 2026 · Reviewed by OCNORA engineering

The token handoff, step by step

The builder mounts in an iframe on a page in your product. Your product already knows who the user is and which of your customers they belong to, so it vouches for them. Your backend signs a short-lived token for that user and tenant. Your host page passes it to the iframe over postMessage. OCNORA verifies the token, creates the user on first arrival and opens that tenant’s workspace. There are no shared cookies and no second login.

embedded sign-in   (illustrative, no live system)

  your host page ──▶ your backend: "token for this user, this tenant"
         │                     │ signs a short-lived token
         │ ◀───────────────────┘ (signing key stays on your backend)
         ▼
  postMessage(token) ──▶ OCNORA builder iframe
                                │ verifies the token
                                │ first arrival? create the user (JIT SSO)
                                ▼
                        the tenant’s workspace opens

The signing key is the whole trust relationship. Anyone who holds it can mint a token for any of your users, so keep it on your backend, never ship it to the browser, and keep the token’s lifetime short. That is your code, not OCNORA’s, and it deserves the same review as your own login.

Users and roles: created on arrival, removed by you

JIT SSO means there is no user sync job and no second invitation flow. The first time a user arrives with a valid token, OCNORA creates them in the tenant the token names. Inside that tenant, what they can do is set by role: owner, admin, editor or viewer. A role that lacks a permission cannot use it, whether the request comes from the builder or from a script.

Deciding which of your users get which role is yours. Most products already have a notion of an account admin and an ordinary member, and it is tempting to map one straight onto the other. Decide it deliberately: an editor can change workflows that call your customer’s tools with your customer’s credentials.

Tenants and connections: what the boundary is made of

Each of your customers becomes a tenant on your installation. Tenant scope is applied in the data layer on every query, rather than left to each route, and each tenant has its own AI budget, plugins and licence. Monthly token and USD budgets can be set per tenant and per provider; they are checked before each model call, and a circuit breaker holds further calls when a tenant’s budget is used up. You can enable a private node for one tenant and not the others.

Be precise about what that separation is. Tenants are separated in software, inside one installation, and they share its infrastructure: the same cluster, database and workers. If one of your customers needs infrastructure of its own, it needs an installation of its own. Write that into your security answers before a customer’s reviewer asks.

Connections. A tenant’s workflows reach only the tools that tenant has connections for. Each tenant adds connections for its own tools, or you add them on its behalf with its consent. Pick one model and say so in your terms.
Secrets. A connection’s secret is envelope-encrypted and unwrapped on the worker running the step, for the tenant that owns it. The security page sets out how.
Records. Run history, the audit log and Workflow Health are kept for each tenant’s workflows, which is what your support team reads when a run goes wrong.

Tenant setup is a step you build

This is the provisioning gap, and it is the part most plans leave out. Tenant setup is not automatic. When one of your customers signs up, nothing in OCNORA notices. Creating the tenant, issuing its licence, and setting its AI budget and plugins is a step you wire into your own onboarding, and removing them is a step you wire into your offboarding.

Your customer signs up in your product.
Your onboarding creates the matching tenant on your installation.
You issue that tenant’s embedded licence. Every tenant needs its own, so adding a tenant means issuing one.
You set the tenant’s AI budget and enable any plugins it should have.
You decide how its connections will be added, and optionally copy in the templates you ship as a starting point.
Only then does your product start signing tokens for that tenant’s users.

Licences are signed files checked offline, without a phone-home, so a tenant’s licence is something you hold and install rather than something OCNORA grants at runtime. Plan for renewals in the same place you plan for sign-ups. Automating tenant creation is rarely the hard part; remembering that it has to happen at all usually is.

Support and operational ownership

An embedded installation runs in your cloud account, from the Docker Compose file or the Helm chart. The cluster, the database, Redis, backups and upgrades are yours to run. Workflow data, run history and secrets stay in your account, region and database. That is the point of embedding, and it is also a standing operational commitment.

Your customers come to you. You are their first line of support, not OCNORA. They see your brand, so they should reach your help desk.
OCNORA supports you. Embedded partners get a partner support channel. Its terms are set in your agreement; no response time is published on this site.
Your team reads the run record. Train support staff to open a failed run, read each step’s input, output and error, and tell a customer’s own misconfigured connection from a fault in your product.

White-label is also yours to finish. The builder takes your logo, your colours and your domain once you supply them and point the domain at the installation, with its certificate. The dashboard ships in 21 UI languages, so your customers can use the builder in theirs.

Prerequisites, limitations and a next step

Prerequisites: a page in your product that hosts the builder iframe; a backend endpoint that signs a short-lived token per user and tenant; an embedded licence for each tenant; a tenant setup step in your onboarding; a role mapping; and connections for the tools each tenant’s workflows call.

Tenant creation, licensing, budgets and plugins are provisioned by your onboarding code. OCNORA does not create a tenant when your customer signs up.
Users are created on arrival, not synced or removed from your directory. Offboarding is yours.
Tenants are separated in software on shared infrastructure. Separate infrastructure means a separate installation.
Running the installation, its backups and its upgrades is your team’s job.

The embedded automation solution draws the token flow as a diagram and lists what you build against what OCNORA provides. For a first tenant workflow, start from the webhook, transform and forward template: an event from your product, normalised and sent to the tenant’s own endpoint. The enterprise page covers deployment and licensing. When you want to walk your own onboarding through it, book a demo: we start from one tenant, its token and its setup step.