Skip to main content
Open

Group Permissions like those for Community Module and Knowledge Base

Related products:CC Groups
  • February 11, 2021
  • 9 replies
  • 99 views
  • Annina

DannyPancratz

In the evolution of the Groups module, I’d love to see the permission settings match what’s available for other platform modules. Specifically being able to toggle access based on user roles. 

Private versus Public is a workable MVP, but permissions open up a more robust future. 

9 replies

  • Helper ⭐️⭐️⭐️
  • 732 replies
  • February 24, 2021
Updated idea status NewOpen

  • Helper ⭐️⭐️⭐️
  • 732 replies
  • February 24, 2021

@DannyPancratz thank you for your idea. With having permissions working like the community for groups, I'm guessing you would like to automatically add users to groups? What is your exact use case here?


DannyPancratz
Forum|alt.badge.img+7
  • Author
  • VIP ⭐️⭐️⭐️⭐️⭐️
  • 963 replies
  • February 24, 2021

Good question, @Marion Frecaut

A good first use case for us would be to have a “public” group but toggle off permissions to unregistered users. This would help dive logins if my assumptions are correct: unregistered users would see the group, but need to log-in to access it.

Our most likely use case for this would be in our “lounge” group for water cooler type conversations and community introductions. We chose groups because we want to show the group roster, align certain events to that group, and some of the other benefits groups provide. 

Eventually, a more complex use case for us is in the various personas we have in our community. We have customers, partners/consultants, and also the technology vendor themselves. We have ideas for a use cases that would make customer-only or partner-only groups … using a private group for that would be a lot more manual than a user role and group permissions. 

Related to that use case, we’ll likely have groups where we’ll want to give view/read access to some of those user roles, but perhaps limit if they can create new topics or reply. 

Ultimately, I know the community module offers these, and that this is a result of us choosing a group-heavy approach over community categories. (Our biz case for that choice is that showing the group roster and presenting more ways to showcase the people in our community and encourage peer-to-peer connections)


  • 0 replies
  • May 27, 2021

Yes! Being able to set role-based permissions on groups would help. Assuming that this would mean users would only see groups that are allowed with their role or custom role (as we do with categories and recommended topics). Added my vote.


  • Helper ⭐️⭐️⭐️
  • 732 replies
  • June 10, 2021

@DannyPancratz @Scott Baldwin we are considering an alternative to having visibility permissions for groups.

That alternative would be to have hidden groups that is visible to itsmembers only. So you would need to invite each members for them to see the group. Of course that would imply having a way to invite registered users to groups.

Would such groups solve your use case?


DannyPancratz
Forum|alt.badge.img+7
  • Author
  • VIP ⭐️⭐️⭐️⭐️⭐️
  • 963 replies
  • June 10, 2021

I personally like the toggles of other modules on the platform, but I can see how this would work as an improvement on the idea of private groups. 

The good thing about visible, but gated groups is that it allows and “inbound” type of applications to join the group. You can show people that have this exclusive group (good for enticing that pesona to want to join the community), while gating their access. (But the current challenge is that applications and approvals are pretty cumberson, as other ideas/topics articulate)

All that considered, hidden, invite-only groups are a similar path to the primary objective. 

 

Here’s why I’d prefer the permissions like other modules: 

We serve an audience of different company types: customers, partners, and Google Cloud employees. It's likely we’ll have a medium-term use case for a customer only group, and wouldn’t want to admit partners and/or googlers. 

Hidden groups that are invite only aren’t really a fit for this use case. We’d want every customer (custom user role) to have access, as opposed to a smaller invite list. And as new people in that role join, we’d want them to be able to join. In that scenario the full permissions scenario would be more ideal.  

Cc: @marissa.piazza, our new community manager, for context. 


anirbandutta
Forum|alt.badge.img+2
  • Expert ⭐️
  • 1804 replies
  • September 12, 2023
The following idea has been merged into this idea:

All the votes have been transferred into this idea.

anirbandutta
Forum|alt.badge.img+2
  • Expert ⭐️
  • 1804 replies
  • September 12, 2023

Primary/Custom Role based access, in addition to 1:1 approval and invitations enables including necessary teams for collaboration on a project in 1 click.

Picture the Google docs sharing experience, but for the Group container

 For e.g… having the Support team being able to Private and Hidden Betas is a big usecase.


jillian.bejtlich
Forum|alt.badge.img

Adding to this. We’re about to setup a beta group similar to what Gainsight uses, but during the early testing phase I’d like to be able to make it visible to only employees, then approved beta testers. And more importantly, I’d like for only employees to be able to post in the group (we’re allowing PMs to post about new betas and customers to sign up) and everyone to reply.

Current setup is just not allowing this. EEP!


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings