Bulk actions β
Bulk actions are how you change many member records at once. Instead of opening 200 profiles to set the same custom field, you select all 200 from the member list and run a single action. The work runs in the background, you can watch the progress bar, and any rows that fail come back with a retryable error.

Every bulk action β whether triggered from the member list, the connection network, or a filtered view β lands in the same history at Bulk actions in the sidebar. That history is the source of truth for "what got changed, by whom, when, and did it work."
When to use a bulk action β
Reach for a bulk action when:
- You need to change the same field on more than a handful of members.
- You want to message a filtered slice (e.g. "everyone in the Youth ministry who hasn't checked in for 4 weeks").
- You're cleaning up β marking inactive members as lost, deleting test records, or geocoding a backlog of addresses.
- You're onboarding β assigning a new intake of members to a starter group or workflow.
For a single member, the action bar inside their profile is faster. Bulk actions earn their cost once your selection passes about ten rows.
What you can do in bulk β
| Action | What it changes |
|---|---|
| Bulk edit | Any standard field, junction (org unit / ministry / school), or custom field |
| Send message | WhatsApp, SMS, or email through the configured channel |
| Assign or attend | Org unit, ministry, group, school enrolment, workflow trigger, attendance for a meeting |
| Mark as lost / delete / restore | Soft-archive members, soft-delete them, or restore from lost |
| Geocode addresses | Re-runs the geocoder on members whose addresses changed |
Each action has its own row in the process-bulk-action edge function, so the validation rules are the same as the single-member equivalents. You can't bulk-edit a field a single member couldn't have.
How a bulk action runs β
- You select members and pick an action. The UI opens a confirmation dialog with the count of affected rows.
- On confirm, a
bulk_actionsrow is inserted with statusqueuedand the edge function is invoked. - The function validates that every target member belongs to your org, then flips the row to
processing. - Members are processed in chunks of 50. After each chunk, the row's
success_count,failed_count, andfailed_itemsare updated so the UI's progress bar moves in real time. - When the last chunk finishes, the status moves to
complete(any successes),failed(zero successes), or staysdelegatedfor actions handed off to another queue (geocoding, messaging). - You get an in-app notification with the result and a link back to the action's detail page.
TIP
Two bulk actions run in parallel per org at most. Anything beyond that stays in queued until a slot frees up β the UI shows it as queued, not stuck.
Status reference β
| Status | Meaning |
|---|---|
queued | Row exists; processing hasn't started yet. Usually flips within seconds. |
processing | Chunks are being applied. Progress bar moves. |
delegated | Handed off to another queue (messaging, geocoding). Completion is tracked by a reconcile cron. |
complete | All chunks done. May still include per-row failures β check failed_count. |
failed | Every target row failed. Look at the failed-items table. |
cancelled | You stopped the action mid-flight. Successes already applied stay applied. |
Permissions β
You need the members.edit permission to start any bulk action. Sending messages also requires messaging.send. Platform admins can see every org's bulk actions when impersonating; the org's own admins see only their own.
WARNING
Bulk delete is permanent after 30 days. Until then, deleted members live in the recycle bin and can be restored β including by a different admin. After 30 days the row is hard-deleted by a nightly job.
Next steps β
- Create a bulk action β the selection-and-confirm flow.
- Bulk edit β the most-used action.
- Send a message β for outreach and announcements.
- Assign and attend β wire members into the right org structure.
- Mark as lost / delete / restore β for member-lifecycle changes.
- Monitoring and retries β when something doesn't go through.