What Oleria discovers
Once connected, Oleria continuously discovers and maps the following from your Workato workspace:- Accounts - the workspace owner, every collaborator, pending invitees that belong to a collaborator group, and Workato Identity users. Oleria shows each person’s sign-in method, whether they signed in through single sign-on, when they last changed their password, and whether the workspace requires multi-factor authentication or single sign-on, when the audit log records it. See Known limitations.
- Non-human identities - Developer API clients, API Platform clients, recipes, connections, on-prem agents, and MCP server tokens. Oleria shows who created each one and which connections each recipe runs as.
- Credentials - Developer API client tokens, API Platform keys, connection secrets, MCP server tokens, and the certificate bundles API Platform clients authenticate with over mutual TLS, each linked to the identity it authenticates. Oleria never reads the secret values.
- Roles - environment roles, project roles, legacy roles, and API client roles, with each collaborator’s and API client’s role and what each role allows on each type of Workato object. The workspace owner gets a Workspace owner role.
- User groups - collaborator groups and Workato Identity groups, with their members.
- Resources - projects, folders, API collections, and MCP servers, with what each project contains.
- Access - project access granted to collaborators and groups, API collections anyone can call without credentials, the full reach of the owner and of Environment admins, the projects and API collections each API client can reach, the MCP server each MCP token can call, and the MCP servers each Workato Identity group can use.
- Activity - events from Workato’s activity audit log, such as sign-ins, role and group changes, and created or deleted API clients and connections. Workato keeps one year of audit history.
Oleria doesn’t read recipe steps, job history, connection secret values, lookup tables, or data tables. This integration covers identity and access governance only.
Prerequisites
- A Workato workspace in one of these data centers: US, EU, Japan, Singapore, Australia, Israel, South Korea, UK, China, or a free or trial workspace.
- A Workato workspace admin who can create client roles and API clients under Workspace admin > API clients.
- A Developer API client dedicated to Oleria. Workato records every change made with its token as the workspace owner, so a client used only by Oleria keeps its access easy to review and revoke.
- Admin access to the Oleria workspace.
Create an API client in Workato
1
Create a client role
Sign in to Workato as a workspace admin. Go to Workspace admin > API clients and create a client role for Oleria with these privileges:
If the role doesn’t have one of the optional privileges, or your Workato plan doesn’t include that feature, Oleria skips that data and keeps syncing everything else.To let Oleria run remediation actions, also give the role these write privileges. Leave them out for a read-only integration.
Revoking project access also reads Projects & folders, Project grants, Collaborators (including legacy roles) and Collaborator groups to find every way the collaborator reaches the project, so keep those read privileges on the role. Oleria checks them before it runs the action.
2
Create a Developer API client
Create a Developer API client with that role. If your workspace uses environments, put it in the DEV environment, because Workato lists collaborators only through a DEV client. Give it access to all projects.
3
Copy the token
Copy the API client’s token. Workato shows it only once.
The exact location of these settings can change over time. If the steps above don’t match what you see, refer to Workato’s own documentation.
Connect Workato to Oleria
1
Open the integration
Go to your Oleria workspace, select Integrations -> select Workato.
2
Complete the connection form
Select Continue and provide the following:
3
Confirm the connection
Select Authenticate. Oleria reads your workspace and checks that the API client can list collaborators before it saves anything. Find the newly connected workspace on the Connected tab of your Oleria Integrations page.
Verify the integration
Confirm the Workato workspace appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, check that the workspace owner, collaborators, and projects appear in your Oleria workspace.When you edit the integration, you can change the data center and the API token. Leave API token blank to keep the stored token. The new token must belong to the same Workato workspace. To connect a different workspace, add a new integration.
Update a connection made with SCIM
If you connected Workato to Oleria earlier through SCIM, that connection used a SCIM token, which can’t read the Workato Developer API. After this update, its syncs fail with a message asking for an API token. Edit the existing integration rather than deleting it and adding a new one:- Create an API client and copy its token.
- In Oleria, edit the Workato integration and choose your Data center. A connection made with SCIM opens on US (www.workato.com), so change it if your workspace is hosted elsewhere.
- Paste the token into API token and select Update. The next sync uses the new token.
Remediation actions
Oleria can take these actions in Workato. Each one runs with the privileges of the API client’s role:- Remove or delete a collaborator from the workspace. Oleria records the collaborator’s roles, groups and direct project access first, and reverting the action invites them again with the same roles and groups. Workato can’t attach project access to an invitation, so when the collaborator had direct project access, the revert sends the invitation and then reports as failed, naming the projects to grant again once they accept. If the client role can’t read project grants, Oleria still removes the collaborator, and the revert reports as failed because it can’t restore any project access.
- Invite a collaborator with the Member role in DEV and the collaborator groups you choose. If the email already belongs to a collaborator, Oleria sends nothing, and reports an error if you chose groups, since they wouldn’t be applied. Reverting removes them once they accept; Workato has no way to cancel a pending invitation through its API, so cancel it in Workato if they haven’t accepted.
- Create a collaborator group, and delete it on revert. If a group with that name already exists, Oleria leaves it as is.
- Change a collaborator’s environment role. Assigning a role sets it in DEV. Member can’t be removed; remove the collaborator instead. Removing a role replaces it with Member in every environment where the collaborator holds it. Reverting restores each environment unless its role changed again since. If one changed, Oleria leaves it as is, restores the others and reports the revert as failed so you can check it.
- Add a collaborator to a group and remove a collaborator from a group. Reverting undoes the change.
- Revoke a collaborator’s project access granted directly to them, and grant it again on revert. If the collaborator was given a different project role since, the revert leaves it and reports a conflict. If the collaborator also reaches the project another way, through a group’s project access, an admin or legacy role, or as the owner, Oleria changes nothing and names that source so you can remove it there.
- Disable an API Platform client by deactivating all of its active keys, and re-enable those keys on revert.
- Remove an API collection from an API Platform client, the external consumer of your APIs, and give it back on revert.
- Turn off public access to an API collection, so callers need credentials again, and turn it back on at revert. Workato allows public access only on proxy collections.
- Stop a recipe, and start it again on revert.
- Workato has no disabled state for collaborators, so Oleria has no enable action for them. To bring back a removed collaborator, revert the removal. They receive a new invitation and must accept it.
- Oleria won’t remove the workspace owner.
- Oleria doesn’t disable Developer API clients or connections, because Workato can only delete or disconnect them, and that can’t be undone. Oleria doesn’t disable MCP server tokens either.
Known limitations
- Sign-in, MFA, and single sign-on status come from the audit log. Workato’s API doesn’t report them on accounts, so Oleria reads them from recent sign-in and workspace setting events. If there’s no such event, or the client role doesn’t have the Activity audit privilege, Oleria shows them as unavailable.
- Creators come from the audit log. Oleria finds who created an API client, API Platform client, connection, or on-prem agent from its creation event. If that event is older than the recent audit history Oleria reads, the identity has no creator.
- Changes made through the API are attributed to the owner. Workato records actions taken with an API client token as the workspace owner, including changes Oleria makes.
- Pending invitees appear only through a group. Workato’s API doesn’t list invitations, so Oleria discovers only invitees who were added to a collaborator group.
- DEV environment only. If your workspace uses environments, a Workato API client reads a single environment, and Oleria needs a DEV client to list collaborators, so recipes, connections, and other objects that exist only in your TEST or PROD environments aren’t discovered.
- Legacy role workspaces. Removing a collaborator’s role and inviting a collaborator both use Workato’s Member environment role, which exists only in workspaces on Workato’s current role model. In a workspace that still uses legacy roles, Oleria syncs as usual but refuses these two actions with a message saying why.
- No group nesting or role nesting. Workato groups and roles are flat.
- Some objects aren’t inventoried. Oleria doesn’t import Agent Studio genies or genie clients, knowledge bases, skills, API endpoints, on-prem groups, lookup or data tables, tags, API portals, or Embedded (OEM) customer workspaces.