Understanding Integration Logs

Integration Logs give you a complete, record-by-record history of everything that moves between WeGive and your connected CRM (Salesforce, Bloomerang, Virtuous, Planning Center, Neon, Donor Perfect, or Raiser's Edge). Every time WeGive pulls data in from your CRM or pushes data out to it, a log entry is created. This article explains where to find these logs, how to read every column, what each status means, how to interpret the Details and Progress views, and how to troubleshoot the most common situations.

What Integration Logs are for

Think of Integration Logs as the "flight recorder" for your CRM sync. They answer questions like:

• Did this donation successfully sync to my CRM?

• Why hasn't this donor record appeared in my CRM yet?

• Is a large sync still running, or did it finish?

• A record looks wrong in my CRM — what exactly did WeGive send?

• Did last night's pull from my CRM complete, or did it error out?

Each log is tied to a specific integration (the connection to your CRM) and, in most cases, a specific record (a transaction, donor, campaign, and so on). Logs are read-only — they record what happened; they don't change your data.

Where to find them

There are two places to view Integration Logs:

1. The full log (all activity)
Go to Settings → Integrations → Integration Logs. This shows every log across your whole organization, newest first, with filtering and sorting on every column. This is the right place to investigate sync health, find errors, or confirm a batch finished.

2. On an individual record
Open any record that syncs — for example a payment/transaction, donor, or campaign — and scroll to the Integration logs section near the bottom of the page (alongside Audit logs, Notes, and Activity history). This shows only the logs for that one record, which is the fastest way to answer "did this record sync?"

Note: The Integration Logs list intentionally hides "ignored" entries (records that no longer exist and can't be synced), so the list stays focused on meaningful activity.

Reading the columns

The Integration Logs table has many columns. Here's what each one means, left to right.

ID

The unique identifier for this individual log entry. Useful when sharing a specific log with WeGive support.

Model ID

The ID of the WeGive record this log is about — for example the transaction ID 31410527. Combined with Model, this tells you exactly which record was being synced. (Pull and batch logs that operate on many records at once may leave this blank.)

Model

The type of WeGive record involved. Common values include:

• Transaction — a donation/payment

• Donor — a contact/constituent

• Recurring Plan — a recurring donation schedule

• Campaign, Campaign Member, Campaign Fundraiser, Event, Registration

• Communication List, Consent, Household, Fund, Pledge, Soft Credit, Payout, Checkout, P2P Fundraiser, Donor Journey

Integration Type

Which CRM connection this log belongs to: Salesforce, Bloomerang, Virtuous, Planning Center, Neon, Donor Perfect, or Raiser's Edge.

Action (Type)

What the sync was doing. This is one of the most important columns. The actions fall into two groups:

Pulling data in (CRM → WeGive)

• Pull — an incremental pull of recently changed records from your CRM.

• Pull All — a full pull of all records (used for initial syncs or backfills). You'll also see scoped variants such as Pull All Donors, Pull All Transactions, Pull All Funds, Pull All Pledges, Pull All Campaigns, Pull All Households, Pull All Companies, and Pull All Communication List Donors.

• Pull Donors / Pull Contacts / Pull Transactions / Pull Campaigns / Pull Households / Pull Companies / Pull Soft Credits / Pull Allocations / Pull Fund Allocations — pulls limited to a single record type.

Pushing data out (WeGive → CRM)

• Create — creating a new record in your CRM (for example, a new donation Opportunity).

• Update — updating an existing record in your CRM.

• Push Missing — a cleanup pass that finds WeGive records that should exist in your CRM but don't yet, and pushes them. This runs automatically after a successful incremental Pull.

Batch operations

• Batch, Batch Missing, and the per-area batches (campaign members, communication list donors, tag donors) group large numbers of records together so they sync efficiently. A batch entry represents one "chunk" of a larger job.

Status

Whether the sync succeeded, is in progress, or failed. See the full status reference in the next section.

Details

A Click to view link that opens exactly what was sent or received. This is where you see the actual payload or the per-record results. See Reading the Details view below.

Progress

For long-running pulls, a Click to view link showing live progress — how many record types are done, and counts of added/updated/skipped/errors per type. See Reading the Progress view.

Progress Updated

The timestamp of the last progress update. For a running pull, a recent timestamp means it's actively working; a timestamp that hasn't moved in a while can indicate a stalled job.

Pull By

For pulls, which field WeGive used to query your CRM. Some integrations pull in stages — a primary pass, then a secondary, then a tertiary — to make sure related records are captured. The Pull By value tells you which pass this log represents. (Blank for push/create/update logs.)

Initiated

When the log was created — i.e., when the sync action started.

From / To

For pulls, the date range WeGive asked your CRM for. An incremental pull uses From = the moment of the last successful sync and To = now, so it only retrieves records changed in that window. These columns let you confirm exactly which time range a pull covered. (Some specialized pulls store record-ID ranges here instead of dates.)

File

For pulls, WeGive writes a detailed line-by-line log file. When a file is available, you can download it from this column (the download link is valid for 24 hours). These files are mainly useful when WeGive support is investigating a complex pull.

Status reference

The Status column tells you the outcome. Here's every value you may see and what it means.

How retries work for pushes

When WeGive pushes a record (Create/Update) and it fails, WeGive automatically retries. If a record fails three times in a row with no success in between, WeGive stops retrying that record to avoid an endless loop, and records it as ignored. This prevents one bad record from clogging the queue — but it also means a record that consistently fails will eventually stop trying. If you spot repeated Error Execution entries on the same record, that's the signal to investigate the underlying cause (often a CRM validation rule or a required field).

Reading the Details view

Clicking Click to view in the Details column opens the Integration Log Details modal. What you see depends on the action type.

For Create / Update (pushes to your CRM)

You'll see the exact payload WeGive sent — the records and field values, written in your CRM's API format. For a Salesforce donation, for example, you might see an insert:Opportunity block (with Name, Amount, CloseDate, Stage, Campaign, Contact, and so on) followed by an insert:npe01__OppPayment__c block (the payment record, with amount, card details, and payment date).

This is invaluable when a record looks wrong in your CRM: the Details view shows precisely what WeGive sent, so you can tell whether the issue is in what was sent versus how your CRM processed it.

For Pulls

You'll see a per-record-type summary of results, including counts of added, updated, skipped, and errors, plus how long each type took. If something errored, the message is included here.

For Batch operations

You'll see the batch's technical parameters — for example:

{
  "count": 2000,
  "batch_id": "750UR00000rW566YAC",
  "batch_uuid": "83dcfacc-b78d-48af-aa1b-7dcac1656031",
  "start_time": "2026-06-24T22:00:51+00:00",
  "chunk_index": 12,
  "member_id_field": "ContactId"
}

Here count is how many records are in the chunk, chunk_index is which chunk of the larger job this is, and the IDs let support trace the batch in your CRM.

For Error Execution

You'll see the error message, plus the payload WeGive attempted to send. The error message is the key piece — it usually quotes the response your CRM returned (for example, a validation rule that blocked the record).

Reading the Progress view

For long-running Pull and Pull All operations, the Progress column's Click to view opens a live status breakdown. It shows:

• Sync type — typically incremental (only changed records) or a full sync.

• From / To — the date range being pulled.

• Total vs. completed record types — e.g., 4 of 7 record types done.

• Current record type — what's being pulled right now.

• Per-type results — added, updated, skipped, and error counts for each record type as it finishes.

Use this to watch a big sync progress in real time and to see which record type a long pull is currently working on. If the Progress Updated timestamp stops advancing for a long stretch (roughly half an hour or more) on a Running pull, the job may be stalled — WeGive's monitoring will detect this and mark it Failed so it can be retried.

Common scenarios and how to investigate

"Did this donation sync to my CRM?"
Open the payment/transaction record, scroll to Integration logs, and look for a Create action. Processed = it synced. Click Details to see exactly what was sent.

"A donation hasn't synced yet."
Check the log's status. Pending means it's still in the short delay window before pushing — wait a few minutes. Error Execution means it tried and failed; open Details for the reason. No log at all usually means the record didn't qualify for sync or the integration was disabled.

"My nightly pull didn't bring in recent changes."
Find the most recent Pull log. Check From/To to confirm the date range, check Status (Processed vs. Partial vs. Error), and open Progress or Details to see per-type counts. A Partial status means some records errored — the Details view shows how many and where.

"A record imported with wrong/missing data."
For pushes, open Details to see the exact payload WeGive sent. If the value was correct in the payload, the discrepancy was introduced on the CRM side (a workflow, rule, or mapping). If the value was wrong in the payload, that points back to the WeGive record or field mapping.

"A sync has been Running for a long time."
Open Progress and check Progress Updated. If it's recent, the sync is genuinely working through a large dataset. If it hasn't moved in 30+ minutes, the job is likely stuck and will be auto-flagged as Failed and retried.

"I keep seeing repeated errors on the same record."
After three consecutive failures, WeGive stops retrying that record. Open the most recent Error Execution Details to read the CRM's error message — it almost always names the blocking field or validation rule. Resolve that in your CRM (or in the WeGive record), and the next sync should go through.

Best practices

A few habits will keep your sync healthy and make troubleshooting fast when something does go wrong.

Check logs on a regular cadence, not just when something breaks. A quick weekly scan of Settings → Integrations → Integration Logs, filtered to Status = Error or Error Execution, catches problems while they're small. Errors left unaddressed compound — and because pushes stop retrying after three failures, a quiet error can turn into permanently un-synced records.

Filter before you scroll. The full log is high-volume. Use the column filters to narrow quickly: filter by Status to surface only failures, by Action to isolate pulls vs. pushes, by Integration Type if you run more than one CRM connection, or by Initiated date range to focus on a specific window. This is far faster than paging through everything.

Start at the record, not the full log, for single-record questions. When a customer or teammate asks "did this one donation sync?", open that record's Integration logs section directly. It's the fastest path and avoids hunting through org-wide activity.

Read the Details payload before assuming WeGive sent bad data. When a record looks wrong in your CRM, open Details first. If the value was correct in the payload WeGive sent, the issue lives in your CRM (a workflow, validation rule, or field mapping) — not in WeGive. This one check saves the most back-and-forth.

Give a Running pull time before treating it as stuck. Large pulls legitimately take a while. Open the Progress view and watch Progress Updated — if the timestamp is advancing, it's working. Only treat it as stalled if progress hasn't moved for 30+ minutes (at which point WeGive's monitoring will flag it Failed automatically).

Resolve the root cause of repeat errors, don't just re-trigger. If the same record keeps landing in Error Execution, the Details error message almost always names the blocking field or CRM validation rule. Fix that underlying cause — re-running the sync without fixing it will just fail again and burn through the retry limit.

Confirm From/To when investigating a "missing data" pull. Before concluding that records didn't come through, check the From and To columns to confirm the pull actually covered the time window you expected. A pull can succeed perfectly and still "miss" records simply because they fell outside its date range.

Don't disable an integration mid-sync unless you mean to. Turning off a connection causes scheduled syncs to log as Disabled instead of running. If you disable temporarily, remember to re-enable it — and expect a catch-up Push Missing pass afterward.

Note the log ID early when escalating. If you think you'll need WeGive support, grab the ID and Integration Type up front. It lets support locate the exact log immediately instead of reconstructing the situation.

Quick glossary

• Pull — data coming into WeGive from your CRM.

• Push / Create / Update — data going out from WeGive to your CRM.

• Push Missing — automatic cleanup that sends records your CRM is missing; runs after a successful pull.

• Batch / Chunk — a slice of a large job processed together for efficiency.

• Pull By — which field/pass a pull used (primary, secondary, or tertiary).

• From / To — the date window a pull covered.

• Incremental sync — only records changed since the last successful sync.

When to contact WeGive support

Reach out if you see persistent Error or Error Execution statuses that you can't resolve from the Details message, a pull stuck Running with no progress for an extended time, or data consistently failing to sync despite correct values in the payload. Include the log ID (and the Integration Type) so support can locate it quickly.