A Salesforce governed change is whatever the dashboard's author decided to count, and three vendor pages describe control at three different grains: a reviewed pipeline with an audit trail, a human-verified release, and an approved pull request. The same quarter of work can report 100, 80 or 50 percent governed. Before trusting the tile, establish which grain sits under it and which denominator it divides by.
The tile and the question it claims to answer
Take a common tile: "Governed changes, this quarter", a percentage beside a green arrow. It asks whether each Salesforce governed change reached production through a controlled path. But the tile carries no definition beside it, so a reader cannot tell whether it counts changes, releases or pull requests, or what it divides by.
A percentage has a numerator and a denominator, and both are choices.
Tracing the governed share back to its fields
The Salesforce governed change percentage resolves to a count of rows flagged governed over a count of rows in a window. In a constructed export, each row carries change_id, release_id, pr_url, pr_approved_by and deployed_at. In this example the window filter runs on deployed_at, the date the change reached production, not the merge date; a change merged on 30 September and deployed on 2 October lands in the next quarter.
The flag marking a Salesforce governed change is where the definition hides. It can be set by a pipeline log entry, by a sign-off on the parent release, or by a non-empty pr_approved_by. Each is defensible; they are not the same measure.
Three vendor definitions of a Salesforce governed change
According to the vendor's page, read 1 Oct 2026, Gearset describes its Cam agent's output as validated changes submitted to a governed DevOps pipeline "ready for your team to review", promising to "ensure security and quality, while keeping a full audit trail for compliance". Read as a dashboard grain, governed means the change passed through that reviewed pipeline and left a trail.
Copado's Agentia page, read on the same date, states that "humans verify outcomes before any release reaches production". The grain there is the release: a human looks at the outcome before it ships.
Salto's home page, read on the same date, lists "PR-gated approvals, automated promotion to production, and drift detection on every change". The grain is the pull request, approved before promotion. Salto's Salesforce page, read on the same date, also describes a catch-all change log that "tracks all changes no matter how they were done", which matters for the denominator below.
None of these is wrong; each vendor describes what its own product records. The reader's job is to know which Salesforce governed change definition a dashboard inherited.
The same quarter under each definition
A constructed example, with illustrative numbers. In one quarter, 140 metadata changes reached production. Of those, 112 went through the pipeline and 28 were made directly in the production org. The 112 pipeline changes shipped in 14 releases, each signed off by a named reviewer. Of the 112, 70 were merged through a pull request with a recorded approver; 42 were bundled onto a release branch without individual approval.
Under the pipeline reading, with pipeline deployments as the denominator, the tile shows 112 / 112 = 100 percent. Restate the denominator as every change that reached production, and it becomes 112 / 140 = 80 percent.
Under the human-verified release reading, the release grain gives 14 / 14 = 100 percent. Restated to the change grain, the 28 direct edits never joined a release, so it is again 112 / 140 = 80 percent.
Under the PR-gated reading, only approved pull requests count: 70 / 112 = 62.5 percent against pipeline deployments, 70 / 140 = 50 percent against every production change.
Re-checking: 112 + 28 = 140, 70 + 42 = 112, 112 / 140 = 0.8, 70 / 112 = 0.625, 70 / 140 = 0.5. The work never changed; only the definition of a Salesforce governed change did.
Which definition the org should report, and where FlowSprite AI fits
The org should report the strictest grain it can reconcile to every production change: approved pull requests over all changes deployed in the window. That denominator has to come from a log that sees direct org edits too, otherwise the 28 out-of-band changes vanish and the figure flatters itself.
This is the grain FlowSprite AI is built around. Any AI the customer brings drafts the Salesforce metadata change. The change lands as a GitHub pull request in the customer's private repo, it is tested in a sandbox before production, and a human approves it before deploy; production is never auto-touched. The record lives in a repo the customer owns, and every tool call the customer's AI executes is audited. The Enterprise plan, at EUR 199 per month, adds approval workflows with separation of duties and audit log export in CSV or JSON, so the approver can be checked against the author. Professional is EUR 99 per month for up to 10 users.
The limits are real. A repo only records changes that went through the repo, so the out-of-band denominator still needs another source. Teams that want enterprise depth across a whole release suite may find Copado, Flosum or AutoRABIT a better fit, Salto covers business applications beyond Salesforce, and Gearset offers a 30-day trial against FlowSprite's 14 days, according to each vendor's page, read 1 Oct 2026.
A check you can run on last week's data
Take last week. Export every production change your broadest change log holds, with deployed_at in the window. Count the rows. Then count the rows with a non-empty pr_approved_by. Divide the second count by the first.
Put that ratio beside the tile for the same week. If they agree within a point or two (a rule of thumb, not a standard), the tile is consistent with the approved-PR definition and you can stop. If the tile is higher, it is counting releases or pipeline entries, and the footnote it needs is one sentence: a Salesforce governed change means an approved pull request, over all changes deployed, windowed on deployed_at.