Integration Studio

Integration Studio is where the Revenue Cloud talks to everything around it. Your ERP, your PIM, your CRM, your warehouse, your DATEV export — and, in the other direction, your customers' procurement systems. It is a visual canvas rather than a code editor, which matters because in most Mittelstand companies the person who knows what an article master field means is not the person who writes integration code.

What lives here

Workflows are the unit of work. A workflow has a trigger — a schedule, an event, an inbound webhook, a file arriving — and then a chain of nodes that read, transform, branch and write. "Every night at 03:00, read the article export from the ERP, map the fields, create or update products, and report what failed" is one workflow. Workflows are durable: a run that starts at 03:00 and takes forty minutes survives a restart in the middle, and you can see where it was when it stopped.

Runs are what happened when a workflow executed. Each run has a status, a duration, the records it touched and the errors it hit. This is the screen you open when someone says the stock figures are stale. A workflow that has not run is a different problem from a workflow that ran and failed on line 4,812, and the run list is what tells the two apart.

Schedules decide when time-triggered workflows fire. Credentials hold the connection details for an external system — host, user, and the authentication it expects. Secrets hold the values you do not want visible in a workflow definition. Keeping credentials separate from workflows is what lets you point the same workflow at a test ERP and then at production without editing it.

Connectors — the marketplace, installed integrations and your own — are prebuilt pieces for specific systems. An installed integration brings its own screens and its own credential form, and workflows use it as a node instead of you assembling raw HTTP calls.

Events are the platform's own signal. Something happens in the Revenue Cloud — an order is placed, a product changes, a customer registers — and an event is emitted. The Event Catalog lists which events exist and what each carries; the Event Stream shows the ones that actually fired. Events are how you react to something immediately rather than waiting for the next nightly run, and they are the difference between an order reaching the ERP in four seconds and in four hours.

Webhooks are events crossing the boundary. Inbound webhooks let an external system push into a workflow. Outbound webhooks push platform events to a URL you own. A webhook is the low-ceremony option; a workflow is the option with error handling, retries and a run history. Start with a webhook, move to a workflow the first time you need to know why something did not arrive.

Data Exchange is the file-shaped half of integration, which in German B2B is still most of it. Import and export profiles define a file's structure and its mapping to platform fields. An SFTP server gives an ERP somewhere to drop a CSV without anyone building an API. Storage Sync moves files between the platform and your own object storage. Many working integrations are a folder, a naming convention and a schedule.

Punchout deserves its own paragraph, because it is the reason many B2B shops exist at all. A punchout connection lets a buyer start inside their own procurement system — SAP Ariba, Coupa, Onventis, JAGGAER — jump into your shop with their identity already established, fill a basket, and hand it back as a requisition in their system. There is no single "Punchout" screen in the Cockpit today. A punchout setup is assembled: a channel in Commerce Studio for the catalog cut that buyer sees, credentials here, and a connector or workflow handling the roundtrip. Punchout explained covers the mechanics; Set up punchout covers the sequence.

Direct API access, webhooks and the sandbox are the half of this Studio your own IT team and your integrator use without ever opening the canvas. Not every integration should be a workflow. An ERP partner who wants to pull orders every fifteen minutes needs a scoped API key, the endpoint list and the rate limits — not a node graph. A BI team needs a nightly bulk export. A customer's IT needs a punchout endpoint. And all of them need somewhere to get it wrong first, which is what the sandbox is for: a separate tenant with its own keys and its own data, where a failed import costs nothing. APIs, Webhooks & Sandbox covers that path from the Customer side — how to create a key with exactly enough scope, how to set up a sandbox and hand it over, and where the boundary to real development sits.

The screens

Common tasks

• Choose an integration pattern — file, API, event or connector, before you build anything.
• Decide the system of record — which system wins per field. Do this first; it prevents most later damage.
• Connect a system — credentials, a connector, a first successful call.
• Map fields — the ERP's ARTNR to the platform's SKU, and the forty others.
• Build a workflow — trigger, nodes, error branch, activation.
• Fix a failing sync — what the common failures actually mean.
• Create an API key — for the integrator who is calling the platform directly rather than building a workflow.
• Set up a sandbox — a tenant your integrator may break, before anything touches production.
• Monitor your integrations — calls, errors, latency and webhook delivery, alongside the run history.

What is planned for this Studio

Integration Studio's own screens change least of all the Studios. What changes is what flows through them.

Each of the planned core apps brings new objects to sync and new events to react to. Quotes have to reach the ERP as offers and come back as orders — see Quotes & Contracts. Cost centres and approval limits are almost always maintained in the customer's own system rather than typed into your Cockpit, which makes them an import, not a form — see Procurement & Approvals. Translations and eCl@ss classifications arrive from a translation agency and a classification service, and go back out as BMEcat and Datanorm files — see Catalog export profiles. Bills of material usually already exist in the ERP or the PLM system and need mapping, not re-entry — see Model a bill of material. Standing orders and subscriptions generate orders on a schedule, which is a new event source for anything downstream — see Recurring Orders & Subscriptions.

The second change is documentation rather than product: APIs, Webhooks & Sandbox now covers the direct-access path — keys, scopes, the sandbox, rate limits, bulk exports — for the people who are integrating without building an app. Those screens exist today; what was missing was a Customer-facing account of them.

Plan for both when you scope an integration project. A field mapping that ignores cost centres because the app is not installed yet is a mapping you will rewrite.

How it relates to the other Studios

Commerce Studio is what most workflows write into. Products, prices, stock and customers usually originate in the ERP and land here. The decision that shapes everything is which system owns which field: if the ERP owns the price and someone edits it in Commerce Studio, the next sync overwrites it, and the edit looks like a bug rather than a rule working correctly.

Experience Studio consumes the result. Nothing in the storefront changes until the data a workflow wrote is complete enough to render. A sync that half-succeeds shows up as products in the shop with missing technical data, which is a completeness problem in Catalog completeness and a run problem here.

Analytics Studio reports on data this Studio delivered. Numbers that look wrong are often a sync that stopped rather than a report that lies — check the run history before you doubt the dashboard.

App Studio provides the connectors. Installed integrations are apps, with the same install, permission and update model as everything else on your tenant.

Building on this Studio?

If you are writing code against it rather than working in it, the Developer Portal documents the same Studio for developers — APIs, SDKs and extension points.