Zendesk User Management Guide

• Model type: hybrid
• Description: Zendesk uses a base role system (End User, Light Agent, Agent, Admin, Account Owner) combined with optional custom roles for agents. Custom roles allow granular control over specific agent capabilities such as ticket deletion, user management, reporting access, and channel configuration. Admins always have full permissions and cannot be further restricted via custom roles.
• Custom roles: Yes
• Custom roles plan: Suite Professional ($115/agent/mo) and above
• Granularity: Custom roles offer per-feature toggles including: ticket access scope (all tickets vs. group tickets vs. assigned tickets), ability to delete tickets, ability to edit ticket properties, access to reports, ability to manage end users, ability to view and edit agent profiles, and access to specific channels and macros.

1. Sign in as an Admin or Account Owner.
2. Navigate to Admin Center → People → Team → Team members.
3. Click 'Add team member'.
4. Enter the new agent's name and email address.
5. Select a role: Agent or Administrator (and optionally a custom role if on Professional+).
6. Assign the agent to one or more Groups (optional but recommended).
7. Click 'Add team member' to send an invitation email.
8. The invitee must accept the email invitation to activate their account and set a password (unless SSO is enforced).

Required fields: Full name, Email address, Role (Agent or Administrator)

Watch out for:

• Adding an agent immediately consumes a paid seat even before the invitation is accepted.
• If the account has reached its seat limit, the 'Add team member' button will prompt an upgrade before allowing the addition.
• Invitation emails expire; if the invitee does not accept within the expiry window, an admin must resend the invitation manually.
• If SSO is enforced, the invitee cannot set a password via the invitation link and must log in via the configured identity provider.
• Agents are not assigned to any group by default; unassigned agents may not see tickets routed by group-based triggers.

• Can delete users: Verify in tenant
• Delete/deactivate behavior: This app exposes delete operations in its API documentation, but the admin-console path may present removal as deactivation, archiving, or deletion depending on tenant configuration. Confirm whether the UI action is reversible before treating removal as recoverable.

1. Sign in as an Admin or Account Owner.
2. Navigate to Admin Center → People → Team → Team members.
3. Locate the agent using search or filters.
4. Click on the agent's name to open their profile.
5. Click the 'Manage in Support' link to open their full profile in the Support interface.
6. In the agent's profile, click the dropdown arrow next to 'Edit' and select 'Downgrade to end user' to remove agent access, or select 'Suspend' to prevent all login.
7. Alternatively, from Admin Center, click the three-dot menu next to the agent and select 'Deactivate'.
8. Confirm the action when prompted.

Watch out for:

• Open tickets assigned to a deactivated agent are not automatically reassigned; they remain in an assigned-but-unworkable state until an admin manually reassigns them.
• API tokens belonging to the deactivated agent are not auto-revoked and must be manually invalidated to prevent unauthorized API access.
• If the deactivated agent was the sole member of a group, triggers and automations routing to that group will have no active agent to receive tickets.
• Permanent data deletion (e.g., for GDPR compliance) requires a separate formal request to Zendesk and is not achievable through the admin UI alone.
• Suspended end users cannot submit tickets; if an agent is downgraded to end user and then suspended, they lose all access including the Help Center.

• Where to check usage: Admin Center → Account → Billing → Subscription - displays current seat count, seats used, and seats available.
• How to identify unused seats: Zendesk does not provide a native 'last login' report in the standard admin UI for all plans. On Suite Professional and above, admins can use the Explore reporting tool to query agent activity. Alternatively, the Zendesk API endpoint GET /api/v2/users can return last_login_at timestamps for all agents, which can be exported and filtered to identify inactive accounts.
• Billing notes: Seats are billed per agent per month. Adding an agent mid-cycle results in prorated billing for the remainder of the billing period. Removing or deactivating an agent frees the seat but does not automatically reduce the contracted seat count on annual plans; seat count reductions on annual contracts typically require contacting Zendesk Sales at renewal. Month-to-month plans adjust seat counts at the next billing cycle.

Every admin also occupies a full agent seat - there is no admin-only seat type. If you add admin-only users without accounting for this, seat costs inflate silently across every app tier.

Adding an agent consumes a paid seat the moment the invitation is sent, before the invitee accepts. On annual plans, deactivating an agent frees the seat but does not reduce your contracted seat count; that requires contacting Zendesk Sales at renewal.

Identifying unused seats is not straightforward on lower-tier plans. Suite Professional and above can query agent activity via Explore. Below that tier, you need the API (GET /api/v2/users with last_login_at) to surface inactive accounts - there is no native last-login report in the admin UI.

The most consistent friction point reported by Zendesk admins is the absence of native SCIM for Zendesk Support.

SCIM exists only for Zendesk QA, a separate product, creating an inconsistency that forces Professional+ teams to rely on Okta or Entra ID API connector workarounds with additional configuration overhead.

Offboarding is the other recurring pain point. Deactivated agents' open tickets are not automatically reassigned, and API tokens belonging to deactivated agents are not auto-revoked - both require manual cleanup that is easy to miss.

Permanent data deletion for GDPR compliance requires a separate formal request to Zendesk rather than an admin UI action, which adds process overhead for compliance-sensitive teams.

Common complaints:

• No native SCIM provisioning for Zendesk Support; SCIM is only available for Zendesk QA (a separate product), creating inconsistency across the Zendesk product suite.
• Reliance on third-party IDP connectors (Okta, Entra) for automated agent provisioning, which requires Professional+ tier and additional IDP configuration effort.
• Deactivated agents' open tickets are not automatically reassigned, requiring manual cleanup that is easy to overlook during offboarding.
• API tokens for deactivated agents are not automatically revoked, creating a potential security gap that admins must address manually.
• No built-in 'last login' visibility in the admin UI on lower-tier plans, making it difficult to identify and reclaim unused seats without API access or Explore.
• Permanent user data deletion requires a separate formal request to Zendesk rather than being available through the admin console, complicating GDPR compliance workflows.
• Admins consume a full paid agent seat with no option for an admin-only seat type at a lower cost.
• Seat count reductions on annual contracts require contacting Zendesk Sales and cannot be self-served mid-contract.

Manual management is viable for teams with low agent turnover and fewer than a few dozen seats. The Admin Center UI is functional, but every offboarding step - ticket reassignment, token revocation, seat reclamation - requires deliberate manual action with no automated safety net.

For teams on Suite Professional or above with an existing IdP, the Okta or Entra API connector provides automated provisioning without native SCIM. For Suite Enterprise accounts, native SCIM is available and is the more reliable path for lifecycle automation at scale.

If your team spans multiple Zendesk products (Support, QA), treat each product's provisioning model separately - SCIM availability and configuration differ between them.

Bottom line

Zendesk's manual user management is workable but operationally demanding: seat consumption starts at invitation, offboarding leaves open tickets and live API tokens unless explicitly cleaned up, and seat reclamation on annual plans requires a Sales conversation rather than a UI toggle.

Every app in your stack that depends on accurate agent rosters will feel the downstream effects of a missed deactivation step. Teams below Suite Professional have limited tooling to audit seat usage without API access, making proactive hygiene harder to sustain as headcount changes.