Nightly transfers between Salesforce orgs: what we learned at GoodLeap

The situation

GoodLeap is a US mortgage and consumer-finance lender running loan origination on Financial Services Cloud, Sales Cloud and Service Cloud across several orgs, with a backlog measured in months. Loan officers assembled client context by hand before every call. Marketing attribution was updated manually. And a nightly transfer of about 20,000 records between systems failed roughly every two weeks, found in the morning and fixed by hand, with nobody able to say which change had caused it.

Why nightly transfers fail

Not usually because of the code that moves the records. Because of everything around it: a field someone renamed on one side, a payload that grew past a limit, an OAuth token that expired, a trigger added last week that now fires on every imported row, and no record of any of those changes. The transfer is the place where every undocumented change in two orgs meets at once, at night.

What we changed, in order

1. A two-week win first

Before touching the transfer, one visible result: mortgage marketing attribution automated on opportunity creation, with bulk transactions and protection for valid manual values. Two weeks, one named outcome, trust earned.

2. An integration backbone

MuleSoft Anypoint and Composer where the client already paid for them, with field and payload mapping written down, webhooks and Platform Events instead of polling, OAuth client-credential flows that renew themselves. Figure, ICE Encompass, Insellerate, Verse, Mogli SMS, Genesys Cloud CX, Experience.com, Domo and Databricks all talk to Salesforce through that backbone now.

3. Idempotent writes and visible failures

A record delivered twice changes nothing twice. A failed batch retries with backoff, then lands in a queue a person can see, with an alert. A runbook says what to do on Monday morning and how to replay.

4. A release process

Development, QA, user acceptance, production. A go/no-go, smoke tests, a release window, a rollback tested before the window opens, and a change record for every release: who asked, who built, who tested, who approved. Small governed work streams instead of a big bang: four projects in the first four weeks, eight in nine.

The numbers

Delivery that used to take six to twelve months on the internal baseline now ships in weeks. Thirteen governed production releases documented. The large integration releases of early 2026 ran without a P0 or P1 incident. And one rollback in the period, which we count as a success: the rollback path existed, it was tested, it was used, and nobody found out in the morning.

What we did not do

Service Cloud Voice and Agentforce were discussed and scoped, and not contracted. The integration and release work had to come first, and the case study says so. An agent on top of an org whose nightly transfer fails every two weeks would have been a complaint, not a feature.

Five checks for your own multi-org setup

1. When the transfer last failed, how did you find out: an alert, or a person?
2. Can anyone list the changes made to either org in the last month, with names?
3. Is there a test environment with a copy of the data where the transfer runs before production?
4. Does a delivered-twice record change anything twice?
5. Who can replay a failed batch without calling the partner?

What a change record looks like

Requested by: the head of lending operations, because transfers failed silently twice a month. Built by: the lead engineer named in the proposal, the same two people since release one. Tested in: a full copy of the system, then by the users, with a test script signed by the operations lead. Approved by: compliance, IT, the business owner. Release window: Friday, 02:00–06:00 Eastern. Rollback tested: twenty minutes, no data loss. Result: no incidents. One page, filed by compliance, readable at an examination. Every release gets one, and the thirteenth looks like the first.

Why MuleSoft, and when not

GoodLeap already ran MuleSoft Anypoint and Composer, so the backbone used them: a licence already paid for, with the monitoring and retry behaviour built in. We would not have recommended buying it for one transfer. For a single org with two or three integrations, Platform Events, Change Data Capture and REST callouts do the same job without a middleware bill, and the runbook is shorter. The rule is simple: use the middleware you pay for; do not buy middleware to fix one flow.

The full GoodLeap case, and the integration services page with the five rules every integration we ship follows.