ZoomInfo User Management Guide

• Model type: role-based
• Description: ZoomInfo uses a predefined role-based model with Admin and User as the primary roles. Admins can configure credit allocations per user and restrict certain features (e.g., bulk export limits, CRM integration access) at the team or user level. There is no publicly documented fully custom role builder; permission granularity is limited to what the Admin Center exposes.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Role-level (Admin vs. User) with per-user credit caps and some feature toggles (e.g., Engage access, bulk export on/off). Team-level groupings can be used to apply settings to cohorts of users.

1. Log in to ZoomInfo and navigate to Admin Center (top-right menu → Admin).
2. Select 'Users' from the left-hand navigation.
3. Click 'Add User' or 'Invite User'.
4. Enter the new user's email address, first name, and last name.
5. Assign a role (Admin or User).
6. Optionally assign the user to a Team.
7. Set credit allocation for the user if applicable.
8. Click 'Send Invite'. The user receives an email invitation to activate their account.
9. User must accept the invitation and set a password (or authenticate via SSO if enforced).

Required fields: Email address, First name, Last name, Role (Admin or User)

Watch out for:

• Adding a user consumes a licensed seat; if the account is at seat capacity, the invite will be blocked until a seat is freed or the contract is expanded.
• If 'Require SSO' is enabled, the invited user must authenticate through the configured IdP and cannot set a local password.
• Invitation emails can land in spam; users should be advised to check junk folders.
• Users added via manual invite are not automatically linked to SCIM-provisioned groups; group membership must be managed in the IdP if SCIM is active.

• Can delete users: No
• Delete/deactivate behavior: ZoomInfo does not offer a permanent user deletion option through the Admin Center UI. Admins can deactivate (disable) a user, which immediately revokes login access and removes the seat from active use. The user record and their historical activity (exports, searches) are retained in the system for audit and reporting purposes.

1. Navigate to Admin Center → Users.
2. Locate the user by searching their name or email.
3. Click the user's name or the action menu (three dots) next to their record.
4. Select 'Deactivate User'.
5. Confirm the deactivation in the dialog prompt.
6. The user is immediately locked out; their seat becomes available for reassignment.

Watch out for:

• Deactivating a user does not automatically reassign their owned lists or saved searches; an Admin must manually transfer or archive them.
• If the deactivated user was the sole Admin, the account may lose Admin access - ensure at least one other Admin exists before deactivating.
• CRM integration tokens tied to the deactivated user's OAuth session will expire or break; audit integrations before deactivating.
• Reactivating a previously deactivated user requires a seat to be available; if the account is at capacity, reactivation is blocked.

• Where to check usage: Admin Center → Usage & Activity (or Reports) → view credit consumption per user, export activity, and seat utilization over a selected date range.
• How to identify unused seats: Admin Center → Users → sort by 'Last Login' or 'Last Active' date to identify users who have not logged in within a defined period. Credit usage report can confirm zero-consumption users.
• Billing notes: ZoomInfo uses annual contracts with custom pricing negotiated per account. Credits are consumed per export action (contact reveal, company reveal). Unused credits do not roll over at contract renewal unless explicitly negotiated. Seat counts and credit pools are set at contract signing; mid-term additions require a contract amendment and are typically prorated. All pricing is quote-based; published figures are estimates from disclosed contract data.

Every app that relies on manual provisioning carries a hidden coordination cost, and ZoomInfo compounds it in two ways. First, adding a user consumes a licensed seat immediately; if the account is at capacity, the invite is blocked until a seat is freed or a contract amendment is processed.

Second, credit allocation per user must be set and adjusted manually by an Admin - there is no automatic rebalancing when a user leaves mid-year, meaning unused credits can sit idle until renewal.

Deactivation does not delete the user record or reassign owned lists and saved searches; an Admin must handle that cleanup separately, and any CRM OAuth tokens tied to the deactivated user will silently break if not audited first.

Recurring friction points reported by ZoomInfo admins cluster around three areas. Pricing opacity is the most common: there is no public rate card, so budget planning requires a full sales cycle.

SCIM and SSO enforcement are gated behind the Enterprise tier, leaving teams on lower plans with manual-only workflows for every provisioning action.

Documentation for non-Okta identity providers - Entra ID, OneLogin - is noticeably thinner than the Okta guide, which creates ambiguity when configuring SCIM in mixed-IdP environments.

The absence of true user deletion is also flagged by admins with data privacy obligations, since deactivated records persist in the system indefinitely.

Common complaints:

• Pricing is not publicly listed; buyers must go through a sales process to get a quote, making budget planning difficult.
• SCIM provisioning and SSO enforcement are gated behind the Enterprise tier, leaving smaller plan customers with manual-only user management.
• Documentation for non-Okta IdPs (Entra ID, OneLogin) is less detailed than the Okta integration guide.
• No true user deletion - deactivated users remain in the system, which concerns some admins managing data privacy obligations.
• Credit allocation per user must be manually managed by Admins; there is no automatic rebalancing if a user leaves mid-year.
• Seat costs are high relative to usage for occasional users, and a lower-cost Viewer tier is not consistently available across all contracts.
• Admins report that reactivating a deactivated user can be blocked if the seat count is at capacity, requiring a support ticket to resolve.
• The Admin Center UI has been described as non-intuitive for bulk user management tasks beyond CSV import.

Manual management is viable for small, stable teams where seat counts rarely change and an Admin can absorb the overhead of credit allocation and offboarding cleanup.

It becomes a liability at scale: every app added to a growing stack multiplies the per-user coordination cost, and ZoomInfo's high per-seat pricing makes unused or mis-allocated seats expensive to carry.

Teams expecting frequent onboarding or offboarding cycles, or those with SSO already in place, should evaluate SCIM provisioning - but only if they are on or willing to move to the Enterprise tier, since that is the hard prerequisite.

Viewer-tier access, which could reduce seat cost for occasional users, is not consistently available across all contracts and should be confirmed before signing.

Bottom line

ZoomInfo's manual user management is functional but operationally demanding: seat capacity blocks invites, credit allocation is fully manual, and deactivation leaves records and integration tokens requiring separate cleanup.

The role model offers limited granularity - Admin or User, with per-user credit caps as the primary control lever.

Teams that can meet the Enterprise tier and SSO prerequisites will find SCIM provisioning a meaningful improvement, but those below that threshold should plan for sustained Admin overhead on every provisioning action.