Integration Studio
Start here
The five groups
Build the workflow
The workflow document, the 52 built-in nodes, expressions, node configuration and the shipped templates.
Start the workflow
Manual, schedule, webhook and event triggers, and whether the caller waits for the result.
Connect the systems
Credentials, OAuth, the secret store, file transfer, and reaching Revenue Cloud itself.
Run, watch, recover
Runs and their steps, retries and error routing, missed firings, revisions and the audit log.
Extend the Studio
Write your own nodes, package them, resolve config at author time, and get them registered.
Integration Studio is the workflow builder inside Cockpit. You wire nodes on a canvas — an HTTP call, a transform, a branch, an SFTP download, a storage upload — connect them with edges, add a trigger that starts the run, and the platform executes it durably, per tenant, with a run history you can inspect.
This section is for integration engineers, partner teams and system integrators moving data between Revenue Cloud and a customer's ERP, PIM, CRM, or supplier feed. It documents the Cockpit experience: what a workflow is made of, how a run is started and observed, and how to reference data between steps.
v0-draft). Shapes documented here are current, not final, and a future schema version may require a migration. Build against it with that in mind, and check the changelog before you commit a customer to a delivery date.How this section is organised
Five groups, in the order you meet them.
| Group | What it covers |
|---|---|
| Build the workflow | The workflow document and its revisions, the node catalog, expressions, how a node's configuration fields work, and the templates you can start from. |
| Start the workflow | The four trigger types in detail, and the execution-mode policy that decides whether a caller waits. |
| Connect the systems | Credentials and their auth kinds, three-legged OAuth, the encrypted secret store, file transfer over SFTP and FTP, and reaching Revenue Cloud's own API from a workflow. |
| Run, watch, recover | Reading a run, retries and error routing, firings that never became a run, and the revision and audit trail. |
| Extend the Studio | Writing your own nodes and credential types, packaging them, and how a package reaches a tenant. |
New to it? Getting started has a workflow running in Cockpit in about fifteen minutes.
What a workflow is
A workflow is a versioned JSON document plus a set of trigger records:
nodes[]— the steps. Each one names a node bynamespace:slug, pins a node version, and carries its ownconfig.edges[]— directed connections from one node's output port to another node's input.variables— workflow-level values referenced from node config, so the same graph can be re-pointed at a different host or folder without editing every node.- Canvas organisation — node groups, sticky notes, tags and an icon. The engine ignores all of it.
Every save bumps the workflow's revision and archives the previous one, so you can read the history and restore an earlier version. See The workflow document.
Triggers are separate records, not nodes. A workflow can carry several of them, and they only ever appear on the from side of an edge. See Triggers.
What you build with it
Three shapes cover most of the work:
A scheduled file pipeline. A supplier drops a catalog on SFTP; a nightly schedule lists the inbox, streams each file into the import service, runs an import profile, and moves the file to an archive folder. There is a shipped template for exactly this — see Import a BMECAT product catalog.
A scheduled API sync. Pull yesterday's records out of an ERP over HTTP, reshape them, and write them back through the platform API. The retries, the run history and the credential handling are the platform's problem, not yours.
An event-driven reaction. A platform event — a product created, an order placed — starts a workflow that pushes the change into an external system. The event stream is the platform service behind it; the workflow is the consumer.
When not to reach for it
- Core business logic that belongs in an app. If the behaviour is part of the product rather than the wiring between two systems, build an App.
- A tight synchronous path with a hard latency budget. Synchronous runs are capped at 30 seconds and carry the same durable machinery as asynchronous ones. If a buyer is waiting on a millisecond-scale response, call the source system directly.
- Bulk import and export as an API operation. The
/v1/io/*endpoints on the public gateway do this without a workflow. Browse them in the API Explorer; Integration Studio has nodes that drive the same service when you want it inside a flow — see Reaching Revenue Cloud. - Outbound webhooks to your own endpoints, or reading the event stream directly. Those are platform services: Webhooks and Events.
Where the product is today
Two limits apply across the whole studio and are worth knowing before you plan around it:
- Authorization inside the studio is not role-based yet. Tenancy is enforced — a workflow only ever sees its own tenant's data — but there are no per-ability roles. Anyone who can open Integration Studio for a tenant can edit its workflows and read its credentials list.
- Node packages are not entitled per tenant. Every registered node package is visible to every tenant, so a package registered for one customer shows up in another customer's palette. See Registration.
Where to go next
New to the platform? Start with the platform overview. Want a workflow of your own running first? Getting started. Want to see a finished workflow before you build one? Install the BMECAT catalog import — it is a real template, screenshot by screenshot.