The Role of Segmentation for Your Community Communities, online and offline, are diverse and complex structures — continue reading
The Role of Segmentation for Your Community
Communities, online and offline, are diverse and complex structures that we can categorize in different ways. You can look at your community from an engagement perspective which splits users into groups depending on their contribution level. Alternatively, you can look at them from a functional level: what role someone has.
These are just two of the many ways to categorize your community members.
These segmentations allow community managers to understand the working of their community better. They determine how each user interacts with the community and what they are doing, and what content, tools, and rights they need to contribute to a community.
Most of these segmentations can be applied simultaneously, creating an exceptionally diverse and complex structure within communities. The role and rights might even change based on other segmentation variables as people wear different hats and act differently in different situations.
We translated this complexity of communities into Open Social to ensure community managers have all the tools they need to create a digital space for their community that represents all the granularity that the offline world has.
What are Role-based Permissions?
A role-based permission system makes it possible to determine who can see what and perform what action in which context. A role consists of a specific set of permissions that define how a member accesses your community platform.
Within Open Social, we differentiate in general between a few basic permission types:
- View
- Create
- Edit
- Delete
We can create permissions for each entity (e.g., events, groups, blogs) and further specify these permissions by context. It is, for example, possible to add separate permission to create content based on the membership within a group or if a user can comment within an event based on their involvement in this event.
We can then create roles by defining a set of permissions for each context within the community.
As you can see, this can get complex quite fast so, with Open Social, we predefined the following roles with accompanying permissions:
- Anonymous user: Users who have not logged in. They are not allowed to perform actions on the platform. They only have limited access to public content and cannot see member profiles.
- Authenticated or logged-in user: Users who have registered for the platform. They can comment, edit or create content, events, or groups. They can also join other groups and events.
- Content manager: Users in charge of the daily operation of the platform. They can delete and unpublish any content, posts, comments, and groups. Editing content is limited to guarantee that editorial rights remain with the content’s original author.
- Site manager: Users in charge of the configuration and management of the platform and can manage all user accounts.
- Group Manager/Event Manager: When a logged-in user creates a group or an event, they automatically become the group or event manager. They get extra permissions related to member management in the group or event.
Why are Access Permissions Important for Community Building?
Standard role-based permissions only cover the very basics of a community’s member segmentation. As discussed previously, a community is much more complex than this. As most are grown organically, they have different definitions of a community manager and what kind of specialized roles they need.
This need for specialization grows with the size and complexity of the community. At a certain point, it might be necessary to
- split between content and people managers,
- create domain-specific community managers,
- have regional moderators, etc.
The variations and how the permissions in these functions are split are as diverse as communities themselves.
Supporting Community Owners in Accommodating Their Needs
We added more diverse roles that allow for specialized functions within the communities to facilitate this complexity.
An excellent example of these specialization roles is the Taxonomy manager. We realized that in larger organizations, not all community managers are tasked to manage the whole community but are usually domain experts who only focus on their specific area of expertise.
Based on this insight, we added the possibility to give out community management rights to people for only a specific topical area of the community, defined by taxonomies.
A user with community management rights for one or more taxonomies can now edit, unpublish, or change authoring information for all content or groups with this taxonomy.
We added a few more variations as group and event content managers to separate the content vs. the people management of these spaces. Segment managers can manage people based on the segment they belong to and moderators with specific rights within discussions.
Nevertheless, the more we worked with big-scale communities and created their digital spaces, the more we realized that we could not anticipate all variations.
For that reason, we made two relevant changes within the structure of Open Social that allow owners of the community to accommodate their needs:
- Custom Roles & Content access
- 0-permission user
Custom Roles & Content access
These two features, summarized in the Customized Content Access extension, allow site managers to create new roles within their community with custom permissions and then define the content and group access based on these roles. This way, you can create a new role, for example, ‘Staff only’, and create a second layer within the community.
The ‘Staff only’ role can have additional permissions, such as editing content or approving the membership of groups, etc.
With the content access, you can now select the ‘Staff only’ role as a visibility option for a blog you created, and only people with this role can access the content.
With minimal effort, you will have created a sub-community within the community where people you trust have more rights and can see additional internal content.
This way, you can create multiple circles within a community representing the closeness and rights people have connected to projects and organizations in real life.
0- permission users
The most significant limitation of this system was that Open Social is by default very inclusive and allows logged-in users to create and view most of the content. For a community, transparency, inclusivity, and trust are fundamental pillars.
There are quite a few instances where you do want to restrict permissions for the general audience of your community.
We see, for example, that a lot of our clients wanted to limit group creation for normal logged-in users as wild growth in groups leads to siloing of the community and a diminished engagement within it.
To accommodate this, we created a new optional default role: the 0-permission users. Users with this role still have permissions, but they are limited to the same ones as public or not-logged-in users have.
That means they can see public content, navigate the site but cannot add content, join groups, events, interact in any other way with other members, or be found by other members of the community.
The only additional permission they have is to fill out their profile so the community managers can identify the user.
This radical reduction in the base permission now builds the foundation so that site owners can customize the default user role they need for their community.
More Applications for Community Owners
These changes also solve other problems within the community space:
Monetization
With the new membership payment extension, we apply these reduced roles by default. This way, community managers can build different tiers of membership that allow users to engage differently with the community and connect the roles automatically with a payment process in the community.
For example, a community can have a free tier where people can only interact with other members and a paid membership that allows them to create content on their own.
Spam Prevention
Another application is spam prevention. The system does not verify new accounts by default, and those unverified users can’t create content. Only when the community managers approve a user and give them a new role will they be able to engage with the community. This will ensure spam content can’t be created.
Trusted User / Information Density
Lastly, creating an unverified user role can help with the security and perceived maturity of the community. New, unverified users without an up-to-date profile are filtered out of overviews.
The sense of security and belonging are paramount to a community’s success. For the latter, it takes a massive amount of effort from community owners to make sure members feel like they belong.
However, community owners rely on community software features for the former: “sense of security”. One crucial way of instilling that sense of security is to make sure the users don’t come across spam content, their profiles are not hacked into, and so on. Community owners can only achieve this by creating access layers so that only authorized individuals can access certain parts of the platform.
Are you interested in learning more about Open Social and community building trends? Subscribe to our newsletter to stay in the know.
