An approval rate for Salesforce agent approvals is only meaningful once its denominator is written next to it: approved changes over drafted changes, over reviewed changes, or over decided (approved plus rejected) changes each answer a different question. The defensible default is approved over reviewed, counted on one cohort date field, with drafted volume reported beside it. A rate built from an audit log needs extra care, because an audit that records executed tool calls never sees the calls that were refused.
What the approval tile claims to answer
The report is a single tile on a governance dashboard: "Agent change approval rate, last 30 days: 75%." It claims to answer a fair question: of the changes an AI agent proposed against Salesforce metadata, how many did a human accept?
Credit first: somebody chose to measure Salesforce agent approvals. But the question in the title and the query underneath are not the same object.
Tracing Salesforce agent approvals back to the pull request
The vendors building Salesforce agents describe a review step. According to the vendor's page, read 1 Oct 2026, Gearset's agent produces "validated changes ready for your team to review". Copado's Agentia page states that "humans verify outcomes before any release reaches production", according to the vendor's page, read 1 Oct 2026. Salto lists "PR-gated approvals" on its home page, according to the vendor's page, read 1 Oct 2026.
Where review is a pull request, the tile traces hop by hop. The tile reads a count of approved changes. That count reads pull requests with an approving review. Each pull request carries created_at, merged_at and closed_at, and each review carries submitted_at and a state. The grain is one pull request. The numerator is pull requests with at least one review in state APPROVED.
The denominator of Salesforce agent approvals is where the definitional choice sits, and the tile above does not print it.
Three denominators, three readings
A constructed example, illustrative numbers only. In one 30-day window an agent drafts 200 Salesforce metadata changes. 40 never reach a reviewer: the author discards them, or they fail testing. 160 reach a reviewer. 120 are approved.
- Approved over drafted: 120 / 200 = 60%.
- Approved over reviewed: 120 / 160 = 75%.
- Approved over approved-and-rejected only, excluding the 10 still open: 120 / 150 = 80%.
Re-check: 200 minus 40 is 160; of the 40 reviewed but not approved, 30 were rejected and 10 are open, so 120 plus 30 is 150. Three readings, 60% to 80%.
The date field matters as much as the denominator. If the numerator is windowed on submitted_at of the approval and the denominator on created_at of the pull request, a change drafted on 28 September and approved on 2 October lands in different windows. Window both sides on created_at, so the numerator is a subset of the denominator.
What the audit log can count, and what it cannot
The tempting shortcut is a second rate, "share of agent actions allowed," computed from the audit log. That figure is biased in one direction. An audit log that records the tool calls an AI executes contains no row for a call the permission layer refused, because the refused call never executed.
Same constructed month: the agent attempts 500 tool calls and 60 are denied by its role scope. The audit holds 440 rows. Computed from the audit alone, the allowed share is 440 / 440 = 100%. The true figure is 440 / 500 = 88%. The missing 12 points are the governance events the dashboard exists to show.
The audit figure is a count of executed calls, not a rate. Denials must be counted where they were seen: the AI client's request log or the permission layer's error responses.
This is where tooling changes how Salesforce agent approvals get reported. FlowSprite AI lets the AI the customer brings draft a Salesforce metadata change, which lands as a GitHub pull request in the customer's private repository; changes are tested in a sandbox first and a human approves before deploy, and production is never auto-touched. Reviewed and approved changes are therefore pull requests in a repository the customer owns, and every tool call the AI executes is audited. The Enterprise tier, EUR 199 per month, adds approval workflows with separation of duties and audit log export as CSV or JSON, which supplies the executed-call count. Its limits are the ones this post describes: the audit covers executed calls, so denials still need the client-side count. According to the vendor's page, read 1 Oct 2026, Gearset offers a 30-day trial with no card, more room than FlowSprite AI's 14 days. Large multi-org release teams may prefer Flosum, which, according to the vendor's page, read 1 Oct 2026, targets "multiple orgs" and "enterprise-scale release processes".
Which definition to adopt for Salesforce agent approvals
For Salesforce agent approvals, report approved over reviewed as the headline rate, windowed on created_at, and print three numbers beside it: drafted volume, open-at-snapshot count, and denied calls from the client log. Approved over drafted mixes reviewer judgement with author abandonment and sandbox failures; it is a pipeline yield, not an approval rate. Approved over decided excludes open items and flatters a slow reviewer.
A working threshold, chosen for this post rather than taken from any standard: where readings differ by under two points, say so and stop arguing. In the constructed month the drafted and reviewed readings differ by 15 points, which is material.
A quick check against the tile
From the repository the agent writes to, pull every pull request with created_at in last month's window. Count those with any submitted review; count those with an APPROVED review. Divide, and compare with the tile. If the tile is higher, either its numerator is windowed on a different date field or its denominator excludes open items. Then open the AI client's log for the same window and count refused calls. If that count is not zero and the dashboard shows no denials, the tile is reading the audit as if it were complete.