Audit your Planning Center people data with AI

The goal is a prioritised cleanup list with evidence, not a bulk edit. A hygiene audit is read-only: it finds problems, sizes them and says what a person should do about each. Nothing is merged, deleted, re-linked or updated during the audit. A list that says "merge these 14 pairs after checking" is useful; a list that has already merged them is a mistake the user cannot easily undo.

Scope matters more than thoroughness. A church database can hold tens of thousands of people. Audit one slice at a time and say which slice it was.

1. Confirm the account and scope before searching

Call people_current_organization first. Confirm the organisation name back to the user, because a connection can be authorised for more than one account and cleaning the wrong one is the costliest mistake here. Note whether the People product was authorised; if it was not, stop and say so (see essentials).

Then fix the slice. Ask, or infer from the request, one of:

• the whole database (only if the user explicitly wants it, and expect pagination across many calls),
• a campus (people_church_campuses lists them),
• a list (people_lists and people_list_results), which is the safest and most common scope,
• a field or form area, such as records missing a particular field.

Write the slice into the report header. Findings from a list of 200 people must never be presented as findings about the whole database.

2. Find duplicates by evidence, not by name alone

Use people_search with name fragments, then compare candidates on stronger signals:

• Shared contact details: the same email address or phone number across two records is a strong duplicate signal. Same name with different contact details is a weak one: two people called "Sarah Johnson" in one congregation is normal.
• Same household: two records already in one household are probably intentional, not duplicates (spouses, teenagers). Do not flag them.
• Birthdate and address: agreement on both is strong; disagreement on either usually means different people.
• Nicknames and spelling: "Bob"/"Robert", "Jon"/"John", transposed letters, a married name on one record only. Treat as a candidate, never as a certainty.

Grade each candidate pair: likely duplicate (shared email or phone plus matching name), possible (name and one other matching signal), unlikely (name only). Report only the first two in detail.

3. Check completeness where it actually matters

Missing data is only a problem when it blocks something the church does. Prioritise:

• Contact route missing on people who are active volunteers or in groups: they cannot be reached when a roster changes.
• Household links missing for people who appear to be family (same surname, same address on another record, children without a parent link). Use people_households to check.
• Required form or field values empty for records that went through a form (people_form_submissions) where the field was mandatory. An empty value on a record that never touched that form is not a defect.
• Stale field data: check people_field_data and people_field_definitions for values that are clearly out of date (for example, a "current grade" field still set to a grade from several years ago). Flag the pattern, do not guess the correct value.

Use people_field_definitions to learn which fields are required or meant to be used before calling any gap a gap.

4. Check the notes and workflow residue

Old notes and abandoned workflow cards are a common hidden mess: a card "Follow up with new visitor" still open from two years ago, or a note category used inconsistently. Check people_workflow_cards and people_notes only as a sample, to see whether the problem is widespread. A few stale items are normal; hundreds suggest a process was abandoned, and that is worth saying.

5. Common patterns and traps

• Two records, one person, different households. Often caused by a family member joining through a different form. Do not merge households automatically; the household membership decides who gets the family mailing.
• "Duplicates" that are a parent and an adult child with the same name suffix (Jr./Sr.) or the same address. Flag as unlikely.
• Data entry in the wrong field (a phone number in the email field, a full name in the first name field). Easy to fix once spotted, so list these as quick wins.
• Missing values that are really "not applicable" (no email for a child). Do not count these as gaps.
• Scope inflation. A search that returns the first page only looks like a small problem. Check the total before reporting a count, and say if you stopped early.
• Privacy. Hygiene audits surface sensitive data such as safeguarding notes, background-check status and family circumstances. Summarise the existence of such issues without repeating the sensitive content. Never copy that content into the cleanup list.

Output

Account: <organisation name confirmed via people_current_organization>
Slice audited: <whole database | campus | list name | field>, <N> records checked (<total if known>)
Not checked: <products, fields or pages not reached>

Likely duplicates: <count> pairs
- <Name A> / <Name B>: <matching signals>. Action: review and merge in Planning Center
Possible duplicates: <count> (listed for review, not recommended for merge yet)
Missing household links: <count>
Required or key fields empty: <count>, by field: <field: count>
Stale field values: <count>, pattern: <description>
Quick wins (wrong field, obvious typo): <count>
Sensitive items noticed, not reproduced: <count and type only>

Next step: <the one thing to do first>

Rules

• This is an audit. Do not merge, delete, re-link, edit or move any person, household, note, card or field value. Changing any record is a write action and needs the user's explicit yes, item by item, after they have reviewed the list. Wait for the user's explicit yes before any such change.
• Do not switch the active organisation or the product authorisation to widen the search. Changing it needs the user's explicit yes, and you should wait for the user's explicit yes before doing so.
• Never state that two records are the same person without matching evidence; say "likely" and show the signals.
• Never copy safeguarding notes, background-check results or other sensitive content into the output.
• Never report a count without saying which slice it covers.

Done when

• The organisation and slice are confirmed in the report header.
• Every duplicate or gap listed has at least one concrete signal behind it.
• Nothing has been changed, and the output states that the user must approve any change.
• The "Not checked" line is honest about what was out of scope or not reached.