Skip to main content
Connect Zuora to Oleria to see who can sign in to your Zuora organization through Zuora OneID, who is an Organization Admin, and which OneID user groups each person belongs to. OneID is the identity layer in front of your Zuora tenants. Oleria reads it with a OneID OAuth 2.0 client, so you can review access to Zuora and take action directly from Oleria.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Zuora OneID organization:
  • Accounts - every OneID user in the organization, with their name, email address, user name, status, creation date, and last OneID login. Active users are enabled. Deactivated users, and users who haven’t yet accepted their OneID activation email, are imported as disabled. Organization Admins are marked as administrators. Oleria also keeps each user’s region, federated ID, and deactivation date with the account.
  • Single sign-on - users who sign in through single sign-on are shown with single sign-on as required. Other users are shown with password sign-in.
  • Groups - every OneID user group, and the users who belong to it.
  • Organization roles - the two OneID organization roles, Organization Admin and Standard User, and which users hold each one. A user normally holds one organization role. If Zuora’s user records disagree about whether someone is an Organization Admin, Oleria shows them as an Organization Admin.
  • Global and tenant roles - the OneID global roles, and the roles defined in each tenant that a global role refers to, with their permission groups and permissions in the role description. These roles are imported as an inventory without members (see Known limitations).
  • Activity - events from the OneID audit logs, such as OneID sign-ins, failed sign-ins, and sign-outs; users created, changed, deactivated, or reactivated; MFA and password resets; changes to organization roles, roles, permissions, and user groups; OAuth 2.0 clients created, changed, or deleted; and changes to single sign-on, security policies, and other settings. Sign-in events include the IP address, browser, and sign-in method. Other audit events are imported with their original Zuora object type and action.
If you enter Tenant IDs when you connect, Oleria also imports, for each of those tenants, its sign-ins, its setting changes, and changes to its users, roles, and permissions. Without tenant IDs, Oleria imports OneID-level audit events only. On the first sync, Oleria reads up to 90 days of audit history. Successful sign-ins by the OAuth 2.0 client that Oleria connects with aren’t imported, so Oleria’s own routine reads don’t appear as activity. Failed sign-ins and any other events from that client are imported and marked as coming from the Oleria connection, so misuse of the credential stays visible. Oleria refreshes this data on its regular sync schedule.
Oleria doesn’t import billing data, such as customer accounts, subscriptions, invoices, payments, or your product catalog. Oleria also doesn’t import users that exist only inside a single tenant and aren’t linked to OneID, OAuth 2.0 clients, or AI agents. This integration covers identity and access governance for OneID users, user groups, and roles only, so Oleria doesn’t populate Access Inventory or resource-level Access Graph data for Zuora.

​
Prerequisites

  • Your Zuora organization uses Zuora OneID.
  • A OneID Organization Admin, to create a OneID OAuth 2.0 client. OneID lets only administrators manage OAuth 2.0 clients.
  • Admin access to the Oleria workspace.
OneID has no read-only OAuth 2.0 client. The client you create for Oleria can read and change OneID users and user groups, and Oleria uses the same client for remediation actions. Store its secret as an administrative credential. Zuora doesn’t document whether a client stops working when the administrator who created it is deactivated or demoted. Create the client as a dedicated integration administrator rather than an employee, and don’t use Oleria to deactivate or demote that administrator.

​
Create a OneID OAuth 2.0 client in Zuora

1

Open the OAuth 2.0 client settings

Sign in to Zuora OneID as an Organization Admin and go to Settings -> Manage OAuth 2.0 Clients.
2

Create the client

Create an OAuth 2.0 client with the grant type Client Credentials and the Scope Type Organization.
3

Copy the credentials

Copy the client’s Client ID and Client Secret and store them securely until you’ve connected Oleria.
4

Note your tenant IDs (optional)

To import sign-ins, setting changes, and user, role, and permission changes for specific Zuora tenants, note the numeric ID of each of those tenants. Each tenant must belong to the same OneID organization as the client. Oleria doesn’t check tenant IDs when you connect, so a wrong ID shows up only as missing tenant activity.
The exact location of these settings can change over time. If the steps above don’t match what you see, refer to Zuora’s own documentation.

​
Connect Zuora to Oleria

1

Open the integration

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

Complete the connection form

Select Continue and provide the following:
3

Confirm the connection

Select Authenticate. Oleria checks that OneID issues an access token for the client, that the client can list OneID users and user groups, and which OneID organization the client belongs to. Oleria also tries to read last-login data, global roles, and the audit logs for OneID and for each tenant ID you entered. If any of these can’t be read, the connection still succeeds, and Oleria skips that data until it can be read. Find the newly connected organization on the Connected tab of your Oleria Integrations page.
If Authenticate fails, Oleria shows the reason. The most common causes:
  • OneID rejects the Client ID or Client Secret. Copy both values again from Manage OAuth 2.0 Clients and check that they’re complete.
  • OneID answers Admin access denied. The client must use the Client Credentials grant type and the Organization scope type, and must be created by a OneID administrator.
  • The OneID base URL has no OneID API. Leave the field empty to use https://one.zuora.com.
You can connect each OneID organization to Oleria once. To connect a different organization, add a new integration.

​
Verify the integration

Confirm the Zuora organization appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, you can review the discovered accounts, groups, roles, and activity in your Oleria workspace.
If you rotate the client secret or replace the OAuth 2.0 client, update the integration in Oleria with the new values. To keep the stored client secret when you edit the integration, leave the Client Secret field empty. If you clear Tenant IDs, Oleria stops importing tenant audit events. If you clear OneID base URL, Oleria uses https://one.zuora.com. The new client must belong to the same OneID organization; Oleria refuses an edit that points the integration at a different organization.

​
Remediation actions

Oleria can take these actions in Zuora OneID. Each one uses the integration’s OAuth 2.0 client:
  • Deactivate a user. The user can no longer sign in through OneID or single sign-on. Zuora keeps the user record, so the user can be reactivated. Reverting the action reactivates the user, but only if they were active before.
  • Reactivate a user. Only deactivated users can be reactivated. Reverting the action deactivates the user again.
  • Add a user to a user group, or remove a user from a user group. Oleria asks Zuora to change only that user’s membership and checks that every other member is still there afterwards. Reverting the action undoes the change. Adding a user to a group also grants the tenants and OneID user roles that the group grants in Zuora.
  • Change a user’s organization role to Organization Admin or Standard User. Assigning a role replaces the user’s current organization role. Reverting the action restores the previous role, but only if the user still holds the role Oleria assigned.
Changing a user’s organization role is turned off by default while Oleria verifies it with Zuora. Until then, Oleria shows the action as not enabled. If it runs, Oleria checks the request, including the guards below, and the action fails with a message naming the change it would have made. Nothing changes in Zuora. In the meantime, change organization roles in OneID.
If the user is already in the requested state, for example already a member of the group, the action succeeds without changing anything, and reverting it changes nothing. Keep these limits in mind:
  • Oleria won’t deactivate or demote the only active Organization Admin, because that would lock your organization out of OneID administration. Make another user an Organization Admin first. If Oleria can’t read the users or their organization roles to check this, it refuses the action.
  • Users who haven’t accepted their OneID activation email can’t be reactivated from Oleria. They become active when they accept the email. If you deactivate one of these users, reverting the action fails instead of making them an active user. Restore them in OneID.
  • Global and tenant roles can’t be assigned from Oleria. Zuora grants them through user groups, so use a group action or OneID instead. Oleria also won’t change the organization role of a user who holds no organization role, several roles, or a role other than Organization Admin or Standard User.
  • If someone changes a user’s organization role in OneID after Oleria changed it, reverting the action leaves the new role as it is.
  • If removing a user from a group also removes other members, Oleria adds those members back in the same action and reports them. If Oleria can’t add them back, the action fails and names them so you can re-add them in OneID.
  • After each change, Oleria reads the user or group again to confirm it:
    • If Zuora’s response was lost or Zuora returned an error, and the change doesn’t show when Oleria reads it back, the action fails with a message saying the change may have been applied. Check the user in OneID before you run the action again.
    • If Zuora accepts the change but reading it back shows it wasn’t applied, the action fails and there’s nothing to revert.
    • If Zuora accepts the change but Oleria can’t read the user or group again, the action is reported as successful without confirmation. Check the user in OneID.
  • Deactivating a user in OneID doesn’t remove accounts that exist only inside a tenant. Zuora documents a grace period after a user moves to OneID during which they can keep signing in to a tenant with local credentials, so a recently migrated user may still be able to sign in to a tenant directly until that period ends.

​
Known limitations

  • No group-to-role bindings. Zuora’s API doesn’t show which tenants and roles a user group grants, or which tenant roles a user holds. Oleria imports global and tenant roles without members, so tenant access granted through user groups isn’t shown in the access graph.
  • Administrators are Organization Admins only. Only OneID Organization Admins are marked as administrators. A user who is an administrator in a tenant through a user group isn’t flagged.
  • No tenant-local users. Users that exist only in a tenant’s own user list and aren’t linked to OneID, including tenant API and integration users, aren’t imported. Their sign-ins appear as tenant activity without a linked account when you enter that tenant’s ID.
  • No MFA or password data. Zuora’s API doesn’t show whether MFA is required or which factors a user has enrolled. Oleria shows MFA as not applicable for single sign-on users, whose identity provider handles MFA, and as unavailable for everyone else. Oleria doesn’t import password change dates.
  • No OAuth 2.0 clients or AI agents. Zuora has no API to list OneID or tenant OAuth 2.0 clients, so Oleria doesn’t import them as non-human identities and can’t disable them. Creating, changing, or deleting a OneID OAuth 2.0 client appears as activity. Zuora AI acts as the user who invokes it, so its actions appear under that user.
  • Last login is OneID only. An account’s last login reflects sign-ins through OneID. Sign-ins with local tenant credentials and API use aren’t reflected.
  • Optional data needs Zuora’s Admin Integrations and audit log APIs. If the client can’t read OneID’s Admin Integrations API, Oleria imports users and groups without last login, and without global and tenant roles. If the client can’t read the OneID audit logs, or a tenant’s audit events, Oleria skips them and the sync still completes. This can happen when a tenant ID doesn’t belong to your organization. If you don’t see tenant sign-ins after the first sync, check that each tenant ID belongs to the same OneID organization as the client.
  • Tenant roles come from global roles. Oleria imports a tenant’s roles only for tenants that a OneID global role refers to.
  • Group priority. Zuora’s API doesn’t return user group priority, so Oleria doesn’t show it.
  • Rate limits. Zuora doesn’t publish OneID API rate limits. Oleria paces its requests to leave room for your other Zuora OneID integrations, so large organizations can take longer to sync.

​
Contact us

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