A deceased donor record still has work to do

Do not delete a donor record when you learn the person has died. Mark the person deceased with the source and date you verified, stop every active communication path, repair household-facing fields, and keep the gift history intact.

The closeout has five parts: evidence, status, audience suppression, household repair, and open work. It is complete only when the next appeal excludes the person and the surviving household record still reads correctly.

Verify the person before changing the status

Start with identity. A returned envelope, unfamiliar name, or possible match from an external list is a reason to review the record, not enough evidence to change it.

Record the smallest useful evidence packet:

• the contact ID you reviewed;
• who or what reported the death;
• the date your team learned about it;
• the date of death, only when known;
• the staff member who confirmed the change.

Do not guess a precise date. Blackbaud's current deceased-constituent workflow accepts a partial date or no date and keeps separate confirmation and source fields. Those exact fields are product-specific, but the underlying rule travels well: preserve what you know and how you know it.

If the match remains uncertain, put the record in a review queue and suppress the risky mailing while someone verifies it. Do not merge or erase the contact to make the queue disappear. The duplicate donor record checks still apply when two similar names are involved.

Preserve the donor and gift history

Change the person's lifecycle status without removing the record that explains past gifts, acknowledgments, relationships, and staff decisions.

Argenta's current database-cleanup guidance recommends suppressing rather than deleting a deceased donor record so the giving history remains available. Blackbaud likewise retains the constituent information after the status change.

Your own retention policy may require different fields or access controls. The safe operational default is to keep history available to authorized staff while removing the person from active fundraising work. A deceased status should not rewrite prior gift ownership, move gifts to a spouse, or turn an old household total into a new transaction.

Check every communication audience

Do not assume the deceased flag reaches every mailing list. Status and audience rules are separate controls, even when one product updates both.

Salesforce NPSP currently applies Do Not Contact, Do Not Call, and Email Opt Out when a contact is marked deceased. Its guidance still tells users to filter marked contacts out of communication reports. That second control matters when a saved report, synchronized list, or prior export can outlive the status change.

Check each path your team actually uses:

• CRM mailing and call reports;
• synchronized email or SMS audiences;
• saved campaign lists and scheduled exports;
• recurring direct-mail files held by an outside partner.

Remove or exclude the person in the source system and confirm the downstream result. Do not delete an email address merely to prevent a send. A status or suppression rule leaves an auditable reason and avoids turning a communication problem into missing donor data. The donor communication preference workflow uses the same principle for donor instructions: keep the record, then control which purpose and channel may use it.

Repair the household-facing fields

A deceased status can leave a living person under the wrong household name, salutation, or primary contact. Review those fields separately instead of copying the deceased person's status onto the household.

Salesforce's current workflow removes the deceased person's name from household naming and greeting fields and may assign another household member as primary contact. Use those changes as a review checklist, not as proof that another CRM made them or that the surviving person's preferences changed.

For a linked household, check:

• the household label and postal salutation;
• the surviving primary contact;
• any joint-mail rule;
• the living person's own email, phone, and mail choices.

Do not infer the survivor's preference. Update the shared mailing presentation only from verified information, and leave each person's historical gifts on the person who made them. The donor household record model explains why a relationship may change while person-owned facts remain in place.

Close future work without inventing instructions

The contact may still own open tasks, a scheduled appeal, portal access, or an active recurring gift. Route each item to a named staff owner for review. A deceased status is not, by itself, an instruction about an estate, a payment method, a subscription, or another person's access.

Close outreach tasks that should not happen. Reassign a household relationship task only when the surviving person is the correct owner. For any active payment schedule or unsettled transaction, follow the platform's supported process and your organization's policy; do not silently cancel, transfer, or edit financial records as part of the contact cleanup.

Run a two-export closeout test

Test the result before the next live send:

1. Run the normal CRM appeal or call-list export. The deceased contact should be absent.
2. Run or preview the connected email, SMS, or mail-vendor audience. The same contact should still be absent after synchronization.

Then open the household view. The surviving person should remain available only under their own current instructions, and prior gifts should still trace to their original owners.

If the record fails either export, the closeout is incomplete. Fix the source rule, refresh the downstream audience, and test again. The work is finished when the person is excluded from future outreach, the living relationship record is accurate, and the historical trail still answers what happened.

Keep the history and stop the next send