G2 User Management Guide

• Model type: role-based
• Description: G2's seller portal uses a role-based model with at minimum an Admin role and standard user/team member roles. Granular custom role creation is not publicly documented.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Coarse; role assignments control broad access areas (profile management, analytics, integrations). Field-level or object-level permissions are not publicly documented.

1. Log in to my.g2.com with an Admin account.
2. Navigate to Settings → User Management.
3. Click 'Invite User' or equivalent button.
4. Enter the invitee's email address and assign a role.
5. Send the invitation; invitee receives an email to accept and set up access.

Required fields: Email address, Role assignment

Watch out for:

• Professional plan limits total admin users to 10; inviting beyond this limit requires an Enterprise plan.
• Invitations may expire if not accepted within a set window (exact duration not publicly documented).
• SSO must be configured separately; invited users on SSO-enabled accounts may need IdP-side provisioning.

• Can delete users: Unknown
• Delete/deactivate behavior: G2's public documentation does not clearly distinguish between deactivating and permanently deleting a user from the seller portal. The available action appears to be removing/revoking access rather than a hard delete. Exact data retention behavior post-removal is not publicly documented.

1. Log in to my.g2.com with an Admin account.
2. Navigate to Settings → User Management.
3. Locate the user to be removed.
4. Select the option to remove or revoke access for that user.
5. Confirm the action.

Watch out for:

• No public documentation confirms whether removed users can be re-invited without data loss.
• Integration credentials or API tokens set up by a removed user may break if tied to that user's account.
• SCIM-based deprovisioning behavior is not publicly documented for G2.

• Where to check usage: my.g2.com → Settings → User Management (shows current users and seat consumption)
• How to identify unused seats: No publicly documented automated tool for identifying inactive users. Admins must manually review the user list and last-login data if available.
• Billing notes: G2 is an annual contract product. Seat limits are enforced at the plan tier level rather than per-seat billing. Q4 negotiations have historically yielded 43–49% discounts. Add-ons (Buyer Intent, G2 Demand, Review Growth) significantly increase total contract value and are priced separately.

Because G2 does not expose user provisioning through its public API, every app in your stack that relies on G2 seller access must be managed manually through the admin UI at my.g2.com → Settings → User Management.

There is no automated way to sync identity changes from your IdP to G2 outside of an Enterprise SSO configuration - and even then, SCIM auto-provisioning is unconfirmed in public documentation.

When a team member is removed, integration credentials or API tokens tied to that user's account may silently break. No public documentation confirms whether removed users can be re-invited without data loss, which adds operational risk to every offboarding action.

The 10-admin cap on the Professional plan is the most frequently cited friction point among mid-size teams that need broader internal access without committing to Enterprise pricing.

Procurement teams also flag the opacity around what Enterprise actually unlocks - unlimited admins and potential SCIM support are not publicly documented, requiring direct sales engagement to confirm.

SSO and SCIM configuration details are absent from public-facing documentation, which makes pre-purchase evaluation difficult. Users also report uncertainty about what happens to data and connected integrations when a team member is removed from the portal.

Common complaints:

• Admin seat cap of 10 on Professional plan is frequently cited as a friction point for mid-size teams that need broader internal access without upgrading to Enterprise.
• Lack of transparent public documentation on user roles and permissions makes pre-purchase evaluation difficult.
• SSO and SCIM configuration details are not publicly documented, requiring direct engagement with G2 sales or support to understand provisioning options.
• Users report difficulty understanding what happens to data and integrations when a team member is removed from the portal.
• Pricing opacity around Enterprise user management features (unlimited admins, SCIM) is a common complaint in procurement discussions.

If your team has fewer than 10 people who need admin access to the G2 seller profile, the Professional plan is operationally sufficient for manual user management. Keep in mind that every app connected to G2 through a team member's credentials becomes a manual cleanup task the moment that person leaves or changes roles.

If you need broader internal access, SSO, or any form of automated provisioning, you are looking at an Enterprise contract at custom pricing.

Q4 negotiations have historically yielded 43–49% discounts on G2 contracts, which is worth factoring into timing. Add-ons - Buyer Intent, G2 Demand, Review Growth - are priced separately and can significantly increase total contract value beyond the base list price of ~$15,000/year.

Bottom line

G2's seller portal is a manually managed environment with a coarse role model, a hard admin seat cap on Professional, and no publicly confirmed path to automated provisioning short of an Enterprise SSO arrangement.

Every offboarding action carries integration risk because API tokens and credentials are tied to individual user accounts with no documented cleanup behavior.

Teams that need more than 10 admins, want SSO, or expect SCIM support must engage G2 sales directly - none of those capabilities are self-serve or publicly documented at the time of writing.