Nonprofit Success Pack

Hi Tory, 

This is a well-documented NPSP behavior, not a bug — it happens whenever the user who originally scheduled the NPSP nightly batch jobs (rollups, recurring donations, etc.) gets deactivated (left the org, license removed, etc.). Once that user is inactive, NPSP's scheduled jobs stop running correctly and this exact error fires. 

Fix: 

1. Setup → Quick Find → Scheduled Jobs 

2. Find any job(s) where the "Submitted By" column shows the inactive user, and click Del next to each one 

3. Go to the NPSP Settings tab (App Launcher if it's not in your nav) 

4. Click Bulk Data Processes → Batch Process Settings — just opening/saving this page automatically recreates the default NPSP jobs under your (currently active) user 

5. Confirm Don't Auto Schedule Default NPSP Jobs is unchecked — if it's checked, step 4 won't auto-recreate the jobs and you'll need to reschedule manually via Setup → Apex Classes → Schedule Apex 

6. Go back to Scheduled Jobs and confirm the jobs now show as Submitted By your active user 

One job to leave alone: NPSP 00 - Error Processing runs hourly by design — don't delete/reschedule it unless it's also showing the inactive user issue. 

Since this will happen again any time whoever's listed as "Submitted By" gets deactivated, it's worth having a step in your offboarding checklist to have another active admin rerun this process whenever that person leaves. 

Reference:

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.  

This is a type of program enegaement (development program, unit is hours or meetings). As such, PMM data structure can handle the job but it might be overkill if that's the only reason you need it. And PMM data structure is identical to V4SF data structure, so you can also model it as a volutneer hour. That's what we do, but I accepted long ago that a volutneer hour represented lots of different things in our database (all of which measure hours of engagement by someone (contact) for a purpose (job) on a specific date.) Thus if you also do group meetings, public speaking, etc for purposes of awareness raising and development, it can work. And you can actually sub-divide the meetings by job or program service (equivalent) for things like planned giving meeting, major gift meeting, donor nurturing meeting, donor cultivation meeting, capital campaign meeting, etc. 

V4SF hours are associated with a contact only and now an account. PMM Service Deliveries can be associated with a contact or an account. 

Activities (and events) don't work for historial recordkeeping of any sort becuase they are autoarhived by Salesforce and you cann't turn that off. 

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.