Communities and Spheres
For organizations that have an existing deployment of Aurea Social, you can certainly leverage existing communities for the purpose of messaging employees using this solution.
To fully benefit from these new capabilities however, NewsGator recommends that new communities be created to provide key channels of communication for segments of your employees.
The purpose is so that communications managers can better control membership of the communities for messaging. You wouldn’t let end users decide today what key email distribution lists they are part of for important communications; the same holds true for this solution.
For this reason, it’s recommended that these new communities be configured using SharePoint audiences to control membership and disabling the follow controls.
Onboarding and back office HR processes should be updated to ensure employees are always subscribed to the right communities.
Refer to the Aurea Social Admin Guide for details on how to use SharePoint Audiences to manage a community’s membership.
The following are considerations when setting up these communities/spheres:
- Community Vs. Sphere
- Do you want to keep it admin only for posting messages
- Do you need to store attachments
- Public Vs. Private Security
- Title
- Read Only
- Disable Follower Controls
- Discoverability
The main consideration for spheres versus communities is in regards to two things:
The biggest implication for point one, is that if you create the group as ready only, spheres can only have one admin with the ability to post.
With regards to attaching content (images, docs, etc.), attachments posted to the stream on private spheres winds up in a publicly accessible document library. While the first release of Internal Communications Solution doesn’t support attachments from the admin console, the capability is intended to appear in a near release.
The key thing to understand for public versus private groups, is whether messages in the group in question should be seen by people who are not members. If it’s a group for management, the answer is likely no. If the group is more casual or open in nature, public is best.
Public is recommended for most groups simply because you should not target a private community and a public community (this makes the post public). If you have a large amount of private communities, you could wind up having to create many instances of the same message, which makes it more difficult to manage.
Private communities should never grow to more thank 5k users as this is not scalable per SharePoint software boundaries.
The title should, as clearly as possible, let the members know the purpose of the group. Providing a more creative title is ok as long as it’s easy to understand derive why you are part of the community being targeted.
Setting a group read only means that only the group owner can post to the community. Since the person tile can now filter by communities you are a member of (a key configuration when setting up the Internal Communications Tile), it is ok to give others the ability to post to official communities. It won’t flood the official tile with noise because of how the tile is setup.
Keep in mind that spheres can have only one owner, so making it read only means that only one user has the ability to post. Additionally, read only does not mean that users cannot comment, like, etc. You need to lock the post to prevent commenting.
It is highly recommended that you disable the ability to follow / leave a group that is used for corp comm messaging. Membership should be handled by the syncing of audiences only so that messaging is guaranteed to go to the right employees.
Discoverability should be turned off unless users are allowed to follow the group without being in the correlating audience. This prevents these communities and spheres from crowding the other groups in Aurea Social community discovery web parts.