Skip to main content

Primary vs. Custom Roles: How are you setting up your internal team?

  • April 7, 2026
  • 2 replies
  • 22 views

NEOGOV Tom

Hi everyone,

I’m currently reviewing our user role architecture for the NEOGOV Success Community, and I’d love to get a "pulse check" on how other community teams are handling roles for their internal staff (Community Managers, Admins and general Employees).

In the Gainsight CC world, we have Primary Roles (the baked-in foundations) and Custom Roles (the surgical layers). 

Common wisdom suggests that even for internal staff, we should keep the Primary Role as "Registered User" and then layer a Custom Role (e.g., "Employee" or "Admin") on top. The logic I'm leaning toward is:

1.  Reporting: It's much easier to filter out internal noise from customer engagement data if we use a Custom Role for staff.
2.  Permission Precision: Using Custom Roles seems to offer more "surgical" control over who can moderate what, without giving everyone the full keys to the Control Environment.


My question for the group: Do you set your Community Management team’s Primary Role to "Administrator" or "Registered User"? 

Looking forward to hearing how you’ve structured your ecosystems!

2 replies

mitchell.gordon
  • Helper ⭐️⭐️⭐️
  • April 7, 2026

I only give Admin to a handful of users who need and use backend access to the platform. I use custom roles attached to gamification ranks to distinguish internal vs external users. Below is an example of an employee vs an admin inside of my community. 

You are correct on being surgical with permissions within the backend with custom roles. Giving you custom roles is helpful as well if you build an internal only community space or if you want to rest new pages. You can give only employees access this way to test things out before going fully live with a page.


atwhite
Forum|alt.badge.img+1
  • Helper ⭐️⭐️⭐️
  • April 8, 2026

We do the exact same thing: Primary roles for administrators (very few) and registered users (essentially everybody else), with a Custom role specifically for Employees. 

Among non-employees, customers (and others) get assigned other Custom roles based on which products they use, and we control content access accordingly.