Salesforce DevOps training in week one: count the artefacts, then delete five

A constructed week-one plan asks an admin to hold eleven artefacts. Six is the realistic number, by my count, for a first week of Salesforce DevOps training. The fix is deleting five artefacts, keeping the six that touch one real change, and judging the week by whether the admin has started one change and had its pull request reviewed.

What should an admin be able to do after week one?

Week one is not "learning Git". Its capability should be observable as an action, not a quiz score.

A reasonable week-one capability, stated as behaviour: the admin describes a small metadata change, reads its pull request diff, asks one question in review, and confirms the change was tested in a sandbox and approved by a human before anything deploys. Production comes in a later phase.

Anything outside that sequence is ongoing enablement, not onboarding. My judgement, not a measurement: I would expect Salesforce DevOps training that blurs the two to stretch past its planned week.

What a constructed week-one plan carries

Here is an illustrative week-one checklist for Salesforce DevOps training. Count the artefacts out loud:

1. Branching strategy document
2. Git command cheat sheet
3. CLI installation guide
4. Pipeline diagram
5. Environment map (which sandbox is which)
6. Naming conventions for branches and components
7. Merge-conflict runbook
8. Pre-deployment checklist
9. Rollback runbook
10. Review checklist
11. A certification-style module with a quiz at the end

Eleven artefacts. If each takes an assumed 1.5 hours to read and practise (an illustrative figure, not a measurement), that is 11 x 1.5 = 16.5 hours, or about 41% of a 40-hour week, before the admin has changed anything.

Cognitive load: why I cap the list at six

In the plan assumed here, the admin is also doing the job, with tickets still arriving.

Six is my working ceiling, a judgement rather than a measured limit. Past it, I would expect the later documents on the list to get skimmed rather than used.

So delete, do not add. In this constructed plan, five artefacts go:

• The Git cheat sheet, if the tool raises the pull request for the admin
• The CLI installation guide, for the same reason
• The pipeline diagram, replaced by watching one change move through the pipeline
• The merge-conflict runbook, deferred to the phase when two people edit the same component
• The certification module, because passing a quiz is not evidence of a capability

That leaves six: branching strategy, environment map, naming conventions, pre-deployment checklist, rollback runbook and review checklist. At the same assumed 1.5 hours each, that is 6 x 1.5 = 9 hours, a saving of 16.5 - 9 = 7.5 hours, and the remaining load sits at 22.5% of the week.

Where the tool decides what Salesforce DevOps training has to cover

Which artefacts can be deleted depends on what the tool does for the admin.

FlowSprite AI is built around one reviewable artefact: the pull request. The customer brings their own AI to draft a Salesforce metadata change; FlowSprite AI lands it as a GitHub pull request in the customer's private repo. Changes are tested in a sandbox first, and a human approves before anything deploys. Production is never auto-touched, and the pull request lives in a repo the customer owns. So the Git cheat sheet and CLI guide can come off the week-one list: the artefact the admin learns is the pull request itself. Pricing is public: EUR 99 a month for Professional with 10 users, and the trial is 14 days with no card.

The honest limits. A team that wants a longer evaluation window should note that Gearset offers a 30-day trial with no card details required, according to the vendor's pricing page, read 1 Oct 2026, and Hutte also lists 30 days with no credit card on its pricing page, read 1 Oct 2026. Hutte's core pitch is scratch-org pooling, according to the vendor's environments page, read 1 Oct 2026. For enterprise release management, Flosum describes itself as designed for "enterprise-scale release processes", according to its homepage, read 1 Oct 2026, and Copado pitches its Agentia Pro tier at enterprise multi-org teams on its Agentia page, read 1 Oct 2026. A developer-heavy team happy to run tools locally may prefer the Salesforce DX MCP server, open source under Apache 2.0, per its GitHub README, read 1 Oct 2026.

The manager's part in week one

The manager's week-one job is three observable things:

1. Pick the first change: small, real, low-risk, on a sandbox
2. Review the admin's first pull request personally, and leave one question rather than a list of corrections
3. Remove one standing meeting from the admin's week to pay for the time

The question in review is the manager coaching.

Observe the result in behaviour, not a survey: did the admin start a second change unasked, and read the diff before approving? That is the evidence Salesforce DevOps training should produce.

What the programme should stop doing

Stop counting modules completed. Stop adding a week-one document every time something breaks in week three. Stop treating Salesforce DevOps training as a fixed curriculum delivered before the work, and start treating it as the shortest path to one reviewed change.

The programme is adequate when the six remaining artefacts are the ones the admin opens unprompted. My rule of thumb: if an artefact has not been opened by the end of week two, treat it as not week-one material.

Good Salesforce DevOps training is measured in time to first change. Here is my threshold, a judgement rather than a benchmark: if the admin has not had a first pull request reviewed by day 5, cut the checklist again before adding anything. If there is still no merged change by day 10 of a 14-day trial (my cut-off), I would treat it as a plan problem rather than an admin problem, and spend the remaining four days on one change rather than on more reading.