GCM Docs

Appearance

Import history ​

Bulk imports (members, donations, attendance from CSV) run as background jobs so the browser doesn't have to hold a connection open for 30,000 rows. The Import History tab on Data & Logs shows the last 50 jobs your org has run, with row counts so you can see at a glance whether the import finished cleanly.

Open it from Data & Logs → Import History in the sidebar.

Import history table with status and row counts

Reading the table ​

Each row is one import job. The columns are:

ColumnMeaning
Statusqueued, processing, complete, or failed. A green badge means complete; grey means still in flight or queued.
TotalNumber of data rows in the uploaded CSV (excludes the header row).
ProcessedRows the worker has finished. While the job is running, this climbs in real time on refresh.
FailedRows that errored out — bad emails, missing required fields, foreign-key violations, duplicates that hit the skip-duplicate rule.
CreatedWhen the upload was kicked off, in your org's timezone.

A healthy job ends with status = complete, processed = total, failed = 0. Anything else needs attention.

Job lifecycle ​

When you upload a CSV from the Bulk Actions module:

  1. The file is parsed and a row is inserted into import_jobs with status = queued.
  2. A worker picks it up, sets status = processing, and starts inserting rows in batches of 100.
  3. Each successful row increments processed_rows; each failure increments failed_rows and appends an error to a per-row failure list.
  4. When all rows are attempted, the worker sets status = complete (even if some rows failed — partial success is still success).
  5. If the worker itself crashes (network blip, edge function timeout for a 50k-row job), the job is left at status = processing until the next worker picks it back up; jobs older than 30 minutes in that state are marked failed.

TIP

You can navigate away from Bulk Actions while an import is running. The job continues server-side and you can come back to this page to check progress.

What "failed" rows actually means ​

The failed_rows count is rows the worker rejected, not rows it couldn't process at all. Common reasons:

  • Validation failure — email isn't a valid email; phone doesn't match the country format; a required field is blank.
  • Foreign-key miss — the CSV references a group, ministry, or fund that doesn't exist yet. Create the parent rows first, then re-import.
  • Duplicate skip — if you turned on "skip duplicates" in the upload UI, rows matching an existing member by email or phone count as failed (technically skipped, but the column doesn't differentiate).
  • Permission denied — your role doesn't have write permission on the target table for some rows. Rare; usually only happens with custom RBAC setups.

The first 100 row-level errors are stored in the job's error log. The bulk-actions UI shows the first 10 inline with a "download all errors" CSV button.

Triaging a partial-failure import ​

  1. Open the failed job from Import History.
  2. Click Download error CSV — it's the original file with two extra columns: __row and __error.
  3. Fix the errors in the CSV (or split out the problem rows).
  4. Re-upload just the corrected rows. The duplicate-skip rule will prevent re-importing rows that already succeeded.

WARNING

Don't re-upload the original CSV without duplicate-skip on after a partial failure. You'll create duplicates of every row that succeeded the first time.

Differences vs the audit log ​

The audit log captures what the import did (one row per inserted member, with actor_email = system). Import History captures whether the job itself finished. Use:

  • Import History when you want to know "did my import work, and how many rows didn't?"
  • Audit log when you want to know "what specifically did this import touch?" — filter the audit log to the time window of the job.

A typical 1,000-row member import writes 1,000 rows to the audit log and 1 row to import history.

Retention ​

Import jobs and their error logs are kept for 1 year on all paid plans (90 days on Starter). The original uploaded CSV is deleted from storage after 30 days regardless of plan — long enough for re-imports and forensics, short enough to keep storage costs sane.

If you need the original CSV for compliance, download it from Bulk Actions → History (a different view that exposes the raw file) before the 30-day window closes.

See also ​