What's Changed Since the First Beta
We released the first NPPatch beta about a month ago. Here’s what’s been happening since.
The short version: We’ve been replacing legacy layers, cleaning up the admin experience, and absorbing Program Management into the package. If you installed the early beta, the app you’d see today is meaningfully different - and if you haven’t installed it yet, now is a great time to try it out.
A completely new Settings experience
This is probably the most visible change. The entire NPSP Settings page - all 36 Visualforce panel pages and their 25 controllers has been replaced with a native Lightning Web Component.
That sounds like a behind-the-scenes thing, but it’s not. The old settings page was a Visualforce monolith that loaded slowly, looked dated, and required you to type raw values into text fields for things that should have been dropdowns. The new one is faster, cleaner, and actually helps you configure things correctly.
A few highlights:
- Health Check now auto-runs when you open it, shows results in organized tabs, and gives you human-readable descriptions for passing checks — not just raw field values. There’s also an Error Log tab.
- Trigger Configuration has typeahead search for Object and Class fields and multiselect checkboxes for trigger actions. No more free-text entry and hoping you spelled the class name right.
- Error Notifications lets you search for users and Chatter groups by name instead of typing IDs.
- Allocation Settings shows the Default GAU as a searchable dropdown.
- Campaign Member Settings populates status dropdowns from the live CampaignMember.Status picklist — you see real values, not a blank text box.
- Contact Role Settings has collapsible guidance sections explaining how the roles actually work.
- Duplicate Rule Settings is entirely new — this panel didn’t exist in NPSP at all.
And several features that previously required multi-step enablement wizards — Enhanced Recurring Donations, Customizable Rollups, Advanced Mapping, Gift Entry — are now simply on.
Relationships Viewer with a D3 network graph
The old Relationships Viewer used Arbor.js, a canvas-based physics library that hasn’t been updated in over a decade. We replaced it with an interactive D3 network graph.
You can drag nodes around, click into them for detail, zoom in and out, and control the depth of the traversal. It uses a breadth-first graph walk to fan out from a contact and show their full relationship network. The existing tabular tree grid view is still there, now organized as a tab alongside the graph.
This could still use a redesign, but this at least gets us to modern and stable.
*The link on this one is broken when running from the namespaced package so you’ll have to wait for the next release to get a live look.
Manage Household — rebuilt from scratch
The Manage Household page was a Visualforce + Aura + jQuery hybrid. The VF page hosted an Aura app that loaded jQuery for drag-and-drop reordering, with a vfEventHandlers bridge to pass messages between the layers. It worked, but it was fragile and difficult to maintain.
It’s now a pure Lightning Web Component. You search for contacts to add using the standard lightning-record-picker (which auto-filters out people already in the household), reorder with up/down arrows, and merge households through a built-in prompt. No jQuery. No Visualforce. No bridge code.
This is another rebuild that should be considered a starting point only. Better UX is definitely possible!
Program Management is now built in
We’ve absorbed the Program Management Module (PMM) into NPPatch as a first-class module. That’s 8 custom objects, roughly 107 Apex classes, and 36 LWC components — all sharing the same namespace and utility layer as the rest of the package.
This means Programs, Services, Service Deliveries, and Service Participants all live alongside your fundraising data in the same org, with a dedicated Programs app and navigation. The sample dataset includes both fundraising and program records — a fictional “Meadowlark Youth Literacy” organization — so you can see the full picture right out of the box.
Shared utilities have been extracted into nppatch-common, which is available to all modules. This is the beginning of a modular architecture that will let the package grow without turning into another monolith.
Every custom field is documented
All 951 custom fields across 67+ objects now have admin descriptions and user-facing inline help text. Previously, most fields had none. Lead fields had literally zero.
This matters more than it sounds. Hover over a rollup field and you’ll see which filter group drives it and a note warning against manual editing. Hover over the Preferred Email field and you’ll see the TDTM copy-to-standard behavior explained. Hover over a deprecated field and you’ll see it clearly marked with what replaces it.
If you’ve ever stared at a custom field on an NPSP object and wondered “what does this actually do,” this is the fix.
App organization
The old NPSP shipped as a single Lightning app. NPPatch now organizes functionality into dedicated apps - Fundraising, Gift Processing, Finance & Funds, Program Management, and NPPatch Administration.
One-click install via MetaDeploy
If you tried the beta using our install guide, you’ve already seen this — but it’s worth noting how much is happening behind that install button. The installer at install.nppatch.com runs preflight checks (My Domain enabled, Chatter enabled, not a production org), handles the click-through agreement, and then does all the post-install configuration: activating record types, initializing default settings, configuring the admin profile, and assigning layouts.
What we removed
A significant part of this work has been removing things. The NPSP accumulated a lot of code over the years — integrations with services that no longer exist, migration paths between feature versions, redundant engines kept around for backward compatibility. All of that is weight that makes the codebase harder to understand, harder to maintain, and harder for the community to contribute to.
Here’s what’s gone:
- Elevate integration — 37 Apex classes, 5 LWC, 23 custom fields, and 19,408 lines of code for a payment processing service that was only available to Salesforce.org customers
- Recurring Donations v1 and the RD1-to-RD2 migration wizard — Enhanced Recurring Donations is the only engine now
- Legacy NPSP Rollups (the RLLP engine) — Customizable Rollups is the only rollup engine
- Batch Data Entry — the entire ‘Batch__c’ object tree
- Batch Gift Entry — 8 classes, 5 Aura components; the modern Gift Entry is always on
- SmartyStreets address verification
- Salesforce.org telemetry and instrumentation
- Help Text field mapping — Advanced Mapping is the only mapping engine
- 36 Visualforce settings pages and their controllers (replaced by the new LWC settings)
Every one of those removals makes the codebase smaller, simpler, and more approachable for someone who wants to understand how it works or contribute a fix.
Code quality
We also cleaned up what’s left. The entire LWC codebase — 463 files — now has zero ESLint errors. Over 250 errors were fixed manually, and the linting process caught real bugs: a === that should have been = in the RD2 status automation save path, missing parentheses on method calls. Hungarian notation has been removed from the BDI classes, with roughly 600 identifiers renamed to follow standard conventions.
This isn’t glamorous work and there’s still more to do, but it’s the kind of thing that makes a codebase maintainable by a community rather than just by the team that originally wrote it.
Try it
If you’ve been waiting for things to settle before installing the beta, they’ve settled quite a bit. The install guide will get you up and running in a few minutes.
And if you installed an earlier version, we’d love to hear what’s changed for you. Bugs, feedback, impressions — all of it helps.
- Found a bug? Open an issue on GitHub
- Have feedback? Start a discussion
- Want to talk to us? admin@nppatch.com
- Not signed up for the beta? Join here