Introduction
User permissions let you control which users can access resources, such as data and applications, but it also specifies what tasks users can perform. We recommend assigning permissions based on groups, but this isn't always as easy as it sounds.
In this article we will talk about how to get your user groups into Workspace 365, the three main access levels, the different kind of roles and what they entail. Furthermore, we will talk about group permissions and how to avoid permission conflict.
Sync user groups
Groups are a convenient way to grant or revoke the same permissions to multiple users at once, rather than individually for each member of the group, without modifying the permissions.
There are two options to get your user groups into the Workspace environment:
(Recommended) Import user groups automatically from Microsoft Entra ID (previously called Azure AD) to Workspace 365:
Automated user provisioning via SCIM. (Recommended)
Automated user provisioning via our Azure AD synctool.
Create user groups manually. (Possible but strongly discouraged)
Access levels and their visibility
Once your user groups are in place, you can grant access permissions on three levels:
Level 1: Shared space(s) - by default, everyone has access
Level 2: Shared tile group(s) - by default, nobody has access
Level 3: Apps/tile(s) - by default, everyone has access*
*All users will have permissions for the default apps in Workspace, like the Documents app, Email app and Online Editor apps. For these default apps, permissions cannot be set. For non-default apps, permissions must be assigned.
As a Workspace administrator, you can create Shared spaces (1). You can determine the visibility of these Shared spaces; visible to everyone or just selected users and/or groups. When the Shared space is created, you add Shared tile groups (2) to it. And within these Shared tile groups, you can add applications and tiles (3). You can determine who has access to Shared tile groups within these Shared spaces and manage access to specific apps/tiles inside the Shared tile groups.
We recommend setting permissions as high as possible, thus on Shared spaces and Shared tile groups, based on user groups. For example, give the communication department/employee owner rights to the Shared tile group that contains the Hub, allowing them to manage and create announcements and/or knowledge items.
These access levels are only visible to users when they are explicitly granted access by the administrator. In other words, users will not see Shared spaces, Shared tile groups and/or tiles that they have not been granted access to, even when it's pushed to users by the Workspace administrator.
Permissions granted to access level(s) | Visibility to users |
Shared space (level 1) | |
Shared space (level 1)
Shared tile group (level 2) | |
Shared space (level 1)
Shared tile group (level 2)
App/tile (level 3) |
Roles
Next to setting the desired permissions on each access level, you can define roles. A role is an identifier that can be used to associate permissions with applications, including or excluding users from performing specific tasks in Workspace.
From most to least permissions, you can make someone a Workspace administrator, Owner, Editor or User.
Roles & Permissions
You want to limit users' permissions to only what are strictly required to do their jobs.
Summarized below are the Workspace roles and their corresponding permissions. Take a look at the table and decide which role is appropriate to grant.
Role | Permissions |
Workspace-Administrator | Administrators have all permissions within the workspace, and can therefore control and manage all features and aspects of the workspace. You should always have at least one administrator active in your workspace environment. An active administrator account is also a requirement to request emergency access. For more information go to: How to make someone a (primary) administrator.
|
Owner - Application | Only the administrator can assign the role "owner".
|
Owner -
Shared tile groups |
|
Owner - |
|
Editor - |
|
User |
|
Group management & Group permissions
Now that you understand what each Workspace role entails, it's important to know how to give their corresponding permissions. We recommend to do this based on groups.
User groups can be synced automatically from Microsoft Entra ID to Workspace using our Azure AD synctool or the Azure SCIM API. Assign group permissions first. If you set everything to 'Allow' or 'not set', you can then proceed to 'group management' and manage the editor- or owner permissions per user (group) from there. 'Not set' is automatically 'Deny'. For example, make team leaders owners of their team's Shared tile groups.
Group permissions: manage the default group permissions for your Workspace environment
Group management: manage permissions for individual groups
List view: displays a list of all groups with Name, Number of users and Description
Visual view: displays a visualization of group hierarchy
Permissions levels
There are three group permission levels: 'Not set', 'Allow' and 'Deny'.
To avoid permissions conflict, keep in mind that Group management takes precedence over the default Group permissions. However, ‘Deny’ overwrites everything and is always ‘Deny’ for all groups. To clarify this, take a look at the flowchart and the table depicted below.
Example scenarios
Scenario 1
Sarah is a member of the ‘Communication’ group.
You set the following permissions for ‘Create and manage all announcements and categories’:
Group permissions: ‘Not set’.
Group management: ‘Allow’ for the Communication group.
As a result, Sarah is allowed to create and manage announcement and categories, because she is member of the Communication group which is set to 'Allow'. In this scenario, Group management takes precedence over the default Group permissions.
Scenario 2
Sarah is a member of the ‘Communication’ group.
You set the following permissions for ‘Create and manage all announcements and categories’:
Group permissions: ‘Not set’.
Group management: ‘Not set’ for the Communication group.
As a result, Sarah is not allowed to create and manage announcement and categories, because 'Not set' is automatically 'Deny' unless you'd chosen 'Allow' for the Communication group in Group management.
Scenario 3
Sarah is a member of the ‘Communication’ and ‘HR’ group.
You set the following permissions for ‘Create and manage all announcements and categories’:
Group permissions: ‘Allow’.
Group management: ‘Allow’ for the Communication group, but ‘Deny’ for the HR group.
As a result, Sarah is not allowed to create and manage announcements and categories, because she is a member of the HR group which is set to ‘Deny’.
Scenario 4
Sarah is a member of the ‘Communication’ and ‘HR’ group.
You set the following permissions for ‘Create and manage all announcements and categories’:
Group permissions: ‘Deny’.
Group management: ‘Allow’ for the Communication group, but ‘Not set’ for the HR group.
As a result, Sarah is not allowed to create and manage announcements and categories, because 'Deny' in Group permissions overwrites everything.