A permission level is a group of access rights within Rotaready, like "can view rotas" and "can view employee pay records". You can create as many different permission levels as you like and customise what access rights they have. Each employee user account is mapped to a permission level, thus determining what they have access to.

You might want to ensure certain employees are limited to their reportees when accessing some functions, such as "can view employee pay records for reportees only". By organising your permission levels into a hierarchy, this is possible. It's not uncommon to organise your permission levels in a similar structure to your corporate hierarchy.

⚡️ Permission levels are easy to use, but can be difficult to get right, especially in larger organisations. Saving your changes puts them live, so be sure to test them first using the Permissions Sandbox.

👀 Find out more in our Spotlight Session 'Permissions - the key to getting it right'.

Go to Settings, then click Permissions.

Drag and drop levels, ordering them in a tree-like fashion to represent a hierarchy. Clicking Edit on a level allows you to customise what access rights the level represents, using the checkboxes next to each item.

When creating a new permission level, don't forget to drag it to the appropriate place within your hierarchy.

⚠️ If you have anything that uses the Rotaready API, such as an integration built by you or a 3rd party, you're likely to see a permission level for these. Be careful as what you change here will affect what your API credentials have access to.

In addition to the access rights associated within their permission level, an employee is also limited by their site access. This is a restriction on the sites/departments they can view. This can be modified on their account in the Site access section.

Upon changing an employee's permission level, they will be logged out of Rotaready if they are currently logged-in.

The permissions sandbox is a helpful tool that allows you to test the impact of your changes before putting them live. You can simulate whether or not an employee can perform a specific action on another employee.

The criteria you need to complete are:

An example scenario: I'd like to check if 'employee 1' can view the pay rates of 'employee 2' 

If the source user has the relevant access to perform the action the sandbox will turn green, otherwise it'll turn red.