Nonprofit Success Pack

@Miriam Hoebel

I’d avoid using email alone as the lookup key, especially if the form is exposing Salesforce data.

For Gravity Forms, a signed/tokenized link generated from Salesforce is a cleaner pattern — identify the Contact first, pass a short-lived token, then let the middleware validate it before pre-filling the form.

For Eventbrite/Absorb, if they can’t support that pattern, I’d put a controlled form/middleware layer in front rather than exposing Contact data directly.

Hi Miriam!

For this use case, I’d lean toward the Absorb–Salesforce integration/API rather than putting Zapier in the middle if you need reliable two-way synchronization and more control over the data. 

For tracking training participation, I’d map the key events first—registration, enrollment, attendance/completion, cancellation, and possibly assessment results—and decide which system is the source of truth for each. 

The two-way registration requirement is possible in principle, but I wouldn’t rely on email alone as the long-term matching key. A safer pattern would be:

Salesforce Contact → identify/match learner → pre-populate Absorb registration → learner confirms/updates → Absorb sends changes back to Salesforce. 

You’ll also want clear rules around which fields Absorb is allowed to update in Salesforce, duplicate matching, and what happens when the learner enters an email that doesn’t match an existing Contact. 

If anyone has implemented the Absorb Salesforce App specifically with Zoom attendance, I’d be interested in hearing whether the native integration handled these registration/update requirements or whether custom API/webhook work was needed. 

Hi @Windsor Windsor

, 

I also echo

on using Tasks and activities. One key issue is choosing the related record; as a rule, we start with the donation, which makes the record roll up to the contact and account record pages. 

Additionally, we edited the page layout of the task/activity to include the related records information; for example, for a task related to a donation (Related To field), we added the related record components based on the Contact and Opportunity lookup fields, so you have in one page the relevant information for the donation (opportunity) and the donor (contact). 

Happy to share more about our customizations if you think it will be helpful. 

Hi Laurel! One of the things I've seen cause this are contacts that should

be moved to the skew processing but are not. This means that they have a LOT of child opportunities. NPSP has a special mode to account for this, but if I remember correctly it's only based on the number of closed opps.  

This can happen for a number of reasons. What I've seen most often is if you have some contacts with a lot of OPEN opportunities, or if you use placeholder contacts that have a lot of related opps and they didn't get updated automatically to go into skew processing mode, you can get these errors.  

Adjusting batch sizes can temporarily resolve the issue sometimes, but you have to adjust them WAY down.  

This is the query that I run in client orgs first to see if there are any standouts. If so I adjust the UseSkewMode field from the query to 'True' for these contacts and then see if the heap issues disappear.  

SELECT ContactId, COUNT(Id) ActualOppsCount
FROM OpportunityContactRole WHERE Contact.npsp__CustomizableRollups_UseSkewMode__c = false
GROUP BY ContactId
HAVING COUNT(Id) > 250
ORDER BY COUNT(Id) DESC
LIMIT 2000

There are certainly other reasons you might get this. Having a large number of, or overly complex, npsp rollups defined and active can do it.  

Theoretically you could run into this issue if you have competing scheduled jobs (non-npsp jobs) scheduled at the same time, in which case both are competing for resources. If you run the job manually and it works without issue, this might be a place to look. 

If the above doesn't square things away, look at follow-up automation that triggers on the contact record update. Make sure your flows / apex have clear entrance criteria and leverage asynchronous paths where possible, so that you don't have a lot of automations triggering at the same time (in the same transaction, which is what the heap size limit is based on). 

You can also likely help this run smoothly by verifying that your Setup - Custom Settings - Customizable Rollup Settings have 'Incremental Contact Hard Credit Non-Skew' set to TRUE - which tells salesforce to only update the contacts that had records change since the last run.  

Hopefully one of these gets you squared away.  

Hi @Karen Hartt

Household groups people as family units under an Account. It doesn't touch the real problem, which is that Contact → Portal User is a 1:1 relationship. Putting the duplicates in a Household just organizes them visually in the same place; it doesn't merge their application history, doesn't stop the third duplicate next month, and it's honestly a slightly odd use of the object (these people aren't a family, they're one person with multiple professional hats).  

What's actually causing this 

Two structural facts collide: 

1. A Contact can only be tied to one active Experience Cloud/Community User at a time.
2. Your dedupe rules are matching on email, and each NPO email is genuinely unique, so Salesforce will never flag these as duplicates on its own.

So merging will always cost you the portal identity on whichever Contact loses. That's not a config bug, it's how portal licensing works. 

1. Fix it at the front door. Add a step to the grant application intake: "Do you already have an account with us (under any organization)?" If yes, capture their existing login/email and attach the new NPO affiliation to their existing Contact instead of spinning up Contact #2. This is the only option that stops the bleeding rather than managing it after the fact.
2. NPSP Affiliations, not Household. If a grant writer works with 3 NPOs, that's exactly what the Affiliation object was built for one primary Contact, multiple Affiliation records to other Accounts. If your portal/application process can key off "which Affiliation is this application for" rather than "which separate login," you eliminate the need for duplicate Contacts entirely.
3. If your portal genuinely requires one Contact per org (some grant portal setups are built that way and you can't change it short-term), don't force a merge. Instead, link the duplicate Contacts to each other a custom lookup, an NPSP Relationship record, or even a shared external ID. So staff and reporting can treat them as one human without triggering the portal user conflict. You lose nothing, you just stop pretending merge is the tool for this.
4. True merge should be reserved for cases where you're willing to deactivate all but one portal user and manually reassign the historical applications afterward (Task/Case/custom object records generally reparent fine on merge, it's specifically the User/login that doesn't survive).

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.