#NPSP23 debatiendo

Hi @John Fine

Both are reasonable. Which tool you should use will depend on what you are rolling up: 

• Customizable Rollups understand NPSP concepts (soft credits, household and contact rollups, time-bound rollups, GAU allocations). They are configured in the NPSP settings UI, run as batch jobs, and stay inside the managed package.
• DLRS works on any object (including custom ones and outside NPSP), can update quickly by trigger, and is actively maintained by its community. It requires deploying Apex, and someone has to own it when you leave.

Use Customizable Rollups for standard NPSP giving metrics, and DLRS only for rollups NPSP cannot do. Do not run both on the same target field. Whichever you pick, document it, and check batch times on your data volume. 

 Hi @Michelle Chang, 

Have you checked out the AppExchange to see if there are any apps that you can use instead of doing any custom dev?

• I could find few options for both Stripe and Aquare

https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FnCw4UAF

I hope this helps.

Hi Adam,

The custom field mapping is applied when NPSP creates an installment Opportunity from the Recurring Donation. 

So if Installment Opportunity Auto-Creation is disabled, NPSP won't automatically create the next installment just to apply the mapping. If an Opportunity is later created by an external donation platform, the Recurring Donation → Opportunity custom field mapping would not automatically populate that Opportunity unless the integration/process creating it explicitly applies the value. 

Also, updating the Recurring Donation doesn't simply copy the value to every historical/closed Opportunity. NPSP's behavior around existing open installment Opportunities can update mapped values depending on the Recurring Donation processing/configuration. 

For an online donation platform creating the Opportunity directly, I'd recommend checking the integration's field mapping or automation rather than relying on the NPSP Recurring Donation mapping. 

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