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 is included on our Standard, Premium, and Ultimate plans. Advanced Permissions (see below) is available as an Element in Premium and Ultimate.

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:

"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.

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: Charles. 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!

Settings are exactly what they sound like: they describe what a role's members have permission to do within Beacon.

The features tab allows you to configure the permissions for many of the features in Beacon.

Each level of permission means something slightly different depending on which part of Beacon the member is being granted permission to.

Note: Permissions are not immediately updated for all members in a role when you select new permissions. You need to press the Save role changes button.

Here's what the three permission types mean here:

These work similar to Features, however you can have more control if you have "Advanced Permissions" element enabled (Available in Premium and Ultimate plans).

Here are what the four option types mean here:

When you set access of a Record to "Rules Based", you should now see an Edit Rules button. Note: That you can't save until all Rule Based record types have at least one rule.

To set up your rules, click on the "Edit Rules" button.

Inside of the Modal, you can create seperate rules, which act as ORs, and inside of the Rules you can create "Conditions", which act as ANDs. For instance, for a Case worker, you might want to set up so people can access the Cases that are Owned by the current user but are not closed, but also access the Cases that have no Owner and are New. Then your rules would look like this:

You can have as many Rules & Conditions as you would like.

We don't support the same level of filtering as we do in the List view area of Records, however we support the following:

We do not support:

When you set a record to Inferred, this means you can connect access to the records based on one (or more) records that have this as a related Record.

To set up your Inferred access, click on "Edit Fields" button.

Inside of the Modal, you can select 1 or more fields to gain access. For instance in the example below, you could give access to all the all People where the person can see the Activity in the Related To Field and/or the People where they have a Case they can access. This is useful for when people need to see or edit related records to do their job correctly.

Note: You will need to select at least one for access.

When you set Activities to Inferred, they act differently than other record types. Because Activities are used across lots of different record types, and you often want to see Activities for Inferred records as well, we have set them to work on any record type.

This means that if a Record is All Access, Rules or Inferred, you'll be able to see the Activities in the Timeline view.

This also means that in the Activities List views (and exporting), we only show you the activities of records that you have access to.

Once you have set your Access, if you come to the Permissions tab you can get more granular. Here you will see settings for all Record Types that have either All Records, Rules Based or Inferred access.

Here you can set for each record type the following options:

​

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.

This is also the case with setting Rules & Inferred. For instance if you set a role with:

Role 1:

Role 2:

Then if a user is in both roles they will get:

Note: If you are making changes to Features, Access or Permissions, you can't add users until you save. And visa versa for when you add users.

When you make changes in Roles & Permissions, you need to press the Save role changes button, or your changes will be lost. When you press this you will receive a warning:

This warning lets you know that while processing, users might be able to access records & fields based on the previous settings, while we make the changes.

You will then see a progress bar. This will work even if you close the tab, so do not worry. This is purely to let you know. If you close this down, you will notice that the progress bars show under each of the record types, so you can see how they have calculated. In the top right under the Save record changes button, there is a progress bar that shows the total progress across all records.

Note: That while changes are being made, you can make additional changes but you will not be able to save them until it is complete.

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.

If a user goes to record they don't have access to, they will see this:

Which is also the same message if there isn't a valid URL as well (we do this for security purposes).

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.

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 to their account. Once you have clicked on save, if the record access has changed from or to No Access, you will see the Record appear/disappear from the sidebar. It will still show if you are using rules/inferred, even if there are currently no records that are matching the users rules:

All Records:

No Access:

(Notice that Organisation is missing)

Note: In this example, if you are an admin, you will see all records regardless.

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.

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 has CUSTOM from every field on the person record:

The role is also forbidden from newly created fields.

Tip: Look at the Permissions tab to see both Permissions and which records people have any access to.

If you want to restrict users from deleting records, and you have the Advanced Permissions element 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.