Robin Powered updates
We've changed the way permissions work to create an experience that's easier to understand and configure for your users and groups. This change affects organizations that opted into the Permissions Beta only.
What’s changing?
Early Beta: Users have the access allowed by their most restrictive role.
For example: If a user belonged to two groups, one group with access to "A" and another group with access to "A" and "B", then the user would only be able to book "A".
Now: Permissions are additive, and users have access to the greatest number of permissions allowed to them. That same user from the example above now has access to book "A" and "B".
Why are we making this change?
Your feedback throughout this early Beta period was clear — the old way was super confusing, and hard to manage for larger organizations where users belonged to multiple groups. Before releasing to everyone, we’ve decided to change the way permissions are applied.
With this change, the actions that a user is allowed to do is the sum of all the things their roles and groups allow them to do. If the user belongs to any groups with a role that allows for something (e.g., booking a room) then the user will be able to do it — even if another role doesn't grant this permission.
This approach makes managing permissions more straightforward, since you now only need to determine if a user belongs to a group which has permission to do something. You can also grant power with a new role without reviewing all existing role assignments.
Today's change was key to making the feature more intuitive, and the additive permissions approach should be familiar for teams already using Role-Based Access Control across their organization.
What should administrators do?
If you have created custom roles, we recommend taking a minute to review any groups with multiple roles assigned. You may need to update them to avoid granting access to rooms you’ve explicitly blocked previously. See below for tips on how to do this.
Understanding and modifying the default roles
Does this statement apply to your organization?
“Everyone can book everything (all rooms and/or desks) in our organization.”
If so, then change nothing. Remember that all new users with automatically join with the Member role, and that this role allows booking all spaces and/or desks by default.
If this isn't the case for your organization, then you'll want to modify the permissions for the Member role by restricting them to the lowest common level of access. This may mean preventing members from booking any spaces or desks at all.
Creating custom roles
In the new permissions model launched today, permissions are now additive.
So if this statement applies to your organization:
“People in the Marketing group can book anything on the 6th floor except for two executive board rooms;”
Then you'll want to do the following:
- Modify the default Member role by restricting any spaces, levels or locations that aren't bookable by everyone.
- Create a custom role that's allowed to book anything on the 6th floor. For that same role, add two exclusions for the executive board rooms.
- Assign the Marketing group to the new custom role. Ensure that the group contains the appropriate members -- you can use SCIM to sync these automatically from your Identity Provider.
In this case, everyone in the marketing group starts with the default permissions allowed for the Member Role, and then gets the added permissions of new custom role.
Assigning permissions to a single user
“I only want this to apply to a single person, why do I have to make a group?”
Today, roles must be assigned to a group, and not a specific user. If you’ve created many highly specific policies meant for specific users, you’ll need to create a group and assign the policy to them that way.
