#Nonprofit34 debatiendo

From a Salesforce perspective, closing an existing recurring donation to create a brand-new one is an outdated workaround from legacy systems. 

When working within the Nonprofit Success Pack (NPSP), especially utilizing Enhanced Recurring Donations, the platform is specifically designed to handle updates dynamically. Editing the existing installment amount and setting an effective date preserves the unbroken relationship history, maintains clean roll-up summaries, and avoids orphaned child opportunities without breaking payment tokens or schedules. 

For organizations on Nonprofit Cloud, the architecture shifts to standard objects like Gift Commitments and Gift Transactions. Rather than recreating records, you manage increases directly on the active commitment record, ensuring longitudinal reporting stays intact and sparing donors or staff from unnecessary administrative friction.

This typically occurs because the automated scoring package or managed flow tries to execute synchronously on newly inserted Opportunity or Contact records simultaneously with the GoFundMePro data sync. When high-volume or third-party payment integrations push records into your instance, the sudden influx of DML operations can cause lock contention or trigger depth limits, causing the scoring flow or trigger to fail before it can evaluate the $100 and 999-day threshold criteria. 

To resolve this, you should refactor or transition the scoring logic into an asynchronous process, such as a Queueable Apex job or a scheduled batch process, rather than letting it fire on immediate after-insert triggers from the payment portal. This decouples the GoFundMePro gift ingestion from the resource-intensive iWave scoring callouts, ensuring the donations sync cleanly first without being blocked by subsequent processing errors. 

Additionally, review the error logs in your Setup under Apex Exceptions or Process Automation Failures to identify the exact failing element. Adding explicit null checks and bulkified try-catch blocks within your wrapper handler will also prevent third-party integrations from stalling when missing secondary related fields during creation.

Hi, 

good question, and you'll get both sides arguing. I'm going to stick to what's relevant to your situation: small team, limited budget, no permanent partner, and adoption as the sole goal. 

The Salesforce side is closer than it appears 

Both platforms offer a 'Salesforce inside my inbox' type view - a pane showing contact/account/opportunity info for the emails you're opening, logging emails, and creating records from the mail window. Outlook has the Outlook integration, and Gmail the Gmail integration. Both can be set up per your admin's clicks and don't usually require a paid AppExchange package. Check your edition as it'll depend on your licences. Most people fall into the trap of thinking that one is easier, and find the real work comes in permissions, fields mapping and training, not on the connector. 

A free method to test 

Run both integrations in a sandbox with 3-5 users for two weeks (free trials for both platforms, sandbox for Salesforce). 

Include at least a couple of your Africa-based collaborators. Connectivity and old PCs usually define adoption more than features do. 

Test the daily flows: send and log an email, create a task, create a lead from the side panel, find a contact quickly. 

Compare the admin work. Ask yourself who's going to maintain this when you're unavailable? 

On the collaboration questions 

Co-editing: Both can do real-time editing well, but Google Docs and Sheets feel quicker on a browser, which may be a consideration on poor bandwidths. The Office web apps are okay but desktop and web can be different beasts. 

Whiteboard: Microsoft has it built in. Google's Jamboard is retired, so check if Google has any recommendations before relying on it. 

Wiki/FAQ: Neither are very good out the box. On the Microsoft side, SharePoint pages or Loop are better options for evolving documentation than OneNote. On Google, Sites plus Docs (and Drive search) is simple and has good search. 

Price: Both vendors have nonprofit programmes, and terms often change, so ask both for current eligibility and discounts. 

Common mistakes people make 

Picking on feature sets and not running a pilot, and adopting the wrong tool as a result. 

Opening up email and calendar sync for everyone without thinking through what ends up in Salesforce. 

Not taking shared mailboxes, calendar permissions, and aliases into account when switching platforms. 

Switching MX records before mailboxes have been migrated so new mail ends up in the wrong place. 

Cancelling the old licences before data has been verified and moved. 

My honest opinion is that if your people spend their time in the browser, are distributed, and want something they can host themselves, Google will usually be the lighter option. If your team needs to use desktop Office apps, or has Microsoft grants, it's perfectly reasonable to stick where you are. Adoption beats feature lists either way. 

If you do adopt Google, the

Migration Tool can migrate mailboxes, calendars, contacts, and OneDrive in bulk with user mapping, and has a free trial where you can try a small batch first. 

Hope that helps, and am happy to go deeper into the Outlook vs Gmail side-panel setup if it's useful.

@Ryan McCracken those blank GAU rows are the join, not bad data. A payment and a GAU allocation are both children of the opportunity. A custom report type can walk down one of those, not both. That is why one type has close date and the GAU, and the other has payment date, and the combined type shows a blank GAU.

Campaign is on the opportunity, so that half is easy. Opportunities with Payments, filter Campaign, Close Date, and Payment Date.

For a GAU, use Opportunities with GAU Allocations and filter the GAU plus Close Date. Payment Date will not be on that report. A joined report can sit the two side by side on Opportunity Id, and the amounts will repeat when one opportunity has several payments and several allocations.

If you need one row that is a payment, a GAU, and a payment date, that is what Payment Allocations are for. Without them, NPSP never stored which payment funded which GAU.