Skip to main content
Exposing a workflow is how you surface a platform-built automation to a customer so they can turn it on for their own account. You build the workflow once on the platform, then this page covers the Native side: listing the workflows available to a customer, letting them enable one, collecting its config fields, and triggering it for their linked account. A workflow is enabled per linked account. Enabling it for one customer never affects another, and a customer only ever sees the workflows you have published to them.
This page does not cover building workflows. Triggers, nodes, and data mapping are defined once on the platform; see the Workflows overview. Here you only expose what is already built.

​
How exposing a workflow works

A workflow surfaces to a customer through their config: the same object that holds their config field values also lists every workflow available to them and whether each is enabled. You read that list, render it, and write back the customer’s choices.
1

Publish the workflow on the platform

Build and publish the workflow for the connector. Published workflows appear in the customer’s config; unpublished ones do not.
2

Read the customer's config

Fetch the config for the linked account. The response includes a workflows array, each with an id, name, enabled flag, and any workflow-level config fields.
3

Let the customer enable and configure it

Render the workflow with a toggle and its fields, then save the customer’s choices back to the config.
4

Trigger the workflow

Once enabled, the workflow runs from its trigger: a connected-app event, a schedule, or an event your backend fires for the linked account.

​
Surface workflows in your UI

You have two ways to expose workflows, matching the two frontend flows. Both read and write the same config, so pick by how much UI you want to own.
ApproachWhat you buildBest when
Prebuilt componentDrop in the React SDK <Config> componentYou want toggles and fields rendered for you
Your own UIRead the config, render workflows yourself, save with the SDKYou need a fully custom settings experience

​
With the React SDK component

The React SDK <Config> component renders connection status, config fields, and a toggle for each available workflow. The customer enables a workflow and fills its fields inside the component, and the SDK saves the result. You write no toggle logic. 
import { Provider, Config } from "@cobaltio/react-cobalt-js";

function Integrations({ sessionToken }) {
  return (
    <Provider sessionToken={sessionToken}>
      <Config slug="hubspot" />
    </Provider>
  );
}
See the React SDK flow for setup, and the React SDK reference for every prop.

​
With your own UI

To render workflows yourself, read the config, then write the customer’s choices back. The config response lists each available workflow with its id, name, enabled state, and fields.
1

Read the available workflows

Call config() for the linked account. The workflows array tells you what to render.
SDK
const config = await cobalt.config({ slug: "hubspot" });
// config.workflows -> [{ id, name, enabled, fields: [...] }, ...]
2

Save the customer's choices

Use updateConfig() to enable a workflow and set its workflow-level fields. Reference each field by the id from the config response.
SDK
await cobalt.updateConfig({
  slug: "hubspot",
  workflows: [
    {
      id: "64d1fac58716dc5065127ffe", // workflow id from the config response
      enabled: true,
      fields: {
        "64da0b57c9ae95561bb0a24f": "C044U7Q074J" // field id -> chosen value
      }
    }
  ]
});
The same config() and updateConfig() methods set application-level config field values and enable workflows in one place. For the full request and response shape, see Config fields.

​
Trigger an exposed workflow

Enabling a workflow does not run it. Once it is enabled for a linked account, it runs from its trigger, which is set when the workflow is built:
  • A connected-app event, such as a new contact created in the customer’s connected app.
  • A schedule, which runs the workflow at a set interval.
  • An event your backend fires for the linked account, when your product should kick off the workflow.
The trigger type is part of the workflow definition on the platform, not a Native setting. Choose it when you build the workflow. To fire an event trigger from your backend, send the event for the linked account with the Trigger event API; see Events.

​
Best practices

  • Publish before you expose. Only published workflows appear in a customer’s config.
  • Show only what applies. Render the workflows array from the customer’s config rather than a static list, so each customer sees what is available to their connection.
  • Collect a workflow’s fields when they enable it, not before. Workflow-level config fields belong to the workflow.
  • Name workflows for the customer. The name in the config is what they see.

​
See also