Customising Beacon and adding new fields is nice and easy to do, but at times you might be unclear which fields you need to create for the job. Beacon offers a wide range of different fields for you to store information in, and it's important to make sure you're using the right ones.
Each field in Beacon has special qualities - some with automatic formatting - that make them really good at doing specific jobs. Some fields also have limitations to the way you can use the data held in them, meaning they're not fit for all purposes.
Let's take a look at some considerations for choosing the correct types of fields when customising Beacon.
Long text vs Short text
Usually, this is a really intuitive choice to make! But let's take a look at some important qualities of each type of field that might help you decide.
Short text fields
Can hold a maximum of 255 characters (so roughly a few sentences)
Can apply detailed filters (e.g is, is not, contains, is unique, etc)
Can be used as a deduplication value in import templates
Can be used for grouping in charts
Can hold a combination of text, numbers and special characters
Short text fields are good for recording things like:
Names of things (Funds, Organisations and Events)
Previous database IDs (where a combination of letters and numbers might be used)
Arbitrary pieces of short information (i.e 'job title')
Long text fields
Technically speaking, you could use a long text field to store anything, but you almost certainly shouldn't. Long text fields:
Have (virtually) no limit to the quantity of data you can store
Can only apply limited filters ('is blank' or 'is not blank')
Can search for content in list page search bar
Cannot be used for deduplication in import templates
Cannot be used for grouping in charts
Can hold a combination of text, numbers and special characters
Long text fields are good for recording things like:
Descriptions (e.g the description of an Event)
Notes (more detailed information about something)
Reasons and detailed explanations (e.g 'previous experience' for a Volunteer application)
Deciding which field type to use
For example: "Reason for application" on a Grant application
If you expect a shorter answer -> Short text
“I’m currently struggling to make ends meet - my expenses are exceeding my income.”
If you expect a more detailed description -> Long text
“I’m currently struggling to make ends meet - my expenses are exceeding my income. My current expenses include rent, gas and electricity, food shopping, and transport. My income at the moment is from my part-time work and from basic government assistance, though that’s due to finish at the end of the year. I will need some financial support so that I can continue to live in my flat.”
Long text vs dropdown list
This may not seem like the most obvious comparison, but let's compare the qualities of both fields to work out when we might use one over the other.
Long text fields
Technically speaking, you could use a long text field to store anything, but you almost certainly shouldn't. Long text fields:
Have (virtually) no limit to the quantity of data you can store
Can only apply limited filters ('is blank' or 'is not blank')
Can search for content in list page search bar
Cannot be used for deduplication in import templates
Cannot be used for grouping in charts
Can hold a combination of text, numbers and special characters
Long text fields are good for recording things like:
Descriptions (e.g the description of an Event)
Notes (more detailed information about something)
Reasons and detailed explanations (e.g 'previous experience' for a Volunteer application)
Dropdown list
Provides person entering data with a standardised set of options
Can hold a combination of text, numbers and special characters
Can apply detailed filters (e.g is, is not, is any of etc)
Can be used for grouping in charts
Can allow multiple values to be selected
Can be used to create pipeline views
Dropdown list fields are good for recording:
Standardised lists of options (e.g t-shirt size, gender, type)
Data where you don't want variations (e.g where abbreviations or acronyms might commonly be used for that thing)
Deciding which field type to use
For example: 'Why did you choose to donate to us today?'
If you want a free text answer so people can tell you in detail why they're passionate about your mission -> Long text
"The Beacon foundation does some amazing work and I love to support all of the great things you do. Your mission is super important to me and I have regularly fundraised for you in the past"
If you want a standardised set of options that you feel represent the main reasons people choose to donate -> Dropdown list
The Beacon Foundation's mission is close to my heart
As a gift for a friend of family member
A recent appeal caught my attention
I just wanted to!
It's also a good idea to think about how you're going to use this data.
How it will be used | Long text | Drop-down list |
Filter for all People who made a donation as a direct response to an appeal | ❌ | ✔️ |
Filter for all donations made on someone's behalf | ❌ | ✔️ |
Create a chart to find the most common reason for donations this year | ❌ | ✔️ |
Get a general feel for why people are donating | ✔️ | ✔️ |
It's nice to hear about, but we don't really need to use it for anything | ✔️ | ✔️ |
We want a really detailed understanding of people's reasons for donating; we might ask people if we can share their statements online | ✔️ | ❌ |
ℹ️ Tip: whilst a drop-down list field might feel like the best option here, you don't need to limit yourself to this list only. Adding an 'other' option to your list then allows you to decide whether to report on 'other' as a value (i.e as a reason for donating in it's own right) or add a long or short text field titled 'Reason for donation - other' in addition to allow people to let you know if their reason is something other than your given options.
Remember, you won't be able to report on this option in the same way as your drop-down list, but it will allow you to standardise your responses as far as possible, and still hear what people have to say!
Short text vs Dropdown
Short text fields
Can hold a maximum of 255 characters (so roughly a few sentences)
Can apply detailed filters (e.g is, is not, contains, is unique, etc)
Can be used as a deduplication value in import templates
Can be used for grouping in charts
Can hold a combination of text, numbers and special characters
Short text fields are good for recording things like:
Names of things (Funds, Organisations and Events)
Previous database IDs (where a combination of letters and numbers might be used)
Arbitrary pieces of short information (i.e 'job title')
Dropdown list
Provides person entering data with a standardised set of options
Can hold a combination of text, numbers and special characters
Can apply detailed filters (e.g is, is not, is any of etc)
Can be used for grouping in charts
Can allow multiple values to be selected
Can be used to create pipeline views
Dropdown list fields are good for recording:
Standardised lists of options (e.g t-shirt size, gender, type)
Data where you don't want variations (e.g where abbreviations or acronyms might commonly be used for that thing)
Deciding which field type to use
For example: "Dog breed"
If there are hundreds of dog breeds, or potentially combinations of cross-breeds you don't know about, let people free-type the breed of the dog they're adding to Beacon -> Short text
If you want a standardised set of options that represent the dog breeds you can support -> Drop-down list
Other considerations for drop-down lists
To help you decide, also consider the type of information you're hoping to store.
It's 'static'
By this we mean that the options in this list won't really change all that much. There are a set number of recognised Dog breeds that would be added to the list.
It rarely needs adding to
It's fine if occasionally a new Dog breed comes up, but this shouldn't be an everyday (or even every-month) occurrence. If you know that this list is constantly growing, your drop-down list will quickly become unmanageable.
ℹ️ At this point, we might consider splitting the information into a new record type.
Are people likely to get it wrong?
People spell things wrong or use common abbreviations all the time. If you need a piece of information for very specific reporting purposes, this isn't somewhere you want human error to cause mistakes.
Think about that poor 'Golden lab' that isn't counted in your reporting figures because you only filtered for 'Labradors'!
How do we need to use the information?
Let's consider how this information will be used in determining which field will be best for the job.
How it will be used | Short text | Drop-down list |
Create a chart to find the most commonly cared-for dog breed | ❌ | ✔️ |
Find the number of Labradors in The Beacon Foundation's care this year | ❓ * | ✔️ |
Record new dog breeds that you haven't heard of before | ✔️ | ❌ |
Get a general feel for the dog breeds in your care | ✔️ | ✔️ |
*Whilst you can apply a filter to a short text field to find all 'Labradors', 'Black Labs' and 'Labs' won't be included in your results.
Checkbox vs dropdown
Dropdown lists:
Provides person entering data with a standardised set of options
Can hold a combination of text, numbers and special characters
Can apply detailed filters (e.g is, is not, is any of etc)
Can be used for grouping in charts
Can allow multiple values to be selected
Can be used to create pipeline views
Checkbox:
Can be used to record a 'Yes' or 'No' answer (a "boolean" field)
Can be filtered for 'is checked' or 'is not checked'
Records 'No' as an absence of data, rather than a value
Deciding which field type to use
It's often important to think about the way you might use this field in the future; is the field type you've chosen limiting the scope of your data?
A question you're asking now might feel like a simple 'yes' or 'no' answer, and best suited to a checkbox field. However, will this always be the case? If it's likely that your processes will change, and an 'I don't know' or 'maybe' option could be offered, a better choice might be a dropdown field. As the options you offer expand, very easily add these as new options to your existing list.
For example: "Does your organisation have over 50 employees?"
If you're expecting a simple 'yes' or 'no' -> Checkbox
You work primarily with the CEO of an organisation who will definitely know the answer to this question
If you're expecting some people you speak to to be unsure of the answer -> Dropdown list
You work with all employees at an organisation who might not know the answer. Give them the option 'I'm not sure' so you can follow up with someone else who might know.
It's also important to remember that 'No' is not stored as an explicit value, rather the absence of a 'Yes'. If it's likely that a record could be created where this question wasn't asked, a blank value no longer means 'No'.
For example: "Do you consent to your photo being used in our newsletter?"
If you're going to ask this on all event registration forms -> Checkbox
An Event attendee record could not be created without the person having answered this question.
= NO
= YES
If there's a chance you might not ask this question sometimes -> Dropdown list
An Event attendee record could be created without the person having answered this question. You want 'no' and 'blank' to mean two different things.
= NO
= Not been asked
⚠️ Remember, once you've chosen your field type and created your field, you won't be able to change it later.
Field vs custom record type
NOTE: This is an advanced step and won't be relevant for everyone. Please only consider adding more advanced customisation if you're very comfortable with data structure.
Custom record types are not available to Starter customers.
This consideration is a little different, as we move from deciding whether to store a piece of information on a record in one of the fields mentioned above (dropdown list, short text, long text), or as a custom record type related to that record. If the latter, you'll then make a link between the two records using a 'point to another record' field.
Before choosing to create custom record types, let's first understand Beacon's core record structure and some considerations for splitting things out.
Applying this to a custom record type
We already have two examples in our guide for Volunteer Shifts and Collection tins.
Let's take a look at another example.
Volunteer roles
❌ Simpler but limiting: using a Dropdown field for “Volunteer Roles” on the Person record
Charities often track roles, shifts and qualifications of volunteers, and you might be tempted to use the multi-select dropdown field on a Person (Volunteer) record like this:
Field: Volunteer Roles (multi-select dropdown)
Food Bank Helper
Fundraiser
Driver
Event Support
Admin
Seems simple, but what if…
The person volunteers in different roles at different times?
They switch roles depending on the season or event?
You want to track hours or dates for each role?
You need to know who coordinated each role?
As soon as you need to track any of these things, it's time to split it out.
✅ Better approach: Create a custom “Volunteer roles” record type
Instead of storing basic information in a dropdown, create a related record each time the volunteer takes on a new role.
Each Volunteer assignment record records:
Linked to: Jane Smith (person record)
Role: Food Bank Helper
Start Date: 10/03/2024
End Date: 10/05/2024
Supervisor: Jane Smith
Add another record:
Linked to: Jane Smith (person record)
Role: Fundraiser
Start Date: 15/06/2024
End Date:
Supervisor: Alan Turner
Why this is better:
You can track multiple roles per volunteer, with dates and context
You get accurate information for impact reporting (e.g. active volunteers in a particular role)
It’s easy to filter and manage volunteers by current or past roles
The Person record stays focused on personal info only
Volunteer supervisors can easily manage their teams
Trust and Foundation grant reports
Not all custom record types need to be related to People. You might find that this structure is useful elsewhere in Beacon.
The Beacon Foundation applies for multi-year funded Grants from Trusts & Foundations. Funders require reports from us once a year for the duration of the funding period.
I need to store the following data points:
'Report due'
'Report submitted date'
When multiple reports are typically due for a Trust and Foundation grant, the submitted date of each becomes a quality of a related record in it's own right. To better understand how the team manage submission, we need to know when each report was finally submitted.
'Report written and submitted by'
The person responsible for writing each grant report might differ between instances. The information is related to the report itself, not specifically the Trust and Foundation grant it's being written for. We need to be able to notify teammates when they have been allocated - and now own - a new report.
The fact that I need to store the above information related to a Trust and Foundation grant on multiple different occasions makes this an example of data 'Repetition'.
For each time a grant report is due, the above three data points can (and almost certainly will) change.
What I need is a separate custom Grant reports record type, where each report that is submitted can link back to the Trust and Foundation grant it's for.
First, Create a custom record type called 'Grant reports'.
Next, on your new Grant reports record type, add the following new fields:
Trust and Foundation grant: National Lottery expansions fund
Due date: 23/06/2027
Written and submitted by: Ellen Carter
You now have visibility of all the reports you need to submit for a specific Trust and Foundation grant.
ℹ️ Beacon custom record types come with set core fields:
Name
Person
Notes
Attachments
If you don't need any of these fields, feel free to delete them! The 'Name' field will be set as the 'primary field' for this record type, so you won't be able to delete it yet.
If you don't need it either:
Hide it and come back to it later!