Bulk delete & restore

GCM never hard-deletes member records from the bulk-actions module. Every "delete" is a soft delete — the row gets a deleted_at timestamp and vanishes from every dropdown and list, but stays in the database for 30 days. During that window an admin can restore it as if it never left.

How to bulk delete

Open the members module, filter or select the members you want to remove, and click Bulk actions → Delete.

The confirmation dialog shows:

• The selection count.
• The breakdown by member type — so you can catch a misclick before it happens.
• A red Yes, soft-delete N members button.

Click it and the action queues. The selected rows get deleted_at = now() and a deleted_by user ID. They no longer appear in the members list, in dropdown pickers, in reports, or on the dashboard.

Soft-delete is not the same as marking lost

Deleting a member is for cleanup — duplicates, test rows, mistakes. Marking someone lost records that they've left the church but keeps the record visible and reportable. See Active vs lost members. Don't bulk-delete people who simply stopped attending — mark them lost instead.

The recycle bin

Soft-deleted members live on a separate page: Members → Deleted (or /members/deleted).

Each row shows:

• Name, member type, the org unit they were in.
• Deleted at timestamp.
• Deleted by user.
• Days remaining until hard-purge.
• Two buttons: Restore and Permanently remove.

Click Restore on a single row, or filter to a batch and use Bulk actions → Restore to bring back many at once. Restored rows get deleted_at = null and re-appear in lists, dropdowns, reports — exactly as they were before deletion. Their attendance, donations, group memberships, and ministry assignments all come back along with them.

The 30-day window

A nightly background job hard-deletes rows where deleted_at < now() - interval '30 days'. Once that runs, the data is gone — no restore.

If you need to recover a row after 30 days, the only option is restoring from a database backup, which is a support ticket and an SLA-bound process. So if you've just deleted something important by accident, restore from the recycle bin today.

Permissions

Bulk delete requires members.delete. Bulk restore requires members.restore (typically granted to Administrators only). Permanent removal requires members.purge and is hidden behind a second confirmation that includes typing the org slug — there is no recovery from this action.

Don't bulk-purge during demos

The permanent-remove button is only useful for clearing test data after a sandbox session. On a production org, the recycle bin should run to its natural 30-day timeout — purging early closes the door on accidental-delete recovery.

Other bulk-action types and delete

You can also bulk-delete:

• Donations — same soft-delete pattern, 30-day window, same permission gates (donations.delete).
• Attendance rows — useful for fixing a botched check-in session. Soft-deleted attendance rows don't appear in reports.

For ministries, groups, schools, and meetings, deletion is a single-record action (not bulk) because the cascade impact is larger; see the relevant section's "Delete or archive" article.

What gets logged

Every bulk delete and restore writes one row per affected record to org_audit_log with the action key members.bulk_delete / members.bulk_restore, the actor user ID, and the affected member ID. The audit log is where you trace "who deleted Mary Smith and when".

Next steps

1. Bulk assign & attendance — the additive companion to delete.
2. Monitoring runs — track progress, retry failures.
3. Active vs lost members — the right mechanic for "left the church", as opposed to "delete the record".