Skip to content

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.

Bulk actions history

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 ​

ActionWhat it changes
Bulk editAny standard field, junction (org unit / ministry / school), or custom field
Send messageWhatsApp, SMS, or email through the configured channel
Assign or attendOrg unit, ministry, group, school enrolment, workflow trigger, attendance for a meeting
Mark as lost / delete / restoreSoft-archive members, soft-delete them, or restore from lost
Geocode addressesRe-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 ​

  1. You select members and pick an action. The UI opens a confirmation dialog with the count of affected rows.
  2. On confirm, a bulk_actions row is inserted with status queued and the edge function is invoked.
  3. The function validates that every target member belongs to your org, then flips the row to processing.
  4. Members are processed in chunks of 50. After each chunk, the row's success_count, failed_count, and failed_items are updated so the UI's progress bar moves in real time.
  5. When the last chunk finishes, the status moves to complete (any successes), failed (zero successes), or stays delegated for actions handed off to another queue (geocoding, messaging).
  6. 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 ​

StatusMeaning
queuedRow exists; processing hasn't started yet. Usually flips within seconds.
processingChunks are being applied. Progress bar moves.
delegatedHanded off to another queue (messaging, geocoding). Completion is tracked by a reconcile cron.
completeAll chunks done. May still include per-row failures β€” check failed_count.
failedEvery target row failed. Look at the failed-items table.
cancelledYou 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 ​

  1. Create a bulk action β€” the selection-and-confirm flow.
  2. Bulk edit β€” the most-used action.
  3. Send a message β€” for outreach and announcements.
  4. Assign and attend β€” wire members into the right org structure.
  5. Mark as lost / delete / restore β€” for member-lifecycle changes.
  6. Monitoring and retries β€” when something doesn't go through.