← Zalman Friedman

Salesforce NPC Integration

Neon One, 2025

Problem
Enterprise customers needed Neon Fundraise data — donors, donations, registrations, tickets — synced bidirectionally into their own Salesforce Nonprofit Cloud (NPC) instances. NPC's schema was immature and its documentation underdeveloped and contradictory, but the company's largest-ever enterprise deal depended on it.
My role
End-to-end owner. Led 6 engineers; personally authored the object- and field-level data mapping between Neon's model and NPC's.
Outcome
Shipped. Unlocked the largest enterprise deal in company history — a client with ~$50M in annual fundraising volume, millions of donors, and hundreds of events across North America.

Situation

By 2025 I had owned the platform's CRM sync layer for years — Salesforce NPSP, Neon CRM, Clearview, Oracle, personally producing the data mappings for each and handing them to engineering to validate and build. NPC, Salesforce's replacement for NPSP, was the newest and hardest target, as it was still missing basic objects the fundraising domain requires. NPC didn't support event registration objects, itemized ticket line items, or $0 transactions, though these features are frequently required by nonprofits. Additionally, their documentation contradicted itself often enough that real-world testing revealed noticeable gaps in the written material.

The decisions

The challenge was scoping against a moving, immature schema under an aggressive deadline. My operating rules:

Defer aggressively. Every requirement that wasn't essential to the deal's use cases was cut or postponed. The goal was a sync the client could run their operation on, not schema completeness.

For each gap, escalate before building. First ask Salesforce to extend the schema; only build a workaround when they wouldn't. We got Salesforce to add $0-transaction support, a fix that benefited the whole ecosystem, not just us. We built what they wouldn't support, like a custom object to itemize ticket line items.

Test empirically where docs failed. When documentation was thin or contradictory, I made scope calls based on what the API actually did, not what the docs claimed.

Respect prior decisions. The earlier NPSP integration had established dedup and account/household conventions customers depended on. The NPC build preserved them to maintain compatibility.

Outcome

The integration shipped and we closed the largest deal in company history. The 2023 work making the NPSP integration bidirectional had laid the groundwork for the NPC build. The pattern across the whole sync layer is the same: I do the systems analysis myself — read the partner's API docs, author the field-level mapping, then hand engineering a mapping to refine and build.

What it shows

Hands-on data-model depth, and reversible, requirement-driven scope decisions against a target I didn't control, achieved under deadline, with the company's biggest deal on the line.