Reviewing imports and merging duplicates

Real parish data has duplicates and near-matches. Vianney surfaces them for review and merges only when you say so — keeping the richer record and losing nothing. Identity is never guessed: Vianney proposes, you decide, and nothing merges without your confirmation.

How duplicates are found

• Confident — the same first name (nicknames understood, so Mike and Michael count as one name), the same surname, and the same date of birth.
• Possible — the same first name and date of birth but a different surname. That is usually a maiden-name/married-name pair kept as two records, so each one is listed for you to look at individually.
• Only people with a date of birth on file are ever proposed. Without one there is nothing solid enough to match on, and Vianney would rather say nothing than guess.

Reviewing matches

• For sacraments with no ID to match on, Vianney sorts results into confident, ambiguous, and unmatched.
• Confident matches can attach automatically; ambiguous and unmatched ones wait for you to pick the person or create a new one. Nothing is dropped silently.

Merging duplicates

• 1. Vianney finds likely duplicates — the same person entered twice, or a maiden-name/married-name pair.
• 2. Each pair is shown with both records side by side, marked keep and merge in. The record kept is the newer one — the record created when the person set up their own household, which is normally their current, adult record.
• 3. You review each and confirm the merge.
• 4. On merge, every reference — sacraments, family links, insights, photo, ministries — moves to the surviving record, a former surname is kept as a maiden name, and the link to the parents of the absorbed record is preserved, so the merged person still shows their family of origin.
• 5. Details merge carefully rather than wholesale. The record you keep is the one being kept, so its own values win; the absorbed record's details fill only the gaps — the office should not lose "speaks Spanish" just because the duplicate was the one who had it.
• 6. The AI profile is not merged, because there is nothing in it to merge: it is a summary of the record, and the record just changed. The absorbed one is discarded and the survivor's is rebuilt from the merged facts on the next overnight pass.

Connect data carries over the same way. Group memberships move over, and so does any leader or sender role — if both records held a role on the same group, the stronger one (leader over sender) wins. Prayer requests and Connect's message and delivery history move across exactly as recorded, with no content changed. Conversation posts and private replies repoint to the surviving record too, and a posting suspension always carries over — if either record had its posting paused in a group, the merge keeps that pause rather than lifting it. Subscription preferences merge conservatively: an unsubscribe on either record always survives the merge, and a channel preference (email/text/both) can only get narrower, never wider — so a merge can never make someone more reachable than either record was on its own. SMS-consent attribution moves to the surviving record too. If a subscription record is damaged in a way Vianney can't safely interpret, that one merge is refused and reported rather than guessed at — your other merges go through unaffected.

When both records have a Safe Environment file

If both people carry a Safe Environment record, Vianney does not merge them. It stops before changing anything at all: both records remain, and every piece of clearance evidence on both sides — requirements, training, background checks, documents, expiry dates, notes and any restriction — is left exactly as it was. The pair is set aside for a Safe Environment coordinator to work through by hand, because combining two children's-protection files is a judgement no automatic rule should be making.

• The pair simply stays in your duplicates list instead of merging, and you can come back to it once a coordinator has decided.
• Working through a whole list of duplicates, only that one pair is skipped — every other pair merges normally in the same pass.
• The refused attempt is recorded in the audit trail as record identifiers and counts only, never the contents of anyone's file.
• Who counts as a coordinator is set by an explicit Safe Environment grant, not by job title — see Roles and what each can see.

If only one of the two has a Safe Environment record, the merge goes ahead and that file moves to the surviving record whole: every requirement, training record, background check, document, date, note and restriction comes across unchanged and still belongs together. A merge never rewrites clearance evidence, and never makes anyone look more cleared than they already were.

Ministry serving records follow the surviving record

• Blackout dates move across exactly as entered — the dates, the ministry they apply to, and the reason — and they keep governing: the scheduler will not place the surviving record on a date the absorbed record was unavailable.
• Assignment history moves too, and the name printed on a past roster is left exactly as it was printed. The historical roster still reads the way the parish published it, and the person's own portal schedule shows everything they served.
• A monthly cap — "serve at most so many times a month" — merges the careful way: the more restrictive of the two survives. No cap is the least restrictive setting there is, so a real number always wins; where both records name a number, the smaller one is kept; where they are identical, nothing changes. A merge can never make someone available more often than either record was on its own. See Availability, monthly caps, and blackout dates.
• If the two records disagree about some other serving preference Vianney has no rule for combining, that one pair is refused rather than guessed at — nothing changes and it waits for a person to decide.

Two things deliberately do not carry over

• A calendar feed link — the private link a minister can create in the portal to see their serving schedule in Google or Apple Calendar — is switched off on both records by the merge. It is a personal key, and the identity behind it has just changed. The person makes a fresh one from the portal in a click.
• An active accompaniment record — the named adult on file to accompany a young minister — is ended if either person appears in it, and the office records it again deliberately. A permission that depended on verifying who someone is is never inherited from a merge.

Tips

• Merging is always explicit and logged; a later re-import updates the survivor rather than re-creating the duplicate.
• Work through ambiguous matches a few at a time — your decisions teach the data to line up.
• Take the possible (different-surname) list one row at a time. An unrelated pair who happen to share a first name and a birthday is rare, but it is exactly the case that deserves your eyes.