Overview
Users that have permission to create and manage Sessions in Quantive Results are also allowed to customize the "granular permissions" of Sessions. By default when a Session is created it is "Visible to everyone".
What does that mean?
The "Visible to everyone" permission allows all users in your account to:
Read - users can access the Session and browse its contents.
Update - users can update OKRs in that Session.
Create - users can create OKRs in that Session.
Delete - users can delete OKRs in that Session.
To prevent any malpractices/accidents with the granular permissions of the Session - the "Visible to everyone" permission provides only the creator of the Session and anyone with a user role "admin" with:
Modify permissions - further, change and customize the permissions of that Session.
⭐️ Product hint - if you switch the Session's permissions from "Visible to everyone" to "Custom", without taking any further action and changing the permissions, what you will see is the actual breakdown of the "Visible to everyone" default granular permissions setup. This will help you remind yourself who has access, and what type of access if you leave it "Visible to everyone".
⭐️ Product hint - To allow only OKR owners to be able to update their OKRs in a session, create a session and assign “read” and “create” permissions to the selected users/teams.
These users will be able to create OKRs and assign themselves as owners. They can also add Key Results to their Objectives, but will only be able to update them if they’re the owner.
To summarize - the default session permissions - "Visible to everyone" - are quite open to the users in your account. This is in tune with the OKR best practices that encourage transparency.
❗️It's important to understand that this type of setup assumes high levels of trust and personal accountability in your users as it ignores the "ownership" level for the OKRs in the Session. For example - a user can update or delete OKRs, regardless of who is their owner. But this is where the customization of those granular permissions will give you more control.
Granular permissions customization
If the above level of transparency is just not what you're looking for, don't worry, this is where the Session's granular permissions can come really handy. You can easily gain control of "who does what" in your Session by customizing the Session's granular permissions. All that you need to do is navigate to the "Edit session" modal and make sure to switch the Permissions from "Visible to everyone" to "Custom".
What this allows you to do is change the default granular permission settings of the Session. For example - you can make it private to a team, or a group of users, change who can read, update, create, and delete OKRs, or who will be able to modify the granular permissions of that Session.
The granularity of the Session's permissions spans from "Everyone in the account" to specific Users, Teams, and even whole User Roles.
How you will approach this or what combination of granular permissions you will use is up to you. In the table below you will find a list of the most common permission combinations and their impact, regardless if it's a User, Team, or User Role.
Permission Combination | Description |
Read | Grants view-only read access to the Session's contents. The user cannot create OKRs but other users can make them an owner of OKRs. |
Read + Create | Grants read access together with the ability to create new OKRs. With this permission setup the "ownership" is respected - thus users with this permission will be allowed to update and delete only OKRs they "own", e.g. the user or their team is listed in the "Owner" field. |
Read + Create + Update + Delete | Grants read access together with the ability to create OKRs but also to update, and delete any OKRs in that Session, regardless if they are an owner or not. |
Modify permissions | Grants the user the permission to modify the Session's permissions. |
Sessions granular permissions specifics
It's important to understand that these granular permissions work differently when isolated compared to being combined with other permissions. Also, this goes for the three different permissions levels we have in Quantive Results - user-role, granular, and owner-based permissions. See the below table for more information.
Permission | Isolated behavior |
Read | A user X with this permission will only have read access to the Session's contents. |
Update | Grants read access together with the ability to update any OKRs. User X will be allowed to update OKRs regardless if they are owned by user Y or any other team, even if they are not a member of that team. |
Create | Grants read access together with the ability to create OKRs in that Session. User X will be able to delete and update OKRs owned by them, or owned by a team they are a member of. |
Delete | Similar to Update, if user X has Delete permissions they will be allowed to delete OKRs regardless if they are owned by user Y or any other team, even if they are not a member of that team. |
Modify permissions | Grants the user the permission to modify the Session's permissions. |
Additional notes
By default when creating a new Session the creator of the Session, everyone in the account, and everyone in the admin role will be granted permissions.
To change the selected permissions of the selected User, Team, or User role click on the "key icon" and then update the permissions selection.
To remove all permissions from a User, Team, or User Role, click the "bin icon".
In the search bar, you can search for any User, Team, or User Role that you'd like to grant granular permissions.
⭐️ Product hint - when granting permissions to a team by default you give permissions to all subteams of that team. To change that, make sure the "Include subteams" option is deselected.
Another way to grant permissions instead of using the search bar is by using the "Select from list" functionality. It provides you with a few tabs - Employees, Teams, Roles, or Account.
⭐️ Product hint - by selecting Account you can grant permissions to all users in your account, regardless of their teams or roles.
To prevent locking out sessions without any access to manage them - when setting the Session's permissions, you must grant at least one user full permissions, including "Modify permissions". If only one user is left with such permissions, you will not be able to remove them unless you give someone else these permissions first.
If an Objective is owned by a team, but the KRs are owned by individuals, every member of the team will be able to update the KRs of this Objective, because the Session's permissions are applied to the Objective level.
Quick example
Let's imagine that you want to create a session that is:
visible to everyone
but objectives can be modified by a specific user.
To translate what we want on the permissions language:
everyone in the account to be able to "Read"
and only a specific user to Create, Update and Delete OKRs.
Let's start with you, you're the creator of the Session so let's make sure you keep full access to the Session for yourself.
Then you need to set everyone in the account to be able to "Read."
And it's up to you to decide if you'd like your account admins to have backup access to your Session, in case of admin support is needed.
Let's add our "specific user", who will be able to modify OKRs.
⭐️ Product hint - the blue dots on the screenshot below indicate that the permissions for this User, Team, or User Role have been "customized".
Lastly, make sure you save your changes.
