Can NPPatch be built on top of NPSP?

Ideas
1

The following conversation took place in the contributors Slack workspace. Continuing here so we can capture this publicly/longer term. As a courtesy, names of anyone who did not give express consent to be named here have been replaced with initials.

Karen Zelevinsky - Apr 14th at 11:52 AM

I’ve raised the question with Laura about whether there is any way to maintain the NPSP namespace for fields. The enormous upside to this would be that all existing NPSP integrations, as well as all of the forms we’ve built in things like FormAssembly would all just work. I am especially worried about the integrations, because even we make it easy for 3rd parties to support NPPatch, I think we’ll have a lot of trouble getting them to actually do it, and I can say from my own recent experience that the availability of integrations is a big deal for many of my clients (right now it’s a barrier for adoption of NPC/AgentForce for Nonprofits). So anyway, it would be AMAZING if we could keep the namespace for those existing fields. But is there any way to actually do that?

Rozi Lopez - Apr 14th at 2:28 PM

Sadly I’m not at all optimistic about this. Salesforce would need to decide to allow the namespace to be transferred and actually do most of the work (if it’s even possible), which seems like a nonstarter.

For integrations, I think it’s incredibly important that we stick as close to sales cloud as possible so that there isn’t a need for a dedicated integration. I also think data importer 2.0 will be super important for those cases where an integration does need something extra

JS - Apr 15th at 11:41 AM

Just adding that we’ve thought a bunch about this in developing our unmanaged packages at ----. We’ve found that there are a small handful of tools that are specifically built to only work with NPSP that do not work with Sales Cloud + custom objects, and these are mostly they very small/affordable tools. In those scenarios, we’ve found alternatives that we are able to recommend to clients. Or, if its a transformation issue, we’ve had to build a work around or a flow that processes the records once they come into salesforce (for example, to map to a custom payment object). Otherwise, most tools work with Sales Cloud and we just ignore the NPSP features. So far, it hasn’t been as much of a barrier as we initially thought it would be.

JB - Apr 15th at 1:00 PM

I don’t see any realistic possibility that we would be allowed to share the npsp namespace or ever have access to it. I think this thread is valuable, though, in calling out that if there are integrations or migration tasks that we know will be hard or cause people to shy away from nppatch, then we should be cataloging those and making plans for mitigating those issues. If specific problems can be identified we can always choose to write migration tools or make it easier to integrate with nppatch or even write our own integrations for high value services. If we had a prioritized list of specific issues we could plan work around that.

BW - Apr 17th at 8:29 AM

We don’t need to share the namespace. We need to ensure that what we build can point at both NP_Patch namespace and NPSP namespaces. This would involve a CCI task to replace namespaces when releasing for NPSP orgs versus orgs on the unlocked package.

8:31

The main design choice would be ensuring that new features are in a seperate directory

JB - Apr 17th at 10:20 AM

I think what Karen was raising as an issue are integrations and custom work that references npsp namespaced schema directly-- those users would have trouble switching to nppatch because their existing integrations and customizations for npsp would not automatically work with nppatch. We can’t solve that particular problem with namespace injection. It remains true that users who rely on integrations might have difficulty switching to nppatch as the NPSP successor.

I think what you might be describing is a scenario where we offer a build where we somehow continue to build on top of the NPSP package so that users never need to switch from NPSP at all-- they just install an nppatch layer on top of NPSP? That is a different approach entirely.

BW - Apr 22nd at 9:43 AM

Yes it is a different approach entirely, that I would put all of my votes and time into. As the success of this project requires orgs actually using it. Trigger handlers, interfaces, automations can all be swapped out within NPSP. The swapping would be the best solution for existing NPSP orgs.

Karen Zelevinsky - Apr 24th at 3:03 PM

@Laura Meerkatz Are you open to discussing BW’s idea more?

Laura Meerkatz - Apr 24th at 3:10 PM

I guess but I’m not optimistic about it.

Karen Zelevinsky - Friday at 5:04 PM

I’d love one meeting just to make sure it’s clear what he’s proposing

Laura Meerkatz - Friday at 5:50 PM

If we’re going for clarification, let’s start with a write-up. I hope to have the discourse forum up this weekend or early next week and this is the exact sort of discussion that anyone should be able to weigh in on.

Karen Zelevinsky - Saturday at 9:20 AM

@BW Let me know if I can help with this. Thanks!

Laura Meerkatz - Saturday at 9:28 AM

The forum is up! I still have some polishing to do, including cross-posting the previous discussions from GitHub Discussions, but you are now welcome to go check it out and post conversations there. nppatch.discourse.group

JB - Saturday at 3:29 PM

I have been looking into what it would take to split schema into a package for purposes of licensing, which may be very

applicable here. Let me know when you have a sketch of your idea, @BW. I’m especially interested in what implications it might have for developer experience as well as how treating NPSP as a dependency might impact the evolution of nppatch beyond where NPSP is today.

Karen Zelevinsky - Wednesday at 8:52 AM

@JB @Laura Meerkatz I think the idea is to create a package with just the objects/fields and then always have two nearly identical versions of NPPatch, where the only thing we do is dynamically swap out any reference to objects or fields. One version of NPPatch would have NPSP as a dependency (and we would “turn off” as much of NPSP as we don’t want/need) and the other version would have our new package as a dependency, but all the code would be identical.

Rozi Lopez - Wednesday at 9:18 AM

I think I understand the general idea @Karen Zelevinsky (and @BW), but to echo some of what @JB is bringing up, I think it makes encouraging the community to contribute much more complex (essentially requiring any community contribution to do double work), and that complexity/difficulty only increases as NPPatch drifts further and further away from NPSP.

For example, what if we change the data model in small or not-so-small ways (like altering the relationship between payments and opportunities) that cannot be done by building on top of NPSP. What does that make life look like for people who want to contribute (configuration/code contributions as well as things like documentation and support)?

If something like the new UI for the settings tab is exciting and someone wants to fork that piece over as a small stand-alone replacement for the NPSP settings page in it’s own package I think that’s awesome, and the installation for that could probably have a place on the nppatch installer site or something, but I personally don’t think it should be the main focus of this group.

Karen Zelevinsky - Wednesday at 9:23 AM

@Rozi Lopez I think @BW’s idea was that there would be a single code base that people edit and there would be automations in GitHub that would swap out the field references to auto build the 2nd package. Or something like that. So no extra work for contributors. The question about changing the data model is a good one and would involve a lot more discussion. I am torn because I think for adoption we will get much better results if we use the current model and offer a way for existing NPSP orgs to start using it (no need to rebuild all your integrations, forms, etc.) but I understand the desire to innovate and improve.

1 Like
2

I wanted to catch up and digest this conversation more fully so enlisted Claude’s help. I hope sharing this helps anyone looking at this thread get up to speed more easily. For those deep in the thread, I’m very open to your corrections/additions. As we all know, AI only gets it right to a point. :slight_smile:

AI Synopsis of Thread Thus Far (by Claude)

Key Takeaways

The group is wrestling with adoption vs. innovation: building NPPatch as a standalone replacement for NPSP (more freedom to innovate, but harder migration) vs. building it on top of NPSP (easier adoption, but less freedom to change the data model).

The namespace issue is settled—Salesforce won’t transfer the NPSP namespace, so integrations built for NPSP won’t automatically work with NPPatch.

Agreements Made

  1. Namespace sharing isn’t viable — Salesforce won’t allow it (Rozi, JB, and others are confident this is a nonstarter)
  2. Integration compatibility matters — Even though it’s uncertain how big a barrier it’ll be, the group wants to identify and mitigate specific integration pain points

Outstanding Questions & Tensions

The big one: Should NPPatch be built on top of NPSP (BW’s proposal) or as a standalone Sales Cloud package?

  • BW’s pitch: Use NPSP as a dependency, maintain a single codebase, use GitHub automation to swap namespaces at build time → existing NPSP orgs can adopt without rebuilding integrations/forms
  • Rozi’s counter: This creates complexity for contributors and locks NPPatch into NPSP’s constraints. What happens when NPPatch needs to change the data model (like Payment/Opportunity relationships)?
  • Laura’s position: “Not optimistic” but open to clarification

Unresolved: If you’re contributing to NPPatch (code, docs, support), does dual-package maintenance create extra work? Or can GitHub automation really handle it transparently?

3

The product/architecture team is meeting this Wed, 7/8 at 11:30 am PST/2:30 pm EST to continue this conversation and hopefully make some key decisions. All are welcome and encouraged to join. You’ll find the meeting info on the events page (NPPatch Developer calendar).

4

I want to float a proposal after our conversation yesterday for a product goal.

NPP Core (name TBD). Which contains:

  • The Houshold Account Model (including naming but NOT affiliation management, address syncing tbd)
  • TDTMv2 (exact specs tbd)
  • BDIv2 (exact specs tbd)

and nothing else.

Once we get that released we can explore multiple directions for next steps:
A. Existing NPSP Orgs
We can explore what the installation path looks like for existing orgs, including a metadeploy installer that can disable the appropriate TDTM triggers. We’d be replacing very little in the way of fields (just the final naming fields on account) so the data lift is very light. It’s unlikely this will actually be useful to existing orgs but we can build the practice around figuring out the installation/data migration path regardless and it proves that we can produce something and aren’t leaving existing orgs behind.

B. NPC Orgs
This one sounds crazy, but if there are any brave souls who want to look at how to use or extend this to work with person accounts and NPC fundraising data model they can.

C. Net New
This gives some options for net-new implementations that aren’t a fit for NPC:

  1. Install NPSP (maybe using our new installer that includes quick actions, etc?) and then the NPP Core package on top.
  2. Only install the NPP Core package and do a custom build on top of it. This could be a viable option for orgs that are mainly program focused or grant-making (they could use PMM or outbound funds, for example) or orgs that have a partner with a templated build (eg. NPA) or don’t really need all of NPSP fundraising functionality right away.

The longer-term goal of building additional features would continue. But we could use the experience here to figure out next steps.

I mentioned yesterday and want to reiterate here that fundraising functionality does not have to be the most urgent feature we tackle. It leaves net-new orgs in a bit of a weird situation if we don’t have anything but would possibly deliver more value overall if we instead moved on to something like board management or major donor/moves management work that are actual gaps in NPSP right now.

If we keep things modular we could end up with an NPSP org that has NPP core + NPP moves management + NPSP for fundraising functionality and a net-new org could have NPP core + custom build/NPA for fundraising + NPP Moves management (or whatever combination works best for them). The key is to give ourselves that flexibility and do our best to respond to the community as we go.

5

Why not affiliations, addresses, etc? Part of why the multi-package structure in NPSP was abandoned was because there were so many circular dependencies (ex. automatic soft credits based on affiliation). Obviously not ideal from an architecture standpoint, but consolidating did mean not having to test all the possible variants just to understand what was available in any given org.

@dospromptman will have more/deeper thoughts here, I’m just offering that there many problems that are still quite thorny today and we may consider a simplified architecture (not one but fewer packages) as a way to reduce some types of complications (while creating others).

6

The ‘no affiliations’ is a couple of reasons:

  • it introduces a custom object and requires a heavier data lift for NPSP orgs. Lots of orgs customize affiliations and use them in a ton of different ways (board members, etc) and may have their own automations on top of that. I’m assuming that very few orgs have customized the household account logic or built anything that depends on the NPSP system fields that drive it so it will be a cleaner swap (essentially just replacing npsp naming fields with npp naming fields in reports)
  • mentally I have affiliations grouped together with relationships, a possible new org-to-org relationship, and maybe even moves management as a ‘constituent management’ module/feature that, whether it ends up in the core package or not, deserves some level of thinking/design that will slow down a v1 release.

‘no addresses’ is kind of similar, mainly that we have to decide whether to copy NPSP and use a custom address object or try to fit into contact point address or do something else. Not a terrible idea to have it in the core package someday, just maybe not a v1 thing.

I’m not opposed on principle to larger package(s) and am definitely over-simplifying by trying to hand-wave away the issues with a shared namespace, but I do think that having a very tightly-scoped core that is the main (or only) dependency for everything else grants a lot of benefits that are likely worth the extra integration testing around package dependencies (to a point). Especially if we want to try and support both existing NPSP and non-NPSP orgs simultaneously. It is a good argument to move whatever our ‘constituent management’ stuff is into the core package rather than it’s own thing so that anything else that we build can depend on it (like affiliation-based soft credits).

7

At risk of overgeneralizing, is the basic idea to separate the “engine” of NPSP from the NPSP data model?

If the engine could be updated in a way that’s agnostic to data model, orgs that are happy with their NPSP data model and processes could modernize by replacing the “guts” of NPSP with a core NPP package.

Then packages focusing on common needs within a domain (like fundraising) could offer data model / automation features as optional modules.

Alternatively, if data model features are too closely coupled with the underlying engine, orgs would need to buy into any data model changes to access the other updates… (Ie. To update the TDTM engine and get a new settings UI, you also need to change your data structure for tracking donations…)

Seems like this uncoupled approach would be useful for letting orgs migrate in stages rather than all at once. Even if an org was wanting to upgrade parts of the NPSP data model, it would still helpful to be able to change the underlying infrastructure first, then tackle what needs to change to adopt a revamped fundraising module, for example. But it depends on how feasible the separation actually is…

8

Oh how I wish Kevin Bromer could weigh in on this thread, as I know this was some of the tension around the NPSP Architecture way back when (v2 days) and why we ended up creating those 5 packages (which was kind of the NPSP “core” plus separate pieces of functionality, but it never really worked out that way IRL). It never was really a clean solution, and as @laurameerkatz points out, I think it ended up being a mess of circular dependencies such that you couldn’t really untangle the Cat’s Cradle of Code ™. If you all think that you can cleanly separate the core functionality from the “other stuff”, I love the concept, but I worry that real life isn’t quite that neat and tidy. I will also put in my vote for Affiliations and Addresses being part of Core, but I realize that may open the door to more (and people can probably argue for other things too). All the above said, I trust you all implictly, as I’m frankly way above my head here so thank you for letting an old man ramble.

9

It’s less about separating the engine and more about building the smallest functional unit that we can so that we leave options open for further feedback.

Once we actually have the core built, if the overwhelming need/feedback that we’re getting (or the technical limitations that we run into) means we expand within the same package so be it.

I’m mainly a bit worried that trying to rebuild all of NPSP in a single ‘attempt’ will cause us a lot of problems and keeps us from being responsive to what the community actually needs. My (possibly completely wrong) read is that orgs that are currently on NPSP are not desperately searching for an alternative because they want to do start a database migration in the next 18 months, it’s mainly the opposite.

If we had a working 1.0 version of the all-in-one today, for example, our next steps would be going on the road, demoing and trying to convince people to buy into a large technology project from an unknown organization and I don’t think we’ll be super successful at actually helping who we want to help doing that.

If we can release something that looks like a good start for a long-term replacement with the explicit messaging that we are taking this slowly, looking for feedback, and examining what potential migration looks like for existing orgs every step of the way (or trying to minimize it entirely where we can). I think that gives us a lot more options moving forward to eventually build something better than NPSP without leaving a lot of orgs behind. Plus, as a bonus, any net new migrations that aren’t going to NPC have an option that gives them immediate benefits.

10

If it helps, the demo I’m imagining us putting together with this suggestion looks like the following:

  1. Open an NPSP org with realistic data. Look at a multi-person household, open the manage household interface.
  2. Open the NPP installer and run the install + NPSP conversion plan. The conversion plan:
  • deactivates the relevant NPSP TDTM Handlers
  • copies NPSP naming settings to NPP equivalents
  • uses batch apex or something similar to copy NPSP household naming fields to NPP equivalents
  1. Refresh the NPSP Org and update the page layout/lightning page to display the new NPP household management button. Open it and see the exact same data in a new interface.
  2. Open a report that includes NPSP naming fields and replace them with NPP fields.
  3. Open for discussion/feedback on what we do next, with an emphasis on the fact that we want to take existing customizations into account and reduce the burden of migration as much as possible.

I think if we do that a few times and/or record it folks will get excited for what’s next and want to join the conversation.

11

Thanks - that helps clarify the proposal.

Here’s my attempt at synthesizing a few threads:

Right now the NPPatch repo is a fork of NPSP following the “all-in-one” path.

Instead of that, we’re considering a couple ways to start with smaller and more manageable products.

(1) NPSP Installer:

  • Repo with CCI flow that points to the existing NPSP repo but adds the standard pre and post-install steps Salesforce used to provide.
  • This would re-establish a smoother onboarding process for orgs looking to install NPSP as it currently exists.
  • Alternatively, the installer could point to a forked NPSP repo that addresses some of the basic tech debt issues (Elevate, legacy Recurring Donations) but still uses the NPSP namespace.
    • I don’t know if this second option is feasible, but it would be good to clarify which path (modified NPSP or not) we’re talking about with the installer idea.

(2) NPPatch v1

  • Identify a slice of NPSP functionality that works well as a starting point and is a common denominator across many orgs (such as household management).
  • Create a new repo with the NPPatch equivalent of everything needed for this slice.
  • Build a demo that runs end to end, including installation and turning off competing NPSP code / configuration.