How account deletion (anonymize-all) works

This page explains what actually happens when a member’s account is deleted, so you know what to expect before you approve a request.

The short version

Deleting a member’s account doesn’t erase their records from MapleGather — it anonymizes them. The records stay where they are, and the personal details inside them are replaced with stand-in values: their name becomes something like “Anonymized Member” plus a random ID, their email becomes an address that can’t be used, and other identifying fields are cleared. This happens across your organization’s data immediately once you approve the request. There’s no waiting period and no undo.

Knowing that the records are kept, rather than removed, is the part most worth carrying into the decision — it’s why an anonymized member can still appear in a count, a report, or an export after the request is fulfilled.

Three things the process does not reach are worth knowing before you answer a member: free text someone typed onto a financial record, donation tax receipts already issued to them, and the contents of a file the member uploaded. All three are covered below.

How it works

Anonymizing replaces personal details in place

When you approve a deletion, MapleGather works through the areas of your organization’s data that hold this person’s information and overwrites the personal details it covers in each one. Nothing is removed: every record survives the process, with stand-in values written over the identifying fields the process reaches. It does not reach every field of every record — the two places something identifying can remain are set out further down.

The areas it reaches are:

• Member records — the member’s profile, their contact email addresses, their custom field values, admin notes about them, their activity history, and their household’s name and shared address.
• Memberships — their membership records, any household memberships, and any application they submitted to join.
• Billing and payments — refund requests, which carry a copy of the member’s name. Payments and invoices are reached differently: nothing on those rows is rewritten, and the identity on them changes only because the member record they point at has changed. Free text typed onto them stays as written — see below.
• Donations — including donor name, dedication and thank-you details. Tax receipts already issued for those donations are the exception — see below.
• Events — their registrations, guest lists and any custom answers they gave when signing up.
• Emails — the delivery record of messages sent to them, including the address each went to.
• The member directory — the note they wrote about themselves on their directory entry. Their directory privacy settings themselves aren’t changed.
• Your website — submissions they made through your public forms, including every answer they typed, the email address and IP address the submission carried, and the names of any files they uploaded with them. It also reaches other people’s submissions in one narrow way: where another respondent’s answer happens to contain this member’s email address, that single answer is removed and the rest of that person’s submission is left intact.
• Imported data — records brought in from a previous system, where those records carry their name or email.
• Mobile devices — the device registrations used to send them push notifications.
• The security log — and not only if they were an admin. If they were, the record of the actions they took is anonymized, along with the IP address logged against it. But for any member, admin or not, the before-and-after snapshots frozen onto log entries about them are cleared as well, including the snapshot on any admin override applied to their record. Their support tickets are covered too: the subject, body, page details and any screenshot reference they submitted are cleared.

Some things aren’t anonymized — they’re switched off

A few records hold no personal details at all, so there is nothing in them to replace. What deletion does to those is end something that was still live:

• Any sign-in or verification link still outstanding for that member stops working.
• Any unclaimed event waitlist link, unsubscribe link or email-confirmation link of theirs stops working.
• If an admin is previewing the site as that member at the time, that preview session ends.

This matters because it’s the one part of the process that changes what someone can still do, rather than what a record says.

Records are kept, and not only financial ones

Certain records have to be kept, and payment history and invoices are the clearest example — they’re retained for tax and audit reasons. Nothing on the payment or invoice row itself is rewritten: the identity on it changes because the member record it points at has been anonymized, so the name that resolves from the record becomes the stand-in.

That is a retention decision, not a promise that nothing identifying survives on those records. Free text that was typed onto a financial record stays exactly as it was written — an invoice’s memo, its void reason or its line items; a payment’s description, its check number, or the processor’s decline message. If the member’s name, or anything else about them, was written into one of those fields, it is still there after the deletion, and it is meant to be: these are the records your organization is required to keep intact. So if a member asks whether their name survives anywhere, that is the honest answer — and if they need a specific one, read those fields rather than assuming.

They aren’t the only ones. Website form submissions are also kept: the row stays as evidence that a submission happened, and every answer the person typed is cleared. Consent history is kept too, as a permanent, tamper-evident compliance record, anonymized in a way that keeps the record’s integrity intact. The general rule is the one in the section above — records are retained and their personal details are replaced, rather than the records being removed.

Donation tax receipts stay exactly as issued

When a donation’s tax receipt has already been issued, the receipt document is kept exactly as it was issued — including the donor’s name on it. The deletion anonymizes the donation record itself, but it doesn’t rewrite, re-issue or delete the receipt, because the receipt is your organization’s tax record of what it acknowledged.

The deletion preview tells you this before you approve: under store-donations you’ll see a DonationTaxReceipt row with nothing listed to anonymize and a note that issued receipts are kept as issued. After the deletion, the receipt is still available to admins from the donation, with the donor’s name on it. If a member asks whether their name survives anywhere, this is one of the places it does, on purpose.

Uploaded files: the name goes, the file itself stays

This is one of the places where anonymizing reaches least far — alongside the retained financial records and the issued tax receipts above — and it’s worth knowing before you tell a member their information is gone.

If the person uploaded a file through one of your public forms — a résumé, a signature image, a document — then the deletion clears the file’s name and clears the answers that pointed to it, so nothing in your organization’s data links that file back to them. The stored file itself is not deleted by the deletion request — and nothing else deletes it later either. MapleGather has no process today that removes a stored upload, on a schedule or otherwise, so the file stays in storage indefinitely. What the deletion takes away is every link from your organization’s data back to it.

So the honest summary is: a deletion removes the person’s answers and filenames, not the bytes they uploaded. If a member asks specifically about a file they uploaded, don’t tell them the file has been destroyed, and don’t tell them it will age out on its own — tell them it’s been unlinked and its name removed, and raise it with us if they need more than that.

It’s a single, all-at-once process

MapleGather doesn’t offer a partial or selective deletion — approving a request anonymizes everything at once, consistently, rather than leaving you to pick and choose. This keeps the process predictable, and means you don’t have to work out which areas to cover.

It runs immediately, with no undo

Once you select Approve & anonymize and complete the re-authentication step, the anonymization runs right away, not after a waiting period. There’s no way to undo it afterward, which is why the confirmation step exists and why MapleGather asks you to re-authenticate first.

Some obligations have to close first

If the member has an open subscription or an unpaid invoice, MapleGather shows you this before you can approve — you’ll need to resolve it first (for example, from Billing). This keeps a deletion from silently orphaning an active financial relationship.

Why it works this way

Anonymizing instead of hard-deleting lets MapleGather answer a member’s request to have their personal information removed while still meeting other legal obligations — like keeping tax and audit records — that a true delete would conflict with. Doing it as one consistent, all-at-once process, rather than a checklist of optional pieces, means the same treatment reaches every area rather than depending on who remembered what. Running it immediately on approval, instead of a delayed window, keeps the process predictable for both your organization and the member.

It’s a deliberate trade, and it’s worth being straight about which side of it you’re on when you answer a member: the records that held their details remain, and those details are replaced in the fields the process reaches — which is most, but not all, of the places they can live. The two exceptions are the ones named above: free text on a legally-retained financial record, and the contents of an uploaded file.

Edge cases and boundaries

• The preview you see before approving describes the process, not this particular member. It is generated from the same process that performs the deletion, so what it lists is what that process does — but it lists the records the process would reach whether or not this person has anything in them. Don’t read an entry as evidence that this member has data there, and don’t read a missing entry as evidence that they don’t.
• The preview is also incomplete today, and the part it leaves out is the part with the limit in it. Four of the eleven areas listed above — the member directory, your website, imported data and mobile devices — don’t appear in the preview yet. Your website is the one that matters here: the note spelling out the uploaded-file limit belongs to that area, so the preview will not show you the uploaded-file caveat. Until those areas appear, the “Uploaded files” section above is where you get it. The areas are still anonymized — it is only the preview that is missing them — and when they are added, nothing about the screen changes: the missing groups simply show up.
• If the member was also an admin for your organization, their past actions stay in the security log for accountability, but their name on those entries is anonymized as it is on the other records the process reaches.
• A deletion request can be denied instead of approved — for example, if the member’s identity couldn’t be verified, or if you’re required to retain their records for a specific legal reason. See Deny a data request with a reason.
• Anonymizing an account is separate from, and much more thorough than, archiving a member, which just hides them from your default list without changing any of their data.

Put it into practice

• Review and fulfill a data request (DSR) — the steps for approving or denying a request.
• Deny a data request with a reason — when a request shouldn’t be approved.