Separation of duties Salesforce teams can keep through a reorganisation

A process that requires both managers to remember it is not a process. Separation of duties Salesforce teams set up for AI-drafted changes can survive the tooling and still fail at the handoff: the moment a drafted change moves from the role that asked for it to the role that accepts it. If that handoff is written down as a trigger, an acceptance condition and a rejection path, and enforced by the system rather than by memory, it survives a reorganisation.

What is the handoff, and who owns each side?

The sender is the author role: an admin who prompts an AI agent, plus the agent that drafts the metadata change. The receiver is the approver role: someone who did not ask for the change and who can say no. The trigger is a drafted change landing in a reviewable place, with its sandbox evidence visible alongside the diff.

The acceptance condition is the part that is easiest to leave unwritten. A workable version has three clauses: the change ran in a sandbox first, the approver can see what metadata moved, and the approver is not the person who prompted it.

Copado frames the human side of this as a standard: humans set intent and guardrails, agents execute, and, according to the vendor's Agentia page, read 1 Oct 2026, "Humans verify outcomes before any release reaches production." That sentence describes the receiver. It does not, on its own, say who the receiver is allowed to be, and that is where separation of duties Salesforce governance gets decided.

One change through the ordinary case

A constructed example, numbers illustrative. An org team of eight handles 40 AI-drafted changes in a working week. Two people hold the approver role and split the queue, 20 items each. Review takes about 12 minutes per item, so each approver spends 20 × 12 = 240 minutes, four hours a week. Median time to acceptance is six business hours. Six of the 40 items are rejected, a 15% rejection rate (6 / 40 = 0.15), mostly for missing sandbox evidence.

The ordinary item is boring by design: a validation rule change is drafted, passes in the sandbox, the approver reads the diff and accepts it. Nobody had to remember anything.

The item that arrives incomplete

Suppose the drafted change touches a flow and a permission set, but the sandbox run covered only the flow. The approver rejects it with a reason tied to the acceptance condition ("sandbox evidence incomplete"), and the item goes back to the author role, not sideways to a colleague who might accept it.

Separation of duties Salesforce teams depend on is only real when a rejected item has exactly one way forward: back to the sender.

Where separation of duties Salesforce teams rely on breaks under a reorg

Now the reorganisation. One approver moves to a platform team. Their permissions stay, but their attention leaves. The remaining approver absorbs all 40 items: 40 × 12 = 480 minutes, eight hours a week, double the earlier load. The backlog grows, and the author role's manager grants two senior admins approval rights "for now".

Three weeks later, in this constructed case, 9 of 40 weekly items are approved by the same person who prompted them: 9 / 40 = 22.5%. No one decided to drop separation of duties Salesforce controls. The roles were redrawn and the condition "approver is not the author" was never enforced by anything that noticed.

The question to ask of any handoff: would it survive either side changing manager? Here, one side changed and it did not, because the acceptance condition depended on who happened to hold which role.

The smallest change that removes the break

The smallest fix is to make the system refuse self-approval, so the acceptance condition holds regardless of who is in which role this quarter.

This is the structural point where tooling matters. In FlowSprite AI, any AI the customer brings drafts the metadata change. Changes land as GitHub pull requests in the customer's private repository, changes are tested in a sandbox before production, a human approves before anything deploys, and production is never auto-touched. Approval workflows with separation of duties sit on the Enterprise tier at EUR 199 per month (25 users, 20 Salesforce connections), alongside audit log export and custom policies. The Professional tier at EUR 99 per month does not list approval workflows, so a team that needs the author and approver roles enforced should price Enterprise, not Professional. Every tool call the customer's AI executes is audited, and the changes themselves sit in a GitHub repository the customer owns, which outlasts a reorg.

The honest limits: FlowSprite AI does not fit an enterprise that wants the vendor's own agents across plan, build, test, release and operate; according to Copado's Agentia page, read 1 Oct 2026, Agentia runs specialised agents across that whole lifecycle. Teams that want a longer evaluation will find Gearset offers a 30-day trial with no card, according to the vendor's pricing page, read 1 Oct 2026, against FlowSprite's 14 days.

What it costs the sender, and the signal that it is degrading

Enforced separation costs the author role something real: it can no longer unblock itself. That price is worth naming before the reorg, not after. If the time to acceptance regularly exceeds a working day (a rule-of-thumb threshold, not a benchmark), fix approver capacity; do not loosen the condition.

Leave a working handoff alone if three numbers stay steady: rejection rate, time to acceptance in business hours, and the share of items approved by their own author. The third is the one that matters for separation of duties Salesforce governance, because once author and approver are separated it should stay at zero, and any value above zero means a role changed hands without the rule following it.

The signal that this handoff is degrading: self-approved items above zero in any working week, or a rejection that was resolved by a different approver accepting the same unchanged item. Check both every Friday. If either appears, the process has started depending on someone remembering it.