7 hard lessons from syncing Salesforce to an ERP

We help maintain an integration that posts donations from Salesforce (NPSP) into a cloud ERP. A redelivery storm once doubled a batch of receipts in the general ledger while every dashboard stayed green. Seven lessons, each paid for in production. (Details anonymized; figures blurred.)

1. A successful write is not a correct write

Every API call succeeded — while the books inflated by a mid-six-figure sum. Every check asked "did the call fail?"; none asked "is the result right?" Reconcile amounts across systems, not just statuses.

2. At-least-once delivery + additive updates = a duplication engine

The event bus redelivers after a slow acknowledgement — that's the contract. The workflow updated existing receipts instead of duplicating — standard pattern. But the update appended lines instead of replacing them, so redelivered events doubled receipts in place. "Probe, then create-or-update" is only idempotent if the update is idempotent.

3. Write-back stamps are memory, not truth

A filled stamp doesn't prove the ERP receipt still exists; an empty one doesn't prove absence. A re-synced payout must come back with a brand-new record number — an old number means the run updated something that shouldn't exist. Stop. Only a cross-system check knows the truth.

4. The books changed, and no process looked at changes

Finance reviewed new records — reasonable, and completely blind to in-place damage that creates no new record and touches no dates. If an integration can update existing ledger records, something in your controls has to watch changes.

5. Dollars don't drive risk — concurrent volume does

The storm broke on several hundred batches in one afternoon; a later, larger-dollar wave ran perfectly clean. Same code. The difference was pacing. Know your load brackets before the backlog day.

6. Load-bearing knowledge must live in the artifact that drives the action

The deadline lived in habit. The delete-first rule lived in a chat ritual. The resync flag lived in a prose column only its author understood. All three failed exactly where they lived. Move deadlines into owned calendars, rules into checklists, guarantees into code.

7. Never assign a rule to someone who can't see the system it checks

Split safety rules by who can act: Salesforce-checkable rules to the Salesforce operator, ERP-checkable rules to finance. Most cross-system runbooks silently assume one person can see everything — and then a rule goes unchecked because its assignee literally can't log in to verify it.

Want the full story? Read the case study of the incident, or go deep with the architecture teardown in dgtl Perspectives.