Guides
Monitor donations and read the logs#
Two tabs answer the two questions you actually ask when something looks wrong: is a gift stuck? and what did the app say while it was going wrong? Neither lives in the Settings console, because troubleshooting is recurring work and setup is not.
Where they are#
Open the Pledgivo app. Donation Monitor and Diagnostic Logs sit in the navigation bar alongside Fundraisers and Settings — they are tabs in their own right, not panels inside the Settings console.
| Tab | Answers | Granted to |
|---|---|---|
| Donation Monitor | Is any donation stuck between "paid on Stripe" and "recorded as an Opportunity"? | Fundraising_Admin, Fundraising_User |
| Diagnostic Logs | What did the package record about its own behaviour? | Fundraising_Admin, Fundraising_ReadOnly |
Why the two grants differ
Diagnostic Logs is deliberately not granted to Fundraising_User. Log records are Private
and each one is owned by whoever ran the transaction that wrote it, so a permission set without
View All on Log__c would show a program-staff member only logs from their own sessions. A
near-empty page titled "Diagnostic Logs" reads as nothing went wrong — the one conclusion this
page exists to prevent. Grant it only alongside View All on Log__c.
Donation Monitor#
A live worklist of Donation_Staging__c rows that have not yet become an Opportunity. A staging
row exists between "donor started paying" and "payment confirmed"; anything sitting here has
either stalled or is still waiting on the finalizer.
Start with the default, not with everything#
The list opens on Show → Needs attention, and that default is the point of the page. Most rows in a healthy org are abandoned checkouts — someone opened the form, thought better of it, and closed the tab. Nobody was charged and nothing is owed. Listing those beside genuine failures makes an ordinary Tuesday look like an outage: an org with 21 abandoned carts reads as an org with 21 broken payments.
So the default shows only rows that need a person:
- a donor who confirmed payment whose gift has not landed as an Opportunity,
- a row carrying a finalization error,
- an expired event hold that never released its seats.
Nothing is hidden silently. When abandoned rows are being filtered out, the page says how many and offers to include them. Switch Show to Abandoned only or Everything to see them — they render dimmed rather than alarming.
Narrowing the list#
| Filter | Options |
|---|---|
| Show | Needs attention (default) · Abandoned only · Everything |
| Type | All types · Donation · Event ticket · Recurring |
| Status | All statuses · Pending · Submitted · Payment Confirmed · Processing · Finalizing |
| Created | Any time · Last 24 hours · Last 7 days · Last 30 days · Older than 30 days |
| Search | Donor name, email, staging number, campaign, and the Stripe payment-intent and correlation ids |
Paste a payment-intent id straight from the Stripe dashboard into Search to land on its row. Reset puts every filter back.
Each row carries what you would otherwise open the record to read: donor and amount, the campaign, how long it has been waiting, and its expiry window. For an event order the wording changes to held until, and an expired hold names how many seats it is still holding off sale — the number that decides whether you release it now or after the event.
Retry now#
Retry now re-checks that donation's payment status with Stripe and finalizes or expires it accordingly.
Retry cannot double-charge
It only re-reads the existing payment's current status from Stripe — it never submits a new charge. If the payment genuinely succeeded but finalizing keeps failing (a validation rule, a required field), the row is deliberately never auto-expired, so retrying repeatedly is safe. It simply won't self-resolve until whatever is blocking finalization is fixed — and that is what the Diagnostic Logs tab is for.
Diagnostic Logs#
The most recent entries AppLogger wrote, newest first, capped at 200. The Logging panel in the
Settings console decides what gets written; this tab is where you read it.
An empty list means three different things#
This is the part worth understanding before you trust the page. "No logs" is not one state:
| What you see | What it actually means |
|---|---|
| A gold "Logging is turned off" banner | Log level is Off. Nothing is being recorded at all, so reproducing the problem right now will add nothing here. |
| "Log level is Error, so only failures are recorded" | The packaged default. Anything logged at Info or Debug was never written — turn the level up, reproduce, come back. |
| "Nothing has been logged at level or above" | The genuine all-clear — and it names the purge window, because the nightly retention job deletes by age. An incident from last quarter can be gone rather than absent. |
The page reads both settings back from Settings__c and says which case applies, rather than
leaving you to guess. Getting this wrong is how an investigation ends early on a switch that was
never on.
Reading a row#
Each entry shows its severity as a coloured pill, the class and method that logged it, the message, and the timestamp with a relative age ("14m ago"). Where the entry has them, it also carries a correlation id, a related record id, and a stack trace.
Stack traces stay collapsed until you click Show stack trace on that row. They are the single most useful field when you need one and pure noise on the other 199 rows.
Narrowing the list#
| Filter | Behaviour |
|---|---|
| Level | All levels · Errors only · Warnings and above · Info and above · Everything (debug). A threshold, not an exact match — the same way the org setting itself behaves, so "Warnings and above" means the same thing on both screens. |
| Context | Built from the entries actually loaded, so it never goes stale when a new class starts logging. |
| Recorded | Any time · Last hour · Last 24 hours · Last 7 days · Older than 7 days |
| Search | Matches the message, context, correlation id, related record id and the stack trace — searching a class name finds entries that named it only in the trace. |
Filtering happens in the browser over the already-loaded entries, so it is instant and costs no extra query. Refresh re-reads from the org.
The 200 cap is stated, not silent
When exactly 200 entries come back, the page says "Showing the 200 most recent — older entries
exist". A filtered view of a truncated list must never read as the complete picture. If you're
hunting something older than the cap, narrow the window by raising the log level and reproducing,
or query Log__c directly.
A worked sequence#
- A donor says their gift never appeared. Open Donation Monitor and paste their email into Search.
- If a row comes back at Payment Confirmed with an error, that gift is paid and stuck. Copy its correlation id.
- Open Diagnostic Logs, paste the correlation id into Search. Every entry the failing transaction wrote shares that id, so you get the whole story in order.
- Expand the stack trace on the error entry to find what actually threw.
- Fix the cause — usually a validation rule or a required field on Opportunity — then go back to Donation Monitor and hit Retry now.
If step 3 comes back empty, read the banner before concluding anything: at the Error default level, an entry that failed silently at Info was never written. Raise the level under Settings → General → Logging, ask the donor to try again (or use Retry now), and re-check.
Related#
-
Donations & payments
The staging row, the finalizer, and why there's no Opportunity until payment confirms.
-
Settings & integrations
The log level, the retention window, and the three-tier settings model.
-
Settings console reference
Every setting in the Logging panel, and exactly what happens when you change it.