Lists are one of the most capable things in Planning Center and easy to under-use. Many accounts accumulate far more Lists than staff actively maintain.
That’s not only a discipline problem. The rule builder is deeper than it looks, several of its best features appear only in particular rule shapes, and stale results can still look authoritative. Planning Center does surface invalid Lists in Needs attention, but somebody still has to own that queue and the refresh schedule.
So: how Lists actually work, fifteen rules worth stealing, and the specific wall you hit at the end.
The mental model
A list is a set of rules. Each rule holds one or more conditions. The rule decides how its conditions combine, and the list decides how its rules combine.
That’s two layers, and it’s the thing that makes complicated lists possible. One rule can say “any of these three campuses” while another says “all of these membership criteria,” and the list joins them. If you’ve ever tried to express something in a single flat row of filters and given up, this is why: you needed a second rule.
Four things about that structure are worth knowing before you build anything.
The combinator isn’t just AND/OR. A rule can require all of its conditions, any of them, or none of them, and rules combine across the list the same three ways. None is the important one, because it’s how you express absence. Check-Ins conditions are phrased as attendance rather than absence, so there’s no bare “has not checked in” condition there. What there is, is a rule that says none of: checked in between 60 days ago and today, which produces exactly the same list and is the single most useful thing in this article. Almost every recipe below that involves someone going quiet is built this way. (You can also flip a single condition from include to exclude, which negates just that one and is tidier when you only need one negative.)
Once a rule holds three or more conditions, three further modes appear: at least, exactly, and at most N of them. That’s the closest thing Lists has to a multi-signal engagement rule: at least two of: checked in recently, gave recently, on a team, in a group. It is useful precisely because it stays a transparent membership test rather than inventing a hidden weighted score.
A list can return people other than the ones who matched. This is the feature I’d most like every Planning Center admin to know about. By default a list returns the exact people your rules matched, but it can instead return their household, their parents (an option Planning Center added in January 2026), their primary contact, only the adults, or only the children. Which means “find every child who checked in to VBS and give me their parents’ email addresses” is one List, not an export and a spreadsheet. In an aggregate snapshot of active List records synced to Parable on 1 August 2026, about 92% returned exact matches; parents and primary-contact returns together accounted for about ninety of roughly 3,900 records. That is a dated product-usage observation, not a Planning Center benchmark.
Lists refresh in batches, on a schedule, or manually. A List is not a live query. It’s a stored result set with a timestamp on it. You can have it rebuild nightly, weekly on a day you choose, or monthly on the first, or leave the schedule off and refresh it manually. In the same 1 August aggregate snapshot, 2,404 of 3,937 active List records had auto-refresh disabled. That says nothing about whether each List should refresh automatically: Planning Center specifically warns against auto-refreshing Lists that depend on other Lists, because refresh ordering can make the result inconsistent. For every List, document whether its source is scheduled, manual, or dependent on another List.
A result that has not refreshed for months can describe a different church. For the standalone recipes below, use a schedule when the conditions support it; for a List that depends on another List, keep the dependency warning above in view.
Two smaller things. Whether a List includes inactive people is a per-list matter: scope to active people with an explicit exclude: Inactive date is set rule rather than trusting a default. And Planning Center flags a List as invalid when a rule references something that no longer exists, like a deleted tag, a removed custom field or a retired List. In the 1 August snapshot, 327 of 3,937 active records included inactive people and 435 were invalid: about 8% and 11%, respectively. Invalid Lists are gathered in Needs attention; review that view instead of assuming every saved List still works.
If you want the wider picture of what reporting exists across the suite, I’ve written the complete guide to Planning Center reports; Lists are the People chapter of it.
15 lists worth building
Each of these is described by its goal and its conditions in plain language, because the rule builder’s wording shifts around and menu paths go out of date. Build them by meaning, not by memory.
Where a condition reaches into another Planning Center product, I’ve said so. Lists can filter on activity from other products (Check-Ins, Giving, Groups, Registrations and Services all contribute conditions), which surprises people who assume People only knows about People. You pick the product first and then the condition, and you need permissions in that product to build against it. What Lists can’t do with those products is the subject of the last section.
Assimilation
1. First-time guests, last 14 days. Conditions: created in People within the last 14 days, AND membership status is Guest or blank, AND has an email address or a phone number. Set refresh to nightly. What to do with it: this is the feed for your guest workflow. Attach an automation so anyone new to the list gets a card assigned automatically, and you stop relying on someone remembering to check on Monday. There’s more on the whole pipeline in first-time guest follow-up in Planning Center.
2. Repeat guests who never converted. Conditions: checked in at least twice in the last 90 days, AND membership status is not Member. The Check-Ins attendance condition carries a frequency setting alongside its date range (event, location, time, how recently, and how many times), so the count is part of the rule rather than something you do afterwards in a spreadsheet. What to do with it: this is the highest-value list in your database and the one nobody builds. Someone who has come three times has already decided something. Hand it to whoever does hospitality, not to an email tool.
3. New households with children. Conditions: created in the last 30 days, AND household includes someone under 12. Set the list to return primary contact. What to do with it: kids ministry welcome, and the invitation into whatever your on-ramp is. Returning the primary contact means you get one adult per family instead of six rows for the Hendersons.
4. Connect cards with nobody assigned. Conditions: filled out your connect-card form in the last 30 days, AND a none rule containing “has a card in your follow-up workflow.” Both halves are real conditions, not just automation triggers: People has a Forms condition (pick a form, pick a timeframe, or “any form”) and a Workflow condition where you pick the workflow and then the card criteria you care about. What to do with it: run it weekly as an audit. It should be empty. When it isn’t, something in the hand-off broke, and you’ve found it in a week instead of a quarter.
Drift and absence
5. Members who have gone quiet. Conditions: membership status is Member, AND status is active, AND a none rule containing “checked in between 60 days ago and today.” What to do with it: this is your pastoral care list, and it will be longer than you expect the first time. Sort it by how long they’d been around before they stopped. A family of eight years is a different call from someone who came for a term. More on reading it properly in how to find out who stopped coming to your church.
6. Attends regularly, not in a group. Conditions: checked in within the last 30 days, AND a none rule containing “is a member of any group.” What to do with it: give a groups pastor a concrete invitation pool. Group membership is evidence of a relationship beyond the weekend, not proof of retention. Worth building its sibling too: people who are in a group and have missed the last several group events; Groups conditions cover missed events as well as attendance.
7. Volunteers who have stopped attending. Conditions: scheduled to serve in the last 90 days, AND a none rule containing “checked in between 45 days ago and today.” Services does contribute a condition, built against a service type and a team over a date range, so “still on the roster” is expressible without maintaining a tag by hand. What to do with it: treat the combination as a prompt for the team leader to check the record and ask what changed. A change in serving and attendance can reflect work, health, family circumstances, data gaps or disengagement; the List cannot diagnose which.
Giving
Two things to know before you build any of these, because both will hand you a wrong list and look confident doing it. Only successful donations count: failed and in-process gifts are excluded from the results. And amount conditions apply per donation, not cumulatively: a rule for “gave over $100” returns people who made one single gift over $100, and silently omits the household that gave four times at $30. If you want cumulative totals, Lists is the wrong tool and you’re in Giving’s reports.
8. Gives but doesn’t attend. Conditions: gave at any point in the last 90 days, AND a none rule containing “checked in between 60 days ago and today.” What to do with it: a very short list at most churches and worth every minute. These households are still committed enough to keep giving while something has changed about coming. That’s a conversation, and it’s rarely about money.
9. Recurring givers. Conditions: recurring donor status is a documented Giving condition, so this is a one-condition list. What to do with it: two uses. One is thanking them specifically. The other is reviewing failed recurring gifts promptly; a failure may be a payment problem rather than a donor decision, but confirm the reason before contacting anyone.
10. Gave last year, nothing this year. Conditions: gave between 1 January and 31 December of last year, AND a none rule containing “gave between 1 January this year and today.” What to do with it: read it before you act on it. Joined spouses, seasonal patterns, fund changes and payment states can create false positives. I’ve written up the full false-positive checklist for lapsed givers, because this is a review queue, not a calling list produced without verification.
Serving and groups
11. Every group leader, in one place. Conditions: attended at least one group event in the last six months, with role narrowed to leader. Lists reaches group roles through the Groups attendance condition, and we haven’t found a documented bare “is a leader of a group” membership condition, which means a leader who hasn’t been marked present in six months drops off. Keep a Leaders tag alongside it if your attendance-taking is patchy. What to do with it: leader communications, training invitations, and the annual “who is actually leading something” audit. Share it with your groups director rather than re-exporting it for them every term.
12. Background checks expiring. Conditions: in a kids-ministry group or on your volunteer roster, AND background check expires within the next 60 days. Since September 2025 background checks are a single top-level condition covering status, results and expiration in one place, with pending-status conditions reading only the most recent check. Expiration within a window is the setting you want here. What to do with it: monthly, with refresh on. This is the list that stops a compliance problem being discovered by somebody else.
Operations and hygiene
13. Kids ageing into the next ministry. Conditions: grade is your final elementary year, OR turns 12 within the next six months. Set the list to return parents. What to do with it: make the upcoming age or grade transition visible early enough for an invitation and handoff. Returning parents means you can contact the household adults rather than the child record.
14. Birthdays and anniversaries this month. Conditions: birthdate falls in the current month. Build the anniversary version separately. What to do with it: obvious, but the reason to make it a list rather than a report is the automation: it can feed a card or a note without anyone opening it. Set refresh to nightly so it rolls over on its own.
15. Unreachable actives. Conditions: status is active, AND a none rule containing “has an email address” and “has a mobile number.” What to do with it: run it before every all-church send and hand it to the welcome desk. Every name on it is somebody your church cannot reach, which quietly caps everything else in this article. Build its multi-site sibling alongside, active people with no campus assigned, because that one breaks every per-campus number you’ll ever produce.
What to do with a list once it exists
A list that only you can see is a saved search. Three things turn it into infrastructure.
Categories and stars. Lists get filed into categories and starred for quick access. Once you’re past about thirty lists this is the difference between a tool and a junk drawer. Name them so the name says what the rule does: “Members, no check-in 60d” beats “Pastoral care” by a mile in six months’ time.
Sharing. A List is private to whoever made it until they share it. Add collaborators, and give the person who actually uses it Manage rights if they should adjust the rules. Building or editing a condition from another product requires permission in that product, so a collaborator without Giving access can’t add or edit a Giving rule. Test the exact role with a non-admin account before sharing anything financial.
Automations. A list can act when its membership changes. The documented triggers are someone being added to a list, someone being removed from one, and someone submitting a form; the actions include sending an email and adding the person to a workflow. That’s the bridge from Lists to Workflows, and it’s how a guest list becomes a follow-up process rather than a page somebody visits.
Automations run when the List refreshes and somebody is added or removed. A manually refreshed List can therefore run its automations; the limitation is that nothing happens automatically while no scheduled or manual refresh occurs. In the 1 August aggregate snapshot, active List records reported 570 configured automations and 72 paused automations. Treat those as dated counts, and audit paused automations directly rather than assuming they were intentionally left off.
There’s also a Mailchimp sync, if that’s where your email lives.
Where Lists stop
Here’s the wall, and it’s a structural one rather than a missing feature.
A List is primarily a current person set. It tells you who matches after the latest refresh. Planning Center Home’s List results widget can graph a List’s total over a selected timeframe and compare Lists side by side, so the claim that no count history exists is no longer accurate. What it does not preserve indefinitely is the identity of every person who matched on every prior date. A line can tell you the total changed; it cannot necessarily reconstruct all the names behind March’s point.
Departures are a live wire with limited history. “Removed from a List” is a real automation trigger, so Planning Center can react when someone drops off “attends regularly” or “recurring givers.” It only captures the exit if the automation was armed, and automation history is limited to 32 days. The List results trend preserves totals rather than an indefinite identity-level membership ledger, so “exactly who came off this List last quarter?” still needs an earlier snapshot or another durable record.
Conditions are membership tests, not measurements. You can ask whether someone gave in the last 90 days. You cannot calculate whether they gave less than they did last year. You can ask whether someone checked in recently, but an arbitrary comparison of their current attendance rhythm with their own earlier rhythm needs the dated records. Yes/no questions can be composed into sophisticated shapes, and the at least N of trick gets you closer to a multi-signal person set. It still does not put the underlying measurements on the row.
The operational failure modes are simpler: a List that nobody refreshes becomes stale, and an invalid List needs somebody to act on the Needs attention signal. Assign an owner, record the intended refresh mode, and review both the refreshed-at timestamp and invalid queue.
None of this is Planning Center doing something wrong. Lists are a segmentation tool and they’re a good one. Segmentation answers who, and it does it well. Trend answers how is this changing, and that’s a different kind of question that needs a different kind of storage, somewhere the answer from last month still exists.
Making a list into a metric
That’s the specific gap Parable fills. It reads People, Giving, Check-Ins, Groups and Services from your Planning Center account every night and keeps the history, so the same definitions you’ve built as lists become things with a shape over time.
Practically: you describe the group in plain English, members who haven’t checked in for 60 days, and you get the people. Planning Center now does part of this itself: since January 2026 its list builder can draft a List from a plain-English description, and Home can already graph a List’s total. What’s left, and what this gap actually is, is durable identity-level history and alerts across the joined product data, Giving included, so “who came off this definition since Easter?” can be answered without having armed a specific List automation beforehand.
Everything above still works without any of that, and if your church is small enough that you’d notice a family missing, it’s probably enough. Build the fifteen. Turn refresh on. Share them with the people who should own them.
Just don’t mistake the current names for historical membership. Use Home when the total trend is enough; preserve snapshots when the identities behind earlier points matter.