Summary and recommendation
Zuora user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Zuora user management lives under Settings > Administration > Manage Users.
The platform uses a role-based access control (RBAC) model: every user must be assigned at least one role, or they land in the product with no functional access at all.
Roles are composed of permission sets scoped by functional area - Billing, Payments, Subscriptions, Reporting, Settings - each configurable at No Access, View, or Full Access granularity.
Administrators can use Zuora's built-in roles or build custom ones by mixing permission levels across areas.
Like every app in a finance or billing stack, Zuora's access model means a misconfigured or forgotten account carries real downstream risk.
Quick facts
| Admin console path | Settings > Administration > Manage Users |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Standard User | Access to core Zuora billing, subscription, and reporting features as permitted by assigned role. | Cannot access administration settings, manage other users, or modify roles unless granted explicit permissions. | Users must be assigned at least one role; a user with no role assigned has no access to functional areas. | ||
| Administrator | Full access to tenant settings, user management, role configuration, and all functional areas. | Cannot exceed the user seat limit defined in the contract without contacting Zuora. | Administrator role grants broad access; Zuora recommends limiting the number of users with this role. | ||
| Read Only User | View-only access to records and reports; cannot create, edit, or delete records. | Cannot modify any records, run billing operations, or access administration settings. | Read-only access is enforced at the role level; must be explicitly configured by an administrator. |
Permission model
- Model type: role-based
- Description: Zuora uses a role-based access control (RBAC) model. Each user is assigned one or more roles. Roles are composed of permission sets that control access to specific functional areas (e.g., Billing, Subscriptions, Reporting, Administration). Zuora provides a set of standard built-in roles and allows administrators to create custom roles by combining permission sets.
- Custom roles: Yes
- Custom roles plan: Not documented
- Granularity: Permission sets are grouped by functional area (e.g., Billing, Payments, Subscriptions, Reporting, Settings). Within each area, permissions can be set to No Access, View, or Full Access. Custom roles allow mixing permission levels across functional areas.
How to add users
- Log in as an administrator.
- Navigate to Settings > Administration > Manage Users.
- Click 'Add Single User'.
- Enter the required user details: first name, last name, email address, username, and work phone (optional).
- Assign one or more roles to the user.
- Click 'Save'. The user receives an email invitation to set their password.
Required fields: First name, Last name, Email address, Username
Watch out for:
- Username must be unique across the Zuora tenant.
- The user will not have any access until at least one role is assigned.
- Email address is used for system notifications and password reset; it must be a valid, deliverable address.
- If SSO is enforced on the tenant, the user's login will be governed by the SSO provider and the local password may not be used.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Yes | Settings > Administration > Manage Users > Import Users (CSV upload option available in the Manage Users screen) |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise (requires SSO configuration; SCIM provisioning available via Zuora OneID with Okta) |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Zuora's admin UI centers on deactivation for interactive users, while the API surface includes delete-style user lifecycle operations. Public documentation does not support a single universal rule across all deployment paths, so delete behavior should be treated as tenant- and workflow-specific.
- Log in as an administrator.
- Navigate to Settings > Administration > Manage Users.
- Locate the user to deactivate.
- Click the user's name to open their profile.
- Click 'Deactivate User'.
- Confirm the deactivation.
| Data impact | Behavior |
|---|---|
| Owned records | Records created or owned by the deactivated user remain intact and are still associated with that user's name in audit logs and transaction history. |
| Shared content | Shared reports, dashboards, or configurations created by the deactivated user remain accessible to other users with appropriate permissions. |
| Integrations | API tokens or OAuth credentials associated with the deactivated user may stop functioning; administrators should review and reassign or revoke API credentials before deactivating. |
| License freed | Deactivating a user frees up the seat for reassignment to a new user, subject to the contracted seat limit. |
Watch out for:
- Deactivated users cannot log in but their historical data and audit trail are preserved.
- API credentials (OAuth clients) tied to a deactivated user should be explicitly reviewed and revoked to prevent orphaned integrations.
- Reactivating a user restores their previous role assignments if those roles still exist.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Named User | Full access to Zuora platform features as defined by assigned roles; each named user occupies one seat. |
- Where to check usage: Settings > Administration > Manage Users - the user list displays all active and inactive users; active user count reflects current seat consumption.
- How to identify unused seats: Filter the Manage Users list by 'Last Login Date' to identify users who have not logged in recently. Zuora does not provide a native 'unused seat' report; administrators must manually review last login timestamps.
- Billing notes: Zuora uses custom enterprise pricing; seat counts and costs are defined in the customer contract. Exceeding the contracted seat limit requires contacting Zuora account management. Deactivating a user frees the seat for reuse within the existing contract limit.
The cost of manual management
Zuora does not support permanent user deletion through the UI - deactivation is the only offboarding path, which preserves the user record and audit history but frees the seat for reuse within your contracted limit. Seat counts are defined in the customer contract; exceeding the limit requires contacting Zuora account management directly.
There is no native unused-seat report: identifying dormant accounts means manually filtering the Manage Users list by Last Login Date. Deactivating users one at a time through the UI creates compounding overhead as headcount grows or turns over.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Manual management in Zuora is workable for small, stable teams but becomes a liability at scale. Every app that handles billing data carries elevated offboarding risk, and Zuora's one-at-a-time deactivation flow, absent bulk tooling, and missing inactive-user report create compounding overhead as headcount grows or turns over.
If your organization is already on the Enterprise plan with SSO enabled, SCIM provisioning via Okta or Azure AD eliminates most of this friction and is the recommended path. For teams below Enterprise tier or without a supported IdP, manual management via the admin console is the only option - plan the operational overhead accordingly.
Bottom line
Zuora's manual user management is functional but deliberately limited: no bulk deactivation, no inactive-user report, and no permanent delete.
Every app that touches billing data carries elevated offboarding risk, and Zuora's audit-preserving deactivation model is sound in principle - but the one-at-a-time UI makes it hard to act on that principle at any real scale.
Teams on Enterprise with Okta or Azure AD should prioritize SCIM setup to remove the manual bottleneck entirely; everyone else should build a recurring review cadence into their IT operations before the user list drifts.
Automate Zuora workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
