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.