NationBuilder Tags vs. Saved Filters vs. Lists: Which Should You Use?
August 13, 2026Tags, saved filters, and lists are all useful tools for organizing your NationBuilder database, but they aren't interchangeable.
One of the easiest ways for a database to become cluttered and unreliable is to use tags for information NationBuilder already tracks, or to use a static list when what you really need is a group that changes over time. The basic rules I follow are to use the tool that best matches the type of information you're working with, and don't create a tag when NationBuilder already gives you another way to get the same result.
When not to use a tag
Tags are easy to create, which also makes them easy to overuse.
Membership is a good example. NationBuilder has a built-in membership system that tracks membership types and statuses and allows you to sort and filter people based on that information. There's no reason to duplicate that data with tags.
Let's say you have a member with a particular membership type, and you also add a corresponding tag to their profile. What happens when their membership expires? Or when they move to a different membership type?
NationBuilder's membership information changes, but your tag doesn't. Someone must remember to remove or replace it manually. If that doesn't happen consistently, you eventually end up with tags that no longer reflect the current status of the people in your database.
The same principle applies to information NationBuilder already records automatically. You don't need to tag someone as an event RSVP when NationBuilder already recorded that information. Similarly, you don't need a general donor tag simply to identify people who have donated when donation history is already part of their record.
If NationBuilder already tracks the information and lets you filter by it, use that data instead of duplicating it with a tag.
When tags make sense
Tags are most useful for information that NationBuilder doesn't already have a field or built-in mechanism for, and particularly for information that isn't likely to change frequently.
Imagine an animal rights organization that sends one newsletter to people interested in cats and another to people interested in dogs. NationBuilder doesn't have a standard field for "preferred animal," so tags such as "cats" and "dogs" provide a simple way to record those interests and segment communications accordingly.
In fact, this is how NationBuilder handles signup options. When you give people interests or newsletter options to choose from on a signup form, NationBuilder adds the corresponding tag to their profile based on the option they select. The tag becomes a persistent piece of information you can then use to segment future communications.
Another example comes from Democratic clubs I work with. Some need to send special communications to members who are judges. Being a judge isn't something NationBuilder inherently tracks, it's unlikely to change frequently, and the organization has a specific reason for knowing it. A "judge" tag provides a simple way to identify those members whenever the club needs to communicate specifically with them.
Before creating a tag, I would ask three questions:
- Does NationBuilder already store this information somewhere else?
- Is this information relatively stable, or will someone constantly need to update the tag?
- Do we have an actual reason to segment or communicate with people based on this information?
If NationBuilder doesn't already track it, it's relatively stable, and you'll actually use it, you probably have a good reason for a tag.
Saved filters vs. lists
The biggest distinction between saved filters and lists is this: Saved filters are dynamic. Lists are static.
A saved filter continually updates to reflect what's happening in your database.
For example, you might create a saved filter containing all active members across several different membership types. As new people become members, they automatically meet the filter criteria. When someone's membership expires, they no longer meet the criteria.
You don't have to maintain the group manually.
That's why, in most cases where you want to repeatedly find or communicate with a particular group of people, a saved filter is more useful than a list.
A list, on the other hand, is a snapshot of a group of people at a particular moment. Once you've created it, the people on that list don't automatically change because something in the database has changed.
And sometimes that's exactly what you want.
Lists are used for batch updates, because you're performing an action on a particular group of people at that moment. They're also useful for exports, which similarly represent your data at a particular point in time.
A list can also make sense when you're manually assembling a specific group of people who don't share criteria that can easily be captured with a filter, or when you want to preserve a group for future reference. For example, you might create a list of all members who attended an event in 2025. Because that period has passed, the group doesn't need to update. You could later compare it with a list of members who attended an event in 2026.
But if you're creating a group that you expect to use again and want it to reflect changes in your database, you'll want a saved filter rather than a list.
A simple rule of thumb
When deciding how to organize people in NationBuilder:
- Use NationBuilder's built-in data when the information is already being tracked.
- Use a tag for useful information NationBuilder doesn't otherwise capture, particularly when it's relatively stable.
- Use a saved filter when you want a group of people that should automatically change as your database changes.
- Use a list when you intentionally need a fixed group of people at a particular moment.
The more you can rely on NationBuilder's existing data and dynamic filters instead of manually maintaining redundant tags and lists, the easier it is to keep your database accurate, useful, and manageable over time.
Not sure if you're getting the most from NationBuilder?
My NationBuilder HealthCheck identifies issues and opportunities across your database, website, workflows, accessibility, and SEO, with a prioritized roadmap for what to tackle next.