Managing Permissions

A system admin can grant permissions to users for access to content and administrative features.

When assigning permissions, you follow these basic steps:

Create user groups that capture how you want to grant access to the community's features. Each user group you create can represent a different category of people, from a permissions perspective. You might have user groups for administrators, managers, moderators, bloggers, people in the HR department, people in the Products department, and so on. You create user groups based on how you want to structure access to your community's features.
Add user groups to the different areas in the Admin Console: administration, spaces, social groups, blogs, and home page. For each group you add, assign permissions that capture that group's access.
Assign permissions in one of the following ways:
- Assign a permission level. For administrative permissions and in spaces, you can use permission levels to assign bundled access permissions. You can also create your own space permission level.
- Assign one or more access permissions. For blogs, social groups, and the rest, you work in a more a la carte way, assigning access by choosing from a list of usually fine-grained options.
- Create a user override for special cases. For example, you might want all but one or two people in a particular user group to have the permissions you assigned to the group. For those one or two, you can create a user override that assigns specific exceptions.

Permission Areas

Permission areas represent a mix of roles, places, and content types. Each permission area exposes its own set of permissions that are based on what you can do in the area. When you add user groups to an area, you assign access from among the permissions that the area offers. The permission areas include:

Administrative -- administrative and moderation permissions through which people have access to system-wide settings. Most of these provide access to the Admin Console. With the exception of the Full Access permission level, these don't provide access to content.
Space -- per-space permissions for administering or moderating the space, as well as for working with content there.
Blog -- permissions related to global blogs (such as system and personal blogs) to view and create blogs, comment on global blog posts, and so on.
Social group -- permissions to view and create social groups, as well as work with attachments and images in content there.
Home page -- permissions to create and interact with content that can appear on the communities home page and in the user container, including announcements, polls, videos, and updates.
Mobile -- permission to access the community from a mobile device, such as an iPhone.

For two of the areas -- administrative and space permissions -- the permissions are bundled into permission levels to make managing permissions for the area easier. In both of these areas, communities tend to set permissions along a similar set of themes. The permission levels are designed to reflect those themes.

Note: You can't break out the bundled permissions in the administrative area as you can with space permissions.

Keep in mind that there are a few exceptions in the permissions model. For example, the "blogs" area applies only to global blogs, such as system blogs and personal blogs (neither of which belong, strictly speaking to a place). This leaves out blogs in spaces, social groups, and projects, whose permissions are managed in different ways as described in Managing Blog Permissions.