Set up a Workato connector

C1 provides identity governance and just-in-time provisioning for Workato. Integrate your Workato instance with C1 to run user access reviews (UARs) and enable just-in-time access requests.

Legacy Workato roles are being retired at the end of August 2026. Every Workato workspace must migrate to the new RBAC v2 model (environment roles) before then. See Migrating to RBAC v2 below for the full cutover checklist.

Provision accounts

When provisioning a new collaborator account, the following fields are available on the account creation form:

Field	Required	Description
Email	Yes	Email address of the collaborator to invite.
Name	Yes	Full name of the collaborator.
Environment Roles	Yes	List of environment + role assignments. Each entry must be in env:role format (e.g. dev:Admin, prod:Analyst). At least one entry is required.
User Group IDs	No	Comma-separated list of Workato user group IDs to add the collaborator to.

Environment Roles format

Each entry in Environment Roles encodes the target environment and the role name separated by a colon:

<environment>:<role name>

Allowed environment values are dev, test, and prod. The role name must match an existing role (privilege-group or environment role) in your Workato workspace.

Examples:

• dev:Admin — assign the Admin role in the Development environment
• prod:Analyst — assign the Analyst role in the Production environment
• test:Operator — assign the Operator role in the Test environment

The role must target an environment that the workspace has provisioned. If the workspace does not have the specified environment, the invitation fails with Environment <env> not found.

Capabilities

Resource	Sync	Provision
Accounts
Privileges
Roles
Environment roles
Folders
Projects

Environment roles (RBAC v2): Workato allows exactly one environment role per collaborator per environment. ConductorOne models environment roles as mutually exclusive entitlements: granting a new role for an environment supersedes the collaborator’s existing role there. Directly revoking an environment role is not supported by the connector; to change a collaborator’s access, grant the replacement role instead.

Gather Workato credentials

Each setup method requires you to pass in credentials generated in Workato. Gather these credentials before you move on.

Create a client role

1. In Workato, navigate to Workspace admin > API clients > Client roles > Add client role.

2. Give the new client role a name, such as “C1 integration role”.

3. Select the following endpoints:

   Area	Section	Action	API Endpoint
   Projects	Projects & Folders	List projects	GET /api/projects
   	Projects & Folders	List folders	GET /api/folders
   Admin	Collaborators	Get collaborators	GET /api/members
   	Collaborators	Get collaborator	GET /api/members/:id
   	Collaborators	Update collaborators’ roles*	PUT /api/members/:id
   	Collaborators	Invite collaborator	POST /api/member_invitations
   	Collaborators	Add existing collaborator	POST /api/members
   	Collaborators	Remove collaborator	DELETE /api/members/:id
   	Collaborators	Get collaborator privileges	GET /api/members/:id/privileges
   	Collaborator roles	List non-system roles§	GET /api/roles
   	Environment roles	List environment roles†	GET /api/environment_roles
   	Environment roles	Get environment role†‡	GET /api/environment_roles/:id
   *If you don’t want to use C1 to provision role assignments, you can skip Update collaborator’s roles and Get environment role.

   †List environment roles and Get environment role are only available after your workspace migrates to RBAC v2 — see Migrating to RBAC v2 for the full cutover sequence.

   ‡Get environment role is required only if you want C1 to provision environment role assignments.

   §The Collaborator roles section (including List non-system roles) only appears in the UI if your workspace uses the legacy roles model. If this section is not visible, your workspace has migrated to RBAC v2 — see Migrating to RBAC v2, and use Workato’s Role migration API to migrate your legacy custom roles to environment roles.

4. Save the new role.

Create an API client

1. Navigate to Workspace admin and select API clients > Create API client.

2. Give the new client a name, such as “C1 integration”.

3. Select the client role you set up above.

4. If your workspace has environments enabled, select the environment the API client (and by extension, C1) is allowed to access.

5. Select the projects the API client is allowed to access.

6. If needed, add allowed IP ranges that API requests using this token can originate from (view C1’s IP addresses).

7. Click Create client

8. The new client’s API token is shown. Carefully copy and save the API token.

Look up your data center location

You’ll also need to specify the location of your Workato data center. Workato displays your data center in the base URL of the API endpoint:

• US Data Center: https://www.workato.com/api/
• EU Data Center: https://app.eu.workato.com/api/
• JP Data Center: https://app.jp.workato.com/api/
• SG Data Center: https://app.sg.workato.com/api/
• AU Data Center: https://app.au.workato.com/api/
• IL Data Center: https://app.il.workato.com/api/
• Developer Sandbox: https://app.trial.workato.com/api/

Done. Next, move on to the connector configuration instructions.

Configure the Workato connector

To complete this task, you’ll need:

• The Connector Administrator or Super Administrator role in C1
• Access to the set of Workato credentials generated by following the instructions above

Cloud-hosted

Follow these instructions to use a built-in, no-code connector hosted by C1.

1. In C1, navigate to Integrations > Connectors and click Add connector.

2. Search for Workato and click Add.

3. Choose how to set up the new Workato connector:

   • Add the connector to a currently unmanaged app (select from the list of apps that were discovered in your identity, SSO, or federation provider that aren’t yet managed with C1)

   • Add the connector to a managed app (select from the list of existing managed apps)

   • Create a new managed app

4. Set the owner for this connector. You can manage the connector yourself, or choose someone else from the list of C1 users. Setting multiple owners is allowed.

   If you choose someone else, C1 will notify the new connector owner by email that their help is needed to complete the setup process.

5. Click Next.

6. Find the Settings area of the page and click Edit.

7. Enter the API token in the API key field.

8. In the Data center field, enter one of us, eu, jp, sg, au, il, or sandbox (developer sandbox) to identify the location of your Workato data center. The default is us.

9. In the Environment field, enter one of dev, test, or prod to identify your Workato environment. The default is dev.

10. Optional. If desired, check the box to Disable custom roles sync.

11. Click Save.

12. The connector’s label changes to Syncing, followed by Connected. You can view the logs to ensure that information is syncing.

Done. Your Workato connector is now pulling access data into C1.

Self-hosted

Follow these instructions to use the Workato connector, hosted and run in your own environment.

When running in service mode on Kubernetes, a self-hosted connector maintains an ongoing connection with C1, automatically syncing and uploading data at regular intervals. This data is immediately available in the C1 UI for access reviews and access requests.

Resources

• Official download center: For stable binaries (Windows/Linux/macOS) and container images.

• GitHub repository: Access the source code, report issues, or contribute to the project.

Step 1: Configure the Workato connector

1. In C1, navigate to Integrations > Connectors > Add connector.

2. Search for Baton and click Add.

3. Choose how to set up the new Workato connector:

   • Add the connector to a currently unmanaged app (select from the list of apps that were discovered in your identity, SSO, or federation provider that aren’t yet managed with C1)

   • Add the connector to a managed app (select from the list of existing managed apps)

   • Create a new managed app

4. Set the owner for this connector. You can manage the connector yourself, or choose someone else from the list of C1 users. Setting multiple owners is allowed.

   If you choose someone else, C1 will notify the new connector owner by email that their help is needed to complete the setup process.

5. Click Next.

6. In the Settings area of the page, click Edit.

7. Click Rotate to generate a new Client ID and Secret.

   Carefully copy and save these credentials. We’ll use them in Step 2.

Step 2: Create Kubernetes configuration files

Create two Kubernetes manifest files for your Workato connector deployment:

Secrets configuration

# baton-workato-secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: baton-workato-secrets
type: Opaque
stringData:
  # C1 credentials
  BATON_CLIENT_ID: <C1 client ID>
  BATON_CLIENT_SECRET: <C1 client secret>
  
  # Workato credentials
  BATON_WORKATO_API_KEY: <Workato API key>
  BATON_WORKATO_DATA_CENTER: <Your Workato data center (one of us, eu, jp, sg, au, il, or sandbox). Default is us.>
  BATON_WORKATO_ENV: <Your Workato environment (one of dev, test, or prod). Default is 'dev'>

  # Optional: set to true to skip legacy custom role sync (required if your workspace
  # has migrated to RBAC v2 and the 'Collaborator roles' section does not appear in the API client UI)
  BATON_DISABLE_CUSTOM_ROLES_SYNC: true

  # Optional: include if you want C1 to provision access using this connector
  BATON_PROVISIONING: true

See the connector’s README or run --help to see all available configuration flags and environment variables.

Deployment configuration

# baton-workato.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: baton-workato
  labels:
    app: baton-workato
spec:
  selector:
    matchLabels:
      app: baton-workato
  template:
    metadata:
      labels:
        app: baton-workato
        baton: true
        baton-app: workato
    spec:
      containers:
      - name: baton-workato
        image: public.ecr.aws/conductorone/baton-workato:latest
        imagePullPolicy: IfNotPresent
        env:
        - name: BATON_HOST_ID
          value: baton-workato
        envFrom:
        - secretRef:
            name: baton-workato-secrets

Step 3: Deploy the connector

1. Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.

2. Check that the connector data uploaded correctly. In C1, click Apps. On the Managed apps tab, locate and click the name of the application you added the Workato connector to. Workato data should be found on the Entitlements and Accounts tabs.

Done. Your Workato connector is now pulling access data into C1.

Migrating to RBAC v2

Workato is retiring legacy roles at the end of August 2026. Every workspace must migrate to the new RBAC v2 model (environment roles) before then. Read Workato’s Access Control v2 overview and follow their migration guide to migrate your workspace.

Environment roles sync requires RBAC v2 and is on by default, so exclude it from sync until your workspace migrates (otherwise sync fails with failed to list environment roles: 401).

After your workspace migrates to RBAC v2, complete this cutover in order:

1. In Workato, update your C1 API client’s role with the permissions that only become available after migration:
   • List environment roles — required
   • Get environment role — required only if C1 provisions environment role assignments
2. In the connector configuration:
   • Enable Disable custom roles sync, since the legacy /api/roles endpoint no longer serves custom roles.
   • Confirm Environment roles sync is on (it is on by default — re-enable it now if you excluded it per the note above).

Getting either side of the cutover wrong fails differently:

• Enable Environment roles sync too early (before migration) → sync fails with failed to list environment roles: 401.
• Leave Environment roles sync disabled too late (after migration) → sync succeeds, but silently drops environment role grants — collaborators appear to have no role assignments.

Custom roles also move from the legacy /api/roles resource to environment roles, a different resource type. The first sync after migration rebuilds all role resources and grants from scratch, so expect a large diff with no retained history — this is expected, not a sync error.