#Nonprofit36 debatiendo

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.

@Swetha Movva that In Progress row is stuck. It will not flip to Completed on its own, and the midnight flow will not finish a run that has sat there since May 26.

INVALID_TYPE on the Batch Job Definition means the job pointed at an object or field this org does not have, or the user looking at it cannot see that type. A lookup you cannot describe often shows exactly that on hover.

NPC_DonorGiftSummary is a Nonprofit Cloud definition. It expects the gift objects from Nonprofit Cloud, gift transactions and the donor summary, not NPSP opportunity rollups. If those objects are not in the org, the batch job dies with INVALID_TYPE and the DPE row never gets a failure status, so it just stays In Progress.

Cancel that stuck run before the schedule stacks another one on it. Then open the definition and check the objects it writes. If gift transaction is not there, this DPE cannot run, and no permission on the flow will invent the type.

If the objects are there, the same error is access for the user the flow runs as. The person watching the monitor and the user who runs the job are not always the same.

@Keerthana Udayakumar That error is the All Tabs page, not the Library tab itself. The plus icon builds the whole Classic tab list before you can pick Library, and one broken tab on that list takes the page down with an internal server error.

A Visualforce tab whose page is gone, or a package tab the sandbox can't render, does this. Lightning never opens that page, so the org can look fine until someone switches to Classic and hits the plus.

Try Library from Lightning, or from a Classic app that doesn't include the bad tab. If All Tabs only fails in one app, pull the newest tabs off that app until the plus loads again. I can't read error id 420406434-220348 from here. If you need Salesforce to trace it, open a case with that id and say it happens on the Classic All Tabs page.