Most organizations discover their people database is broken the same way: they try to pull a list, and the list is wrong. Duplicates, stale addresses, fields that mean different things to different staff members, and segments that grew organically into a tangle nobody can explain. The database was not designed badly on purpose. It was designed quickly, and then it grew. This article gives you a framework for designing it deliberately from the start, or for cleaning it up before it gets worse.
The core person record: what belongs and what does not
Before you add a single custom field, define what the core record must hold. Every field on a record has a maintenance cost. Someone has to fill it in, keep it current, and understand what it means. The temptation is to capture everything. The discipline is to capture only what you will act on.
A lean but complete core record for most organizations contains four categories of data. Keep each category as short as possible.
| Category | What to store | What to skip |
|---|---|---|
| Identity | Legal name, preferred name, pronouns if relevant, photo | Nicknames stored as separate records (causes dupes) |
| Contact | Primary email, mobile, mailing address | Multiple email addresses on the same record (use a relationship instead) |
| Relationship to org | Status (active, inactive, prospect), join date, last interaction date | Long free-text "notes" fields with no structure |
| Household or company | Link to household or employer, role in that group | Duplicating the address on both the person and the household record |
If a piece of data does not fit cleanly into one of these four categories, it probably belongs in a tag, a segment, or a related record rather than a field on the person itself.
Tags vs. custom fields vs. segments: when to use each
This is the decision most databases get wrong, and it drives more confusion than anything else. The three tools serve different purposes. Using the wrong one for a given data point is what causes your database to become unreadable in 18 months.
- Tags are for attributes that a person can have many of and that change frequently. Interests, event attendance, informal groupings. Tags are cheap to add and cheap to remove. They should never be the thing you build a report on, because they drift.
- Custom fields are for structured data you will filter, sort, or report on. Membership tier, staff role, T-shirt size, giving frequency. Fields enforce a format (dropdown, date, number) and are harder to corrupt. Use them for data you need to be consistent across the whole database.
- Segments are saved queries, not data. A segment is a dynamic list of everyone who matches a set of conditions right now. “All active volunteers under 30 who attended in the last 60 days” is a segment, not a tag. Segments should never be manually edited; they should always recompute from the underlying data.
A practical rule: if you are writing the same tag on hundreds of records and it never changes, it should be a field. If you are building a list that you update manually every month, it should be a segment.
Households, companies, and relationships
People do not exist in isolation. A church family is a household. A nonprofit donor is often connected to a company that matches their gift. A mission partner is part of a sending church. Modeling these relationships is what separates a contact list from a real database.
- Create a household record for family units The household holds the shared mailing address and has its own name (“The Garza Family”). Individual people link to it. This means when someone moves, you update one address, not four records.
- Assign a role to every person in the household Primary contact, spouse, child, dependent. The role determines who receives communications addressed to the household and who appears on giving statements.
- Link companies separately from households A person can belong to both. Their household is personal; their company is professional. Keeping these as separate relationship types prevents the mix-up where a company’s address overwrites a home address.
- Record peer relationships sparingly Mentor-mentee, small group member, accountability partner. These are valuable but expensive to maintain. Only track peer relationships if your workflows actually use them, not because it would be theoretically nice to know.
Segments that drive action, not vanity
A segment is only useful if it leads to a specific action. Before you save any segment, ask: “What will we do with this list in the next 30 days?” If the answer is “nothing specific, we just want to see it,” archive the segment. Vanity segments clutter your database and make the real ones harder to find.
High-value segments are defined by a combination of status, behavior, and time. Here are examples that map directly to organizational action.
- New within 90 days + no connection to a group. These are people who joined but have not been integrated yet. Action: personal outreach from a staff member or volunteer.
- Active last year + no activity in 90 days. Lapsed engagement. Action: a specific re-engagement message, not a bulk newsletter.
- Giving for 12 consecutive months. Consistent partners. Action: a personal thank-you from leadership, not an automated receipt.
- Attended an event + not in the database before that event. New contacts from a specific campaign. Action: a welcome series, not immediate ask.
- Staff or volunteer + certification expiring in 60 days. Compliance-driven. Action: a reminder workflow triggered automatically.
Data hygiene rules from day one
Clean data is not the result of a one-time cleanup. It is the result of small, consistent rules applied at every entry point. These are the rules that prevent the database from degrading over time.
- Require a primary email on every record. Email is the most reliable deduplication key. A record without an email is an orphan waiting to become a duplicate.
- Standardize name casing on entry. “john smith,” “John Smith,” and “JOHN SMITH” are the same person but will not merge automatically. Enforce title case or lowercase at the field level.
- Date every import. Add a custom field or tag that marks which import batch a record came from. When something goes wrong with an import (and it will), you can find and fix exactly those records.
- Never delete. Archive instead. Deleted records leave gaps. A person who moved away may come back. Mark records inactive with a date and a reason. Delete is for confirmed duplicates only, and even then, merge first.
- Audit one field per quarter. Pick one field each quarter (say, mobile numbers in Q1, mailing addresses in Q2) and run a report for blanks or formatting inconsistencies. A full database audit is overwhelming; a field audit is manageable.
Permissions: who sees what and why it matters
Most small organizations give everyone full access to the people database because it feels simpler. It is simpler, until a volunteer accidentally exports 2,000 records, or a part-time staff member updates a field they do not understand, or a donor’s giving history is visible to the wrong person. Permissions are not bureaucracy. They are a basic protection for the people in your database.
| Role | What they should see | What they should not see |
|---|---|---|
| Full admin | Everything. Merges, deletes, exports, permission management. | Nothing restricted. |
| Staff | Core record, contact info, group memberships, attendance, notes they created. | Giving details, salary fields, private pastoral notes. |
| Volunteer coordinator | Volunteer-related fields, availability, schedule, contact info. | Giving history, private staff notes, personnel records. |
| Finance team | Giving history, pledge records, financial contact info. | Pastoral notes, personnel records, private correspondence. |
| Self-serve (member portal) | Their own record only. Ability to update contact info and preferences. | Any other person's record. |
Studio Faith and Studio Craft both use role-based permissions that map to these categories, so you can configure access once and not revisit it every time you add a staff member.
Key takeaways
- Every field has a maintenance cost. Only add fields you will filter, sort, or report on.
- Tags are for loose attributes. Fields are for structured data. Segments are saved queries, not lists you edit manually.
- Model households and companies as separate records linked to people. Update the household address once, not on every family member.
- A segment is only useful if it drives a specific action. Delete segments that exist only to be viewed.
- Require a primary email on every record. It is your best deduplication key.
- Permissions protect the people in your database. Give each role access to exactly what they need, nothing more.
Common questions
How many custom fields is too many?
There is no universal number, but a good test is this: if a new staff member would not understand what the field means without asking someone, it needs documentation or deletion. Most organizations can run effectively on 10 to 15 custom fields. Beyond 30, the cognitive load of maintaining them usually outweighs the value of the data.
Should children have their own person records?
Yes, if you need to track their participation, attendance, or communications separately. Link them to a household as a dependent. If you only need to know how many children are in a family, a field on the household record (household size, number of children) is sufficient and much simpler to maintain.
What is the best way to handle people who have multiple roles, like a staff member who also volunteers?
One record, multiple roles. Never create two records for the same person because they wear different hats. Use a multi-value field or a tagging system that lets you assign more than one role. The single record is the source of truth; the roles are attributes on that record.
How do I handle a contact who does not have an email address?
Create the record with whatever contact information you do have (phone, mailing address), but flag it explicitly as email-unknown rather than leaving the field blank. A blank email field looks the same as a missed entry. A flag means someone made a deliberate choice, and the record will not show up as a data gap in your hygiene reports.
