← Zalman Friedman

The Salesforce NPC Integration

Data-model tradeoffs against an immature target · 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 thin and contradictory. 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 source-to-target mappings for each and handing them to engineering to validate and build. NPC was the newest and hardest target: Salesforce's replacement for NPSP, still missing basics the fundraising domain requires. No event registration objects. No support for $0 transactions — a problem when free event registration is a core flow. No way to itemize ticket line items. And documentation that contradicted itself often enough that reading it wasn't a substitute for testing it.

The decisions

The real tradeoff wasn't technical elegance — it was scope against a moving, immature schema under a deal 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. This got Salesforce to add $0-transaction support — a fix that benefited the whole ecosystem, not just us. Where they didn't move, we built: 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 rather than relitigating.

Outcome

The integration shipped and the deal closed — the largest in company history. The 2023 work making the NPSP integration bidirectional had laid the groundwork; the NPC build compounded on it. 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 rather than a wish list to interpret.

What it shows

Hands-on data-model depth most PMs don't have, and reversible, requirement-driven scope calls against a target I didn't control — made under deadline, with the company's biggest deal on the line.