Cognism User Management Guide

• Model type: role-based
• Description: Cognism uses a two-tier role model: Admin and User. Admins control all team and billing settings; Users have access only to prospecting and data features. No custom roles or granular permission sets are documented in official help content.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Coarse - two fixed roles only. Admins can set per-user credit/export limits, which is the primary lever for differentiating user access within the User role.

1. Log in as an Admin and navigate to Settings → Team Management.
2. Click 'Invite User' or 'Add User'.
3. Enter the new user's email address.
4. Assign a role (Admin or User).
5. Optionally set a credit/export limit for the user.
6. Click 'Send Invite'. The invitee receives an email to set their password and activate their account.

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

Watch out for:

• Adding a user consumes a paid seat immediately upon invitation acceptance; confirm available seats before inviting.
• If SSO is enforced, new users must authenticate via the configured IdP (Okta) and cannot use password login.
• Cognism does not publicly document a self-service seat-expansion flow; adding users beyond contracted seats may require contacting the account manager.

• Can delete users: No
• Delete/deactivate behavior: Cognism's documented user management supports deactivation (revoking access) rather than permanent deletion of user accounts. Deactivated users cannot log in but their account record and associated data remain in the system. No permanent delete option is documented in official help content.

1. Log in as an Admin and navigate to Settings → Team Management.
2. Locate the user in the team list.
3. Click the options menu (three dots or similar) next to the user.
4. Select 'Deactivate' or 'Remove User'.
5. Confirm the action when prompted.

Watch out for:

• If SCIM provisioning is active via Okta, deprovisioning the user in Okta will automatically deactivate them in Cognism; manual deactivation in Cognism is still possible but may conflict with IdP state.
• Seat release timing after deactivation relative to billing cycle is not explicitly documented; confirm with Cognism account manager for mid-cycle changes.
• No documented self-service account deletion for end users; removal must be performed by an Admin.

• Where to check usage: Settings → Team Management (shows active users and seat count); Settings → Usage or Analytics (shows credit consumption per user, if available to Admin)
• How to identify unused seats: Admins can review last-login dates and export/credit usage per user in the Team Management section to identify inactive seats. No automated idle-seat alerting is documented.
• Billing notes: Annual contracts only; no monthly billing option. Platform access fees are charged separately from per-seat fees. Seat counts and tier (Platinum vs. Diamond) are set at contract time. Mid-contract seat additions may be prorated; reductions typically take effect at renewal. Pricing is custom and negotiated; published figures ($15K/$25K access fee, $1,500/$2,500 per seat) are indicative and subject to change.

Cognism's seat structure separates a platform access fee from per-seat fees, and neither Platinum nor Diamond seats can be reduced mid-contract without engaging the account manager. There is no bulk CSV import; each user must be invited individually through the admin console.

Credit limits must be set manually per user - there is no policy-based allocation or automated idle-seat alerting.

Practitioners consistently flag two friction points: SCIM provisioning is limited to Okta as the sole supported IdP, leaving teams on Microsoft Entra ID, Google Workspace, or OneLogin without an automated provisioning path.

The fixed two-role model is also cited as a constraint for larger teams that need more granular access control. Seat cost inflexibility on annual-only contracts rounds out the most common complaints.

Common complaints:

• Limited IdP options for SCIM provisioning - only Okta is officially supported, with no documented support for Microsoft Entra ID, Google Workspace, or OneLogin.
• No bulk CSV import for users; each user must be invited individually through the admin console.
• Only two fixed roles (Admin and User) with no custom or granular role options, limiting access control flexibility for larger teams.
• Seat cost and contract structure (annual only, separate access fee plus per-seat fee) reported as inflexible for teams that need to scale up or down mid-year.
• Credit/export limits must be manually set per user by an Admin; no automated or policy-based allocation documented.
• No self-service account deletion for end users; all user removal must go through an Admin.

Every app in a provisioning workflow needs a clear answer on IdP compatibility - for Cognism, that answer is Okta only at the Enterprise tier. If your organization needs Entra ID or Google Workspace SCIM, granular permission tiers, or mid-year seat flexibility, the current platform imposes real operational limits.

Admins should audit last-login and per-user credit consumption in Team Management regularly, since no automated alerting exists for inactive seats.

Bottom line

Cognism's user management is functional but deliberately minimal: two roles, Okta-only SCIM, annual contracts, and manual per-user credit configuration. Every app in a sales stack demands some provisioning discipline, but Cognism's constraints make that discipline entirely manual unless Okta is already in place.

Teams without Okta or with complex access-control requirements should factor in the ongoing admin overhead before committing to an Enterprise contract.