When migrating from a previous database and considering how to store your data in Beacon, most information in your spreadsheets is going to feel pretty person-centric. You therefore want to avoid the temptation to store everything on the Person record. But how do you do that?
You should recall this image from your online Lighthouse training, explaining how all of Beacon's record types are linked and relate to each other.
Rather than storing the same data in multiple locations, you use 'point to another record' fields to create connections in your data, so that you only have to change data in one place. But this also means we have multiple different places we could store our data. How do we decide when to split data and then where to store it?
Key criteria for splitting information:
Relevance to core identity:
Information fundamental to who the person is belongs in the person record (e.g., name, address, birthdate).
Context-specific information:
Information relevant only in specific contexts should go into a related record.
Time sensitivity and likelihood of change:
Information that is likely to change by the next interaction should go into a related record.
Repetition
Information that is likely to repeat on multiple occasions, but where you need to store information about each repeated instance should be stored in a related record.
Relevance to core identity
Is this piece of information a 'quality' of the Person or something else? I.e an action the person has taken, or an 'instance' of their involvement with you.
Person record: Think of this as the main profile of the individual. It contains core details about the person themselves, like their:
Name
Date of birth
Contact information.
Related record: This is a separate record that holds information about specific interactions related to that person. These interactions can be things like:
Donations made
Events participated in
Casework you've done with them.
As the number of interactions grows, you can keep adding related records without overloading the main Person record.
For example:
Qualities of the person:
Name: John Doe
Address: 123 Main St
Email: [email protected]
Qualities of an action they've taken:
e.g a related Donation:
Linked to: John Doe
Donation date: 01/01/2024
Amount: £100
Campaign: Winter Fundraiser
Context-specific information
Is this piece of information relevant for all people that you interact with, or only in some circumstances?
Person Record: Contains static or relatively unchanging information about the person, which is generally relevant regardless of the specific interactions they are involved in.
Related Record: Contains dynamic information about specific interactions that are relevant in certain contexts but not always necessary to know about the Person in a wider context.
Example:
We want to store:
Name: John Doe
Address: 123 Main St
Email: [email protected]
Housing situation: Social housing
Case Start Date: 03/04/2024
Specific Need: Monthly food supply
How to organise it:
Person Record:
Name: John Doe
Address: 123 Main St
Email: [email protected]
Case Record (Only needed for food assistance case):
Linked to: John Doe
Case Type: Food Assistance
Housing Situation: Social housing
Case Start Date: 03/04/2024
Specific Need: Monthly food supply
Why split it?
Even though housing and food needs are about the person, they're only important for this case.
So, we keep the general info with the person and put case-specific info in the case record to keep things tidy and clear.
Time sensitivity and likelihood of change
Is this piece of information likely to change over time, or from interaction to interaction?
Person record: Contains static or relatively unchanging information about the person, which is generally relevant regardless of specific interactions they are involved in.
Related record: Contains dynamic, context-specific, or time-sensitive information about interactions that are relevant only in certain contexts and may change over time.
Example:
Person record:
Name: Jane Smith
Address: 456 Elm St
Email: [email protected]
Related record for Grant application:
Linked to: Jane Smith
Application date: 22/07/2024
Grant application type: Financial support
Current income: <£200 per week
Current medication: Fluoxetine
Why split it?
If you only ask about current needs or circumstance (e.g current income, current medication) when working on a particular Grant application, this information should be stored on a related Grant application record.
If this person reapplies for a grant, it's likely that these circumstances might change, and you need to assess their application using current information.
Repetition
Does this piece of information repeat, and does the information vary (or just need to be stored) for each repetition?
Subscription record: Contains static or relatively unchanging information about this instance of giving, which is relevant to the instance of giving regardless of the specific payments made as part of this subscription.
Related record: Contains dynamic, repeating information about individual instances of payments that are relevant to this subscription, with some data that may change over time.
Example:
Subscription record
Record ID: 2724
Payer: Bob Johnson
Amount: £100
Next payment date: 22/07/2024
Frequency: Monthly
Related Payment records (one for each payment made)
Payment One
Payer: Bob Johnson
Subscription: 2724
Amount: £100
Payment date: 22/05/2024
Payment Two
Payer: Bob Johnson
Subscription: 2724
Amount: £100
Payment date: 22/06/2024
Why split it?
The subscription tells you what’s supposed to happen (e.g. Bob pays £100 every month).
The payments show what actually happened and when.
So instead of changing the subscription record each time Bob pays, you create a new payment record for each payment. This keeps the data organised and makes it easy to track payment history.
Custom record types
When considering adding custom record types to Beacon, understanding the main reasons why and how data is split out through Beacon's core structure can be useful.
Take the key criteria for splitting data above and apply the same logic to any additional data that you need to store.
You can read more about how to add custom record types to your account here and look at some examples here.