Custom permission levels and user overrides for spaces

When you create a custom permission level or a user override, you're designing exceptions to existing rules. Those exceptions could replace permission levels included by default, permission levels you've created, or one-off overrides for particular users.

For example, you might want to create a custom permission level for a group of people who should be the only ones to post to a space's blog. Or you might create a user override for a particular user who will be a space's administrator, managing its permissions, and creating spaces beneath it.

Fastpath: Admin Console: Permissions > Space Permissions Admin Console > Permissions > Spaces

When you create this kind of customization, your options are divided into three categories:

No access: Available for a user override only, this option lets you exclude a particular user from access to the space. This is designed as a user-by-user approach. To prevent access for a group of people instead, ensure that those people aren't included in groups that do have access. For example, to restrict access to a space that contains sensitive information, create a user group that contains people who should have access, taking care to leave out those people who shouldn't have it.
Access space: Available in custom permission levels and user overrides, this category provides fine-grained control with which you assign permissions specific to each content type. This is useful if you want to create a permission level that grants access to create discussion threads but only view documents.
Manage space: Available in custom permission levels and user overrides, this category provides a way to create administrative roles for the space. Each space should have an administrator, even if that role is inherited from a parent space. But typically, the roles available in this category go to very few people.

The following sections give details on the options available for each of the categories.

No Access

The user has no access to the space and is not able to see content from it.

Access Space

This category is used to grant custom content-specific access in the space. When you select this category while customizing, you have access to a list of the content types, each with a list of the access levels available for it. Choose an access level for each content type.

The following table lists the access levels that each content type permission level includes, along with the specific permissions each allows.

Table 1. Access Granted for Each Content Type Permission Level
Content Type Permission	View	Create	Reply	Comment	Rate	Vote
Create	✓	✓	✓	✓	✓	✓
Create (for discussions and questions)	✓	✓	✓	✓	✓	✓
Contribute	✓	Ø	✓	✓	✓	✓
View	✓	Ø	Ø	Ø	Ø	Ø
Advanced	See the specifics below

The Advanced access level for each content type provides even finer-grained control of permissions for a content type. After you select Advanced, select check boxes for the permissions which you want to be customizable.

The following table lists what's available in the Advanced level for each content type.

Table 2. Access settings available for each content type
Content Type	View	Create	Rate	Comment/Reply	Additional
External Object	✓	✓	✓	✓
Discussion and question	✓	✓	✓	✓
Poll	✓	✓	✓	✓	Vote
Blog Post	✓	✓	✓	✓
Document	✓	✓	✓	✓
Video	✓	✓	✓	✓
Content share	✓	✓	Ø	Ø
Idea	✓	✓	✓	✓
Event	✓	✓	✓	✓	Insert Image

The following options are also available for customization.

Table 3. Additional access settings
Option	Access Granted
Create Project	Create a project in the space
Create Announcement	Create an announcement in the space

Manage space

Use this category to assign administrative roles that are specific to the space. The following table briefly describes the available access levels with more details provided below.

Table 4. Manage space settings
Option	Access Granted
Full Control	Customize the space overview page, edit space details, delete any space content, create subspaces, manage permissions for that space, delete the space, create a category, and manage the space blog
Moderate	Moderate and edit all content in the space. Selecting this option enables the moderation queue for all content in the space

Full Control

Someone with full control has access to administrative features for the space, along with any sub-spaces beneath it. A space administrator can create sub-spaces, set content defaults, and set permissions for the space. They can see content that is in a moderator queue but hasn't been approved yet. They can designate other space administrators.

Moderate

Granting moderator permission gives someone two areas of access:

A content moderator can approve or reject content before it's published. When moderation is on for the place in which the place was created (such as the space, social group, or globally), the content moderator for that place is able to accept or reject the content in a moderation queue. Setting this up involves not only assigning content moderation permission, but also turning on moderation for those kinds of content you want to be moderated. Note that this ability is not inherited in sub-spaces; the moderator can approve or reject content only in the place where they've been assigned permission.
A content moderator has access to certain links for handling content after it is published. Through these, they can manage content by editing, moving, and deleting it as the need arises. For example, a content moderator might lock a discussion thread that is no longer useful or move a document to another space. These abilities are inherited by sub-spaces of the space in which the permission is granted.

Note that as a fail-safe to ensure that moderated requests always have a place to go, new requests are routed in the following order:

If content would be moderated at the sub-space level but there's no moderator there, it goes to the system moderator's queue.
If content would be moderated at the system level but there's no moderator there, it goes to the system administrator's queue.

This applies to new requests only. For example, if a request is in the queue when moderators are removed, the requests remain in the queue until someone approves or rejects them there. Existing requests are not be routed to the next queue up. If there's only one moderator and that user is deleted from the system, then requests currently in the queue will be orphaned even after a new moderator is assigned to that area. If moderation permissions are revoked for someone, then that user will still have access to the requests currently in the queue but won't be able to approve or reject them.

Note that in order to have moderators approve and reject content in a moderation queue, moderation needs to be enabled for specific content types. For more information, see Moderation.