Permissions ensure that your staff can access the data and functionality that they need within the system. They also ensure that they are restricted from accessing data and functionality that is not relevant to them.
Some permissions are role-based. This means that you set up access based on a person’s job title. For example, all ‘Building Managers’ in your organisation will have the same feature access as each other in the system.
These are then paired with the other types of permissions which are individual. These are asset-based and ensure that a specific ‘Building Manager’ only has access to the property they manage.
There are four areas that work together to govern QUOODA® access. Three are role-based and one is individual. We explore how this works below. You can click on the title of each area, and you will be directed to the help page that shows you the steps needed to set up or amend that specific option.
Role Security
This is the top level of security within QUOODA® and in the event of any conflicts in permissions across the four areas, this setting will take precedence. As such, it is the one that requires the most time, care, and attention.
In this area, you will be able to control what each job role can do. We will set up your core roles during the onboarding process but as your business evolves you may need to add new roles or tweak access for existing ones. Please bear in mind that any change made here will be applied to each user with that job role.
Role-based menu visibility
These are the building blocks of QUOODA® and will decide which menu items your users can view. This allows you to make things easier to find for your users by hiding the things they do not need.
There is not much risk if this setting is too open, the ramifications are more about the time it takes to find things because of unnecessary buttons. If the role security (see above) is set correctly, even if your users can see menu items that they will not be using, they will not be able to do anything within them.
Data permissions
Now that you have set up the options that your users can see and what they can do within them by their role we move on to the individual settings. Data permissions are the most significant of these and they control the assets (properties and sub-assets) that a user can see.
Going back to our initial example, a ‘Building Manager’ may have access to the one property they oversee. To build on that example, an ‘Area Manager’ may need access to a group of properties within their area. The ‘Head of Health and Safety’ may need access to all properties.
These data permissions will affect every feature within the system and restrict their view of data to just the records associated with the assets they have data permissions for.
Compliance permissions
As we have outlined above you can control access to the Compliance RAG through role security and the assets seen on the RAG via data permissions. This further option allows you to control which compliance rules are visible based on user role.
You can add/remove role access to all compliance rules at the same time by toggling off/on the ‘Document compliance’ feature within Role Security.
If you remove all access to the document compliance feature in role security, the following message is displayed at the point of save, confirming all access to compliance rules for that role will also be removed.
Please note - If a Corrective action is created and the assigned user does not have access to the compliance rule, they will not see the task.
If you add access to the document compliance feature in role security the following message is displayed at the point of save. You can choose 'Yes' to provide access to all compliance rules, or 'No' to provide access to no compliance rules.
From that starting point of all/nothing you can then remove/add individual rules as required by following Step 8 of the adding a compliance rule help page.