Introduce "Explicit Deny" Override for Community Permissions (Moving Beyond All-or-Nothing Roles)
Objective / Summary
Currently, Gainsight Community permissions (Category Visibility, Create Topics, Create Replies) operate on an additive basis. If you want to hide a category from just one specific custom role, you have to completely disable permissions for the baseline "Registered User" role and manually enable them for every other custom role. We need an Explicit Deny override capability to easily restrict specific roles without rebuilding the entire permission matrix.
The Problem
Because permissions are strictly additive, the default "Registered User" role acts as a catch-all. If "Registered User" has visibility checked, everyone sees it.
If we have 10 custom roles and want to hide a category from just one of them, the current workaround requires us to:
-
Uncheck visibility for the "Registered User" role.
-
Manually check and manage visibility for the other 9 custom roles.
This creates massive administrative overhead, increases the risk of human error during configuration, and makes scaling user roles incredibly tedious.
Proposed Solution
Introduce an Explicit Deny (or block) option alongside the existing checkboxes.
-
How it would work: Keep the baseline access enabled for "Registered Users," but allow admins to select a specific custom role and explicitly check a "Deny/Hide" box.
-
An explicit Deny should always override a baseline Allow, instantly hiding the category, topics, and replies for that specific segment without impacting the rest of the community.
Business Value / Impact
-
Simplified Access Management: Reduces configuration time from hours to seconds when managing complex, multi-tiered community access (e.g., hiding partner content from competitors, or internal content from customers).
-
Scalability: Allows teams to scale custom roles dynamically without having to re-architect category permissions every time a new role is introduced.