Note: Roles and permissions is a Professional plan feature. You can upgrade your account to the Professional plan on your Beacon Billing page.

Screen Shot 2019-03-11 at 20.53.37

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 users in Beacon: admins and regular 'member' users. Admins can do anything within Beacon. Most importantly this includes:

  • Inviting other team members

  • Configuring the Beacon database

  • Setting up roles and permissions for members

Only your most senior technical users should be Beacon admins. Remember, with great power comes great responsibility!

Regular users still have full access to the database, but they don't have access to the admin-only features, such as:

  • 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

  • Create new record types - only admins can create new record types from your settings

  • 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 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 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, or, click on an existing role to open the settings for that role. From here you can configure or delete the role.

Roles and members

From this screen we can see that this role currently has only one member: David. From here we can add and remove members from this particular role. Members need to already have been invited to Beacon before they can be added to a role, which you would do 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 can 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.

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

Screen Shot 2019-03-11 at 21.58.45

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

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.

Screen Shot 2019-03-11 at 22.09.46

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 level 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:


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 edited. Read fields can still be referenced by other records and included in reports and exports.


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.


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

These two layers of scrutiny ensure that Beacon's permissions are enforced securely.

Did this answer your question?