Skip to main content

Roles and Permissions 2025

Control which parts of Beacon your users have access to

Updated this week

Warning: This article includes features that are coming out in late May, if you trying to implement this beforehand, you may want the old article

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

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

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

Feature Settings

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:

  • 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

Access Settings

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:

  • All Records - This gives the user access to everyone one of the records

  • Rules Based [Requires Advanced Permissions] - Means that you can set up multiple rules & conditions, which must be meet for the user to gain access to the specific record. For instance, "Cases where the current user is the owner" or "All Events where the type is Marathon".

  • Inferred [Requires Advanced Permissions] - Means that you can give access to certain records, if they are related to a Record for which there is a Rule. For instance, "People where you have access to a case they are on" or "All Event attendees for the Events you have access to".

  • No Access - The record type is hidden from the user's sidebar and they are unable to access it.

Setting Up Rules

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:

  • Short Text - (Blank/Not Blank/Contains/Is)

  • User - (Is blank/is not blank/is/Current User)

  • Date - (Blank/Not Blank)

  • Phone - (Blank/Not Blank)

  • Dropdown - (Blank/Not Blank/Is/Is not/Is any of)

  • Related Record - (Blank/Not Blank/Is/Is not)

  • Currency (amount) - (Blank/Not Blank/Is/Is Not/Greater Than/Less Than)

  • Currency (currency) - (Blank/Not Blank)

  • Number - (Blank/Not Blank/Is/Is Not/Greater Than/Less Than)

  • Percent - (Blank/Not Blank/Is/Is Not/Greater Than/Less Than)

  • Rating - (Blank/Not Blank/Is/Is Not/Greater Than/Less Than)

  • Checkbox - (Checked/Not Checked)

We do not support:

  • Smart Fields

  • Rollup Fields

  • Long Text

  • Location

Setting up Inferred Access

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.

If you'd like to use Inferred and Rules on a Record i.e. "People that are on Cases I own (Inferred), or People I created (Rule based)", you can do this by having users in multiple Roles (though, please see the note about combining roles below).

(Field) Permission Settings

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:

  • Write: Which means they can create, delete and edit records

  • Read: Which means they can view all details of the record

  • Custom: Which means you can set permissions for each field inside of the records:

    • Write: Can Edit the field

    • Read: Can view the field but not edit it

    • Forbidden: Can not see the field or edit it


​

Combining roles

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:

  • Cases Access: Rules based on Owner

  • Cases Permissions: Can Edit all fields

Role 2:

  • Cases Access: Can access all Records

  • Cases Permission: Can only edit the Notes field

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

  • Cases Access: Can access all Records

  • Cases Permission: Can Edit all fields

Saving Changes

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.


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

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.

Important Security Considerations for Rules & Inferred Access

  • If you use Smart Fields, you can reveal data outside of Rules (this is as designed). This can be done intentionally but make sure you that you double check. For instance, the Cases title has the Persons Name in it, whereas you could have blocked access to People.

  • We recommend not giving people access to Imports or Workflows that have Rules, as using these 2 tools could allow someone to give themselves access to records.

  • Dashboards and Exports use the Rules & Inferred Access, which means if people have rules for access, their dashboards and exports and custom for them.


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

How can I restrict record deletion?

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.

Did this answer your question?