> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wegive.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Understanding Integration Logs 

> WeGive Help Center article: 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.

***

## Who can access Integration Logs

Integration Logs are gated by the same `integrations.view` permission that gates the integration settings pages themselves. If you don't see Integration Logs in your dashboard, ask an Admin in your organization to grant you that permission.

## Where to find them

There are three 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?"

**3. Integration Logs Ignored**\
A separate page, **Settings → Integrations → Integration Logs Ignored**, holds logs that were filtered out of the main view — for example when a record no longer exists and can't be synced, or after a record has been explicitly excluded from future retries. This is its own table (and its own backend table, `integration_logs_ignored`), not a toggle on the main Integration Logs view. Most users don't need to check it regularly; it's primarily useful when investigating why a specific record has stopped attempting to sync at all.

***

## 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.

| Status | Meaning | What to do |
| - | - | - |
| **Pending** | The sync is queued but hasn't started yet. Push actions (Create/Update) are intentionally delayed a few minutes after a record changes so related data can settle. | Wait a few minutes and refresh. |
| **Running** | The sync is actively executing right now. | For large pulls, check the **Progress** view to watch it work. |
| **Processing** | A batch sync is in progress. | Normal for large jobs. Refresh to see it complete. |
| **Processed** | The sync completed successfully. | No action needed. |
| **Partial** | A pull finished, but some individual records hit errors. Most data came through; a subset did not. | Open **Details** to see how many errors occurred and on which record type. |
| **Error** | A pull failed on a specific record type and could not complete that portion. | Open **Details** for the error message; contact support if it persists. |
| **Error Execution** | The entire sync job threw an error and stopped. **Details** will include the error message and the data WeGive attempted to send. | Open **Details**; this is the most useful status for diagnosing push/create failures. |
| **Ignored** | WeGive tried to sync a record that no longer exists, so it was skipped. (These are hidden from the main list.) | No action needed. |
| **Disabled** | The integration was turned off when this sync was scheduled to run, so it didn't execute. | Re-enable the integration if the sync should have run. |
| **Cancelled** | The sync was cancelled before it ran. | No action needed unless you didn't expect it. |
| **Failed** | The job became stuck and was automatically marked as failed by WeGive's monitoring (e.g., it ran far longer than expected without progress). | Usually retried automatically; contact support if it recurs. |

### 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).

A log is only eligible for the dashboard's manual **Retry** action if its status is one of **Failed**, **Error**, **Error Execution**, or a small set of internal batch-chunk states shown as "blocked" — retrying replicates the log into a fresh pending record rather than re-running the original in place, so the original failed log stays in the history for reference.

***

## 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.