Following a Salesforce workflow automation change from pull request to meetings

A routing change in Salesforce workflow automation is approved in an afternoon and judged months later, and most teams only keep a record of the afternoon. The case below is constructed, with illustrative numbers: a Flow that moves leads from nurture into a sales queue gets a lower threshold, passes review, and its meetings arrive three to six weeks after deploy. Only the review record and a holdout show whether the change did anything.

The programme and the change to it

The programme: a record-triggered Flow evaluates every lead in the nurture programme when its score updates. The entry trigger is a form fill that does not request contact; the exit condition is a score of 70 or above, at which point the Flow assigns the lead to the sales development queue and suppresses further nurture sends. Leads below 70 stay in a monthly cadence for 26 weeks, then lapse into dormancy; re-entry needs a new form fill.

The proposed change lowers the threshold from 70 to 60: one number in one decision element, small enough to skip review, large enough to change the sales queue for six months. That is the usual risk in Salesforce workflow automation.

Who enters the new branch

In the constructed case, 1,200 leads enter nurture per month. At the old threshold, 180 of them (15 percent) cross 70 within the window and exit to sales. At 60, the share rises to 300 (25 percent). So the change routes 300 minus 180, or 120, additional leads a month into the queue, all of them scoring between 60 and 69.

Those 120 leads are not a random draw. They reached 60 by opening emails and visiting pages, so they were already likelier to book on their own. Comparing them with leads still in nurture flatters the change.

PR, sandbox and approval for Salesforce workflow automation

The review path is where Salesforce workflow automation leaves evidence or does not. Here the change arrives as a pull request: the Flow metadata diff shows 70 becoming 60, and the description states the population estimate. A sandbox run pushes 20 test leads through, 10 scoring 60 to 69 and 10 scoring 55 to 59, and checks that only the first 10 reach the queue. An approver who did not write the change signs off. Only then does production move.

FlowSprite AI works on the same principles: the team's own AI drafts the metadata change, the change lands as a GitHub pull request in the customer's private repository, it is tested in a sandbox before production, and a human approves before deploy; production is never touched automatically. Professional is EUR 99 a month for 10 users and includes deploy preview, dependency analysis and drift detection; approval workflows with separation of duties sit in Enterprise at EUR 199 a month. Its limits are real. The free trial is 14 days, while Gearset offers 30 days with no card according to the vendor's pricing page, read 1 Oct 2026; Hutte also offers 30 days with no card, according to Hutte's pricing page, read 1 Oct 2026. Teams who work mainly in pooled scratch orgs should look at Hutte; its MCP feature page (read 1 Oct 2026) says it works with sandboxes and scratch orgs, including pooled orgs. A team comfortable wiring its own tooling can start from the free, open-source Salesforce DX MCP server, according to its GitHub README, read 1 Oct 2026.

None of this measures the programme; it fixes the date, diff and approver the measurement needs.

The baseline and its weakness

The closest baseline is last quarter under the 70 threshold, which mixes threshold, season and sales capacity.

A holdout is the defensible baseline. In the constructed case, half of the 60 to 69 band (60 leads a month) is routed and the other 60 stay in nurture. Suppose the routed half books at 5 percent and the held half at 2 percent. That is 3 meetings against 1.2 a month, a difference of 1.8. Over 12 weeks, roughly three monthly cohorts, the counts become 180 routed leads producing 9 meetings and 180 held leads producing 3.6. That is a gap of 5.4 meetings (9 minus 3.6). Readable only because the split was set before deploy.

Lag, measured separately from the window

The window is 26 weeks. The lag is separate: routing to booked meeting. In this constructed case it runs three to six weeks, so leads routed in the first month (weeks 0 to 4) are not fully read until about week ten, and the 12-week read actually needs about 18 weeks of calendar time. A week-four report shows a fraction.

Engagement and progression separate here too. Routed leads stop receiving nurture, so opens fall while meetings rise. Unsubscribes and complaints belong beside meeting counts, since 120 extra contacts a month can generate both. Salesforce workflow automation changes the population; the meeting report, not the open report, says whether that helped.

The exit condition this programme is missing

For the 5.4-meeting gap to be real, the holdout must be assigned before the threshold moves, the scoring model must stay untouched, and sales capacity must hold. The approval record covers the first; drift detection covers part of the second, since an unreviewed edit to the scoring Flow breaks the comparison silently.

The gap is the exit. A routed lead who does not book within six weeks has no rule: it sits in the queue, suppressed from nurture, neither progressing nor eligible for re-entry. In the constructed numbers, once the whole band is routed, 120 leads a month at 5 percent book 6 meetings (120 x 0.05 = 6), which leaves 114 a month with no next step. Before this Salesforce workflow automation change ships, the Flow needs one more decision: after six weeks without a meeting, the lead re-enters nurture at its current score. Without that exit, each quarter strands another cohort.