Hours to a first reviewed change: a Salesforce pull request workflow capacity model

For a two-admin team giving six hours a week between them, the arithmetic below says one reviewed pull request in week one is a target, and three reviewed pull requests inside a 14-day trial is a target only while both admins hold their hours. Lose two hours and three becomes a wish. The model builds a Salesforce pull request workflow forward from signup to show which input binds.

What does a small admin team actually have to spend?

The planning question for a Salesforce pull request workflow is usually "will the trial tell the team whether this works?" That question hides a unit. The unit is admin-hours, and the deliverable is a change someone other than its author has read and approved.

Four inputs set the model. All numbers here are constructed for illustration, not measured from any team:

• Headcount: two admins, no developer.
• Capacity: admin A gives 3 hours a week, admin B gives 3 hours a week, alongside normal tickets.
• Ramp: the first change carries setup; every later change does not.
• Coverage: each change needs a reviewer who did not draft it, so both admins must be present in the same week.

Keep capacity (hours available) separate from productivity (hours per reviewed change).

Building the Salesforce pull request workflow forward from signup

The first reviewed change, in constructed hours:

1. Connect the Git repository and a sandbox: 2.0 hours.
2. Connect the AI the team already uses: 1.0 hour.
3. Draft the first metadata change and read the diff: 1.5 hours.
4. Run it in the sandbox and check the result: 1.0 hour.
5. Second admin reviews and approves the pull request: 0.5 hours.

First change: 2.0 + 1.0 + 1.5 + 1.0 + 0.5 = 6.0 hours. Every later change skips the first two steps: 1.5 + 1.0 + 0.5 = 3.0 hours.

Available capacity in a 14-day trial: two admins × 3 hours × 2 weeks = 12 hours. Three reviewed changes cost 6.0 + 3.0 + 3.0 = 12.0 hours. The target of three clears with zero slack. Setup absorbs a quarter of the budget; the first change absorbs half.

Same model, one input changed

Admin B loses an hour a week to a quarter-end request, so B gives 2 hours instead of 3. Capacity becomes (3 + 2) × 2 = 10 hours. Three changes still cost 12. The gap is 2 hours. Three reviewed pull requests no longer fit the window. Two reviewed changes cost 6.0 + 3.0 = 9.0 hours and clear with 1 hour spare.

Setup is fixed, so the sensitivity is lopsided. Halving the per-change review time from 0.5 to 0.25 hours saves 0.75 hours across three changes. Losing one admin-hour per week costs 2. The input that binds is released capacity, not speed. That matters for any Salesforce pull request workflow: review is the cheapest step, and teams that already review changes are not buying a new habit.

Trial terms are calendar, not capacity

The org controls capacity; the vendor controls the calendar. Gearset offers a 30-day trial, according to the vendor's page, read 1 Oct 2026: "Try it out for 30 days, with no card details required" (Gearset pricing). Hutte also lists 30 days with no credit card, according to the vendor's page, read 1 Oct 2026, after which users revert to a free plan with reduced functionality and keep their projects and data (Hutte pricing). Copado's Agentia Advanced tier lists a "14-day free trial — no credit card", according to the vendor's page, read 1 Oct 2026 (Copado Agentia).

For the same Salesforce pull request workflow at 6 hours a week, 30 days is 30 ÷ 7 = 4.29 weeks × 6 = 25.7 hours, about 26. That absorbs a lost week; 14 days does not.

Where FlowSprite AI fits the model

FlowSprite AI runs a 14-day free trial with no card, so the 14-day calendar above applies to it; the hours are the constructed inputs above, not a measurement of FlowSprite. The structural fit: the team's own AI drafts the Salesforce metadata change. FlowSprite AI lands it as a GitHub pull request in the customer's private repository. Changes are tested in a sandbox first, and a human approves before anything deploys. Production is never auto-touched, and the record lives in a repo the customer owns. Pricing is public and flat: EUR 99 a month for Professional, which covers up to 10 users and 6 Salesforce connections. For two admins that is EUR 99 ÷ 2 = EUR 49.50 per admin per month. Limits, honestly: a team that cannot release 6 hours inside two weeks should prefer a 30-day trial, a team that needs scratch-org pooling should look at Hutte, whose Core plan includes scratch org and sandbox pooling, according to the vendor's page, read 1 Oct 2026, and a CLI-comfortable team can start from the free, open-source Salesforce DX MCP server, according to the project's GitHub README, read 1 Oct 2026.

The test that turns a target into a wish

A target becomes a wish when the hours required exceed the hours released, at the date the plan is checked. For this Salesforce pull request workflow, the test: by day 7, the first change must be reviewed and approved, which means 6 hours spent. If not, the first change spills into week two, leaving room for one later change at most. Rewrite the target to two reviewed changes that day, not on day 14.

Who signs the number: the admin lead who releases the hours. The decision this entry supports: before starting any trial, write down hours per admin per week, multiply by trial weeks, and subtract 6 for the first change. Each remaining 3 hours buys one more reviewed change. If the result is below 3, the Salesforce pull request workflow target for the trial is one reviewed change, and the plan should say so on day one. If the result is negative, even one reviewed change is a wish.