Beacon's roles and permissions system allows you to control which parts of Beacon your users have access to. You can restrict certain settings, like who has access to forms, you can restrict record types, so one team only has access to the records they need, and you can even restrict fields within records to give you fine-grained control over sensitive information.
There are two kinds of authority in Beacon: Admin and member. Admins have complete authority to do anything within Beacon. Most importantly this includes inviting other team members, configuring the Beacon database, and setting up roles and permissions for members. Admin authority should be reserved for your most senior technical users of Beacon. Remember, with great power comes great responsibility!
Members are just what we call users who aren't admins. Most of your Beacon users will be members. Sometimes we use the terms 'user' and 'member' interchangably just to keep you on your toes, but when we talk about admins we definitely mean admins.
There are some parts of Beacon that only admins have access to:
- Charity preferences - this is where you set all of the important information about your organisation
- Team members - from here you can invite new team members, manage existing ones, and create new admins
- Roles and permissions - more on this later, but this is where you configure what your members are able to access
- Record types - only admins can create new record types
- Activity Types - only admins can create new activity types
- Configuring of record pages - from any record page (e.g. person) an admin can configure how the page is laid out and edit the fields that make up a record
Roles describe the different kinds of member within your organisation. One role has one set of permissions associated with it, so every member with that role has access to the same stuff. A typical set of roles might look like this:
- Fundraising team
- Data entry team
- Executive team
- Service delivery team
The service delivery team are dealing with sensitive patient data, so it's sensible to group them together. The executive team want to be able to read reports but they shouldn't be able to edit records. The data entry team just enter payments, so they only need to be able to see information about payments. And the fundraising team need to update donor information and create reports - but they shouldn't have access to any patient data.
By grouping together members into roles it's much easier to see what everyone has access to.
Roles are created on the roles and permissions page. When you first navigate to this page you'll see that you have one role called "Default role".
From this page you can create new roles. Click on a role to open the page for that role. From here you can configure or delete the role. Later we're going to add some permissions to the role, but for now let's look at the users tab.
Roles and members
From this screen we can see that this role has only one member: me. From here we can add and delete members. Members need to already have been invited to Beacon before they can be added to a role. You do this from the Team members settings page. When you invite a new team member to Beacon you will need to set their roles. This is why only admins can invite new users - only admins have the authority to configure roles.
Members can belong to multiple roles. That's totally fine. It often makes sense for members to have access to lots of different things.
Remember, you cannot assign admins to roles. There wouldn't be any point, since admins have access to everything anyway!
Permissions are exactly what they sound like: they describe what a role's members have permission to do within Beacon.
There are three levels of permission:
- Edit - the member has full permissions and can do anything they like
- Read - the member can access that part of Beacon but can't create, update, or delete anything
- Forbidden - that part of Beacon is off limits
Each level of permission means something slightly different depending on which part of Beacon the member is being granted permission to.
The features tab allows you to configure the permissions for many of the features in Beacon.
Note that permissions are immediately updated for all members when you select a new permissions. Here's what the three permission types mean here:
- Edit - The user has total access to that feature and can change any of the settings. They have the same access as an admin.
- Read - The user can view the current configuration of the feature but cannot change anything
- Forbidden - The feature is hidden from the user's sidebar and they are unable to access it
Record type and field permissions
The record types and fields tab lets you set detailed permissions for every record type in Beacon. Which is pretty cool.
You can control access to each of the record types with the top level permission next to its name. In the example below the member has read permissions for payments and edit permissions for people.
Clicking on the field permissions button opens up a section that allows you to select permissions for every field within the record type. You'll notice that if you select the record level permission again you will set all of the fields to have the same permission.
As we mentioned before, a user can have several different roles. When Beacon computes the permissions that a user has we look at all of the permissions in all of a user's roles and construct a set of permissions that is the most permissive. For example, imagine Bob has two roles: fundraising team and finance team. This means he has access to everything from both roles. The fundraising team does not have access to information about payments, but the finance team does, so we give Bob access. If a field is forbidden by one role and has read permission in another role we will give the member read permission to that field.
Permissions from a user's point of view
Most of what we have talked about so far focusses on how to configure roles and permissions. It's important to consider the effects that those permissions have on your members. This section highlights some of the key effects of permissions on a Beacon member.
The effect of field-level permissions on a field
This is the effect of the different permissions on a phone number record:
With edit permissions for this field you can see it's value and change it to anything you like.
With read permissions you can see the value of the field but it doesn't appear in a bounding box - which means it can't be editted. Read fields can still be referenced by other records and included in reports and exports.
The field is hidden from the user's view. There's no way to know that it's there, although other members may have permission to access it. If all of the fields in a block are forbidden then the whole block is hidden. It won't appear to this member anywhere in Beacon.
If all of a record block's fields are forbidden then the block will not show.
Related record blocks need read or write permissions for all of their fields in order to show.
For example, in the related record block below the member needs permission to read both the amount field and the payment date field of the payment record or this block won't show.
In order to delete a record, you need permission to write all of the fields for that record.
In order to create a record, you need permission to write at least one field.
For a record type to show in your sidebar, you need permission to read or write at least one of its fields.
For a related record field to show a member must have read or write permission for the related field.
It is also not possible to create related record fields if the member does not have read or write permissions for that related field.
Rollup fields can reference forbidden fields
It is possible to create rollup fields that roll up fields that the member does not have access to. This is fine, and actually pretty useful. You can grant access to a field that displays the average of a result but restrict access to the results of individuals.
Smart fields can reference forbidden fields
Similar to smart fields, you can perform calculations with smart fields and the results will display just fine - even if the member doesn't have access to the fields being used to compute it.
Permissions affect list views
Forbidden fields won't show in list views. You also cannot filter by fields that are forbidden. The create button will be disabled unless you have write permissions for at least one field for that record.
Read permission for forms allows users to inspect their configuration but not to change it.
Read permission for reports allows users to view reports but not to change them.
Exporting a record requires permission to read or write all of the record's fields.
Importing records requires permission to both import records and write permissions on all of the fields being created.
We take security very seriously at Beacon. These restrictions are enforced by two layers of security.
The Beacon interface constantly checks a user's permissions and updates to their permissions are immediately pushed. In the example below you can see two browsers side by side. The admin on the left is updating the permissions of the member on the right. You can see the member's interface updates in real time - you do not need to wait for them to refresh or to invalidate their session. The interface ensures that users cannot do things that they are not permitted to do.
The second layer of security comes from the Beacon database. Whenever a user makes a request to the database we check their permissions and only return the data they are permitted to see.
The two layers of scruitiny ensure that Beacon's permissions are enforced securely.