Monitoring bulk-action runs

Every bulk action you fire — assign, attendance, delete, send-message, edit — shows up on /bulk-actions as a row in the run history. That page is your inspection point: did the run finish, did rows fail, do you need to retry, and what exactly changed.

The page auto-polls every 5 seconds while any run is active, so you don't need to refresh.

Run states

Each row has a status badge:

State	Meaning
Queued	The run is in the work queue but the worker hasn't started it yet. Usually milliseconds.
Running	Worker is processing rows. The progress bar shows N of M done.
Completed	All rows applied with no failures.
Partial	Some rows applied, some failed. Most actionable state — you'll usually retry.
Failed	A system-level error stopped the run (database unavailable, permission revoked mid-run).
Cancelled	You hit Cancel. Already-applied rows stay; pending rows skip.

Opening a run

Click any row and you'll see the run detail page:

• Summary cards — total rows, applied, failed, skipped, duration.
• Selection snapshot — the exact list of member IDs the run targeted, captured at click-Apply time.
• Failed items — every row that didn't apply, with a reason.
• Retry failed button (when failures exist).
• Cancel button (when the run is queued or running).
• Re-run button (when the run is finished, regardless of outcome).

The failed-items list

A row fails when the worker tries to write it and the database rejects the operation. Common reasons:

Error	What it means	Usually a
permission denied	The current user lost the permission since clicking Apply	Permission was revoked mid-run
member not found	The member was deleted by someone else during the run	Race condition
unique violation	The write would create a duplicate	Re-running an old assign on members already in the target
null value violates not-null	A required field was missing	Almost always a workflow misconfiguration

The reason text appears inline next to each failed member, so you can scan the list and decide if the run is worth retrying as-is or if you need to fix the underlying problem first.

Retry-failed is idempotent

The retry button re-queues only the rows that failed, with the same parameters. Already-applied rows stay applied — the action doesn't reapply them. Safe to click as many times as you need until either every row succeeds or the failure reason changes (e.g. permission was restored).

Cancel mid-flight

For long-running actions on thousands of rows, you can Cancel from the run detail page. The worker stops fetching the next batch and the run moves to Cancelled. Already-applied rows stay applied. The selection snapshot is preserved, so you can re-run on the same list later.

Cancel is not undo

Cancelling stops further writes, but it does not roll back what's already been written. If you cancelled a delete and 200 of 500 members were already soft-deleted, those 200 stay soft-deleted. Use the recycle bin to restore them if needed.

How long is the history kept

Run rows live in bulk_action_runs and stick around for 90 days. After that, a nightly job archives them off the live table. Permanent audit of who-changed-what is in audit log, which retains indefinitely.

Notifications

If a run takes more than 30 seconds, GCM emails the user who started it when it finishes. If the run hits Partial or Failed, the email includes a link straight to the run detail page. For runs under 30 seconds you'll see the result in-page, no email.

Next steps

1. Bulk assign & attendance — the most common bulk actions.
2. Delete & restore — soft-delete and the 30-day window.
3. Audit log — long-term record of what changed.
4. Users & roles → Audit log — for tracing permission grants and revokes.