Nonprofit Success Pack

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.

You posted this in the NPSP group so first question... are you a System Administrator? If so, when you go to Setup > Object Manager > Leads > Buttons, Links and Actions and click the drop down to the right and "Edit" what do you see under "Salesforce Classic Override"? 

In terms of NPSP "coaching clients" isn't something out of the box, so you will need to provide more information on your lead conversion process. Does this error only happen with certain leads? If so, what makes these different?

Hi , 

Unfortunately, I don't believe Salesforce currently provides a way to selectively enable SLDS 2 for some Visualforce pages while forcing managed-package Visualforce pages to remain on SLDS 1. If a managed package page such as NPSP Contact Merge is broken by SLDS 2, this is likely an issue that must be addressed by the package provider or Salesforce itself.