Skip to main content
Connect Loom to Oleria to see who your identity provider has provisioned into your Loom workspace: its users, its groups, and each user’s workspace role. Oleria reads this data from Loom’s Directory Sync, which Loom runs on WorkOS, so you can review access and take action directly from Oleria.
This integration is for Loom Enterprise workspaces bought on loom.com. If your Loom workspace was bought on Atlassian.com or is managed in Atlassian Administration, use the Atlassian Cloud integration instead. It shows your Atlassian organization’s users and groups. Loom-specific product access and roles aren’t shown there yet.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Loom Directory Sync directory:
  • Accounts - every user your identity provider has pushed into Directory Sync, with their name, email address, title, department, cost center, employee number, and whether they’re active. Oleria also keeps the ID your identity provider uses for each user.
  • Roles - the Admin, Creator, and Viewer workspace roles, read from the loomMemberRole attribute when your directory returns it. Users with the Admin role are marked as administrators. Users whose loomMemberRole is default or not set get no role. If your users show no role after the first sync, contact support.
  • User groups - every group your identity provider pushes into Directory Sync, and its members. Oleria labels these groups as synced.
  • Credentials - the Directory Sync bearer token you connect with. Oleria lists it as an active API token with full access to the directory. It isn’t linked to an account, because the token doesn’t belong to a Loom user.
Oleria refreshes users, groups, and roles on its regular sync schedule.
Oleria doesn’t import videos, folders, spaces, or shared links, and doesn’t collect activity. This integration covers identity and access governance for users, groups, and workspace roles only.

​
Prerequisites

  • A Loom Enterprise workspace bought on loom.com, with a verified domain and SAML single sign-on (SSO) configured.
  • A Loom workspace admin.
  • Directory Sync already set up between Loom and your identity provider, using bearer token authentication. Directories set to OAuth client credentials aren’t supported.
  • Admin access to the Oleria workspace.

​
Get the Directory Sync endpoint and token from Loom

1

Open Directory Sync

Sign in to Loom as a workspace admin. Go to Workspace settings > Security > Directory Sync and select Configure Directory Sync. Loom opens the WorkOS setup console.
2

Copy the endpoint

Copy the Endpoint. It starts with https://api.workos.com/scim/v2.0/.
3

Get a bearer token

The WorkOS console shows each bearer token only once, when it’s created. If the console offers to generate an additional bearer token, generate one for Oleria, so you can revoke Oleria’s access without affecting your identity provider. Otherwise, use the token your identity provider already uses. If you don’t have it, generate a new token and update your identity provider and Oleria at the same time, because that token also provisions your Loom users.
The exact location of these settings can change over time. If the steps above don’t match what you see, refer to Loom’s own documentation.

​
Connect Loom to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations -> select Loom.
2

Complete the connection form

Select Continue and provide the following:
3

Confirm the connection

Select Authenticate. Oleria reads one user from your directory to check the endpoint and token before it saves anything. Find the newly connected workspace on the Connected tab of your Oleria Integrations page.
If Authenticate reports that the token is invalid, check that the token hasn’t been revoked and that the directory uses bearer token authentication. If it reports that the endpoint wasn’t found, copy the endpoint again from Workspace settings > Security > Directory Sync. You can connect each Directory Sync directory only once.

​
Verify the integration

Confirm the Loom workspace appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, check that users and groups appear in your Oleria workspace. If your identity provider sends loomMemberRole, check that users with the Admin role are marked as administrators.
When you edit the integration, you can replace the bearer token. Leave Directory Sync bearer token blank to keep the stored token. You can’t change the SCIM Endpoint. To connect a different directory, add a new integration.

​
Remediation actions

Oleria can take these actions in Loom’s Directory Sync directory, using the bearer token:
  • Deactivate a user and reactivate a user.
  • Add a user to a group and remove a user from a group.
  • Change a user’s workspace role to Admin, Creator, or Viewer, by setting the user’s loomMemberRole.
  • Create a user and delete a user in the Directory Sync directory.
  • Create a group in the Directory Sync directory.
The bearer token has no scopes, so the token you connected with is all these actions need. Before an action runs, Oleria checks that the directory still accepts the token. Keep these limits in mind when you use these actions:
  • Oleria reads the user or group before it changes anything. If the user is already in the requested state, Oleria makes no change, and reverting the action leaves that state in place.
  • Oleria doesn’t retry a change. If Loom’s directory doesn’t respond, Oleria reads the user or group again and reports success only if the change was applied.
  • Reverting an action undoes only the change that action made. Reverting a deactivation reactivates the user, and reverting an add removes the user from the group. If the user or group is already back in its earlier state, Oleria makes no change.
  • When you deactivate a user, Loom applies your workspace’s Member Deprovisioning setting. With Deactivate, the default, Loom keeps the user’s content. With Delete, Loom can permanently delete the user’s content. Reverting the action can’t restore deleted content.
  • Depending on how your directory is set up, WorkOS may delete a user from the directory when the user is deactivated. A deleted user can’t be re-enabled, so reverting the deactivation fails. Re-provision the user from your identity provider instead.
  • If Oleria can’t find the user, deactivating, reactivating, or adding them to a group fails and nothing changes. Removing a user who isn’t in the group succeeds without making a change.
  • Your identity provider owns the Directory Sync directory. If it still assigns the user or group membership, it may undo the change on its next push. Make lasting changes in your identity provider.
  • Loom doesn’t document what a directory group grants inside Loom, so adding or removing a group member may not change the user’s access in Loom.
  • Oleria changes a workspace role only for a user whose current loomMemberRole is Admin, Creator, or Viewer, so reverting can restore it. Oleria reads the user again after the change and reports the action as failed if the new role doesn’t read back. Loom has no “no role” value, so Oleria can only change a role, not remove one.
  • Oleria creates a user without a password, because Loom signs users in through your SSO. The user is inactive unless you choose to activate them. If a user or group with that name already exists, Oleria changes nothing. Undoing a create deletes only the user or group Oleria created.
  • Deleting a user can’t be undone. Loom then applies your workspace’s Member Deprovisioning setting, which can permanently delete the user’s content. If the user is already gone, Oleria makes no change.

​
Known limitations

  • Data reflects your identity provider, not every Loom member. Oleria sees the users and groups your identity provider pushed into Directory Sync. Members who joined through domain capture, an invitation, or SSO just-in-time sign-in may not be visible.
  • Changes made in the Loom UI may not be visible. Role and status changes made in Loom may not reach Directory Sync. A user promoted to admin in Loom may not be marked as an administrator.
  • Deactivated users may disappear. Depending on how your directory is set up, WorkOS may delete a deactivated user from the directory, so the user disappears from Oleria instead of showing as inactive.
  • Roles come only from loomMemberRole. If your identity provider doesn’t send it, or sends default, the user has no role in Oleria.
  • No activity, last-login, or dormancy data. Loom’s activity log is a CSV export with no API, so Oleria doesn’t import activity or flag dormant accounts.
  • No MFA status or sign-in method. Loom doesn’t expose multi-factor authentication settings or how each user signs in. Oleria shows SSO as configured, because Directory Sync requires it, but can’t tell whether SSO is enforced.
  • No non-human identities or AI agents. Loom has no API that lists apps, integrations, tokens, or AI agents, so Oleria doesn’t discover non-human identities or AI agents. The only credential Oleria lists is the bearer token you connect with, without its creation, expiry, or last-used dates.
  • Bearer token only. Oleria doesn’t support Directory Sync directories set to OAuth client credentials.
  • WorkOS endpoints on api.workos.com only. Oleria accepts only endpoints of the form https://api.workos.com/scim/v2.0/{id}.
  • Atlassian-managed Loom isn’t supported. Use the Atlassian Cloud integration for Loom workspaces bought on Atlassian.com or managed in Atlassian Administration. It shows your Atlassian organization’s users and groups, but not Loom-specific product access or roles yet.
  • Workspaces moving to Atlassian. Loom is moving legacy loom.com workspaces to Atlassian. After your workspace moves, this integration may stop syncing or keep showing outdated data. Disconnect it and connect the Atlassian Cloud integration instead.
  • Videos, folders, and spaces aren’t inventoried. Oleria doesn’t import Loom content or who it’s shared with.

​
Contact us

For questions about this integration, contact us at support@oleria.com.