Feature Enhancement Request: Group-Based Account Access Provisioning in Gainsight CS

Summary

Please add support for group-based account access provisioning in Gainsight CS so admins can assign users to reusable groups and provision account access at the group level instead of managing account visibility one user at a time.

Current Limitation

Today, account-scoped access is administratively heavy when multiple users need the same access pattern, because access has to be provisioned and maintained user by user. From an admin perspective, this does not scale well for partner teams, regional coverage models, overlays, or any scenario where users should inherit the same account access pattern.

This is especially important for use cases where users must only see the specific customer accounts they manage and have no visibility into the broader account list.

Requested Enhancement

Please provide a native way to:

• Create reusable user groups or access groups within Gainsight CS

• Assign a defined set of accounts to a group

• Add users to that group so they automatically inherit access to the accounts in scope

• Remove users from that group and automatically revoke inherited account access

• Support different access levels by group, such as view-only vs edit access

• Preserve least-privilege boundaries so users cannot browse or search accounts outside their assigned scope.

Why This Matters

Gainsight appears to already support account-level isolation as a control, and that control is critical for secure segmented access models. However, when that access model must be maintained manually one user at a time, it creates unnecessary operational overhead and makes the model harder to scale consistently.

For example, in our environment we need scenarios where a subset of users should only be able to work specific managed accounts, while still being restricted from admin functions, bulk export, connectors, API access, Journey Orchestrator, and broad report-building capabilities.

Example Use Cases

• External partners or contractors who manage only a subset of customer accounts

• Internal teams that should only access named books of business

• Regional or segment-based user cohorts

• Temporary project teams that need access to a shared subset of accounts

• Future-state permission models where access should be managed by role + group membership rather than repeated manual account assignment

Business Impact

A group-based model would:

• Reduce admin time and repetitive manual provisioning

• Improve scalability as user counts and segmented access needs grow

• Lower the risk of inconsistent or missed access assignments

• Make onboarding and offboarding easier

• Better support secure account-level isolation for partner and segmented-access models

Desired Outcome

We would like Gainsight CS to support a scalable, admin-friendly permission model where account visibility can be managed through reusable groups instead of requiring one-by-one user provisioning for the same account set.