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.
Note: The Roles and Permissions element is available on our Standard, Premium, and Ultimate plans.
Roles
Roles describe the different kinds of regular user within your organisation. Each 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 people and 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 users together 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, or, click on an existing role to open the settings for that role. From here you can configure or delete the role.
Roles and users
When you click on a role, you will be taken to the list of users in that role. From this screen we can see that in this instance the role currently has only one member: Lara. From here we can add and remove members from this particular role.
When you invite a new team member to Beacon you will be able to choose which roles they are a part of. Members can belong to multiple roles: That's totally fine! It often makes sense for members to have access to lots of different things.
Tip: Whilst you can assign admin users to roles, it won't have any impact on what they have access to; admins have access to everything anyway!
Permissions
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.
Features permissions
The features tab allows you to configure the permissions for many of the features in Beacon.
Note: Permissions are immediately updated for all members in a role when you select 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
Note: Record type permissions are available on our Standard plan, field permissions are available on the Premium and Ultimate plans.
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 each individual field within the record type. You'll notice that if you select the record type permission again you will set all of the fields to have the same permission.
Combining permissions
As we mentioned earlier in this guide, 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
Below is an example of the effect of the different permissions on a phone number field:
Edit
With edit permissions for this field you can see it's value and change it to anything you like.
Read
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 edited. Read fields can still be referenced by other records and included in reports and exports.
Forbidden
If forbidden, 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 card are forbidden then the whole card is hidden. It won't appear to this member anywhere in Beacon.
Other considerations:
Related record cards need read or write permissions for all of their fields in order to show.
For example, in the related record card below the member needs permission to read both the amount field and the payment date field of the Payment record, otherwise this card 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 'Point to another record' field to show a member must have read or write permission for the record it points to.
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 roll-up 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 them
Read permission for charts allows users to view charts 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 the import records feature, and write permissions on all of the fields of the record type being imported.
Security
We take security very seriously at Beacon. These restrictions are enforced by two layers of security.
Interface
The Beacon interface constantly checks a user's permissions and updates to their permissions are immediately pushed to their account. 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.
Database
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.
These two layers of scrutiny ensure that Beacon's permissions are enforced securely.
Frequently asked questions
What permissions are applied to a newly created field?
Newly created fields will adopt the permission behaviour of the record type they belong to. Let's take a look at some examples!
Note: As roles will have different permission settings, the behaviour of each scenario will be dependant on the role
A role has EDIT permission for every field on the person record:
This means that, because the role is assumed to have full EDIT access of the people record type, newly created fields for the people record type will also have EDIT permission within that role.
A role has READ permission for every field on the person record:
Spoilers: Same concept as above!
Every field has READ access = new fields will have READ access.
A role is FORBIDDEN from every field on the person record:
You guessed it! The role is also forbidden from newly created fields.
A role has a different permissions for a variety of fields (e.g. READ permission for the email field but EDIT for all other fields):
Not matter the scenario, if a role has a variety of field permissions on a particular record type then newly created fields on that record type will be set to forbidden for that role.
Tip: Taking a look at which permission level is highlighted on a record type is an easy way to think about this.
If a permission is highlighted, this means that all fields within that record type will have that same permission and thus new fields will too. |  |
If no permission is highlighted, this means that some fields within that record type have different permissions to others and thus newly created fields will be forbidden |  |
How can I restrict record deletion?
If you want to restrict users from deleting records, and you are on the Premium or Ultimate plans, you can restrict at least one field on the record type in question to be either 'Read' or 'Forbidden'. So long as this one field cannot be edited, the record cannot be deleted.