A major change to Role Permissions!

The way in which you manage role permissions has been substantially overhauled. From now, you’ll be able to allocate record access straight down to a user’s granular level of interaction with that record.

How it used to be:

In the past, at the role level it was possible to allow/disallow users from creating certain types of records as well as providing customized access rights for viewing, editing and deleting records. This old way of managing roles was good for its time, however, it failed to offer the level of granularity that many users needed and wanted.

How it has changed:

First up, the record creation permissions are exactly the same: Yes/No. The big change comes with the View, Edit, and Delete. With each of these, you’ll see a list of the types of relationships a user may have with a record at the role level. This list is a drop-down list and allows you to control record access for view, edit, and deletion rights to a minute level of detail.

To describe this, let’s use an average ‘Worker’ type role to explain how you might set up your incidents permissions for these users.

Let’s say you want to assign the role permissions for incidents for your average worker:

Create

Create is easy. You’ll want your average worker to be able to create incident records without restriction, so mark this as “Yes”

View

For View, let’s say you want your worker to have some access to records they’re related too, but not too much. In this instance, you’ll select the types of relationships that you feel would be appropriate for that worker to maintain in order to gain access to a particular incident record. In this example, I’ve selected ‘Creator, Reported By, Reported To, Participating Users, Investigators’. I’ve NOT selected ‘All’.

What this selection means, is that if a Worker user is involved in this incident in some way, whether it be as the creator or somebody that has had a related action assigned to them, that they’ll be able to see this record. If however, I had selected “All” as an option as well, it would have also given workers access to view All incident records; which is not something most businesses would want.

Edit

For Edit, I’d like to further limit what my Worker is allowed to do. In the screenshot below, you can see I’ve selected Creator, Reported By, Reported To, and Investigator, whilst leaving NOT selecting All, Participating Users, and Action Assignee.

This means that a worker may only edit an incident record if they are the creator, Reported to, Reported by or are an investigator.

Delete

Delete is an easier one for this type of worker. I would like it so that under no circumstances can a worker delete a record. To achieve this, I’ve not selected a single relationship.

Result:

With these selections, we have a role type that allows assigned users to:

• Create incident records
• View incident records they’re associated with in any way
• Edit only incident records they’re very directly involved with
• Delete no incident records

Role Permissions and Management Organisation

Though this has not changed from before, it is important to understand how the leadership hierarchy interacts with this new role permissions system.

When a Worker type user creates a record, their direct manager (and their manager’s manager and so on) inherit that worker’s rights to that particular record on top of their own. So, as an example, a manager could have exactly the same role rights as worker BUT they would be able to access records they aren’t associated with so long as those records were created by a subordinate within their leadership hierarchy.

For clarity, leaders are set at a per user level on their user profile as shown below.

How will this affect existing account setups?

The great news is that this won’t negatively affect existing account setups. Extensive mapping has been undertaken to ensure that there will be no significant change to access. Old configurations will be automatically converted so that the permissions match exactly to the new permissions. The result of this is that unless you make any changes, your average user won’t notice a change at all.

So, what to do from here? Well if you like the way your account is working now, then you can leave it as is! BUT, if you’d like to tweak your permissions and get them just right, you can now do it.

The end result of this change is that admins will have an extremely granular level of control over who sees what within the system. It ensures that adequate privacy can be maintained without over-limiting access. It’s an exciting change and we’re all looking forward to seeing how you all make use of it.