#NPSP20 debatiendo

Hi @John Fine

Good question, and the timing matters here more than it did even a year ago. Quick facts first, then my take. 

Current state (verified via search): 

• Customizable Rollups (NPSP native): Salesforce ended feature development on NPSP itself in March 2023, and since December 2025 NPSP is no longer offered to new nonprofits through Power of Us at all new orgs get Agentforce Nonprofit instead. NPSP isn't end-of-life and existing orgs aren't losing support, but it's explicitly in maintenance mode with all Salesforce innovation now going into Agentforce Nonprofit (formerly Nonprofit Cloud).
• DLRS: Still actively community-maintained it's part of the Salesforce.org Commons program, has ongoing GitHub activity (open issues/PRs into 2024, community sprint contributions), and isn't tied to NPSP's product lifecycle at all since it's a general purpose Salesforce tool, not nonprofit specific.

My take: DLRS is the safer long-term bet

, for reasons beyond just "who's currently patching bugs": 

1. Decoupled lifecycle risk. Customizable Rollups' fate is tied to NPSP's fate. NPSP isn't dying tomorrow, but Salesforce has clearly signaled where the investment is going (Agentforce Nonprofit / Data Processing Engine-based rollups, which are a materially different, non-real-time architecture). If your org ever migrates off NPSP, Customizable Rollups config doesn't carry over you'd rebuild in DPE anyway. DLRS, being NPSP-agnostic, isn't tied to that migration path at all.
2. You already hit a "long ago" bug on Customizable Rollups with an unclear resolution path that's a real signal about how much active engineering attention it gets versus DLRS's visibly active issue tracker.
3. DLRS is more portable if a future consultant or you-in-five-years needs cross-object rollups on a non-NPSP object relationship, DLRS already handles that generically. Customizable Rollups only works within NPSP's supported rollup framework.

Where Customizable Rollups still wins

, worth weighing against the above: 

• Native admin UI is genuinely more approachable for a future non-technical maintainer no managed package install/upgrade cycle to babysit.
• One less external dependency/package to track for security review, API version compat, etc.
• If your org's roadmap includes migrating to Agentforce Nonprofit in the next few years anyway, this whole rollup question becomes moot either way worth finding out if that's on your org's horizon before doing the DLRS migration work, since it'd be wasted effort in that scenario.

Recommendation: Migrate to DLRS for the rollups you're actively touching now, but before doing a wholesale migration of everything

, find out whether Agentforce Nonprofit is anywhere on your organization's actual roadmap if there's a real chance of that migration in the next 3-5 years, I'd frame this as "band-aid with DLRS now, real re-architecture happens at NPSP migration time" rather than sinking a lot of effort into a rollup system you might replace anyway. 

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

Congrats on getting Give Lively wired up! I would steer away from deleting these, deletion is fragile, the sync usually just recreates them on the next pull and you lose the registration link. Treat it as a categorization problem instead. A few layers, best first: 

1. Fix it at the source mapping if you can. Check whether Give Lively's Salesforce mapping lets you route free/0-dollar registrations to just a Campaign Member (or a non-donation object) instead of creating an Opportunity. If that toggle exists, it is the cleanest fix, the junk never gets created. 

2. If the integration creates the Opportunity regardless, do not fight it, reclassify it. Put free/ticket registrations on a dedicated Opportunity Record Type (e.g. 'Event Registration' or 'Ticket'), separate from your 'Donation' record type. Then two things fall into place: 

- Exclude that record type from NPSP donor rollups so it never inflates lifetime giving. NPSP lets you exclude specific Opportunity Record Types/Types from rollups (NPSP Settings > Donations for the legacy rollups; with Customizable Rollups you exclude via a filter group). That directly fixes the 0-dollars-counting-as-donations problem in your donor totals. 

- Your donation reports and dashboards then filter to Record Type = Donation (or Amount greater than 0), so the free registrations drop out cleanly. 

3. Track the free attendance where it belongs, as a Campaign Member on the event Campaign (which it sounds like you are already doing). That is the right home for 'attended,' and it keeps your engagement reporting intact without touching giving numbers. 

Net: a dedicated record type + exclude-from-rollups + an Amount>0 (or record-type) report filter gets you clean donation reporting without deleting anything or losing the registration history. If free tickets keep coming through as donations even after that, revisit the Give Lively field mapping, that is where the record type gets stamped on the way in. 

If this helps, please mark it as the Best Answer so it is easy for the next person to find. Thanks :)

Hi Babak - that 'Workflow Rule Filter:' with no name is the classic uninstall blocker, and the reason your Flow/Trigger review came up empty is that it isn't a Flow or a trigger - it's a classic Workflow Rule, which is a separate metadata type you haven't looked at yet. 

What's happening: somewhere you have a Workflow Rule whose criteria (the 'filter') references a Recurring Donation field from the package. The uninstall error points at the filter but can't surface the parent rule's name, which is why it's so hard to trace. 

How to find it fast: 

1. Retrieve the Workflow metadata for all objects and grep for the field. Via CLI: sf project retrieve start -m Workflow (or retrieve the Workflow type in Workbench), then search the .workflow files for the Recurring Donation field's API name (it'll be in the npe03 or npsp namespace). That pinpoints the exact rule immediately - far faster than clicking through Setup. 

2. Prefer the UI? Go to Setup > Workflow Rules (not Flows) and review every rule - and crucially the inactive ones too, since inactive workflow rules still block an uninstall. Check each rule's criteria for a Recurring Donation field, plus any Field Updates that target one. 

3. Don't forget cross-object rules: the blocking rule might live on a different object but reference the Recurring Donation field in its criteria or a field update. 

Once you find it, remove the field from the rule's criteria (or delete/deactivate the rule if it's obsolete), then retry the uninstall. 

Two things that trip people up: (a) it's Workflow Rules specifically, not Process Builder or Flow, so the metadata type to retrieve is Workflow; and (b) inactive rules still count. The CLI-retrieve-and-grep in step 1 is by far the quickest way to end the hunt. 

Hope that cracks it!

 If you are working with a mail house/print service provider and intend to continue using them, make sure to send your list with the account id so you can match them up after the fact.  Having said that, using a Mail house and moving your address quality initiatives downstream prior to mailing is the absolute worst place to manage data quality.  IMO, data quality is best managed at the record of truth proactively.   This includes building a custom app or using a managed package like NCOA 4 Salesforce which is available now and in the process of getting in the app exchange.  The process handles the entire data set (not just what you are mailing) and works with a few clicks.  You can choose how to import and avoid duplication.  Happy to show it to you or can see a common demo: Typical NCOA 4 Salesforce demo to a nonprofit organization 

Hey Michelle - few notes here:  

Apple Pay isn't Stripe only - Square supports it through there web payments SDK, so you don't have to switch providers if you already have Square - yes you would need to have a Square account to use it for payment processing.  

I'm assuming your goal here is to be able to accept donations from an Experience Cloud site? With that, there are two options - embedding a Square checkout page on your site, or just having a link to an external Square checkout page.  

If trying to embed on your site, Square would work, but I think you are going to have trouble with Apple Pay. My understanding is that Apple requires that verification file to be served at one exact URL path, and Salesforce's multi-tenant platform doesn't let you just put a file there. There are workarounds (a URL rewriter Apex class, or a CDN in front of a custom domain), but it's real developer work and it tends to be fragile.  

So if you are trying to embed on your site (using the Web Payment SDK in an LWC), I would suggest using Square without Apple Pay. If just adding a link to a Square page, Apple Pay would work fine. The user experience for the second option would be a Donor clicks a button, is redirected to a Square page, pays with Apple Pay / Google Pay / Credit Card / etc, then is redirected back.  

Zapier would not be needed in either case. Square sends the webooks natively. You would just set it up on the Square Developer Dashboard and point it at a Salesforce endpoint. You would have to set up a public endpoint to receive the webhooks though - that would mean a RestResource Apex class exposed through your SF Site with get user acccess. You can add some sort of signature verification to ensure you are not accepting posts from any random sources. You could use Zapier if you wanted - to basically outsource this signature verification - but that would have a cost associated with each transaction.  

Hope this was somewhat helpful - I'm happy to talk through this further if you would like. 

Steve

I've seen NPSP overwrite Opportunity Names for Recurring Donations before, even when the general Opportunity Naming settings appear to be disabled.

My first guess would be that the Recurring Donation automation is updating the record after your Flow creates it. A quick way to check is to look at the Opportunity right after creation and see if the name changes a few seconds later or during a subsequent update.

I'd also recommend checking the debug logs or field history (if enabled) to see what's performing the update. If the update is coming from NPSP-managed automation, that would explain why your Flow's naming convention isn't sticking.

Are you using Enhanced Recurring Donations? That can sometimes behave differently than the legacy version and may apply its own naming logic regardless of the standard NPSP Opportunity Naming settings.