Does your Salesforce change history survive a reorganisation?

A process that requires both managers to remember it is not a process. The same holds for Salesforce change history: it survives a reorganisation only if the receiving role can open it on day one without asking the departing admin for anything. A record held in a Git repository the organisation owns passes that test by default. A record held inside a vendor account passes it only if someone has already moved the seat, the token and the export to a role rather than a person.

Name the handoff before you name the tool

The handoff here is specific. Trigger: the admin who owned Salesforce changes leaves, or the team that owned them is merged into another. From role: outgoing change owner. To role: incoming change owner, often in a different reporting line. Acceptance condition: the receiver can answer three questions for any change in the last two quarters without a meeting. What changed, who approved it, and why.

If the receiver can answer those, the handoff is accepted. If not, it is rejected and the gap goes to escalation, which usually means a manager chasing someone who has already left.

One change through the ordinary case, and one that arrives incomplete

Take an illustrative team. The numbers below are constructed for this example, not measured. The outgoing admin role ships 14 changes a week. Over 26 weeks that is 14 x 26 = 364 changes. In the ordinary case a change arrives with a diff, an approver and a short reason, and the receiver accepts it in under one business hour, Monday to Friday.

Now assume one change in seven arrives incomplete: a diff with no reason attached. That is 364 / 7 = 52 items. If reconstructing the reason takes 20 minutes each, the receiver absorbs 52 x 20 = 1,040 minutes, roughly 17.3 working hours, in the weeks after the reorg. The rejection path is a question to the sender, and the sender is gone. That is the real cost of thin Salesforce change history: not the missing record, but the missing person who could fill it in.

Where Salesforce change history breaks in a reorganisation

It breaks where access is bound to an individual. Read vendor pages with that in mind. Hutte's MCP documentation says, according to the vendor's page, read 1 Oct 2026, that "a token carries the full access of the user who created it, so store it as a secret". That is an honest statement, and it makes a departing user's token a handoff item.

Gearset's Cam page says changes run through its pipeline while "keeping a full audit trail for compliance", according to the vendor's page, read 1 Oct 2026. The page does not say where that trail is stored, so the receiver should ask the vendor which role can export it after the original buyer's reporting line changes.

Salto's technology page says "a Workspace is a folder containing Salto configuration files, including the State and NaCl files", and its Salesforce page says it creates pull requests in your Git repository, according to the vendor's pages, read 1 Oct 2026. That is the same structural answer this post argues for: the record sits in a repository the customer can keep.

The smallest change: move the record to a role-owned repository

Prefer removing a step to adding a check. The step to remove is "ask the outgoing admin". If every Salesforce change history entry is a pull request in a private repository owned by the organisation, the receiver accepts the handoff by being granted repository access. No export, no seat transfer.

That is the structural claim behind FlowSprite AI: any AI the customer brings drafts a Salesforce metadata change; FlowSprite AI lands it as a pull request in the customer's private GitHub repository, the change is tested in a sandbox before production, and a human approves before deploy; production is never auto-touched. Every tool call the customer's AI executes is audited, and the Enterprise tier at EUR 199 a month adds approval workflows with separation of duties and audit log export in CSV or JSON. Professional is EUR 99 a month for 10 users. The limits are real. Its 14-day trial is shorter than the 30-day trials on the Gearset and Hutte pricing pages, read 1 Oct 2026. Salto's home page lists Salesforce, NetSuite, Zendesk, Jira and Okta, according to the vendor's page, read 1 Oct 2026, so teams wanting one platform across those apps are better served by Salto. Organisations that want DevOps, backup and security bought as one enterprise suite will find more depth with Flosum or AutoRABIT, according to the vendors' home pages, read 1 Oct 2026.

What it costs the sender

A repository-first record is not free for the sender. Each change needs a reason written into the pull request at the time of approval, which this example assumes is two minutes of judgement per item. Over the same 26 weeks that is 364 x 2 = 728 minutes, about 12.1 hours, against roughly 17.3 hours absorbed later by the receiver. The sender pays in small, predictable amounts so the receiver does not pay in one large, unplanned one.

If your Salesforce change history already meets the acceptance condition, leave the working process alone. Moving a healthy record for its own sake is a reorg of its own.

The signal that the handoff is degrading

Watch one number: the share of merged changes in the last 30 days with an empty reason field. Count changes with no reason, divide by changes merged. When that rate climbs above the one-in-seven used in the illustrative example above (a threshold to set for your own team, not a measured benchmark), the next reorganisation is likely to reject the Salesforce change history it inherits, and a bill like the example's 17 hours is already accruing.

Then ask the question that matters for any handoff. Would this record survive both sides changing manager in the same month? If the answer depends on a person rather than a role, the Salesforce change history is a memory, not a process.