The Salesforce audit trail you can keep: a claim that could be wrong

A Salesforce audit trail held in a repository the customer owns, with its pull request history, is more inspectable than a trail held inside a vendor product. That is the position, with the two conditions that would make it false and a revisit date.

The claim, stated so it can be wrong

Inspectable has a narrow meaning here. A record is inspectable when a reviewer with no vendor login can answer three questions for a given change: what changed, who approved it, and what was tested before it reached production. A record is kept when it survives the end of a contract.

The claim is comparative. For an AI-drafted metadata change, a repo plus PR history answers those three questions for more changes, and keeps them longer, than a trail that lives behind a vendor session. It does not call a vendor's Salesforce audit trail wrong; it assumes that trail is read through the vendor, an assumption tested below.

Counting what a Salesforce audit trail lets a reader open

This case is constructed, not measured. A Salesforce team ships 40 metadata changes a month through an AI-assisted pipeline. Over a year that is 40 x 12 = 480 changes.

Assume an admin made 30 of those 480 directly in the org, outside the pipeline. The repo holds a pull request for the other 450. Each PR carries a diff and a named approver, and the change is tested in a sandbox before it is deployed. The inspectable share is 450 / 480 = 0.9375, or about 94 percent.

Assume, for this constructed case, that a vendor-held Salesforce audit trail records the same changes at a higher share; that holds for a tool whose log watches the org and is otherwise an assumption. The difference is access. Assume too that its entries are read through the vendor's interface under its retention terms; the vendor pages cited here do not say how their trails are exported or retained. Then, when the contract ends, a reader can open only what was exported.

The assumption the claim is most sensitive to

The arithmetic rests on one input: that changes flow through the pipeline. If 30 out-of-band edits become 200, the repo's share falls to 280 / 480, about 58 percent, and a tool whose log also records direct org edits gives the reader the more complete record.

That is not hypothetical as a design. According to the vendor's Salesforce page, read 1 Oct 2026, Salto automatically creates pull requests in the customer's Git repository and also keeps a "catch-all change log" that "tracks all changes no matter how they were done." According to Salto's pricing page, read the same day, its plans include Git-based version control and automated PRs for all deployments. Salto offers both records: the repo with its PR history, and a log that absorbs the changes a repo misses. The claim in this column assumes the opposite kind of team: one where the pipeline is the normal route and direct edits are the exception.

Where the claim fails, and what the vendor pages show

The claim also weakens if vendors make their trails portable. According to the vendor's page, read 1 Oct 2026, Gearset's agent, Cam, runs changes through its pipeline while "keeping a full audit trail for compliance". According to Gearset's public roadmap, read 1 Oct 2026, a Gearset MCP server is "In progress" under Q3 2026 and agent bring-your-own-key is "Researching" under Q4 2026. Neither item concerns trail export, and the Cam page does not say where its trail is read.

Two points where the alternatives win belong on the record. According to Gearset's pricing page, read 1 Oct 2026, Gearset offers a 30-day free trial with no card, longer than the 14 days FlowSprite AI offers. According to Salto's home page, read 1 Oct 2026, it lists Salesforce alongside NetSuite, Zendesk, Jira and Okta, a breadth a Salesforce-only tool does not attempt.

What FlowSprite AI records, and what it does not

FlowSprite AI takes the repo side of this argument by construction. Any AI the customer brings drafts the metadata change, and FlowSprite AI lands it as a pull request in the customer's private GitHub repository. The change is tested in a sandbox first, and a human approves it before it is deployed. Production is never auto-touched. The record lives in a repo the customer owns, so the PR history remains theirs after the subscription ends.

Its own audit is narrower and should be read narrowly: it covers every tool call the customer's AI executes, and nothing in this column treats it as a complete record. Audit log export as CSV or JSON sits on the Enterprise tier at EUR 199 per month, which is EUR 199 x 12 = EUR 2,388 a year. Professional is EUR 99 per month and includes drift detection and policy guardrails, but not that export.

Held on 9 October 2026, revisit on 9 April 2027

The claim is held as of 9 October 2026. It is withdrawn if either of two things is observed. First, if a vendor publishes a trail that a reviewer can export in full and read without a vendor login, covering diff, approver and test result per change, the repo loses its advantage on access. Second, if out-of-band edits exceed one change in three, the repo loses its advantage on coverage and the Salesforce audit trail that matters is the one watching the org. That cut-off is assumed, not derived. At the cut-off, 160 of 480, the repo still covers 320 / 480, about 67 percent, but a third of changes sit outside it.

The practical step this quarter is a count: divide last quarter's changes with a PR by the total and write the ratio down. That number decides which Salesforce audit trail a team should treat as primary.

The revisit is 9 April 2027. Roadmap statuses are not delivery dates, so the check is whether any vendor trail by then exports in full; if one does, this column will say the claim was withdrawn and why.