Summary and recommendation
Clay 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.
Clay is a credit-based data enrichment and prospecting platform built around shared workspace access. User management lives entirely in Settings → Team, and the permission model is intentionally minimal: two roles, one shared credit pool, no per-table or per-workflow access controls.
Every app in your stack that relies on Clay-authenticated integrations is affected when a member is added or removed, so offboarding requires more than just revoking a seat.
Quick facts
| Admin console path | Settings → Team (within the Clay workspace) |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Admin | Full workspace access: invite/remove members, manage billing, configure SSO/SCIM, access all tables and workflows, manage integrations. | All paid plans | Included in plan seat count; each seat consumes from the plan's shared credit pool. | Only Admins can manage billing and SSO settings. At least one Admin must remain in the workspace. | |
| Member | Create and edit tables, run enrichments, use integrations, view shared workflows. Shares the workspace credit pool. | Cannot manage billing, invite/remove other users, or configure SSO/SCIM settings. | All paid plans | Each additional seat added to the plan; pricing varies by plan tier. All seats share the workspace credit pool. | All members draw from the same shared credit pool; there is no per-seat credit allocation or usage cap per user. |
Permission model
- Model type: role-based
- Description: Clay uses a two-role model (Admin and Member) at the workspace level. All members share a single credit pool. There are no granular per-table or per-workflow permission controls documented publicly.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Workspace-level only; no documented row-, table-, or field-level permissions.
How to add users
- Navigate to Settings → Team in the Clay workspace (https://app.clay.com/settings/team).
- Click 'Invite Members'.
- Enter the invitee's email address.
- Select the role (Admin or Member).
- Click 'Send Invite'. The invitee receives an email to accept and join the workspace.
Required fields: Email address, Role (Admin or Member)
Watch out for:
- Invitees must accept the email invitation before they appear as active members.
- Adding members increases seat count and may affect billing depending on plan limits.
- All members share the workspace credit pool; adding users does not add credits.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: Admins can remove (revoke access for) members from the workspace via Settings → Team. Removal revokes login access immediately. Clay's documentation does not clearly distinguish between a soft deactivate and a hard delete; removal appears to be a permanent revocation of workspace access.
- Navigate to Settings → Team (https://app.clay.com/settings/team).
- Locate the member to remove.
- Click the options menu (ellipsis or 'Remove') next to the member's name.
- Confirm removal. The user loses workspace access immediately.
| Data impact | Behavior |
|---|---|
| Owned records | Tables and workflows created by the removed user remain in the workspace and are accessible to remaining Admins. |
| Shared content | Shared tables and workflows are unaffected and remain accessible to other members. |
| Integrations | Integrations authenticated under the removed user's personal credentials may stop functioning and require re-authentication by an active member. |
| License freed | Removing a member frees the seat, which may reduce the billed seat count at the next billing cycle depending on plan terms. |
Watch out for:
- Integrations connected via the removed user's OAuth tokens may break and require reconnection.
- Clay does not publicly document a 'deactivate without delete' option; removal appears to be the only offboarding action.
- Seat count reduction timing at billing is not explicitly documented in public help content.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Free | 1 user, 100 credits/month, limited enrichment providers. | $0/month |
| Starter | Shared credit pool of 24,000 credits/year, 5,000 people/company searches, multiple seats (exact seat limit not publicly specified). | $134/month (annual) or $149/month (monthly) |
| Explorer | Shared credit pool of 120,000 credits/year, 10,000 searches, webhooks, multiple seats. | $314/month (annual) or $349/month (monthly) |
| Pro | Shared credit pool of 600,000 credits/year, 25,000 searches, CRM integrations, multiple seats. | $720/month (annual) or $800/month (monthly) |
| Enterprise | Custom credit volume, 50,000 company searches, SSO (Okta/Entra ID), SCIM provisioning, dedicated support, custom seats. | $30,000+/year (custom) |
- Where to check usage: Settings → Billing or Settings → Usage within the Clay workspace to view credit consumption and remaining credits.
- How to identify unused seats: No documented per-user activity report or last-login visibility in public help docs. Admins would need to manually track member activity or review table/workflow ownership.
- Billing notes: Clay uses a credit-based model where all workspace members draw from a shared pool. Credits do not roll over between billing periods. Seat count affects plan cost; exact per-seat pricing for multi-seat plans is not publicly listed and may require contacting sales. Enterprise pricing is custom and negotiated.
The cost of manual management
Clay's credit pool is shared across every member in the workspace, with no per-user caps or usage limits. Credits do not roll over between billing periods, so unmanaged member activity can drain the pool before the cycle ends.
There is no documented last-login report or per-user activity view, which means identifying inactive seats requires manual tracking of table and workflow ownership. Seat count changes may affect plan cost, but exact per-seat pricing for multi-seat plans is not publicly listed.
What IT admins are saying
Practitioners consistently flag two friction points: credit burn and access opacity. The shared pool model means a single active member running large enrichment jobs can exhaust credits for the entire team.
The two-role model (Admin and Member) offers no middle ground - there is no read-only role or table-scoped permission to limit exposure to sensitive workflows.
Integrations authenticated via a removed user's OAuth tokens can silently break, requiring manual reconnection across every app that depended on those credentials.
Common complaints:
- Costs can scale up quickly without discipline on credit usage.
- Credits do not roll over between billing periods, leading to wasted spend at period end.
- No per-user credit caps or usage limits, making it difficult to control individual member spend.
- Limited role granularity (only Admin and Member) makes it hard to restrict access to sensitive tables or workflows.
- Integrations authenticated by a removed user can silently break, requiring manual reconnection.
- Lack of a last-login or per-user activity report makes it difficult to identify inactive seats.
The decision
Clay is a strong fit for revenue and growth teams that need high-volume enrichment with flexible data sourcing. The manual user management overhead is low for small teams but grows proportionally with headcount, especially without per-user activity visibility. SSO via Okta or Entra ID is available on Enterprise, which reduces provisioning friction at scale.
Teams below Enterprise tier should plan for manual seat audits and establish internal credit governance before expanding workspace access.
Bottom line
Clay's workspace model prioritizes enrichment flexibility over access control granularity. Every app or workflow connected through a member's OAuth credentials becomes a dependency to manage at offboarding.
For teams on Starter through Pro, user lifecycle management is entirely manual and requires discipline around credit monitoring, seat audits, and integration ownership.
Enterprise buyers gain SSO as a partial mitigation, but SCIM automated provisioning is unconfirmed in official documentation, so headcount-driven provisioning workflows should be validated with Clay's sales team before committing.
Automate Clay 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.
