Roles and Permissions enable you to control which parts of the platform your team members can access. This helps protect sensitive data and ensures that users only interact with what’s relevant to their role.
🔐 What can you restrict?
You can limit access to the following:
Features (e.g. forms, workflows)
Record types (e.g. people, donations)
Individual records (e.g. only 'Donors')
Specific fields within records
Note: Roles and permissions are included on our Standard, Premium, and Ultimate plans.
Advanced Permissions is available as a purchasable Element on Premium and Ultimate plans.
Roles
Roles define the type of access regular users have in your Beacon account. Each role will have a specific set of permissions, meaning all users assigned to a role have the same access level.
Example Roles
Fundraising Team – Manage donors and reports; no access to patient data.
Data Entry Team – Input payments; view only people and payments.
Executive Team – View reports; no editing capabilities.
Service Delivery Team – Access sensitive patient data; kept separate for security.
You can create and manage roles via your Sidebar > Settings > Roles and Permissions.
By default, all new users are assigned to a "Default role" unless you specify otherwise.
From here you can:
Create roles by clicking "Create role"
View, edit and delete existing roles
Managing roles and users
Click a role to see all users assigned to it:
When you invite a new team member to Beacon and add them as a 'Regular' user, you will need to add them to a role.
Users can belong to multiple roles – Beacon will combine permissions in the most permissive way.
Tip: Admin users have access to everything.
Whilst you can assign them to roles, it won't have any impact on what they have access to.
Settings
Settings are where you determine what the members of each role have permission to do in Beacon.
Features
The features tab allows you to configure the permissions for many of the features in Beacon.
Configure access to Beacon’s main features using:
Write – Full admin-level access.
Read – View settings but cannot edit.
Forbidden – Feature hidden from the user's sidebar - no access.
Note: Permissions are not immediately updated for all members in a role when you select new permissions.
Don’t forget to click "Save role changes" to apply updates.
Access
Note: Some of the features described here are features of the "Advanced Permissions" Element and is available only on Premium and Ultimate plans.
Access permissions determine at a Record type level what the users of a role should have access to.
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] - Set up 'rules' - certain criteria - which must be meet for the user to gain access to the records.
e.g "Cases where the "current user" is the owner" or "All Events where the type is 'Fundraising'".
Inferred [Requires Advanced Permissions] - Give access to records if they are linked to a record for which there is a 'rule'.
e.g "People where you have access to their Case"
No Access - The record type is hidden from the user's sidebar and they are unable to access it.
Setting up access rules
Once you set the access of a Record to "Rules based", you'll next need to determine those rules or the conditions for accessing those records.
To set up your rules, click "Edit Rules".
Each rule is a group of AND conditions. Multiple rules act as OR logic.
Example: Case worker
Access all Cases owned by the current user that are not closed
OR Cases that are new and unassigned
Your rules would look like this:
You can have as many Rules & Conditions as you need.
We do not support rules based on:
Smart Fields
Rollup Fields
Long Text
Location
File upload
You won't be able to save your changes until all Rule Based record types have at least one rule.
Setting up Inferred access
Inferred access allows users to see records linked to ones they already have access to.
Example:
People linked to a Case you have "rules based" access to
To set up your Inferred access, click "Edit Fields".
You'll see a card like this pop up if you've set up "rules based access" for any record types that 'point to' people already:
Here, I am giving Inferred access to People records where:
A Case that I have "rules based" access to points to People via the 'Person' or 'Referred by' point to another record fields
An Organisation that I have "rules based" access to points at People via the 'Primary contact' point to another record field.
It's possible to apply Inferred and Rules based access for a single record type.
For example:
I need to be able to access
People linked to Cases that I own AND (Inferred)
People I've created (Rules based)
You'll need to add two separate Roles and add the user to both. Remember, Beacon will combine permissions in the most permissive way.
A note on Activities and Inferred access
Activities behave uniquely when "Inferred access" is applied. Because Activities are linked to most other record types, you'll often want to see Activities for Inferred records as well, we have set them to work on any record type.
You can see Activities on the Timeline for any record you have access to (regardless of whether you have "all", "rules based" or "inferred" access). In the Activities list views (and exports), we only show you the Activities linked to records that you have access to.
(Field) Permission settings
Once you have set your Access settings, you can fine-tune "Permissions" per field:
Write – Edit permissions
Read – View only permissions
Forbidden – Hidden completely
Note: you will only see record types in this list if you have set Access to "All records", "Rules based" or "inferred". Record types with "No access" will be hidden
Combining roles
When users belong to multiple roles, Beacon grants the most permissive combination.
For example, a user is assigned to two roles:
Role | Access | Permissions |
A | Rules based | Edit all fields |
B | All records | Edit Notes field only |
A user in both roles will have the following access and permissions for Cases:
Access → Can access all Records
Permission → Can Edit all fields
This applies to field-level permissions, record access, rules, and inferred access
Saving Changes
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:
While saving, users might retain access to old permissions. A progress bar will appear
In the top right hand corner → shows total progress across all records
Under each record type → shows the progress of each
This will continue working in the background even if you navigate away or close the tab.
While changes are saving, you will not be able to save additional changes until the progress bar has finished updating.
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.
What do users see?
Now that we've covered how to configure roles and permissions, let's take a look at the key effects on the Beacon user.
Trying to access a restricted record
A user will see the following:
For security, this is the same message a user will see if trying access an invalid URL.
Field-level permissions on a field
Edit permission
Users can view and edit the field
Read permission
The field is viewable, but can't be edited.
Provided the user has the correct feature permissions, read-only fields can be exported.
Forbidden
The field is hidden from the user's view completely.
If all fields in a card are forbidden, the whole card will be hidden.
Other considerations:
Related record cards
Users will need Read or Write access to all displayed fields on a related record card in order to see it.
For example, here, the user needs Read or Write access to both the 'Amount' and 'Payment date' fields of the Payment record to see this card.
Creating and deleting records
To create a record, users will need Write access to at least one field
To delete a record, users will need Write access to all fields
Until a record is permanently deleted, users will still be able to access it and any records where inferred access depends on that record.
The sidebar
For a record type to show in a user's sidebar, they need Read or Write access to at least one of its fields.
Point to another record fields
A user must have Read or Write permission for the record it points to in order to view or edit the field.
Action | Point to another record field permission | Pointed to record permission |
Edit field | Write | Read or write |
Create record via point to another record field | Write | Write |
Rollup and smart fields
Rollup and smart fields can reference forbidden fields.
For example, a user that does not have access to the Payments record type will be able to view the "Total" rollup field on the Campaign record.
Users do not need access to fields referenced in a smart field to view the calculated result.
List views
Forbidden fields do not show.
Forbidden fields cannot be used in filter criteria.
The "create" button will only be visible if the user has Write access to at least one field for that record.
Forms
Read access allows users to inspect their configuration but not to change them
Charts
Read access allows users to view charts but not to change them
Exporting and importing records
To export records, users will need Read or Write access to only fields they want to export.
To import records, users will need Write access to the "Import data" feature, Read or Write access to the "Import templates" feature and Write access to all fields on the record type being imported.
If your role is restricted by rules based access, you will not be able to run imports for that record type.
| Rules based access | Field level permissions |
Importing | ❌ | ✅ |
Exporting | ✅ | ✅ |
Access Type | Action | What's required |
Field level access | Exporting | ✅ Read or Write access to the specific fields you want to export |
Field level access | Importing | ✅ Write access to all fields in the record type being imported |
Feature level access | Importing | ✅ Write access to the "Import data" feature |
|
| ✅ Read or Write access to the "Import templates" feature |
Rules based access | Importing | ❌ Forbidden |
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.