On October 17th, 2023, to coincide with the launch of Nonprofit Cloud for Fundraising (NPC), FinDock released as one of the few launching ISV partners its new integration with NPC. Over the past few months, the product team at FinDock has been working closely with the team at Salesforce, responsible for development to ensure interoperability and to create a smooth transition path for partners and customers.
Many partners and customers have asked how FinDock can ensure smooth integration with this new product. In this blog I would like to share some insights into FinDock’s architecture and how and why FinDock is suitable for integration with any Salesforce based solution and how we integrate with the Nonprofit Cloud for Fundraising specifically.
Table of contents
FinDock’s modular approach to Payment Management
FinDock often acts as an orchestrator for data flowing between Salesforce applications and payment processors. So integrations can roughly be classified as either source or payment extension. Source being connections with the Salesforce package providing the accounts payable, such as NPSP or GoMeddo. And Payment extensions being integrations with specific payment schemes such as SEPA or Bacs or Payment service providers like Stripe, GoCardless or Mollie.
FinDock chose to adopt a modular architecture to address the challenges in both payment, and back office or source integration. There are many different forms, protocols, and standards in use for payment processing throughout the world. From SEPA to ACH and Swift to ISO20022, nearly every country has their own particular flavors of files, standards and processors.
On the platform side, there are many possible packages and apps to integrate with as well, varying from Salesforce solutions like NPSP & Nonprofit Cloud to ISV solutions like Certinia (formerly FinancialForce) and Singlify to even custom build one-off implementations.
FinDock’s modular architecture enables customers to install only the functionality they need rather than having one huge package containing everything.
This architecture has some significant advantages, for example:
- Reduction in complexity on a package by package basis
- Risk reduction when introducing new features or otherwise updating packages
- Easier integration of new payment methods and processors
Aside from the Salesforce packages, FinDock also has two Heroku based components: ProcessingHub for file parsing and creation and WebHub which hosts our Payment Pages and provides the gateway for PSP notifications. In this blog we will focus on the Salesforce side of things.
How FinDock connects to the Nonprofit Cloud for Fundraising data model
The introduction of the Fundraising capabilities into the NPC brings a whole new data model FinDock will need to interact with. And this is where our modular architecture really shines. Because of our existing integration with the old Nonprofit Success Pack we can easily integrate the new data model into our standard processes.
Consider the following diagram of a FinDock installation:
Here we see what a simple FinDock installation might look like with NPSP as the source package. The Nonprofit Success Package (in red) either provides the transactions to be collected from recurring donations, or receives new donations from FinDock to be stored in its own data model, such as through the API. This integration is entirely managed by the FinDock for NPSP connector package (in orange).
Because of this standardized interface, we can replace this connector package while retaining all of FinDocks functionality.
As you can see, the only FinDock component which has changed is the connector package. This means that from an end-user perspective, FinDock works exactly the same as before.
Moving from Households and contacts to Person Accounts
Before we get into the payment specific objects, we need to briefly address the switch from the NPSP contacts-in-households model to the Person Account model. As part of the integration with Fundraising in NPC FinDock will ensure full compatibility with Person Accounts. Especially in places where FinDock creates donor records such as through the API or through Guided Matching rules when processing bank- and payment files.
Recurring Donations, Pledges and Payments
Now that we have seen the high level integration pattern. Let’s have a closer look at object mappings from NPSP to NPC with FinDock. Please be aware that not all of the details are fully final yet and object/field mappings might change since development work is still ongoing.
Recurring Donations & Pledges
In NPSP, monthly, quarterly and other interval based donations are recorded in the Recurring Donation object. FinDock creates this object when it receives a “Recurring block” as part of a Payment Intent call through the Payment API. FinDock itself has a recurring object called “Recurring Payment” however, this object is not used in the integration with NPSP but is reserved for stand-alone installations.
In the Nonprofit Cloud fundraising data model, all promised future donations, either interval-based or one-off, are captured in the “Gift Commitment” object. For FinDock this means we will automatically create a Gift Commitment with the associated Gift Schedule whenever a new recurring donation needs to be recorded through FinDock.
One-off donations
Previously, pledges from recurring donations and one-off donations were recorded in the Opportunity object, often renamed to Donations. For the FinDock for NPSP package, this is the main connection point. When new donation opportunities are created FinDock creates an Installment and vice-versa. With NPC storing one-off donations and fulfilled pledges in the Gift Transaction object, the FinDock main integration point shifts to linking the Installment to that Gift Transaction. The Opportunity object is not going away though but will instead be used in its intended role for prospecting and qualifying potential donors and donation opportunities, hopefully resulting in Gift Commitments.
Payments
In NPSP there was the Opportunity Payment object, used to record cash flow and drive Accounting Subledger. Whenever FinDock recorded new cashflow, it would update the Installment and create a new FinDock payment record. And subsequently create or update the NPSP Opportunity Payment record (if NPSP Payments were enabled). In NPC the Gift Transaction is used to capture the status of the donation directly and as such the FinDock Payment object does not have a direct equivalent representation. As such, FinDock will continue to record all cashflow events in its own data model and update the Gift Transaction in NPC with the outcome of that cash flow transaction. Such as marking a Gift Transaction as received and paid (collected) or in the case of a reversed direct debit as Reversed.
Conclusion
While the new Nonprofit Cloud brings many changes to the fundraising data model, the modular architecture of FinDock will enable customers and partners to have a seamless transition. In many cases FinDock continues to work exactly as it does today with NPSP and all the advantages FinDock brings, like scheduling and running Direct Debits and other bulk collection processes, Guided Matching for bank statement reconciliation, Pay-by-Link functionality with PayLinks, and quick and easy Giving Pages all continue to function as expected. In most cases, the configuration steps won’t even change.
Curious to learn more about the Salesforce Nonprofit Cloud? Read more.
In a future blog we will provide more details on the exact nature of the integration between FinDock and Nonprofit Cloud for Fundraising. Make sure to leave your email address here so you don’t miss that!
