Salesforce consulting partner delivery is the path a firm follows from a client request to a documented change in the client's org. A repeatable build process fixes that path: every consultant runs the same stages in the same order with the same templates, so the client gets the same result whoever builds the work.
This guide describes a six-stage process that a small or midsize practice can adopt without new tooling. The stages are intake and org baseline, design decisions, a sandbox build from a standard kit, a written test script, documentation while you build, and a controlled deploy with a handoff pack. Each stage lists what to produce and what to check before moving on. The Cirra AI page for Salesforce consulting partners describes how an AI client can take on part of the build work inside the same process.
Why partners need a fixed delivery process
Client requests arrive in every shape: a new field, a rebuilt flow, a permission clean-up, a request to match what another client already has. Without a fixed path, quality depends on which consultant picks up the ticket. Senior people get pulled back into rework, junior people guess at conventions, and documentation is written at the end of a sprint from memory.
A written process moves those choices out of individual heads and into templates. It also makes a second consultant interchangeable with the first. When a client returns after six months or a colleague covers a holiday, the next person opens the same set of records and sees the same structure.
The artifacts that make a process repeatable
A process lives in its artifacts. Six records carry a request from intake to handoff, and each one has a named owner so nobody assumes someone else filled it in.
| Artifact | What it holds | Owner |
|---|---|---|
| Intake form | The request, the business reason, the objects and users affected, the approver and the requested date | Delivery lead |
| Org baseline | Edition, available sandboxes, installed packages, automation inventory per object, naming conventions already in use | The consultant who first connects the org |
| Standard build kit | Naming rules, permission set pattern, templates for fields and flows, rules for description text | Practice lead |
| Build ticket | One change, its design decision, its sandbox and its test cases | Builder |
| Test script | Steps and expected results for each user persona | Builder, run by a second consultant |
| Handoff pack | Change log, documentation updates, deploy notes and open items | Delivery lead |
Keep each artifact short enough that people fill it in. One page is a good target.
The six stages of a repeatable build
Stage 1: Intake and org baseline
Every request enters through the same form. Required fields are the outcome the user wants, who is affected, which objects are involved, whether the change touches existing automation, and who approves it. A request that cannot name a business outcome goes back to the requester before anyone opens the org.
The consultant then compares the request to the org baseline. The baseline is a living record created the first time your firm touches a client org. It lists the edition, the sandboxes available, installed packages, the flows and triggers on each object, and the naming conventions the client already uses. For a new client, building the baseline is the first piece of work. Reading the live metadata gives a more reliable picture than a handoff document, because documents drift as soon as someone changes the org.
Check before moving on: the request names a business outcome, and you know what else on the same objects already runs.
Stage 2: Design decisions before anyone builds
Write the design decision on the build ticket before opening Setup. Settle four questions: whether the change is declarative or needs code, which object holds the data, how access will be granted, and what each new component will be called. Naming belongs in the standard kit so no consultant invents a convention per client. The guide to Salesforce naming conventions covers the patterns worth putting in that kit.
Grant access through permission sets named for the job they enable, and avoid editing profiles for a single request. A second consultant reviews the design for anything that adds to an object that already carries automation, because a new record-triggered flow on a busy object can interact with the automation already there.
Check before moving on: a second consultant has read the design, and the test cases are listed on the ticket.
Stage 3: Build in a sandbox from the standard kit
Give each consultant a Developer or Developer Pro sandbox for the client, and keep a shared sandbox for user acceptance testing. The post on Salesforce sandbox best practices explains the sandbox types and how refreshes work.
Start every build from the kit. Copy the field template with its description and help text filled in, start flows from the skeleton that already has a fault path, and create the permission set from the firm's pattern. Record what you built on the ticket as you go. Deploy or retrieve any work in progress before a sandbox refresh, since a refresh can overwrite changes that exist only in the sandbox.
Check before moving on: every component on the ticket matches the design decision and the kit's naming rules.
Stage 4: Test with a script
A test script lists a persona, the steps and the expected result for each case. Include at least one persona who should be blocked from the new field or action, because access mistakes show up there first. Add a negative case for each validation rule and a multi-record case for each automation.
The builder writes the script and a second consultant runs it. Results go on the ticket, including failures and the fix. When a client signs off in user acceptance testing, attach their confirmation to the same ticket so the evidence sits in one place.
Check before moving on: every case has a recorded result, and the person who ran the script is not the person who built the change.
Stage 5: Document while you build
Documentation written after the sprint is a reconstruction. Write each entry at the moment of change: the data dictionary line for a new field, the purpose of a flow, the description of a permission set. The rule is short. A change is not finished until its documentation entry exists, and the reviewer checks for it.
A description typed at build time takes little effort, and it prevents the situation where the next consultant opens a client org and finds dozens of fields nobody can explain. The page on Salesforce org health and documentation with AI shows how an AI client can read live metadata and turn it into a document you can hand to the client.
Check before moving on: the documentation entry exists and says why the component exists, in addition to what it does.
Stage 6: Deploy and hand off
Deploy through the route the client has agreed to. Change sets and Salesforce CLI are common options, DevOps Center is another, and the process works with any of them. Validate before the deploy window, confirm that the permission sets travel with the change, and keep the test script handy for a quick check in production afterward. A field that deploys without its permission set can look to users like a field that does not exist.
Close the ticket with a handoff pack: the change log entry, the documentation updates, the deploy notes and any open items. Send the client the same pack in the same format every time. After a few engagements the format becomes familiar, and clients stop asking where to find things.
Check before closing: the handoff pack is complete and the client has received it.
A build ticket template you can copy
The build ticket is the artifact consultants touch most. This version fits on one screen and works in any ticketing tool or shared document. It contains no code or formulas, so nothing in it depends on a particular org.
BUILD TICKET Client org: Request ID: Business outcome: Design decision (declarative or code, and why): Objects and fields touched: Existing automation on those objects: Access (permission sets created or changed): Naming checked against the standard kit: yes / no Sandbox used: Test script link: Test result and reviewer: Documentation entry updated: yes / no Deploy route and window: Handoff pack link:
Every line maps to one of the six stages. If a line stays empty at close, the ticket is not done.
Where an AI client fits into the process
Cirra AI is the first commercial Salesforce Admin MCP Server. It is hosted, so there is nothing to install. Your team connects each client org once through OAuth and works from the AI client it already uses, such as Claude, ChatGPT or Cursor. Cirra AI makes changes as the connected user, within that user's permissions.
Inside the six stages, it helps most in four places:
- Baseline and documentation. Ask for a review of one area, such as automation on the Opportunity object, and Cirra AI reads the live metadata. You can compare metadata between two connected orgs in the same conversation and ask your AI client to write the findings to a Word, Excel or HTML document.
- Build. Paste the design decision from the ticket and ask for the objects, fields, flows, validation rules or permission sets it describes. The consultant reviews the result in the sandbox against the design before it goes anywhere.
- Repeat work across clients. Each client org is its own connection under one account, and you switch between them by naming the org in the conversation. The same request can roll a standard permission set or validation rule out to several connected orgs, one at a time. The multi-org Salesforce management page describes the setup.
- Governance. Access controls cover four data categories (Metadata, User Data, Personal Setup Data and Business Data). Each category can be set to None, Read Only or Read and Write. Actions are logged in an exportable audit trail.
Cirra AI does not manage promotion through your release process. Make the change in the sandbox and deploy it through the route you chose in Stage 6. The Team plan includes unlimited users, sub-teams and Salesforce orgs with a shared credit pool. Cirra AI requires Salesforce Enterprise Edition and up, and the Free plan includes 100 credits a month if you want to try it on one org first.
Mistakes that break repeatability
- Letting templates fork per client. A consultant copies the kit, tweaks it for one engagement and the tweak spreads. Keep one kit, and record client exceptions in the org baseline.
- Skipping the baseline on small requests. The small change on a busy object is the one that collides with existing automation. The baseline lookup takes a few lines on the ticket.
- Letting the builder test their own work. People read their own work the way they meant it. A second consultant finds the case the builder did not think of.
- Writing documentation at the end of the sprint. By then the reasons are forgotten. Treat the entry as part of the change.
If your practice runs the same process across several client orgs, the next step is to see it against a real org. Connect a sandbox and walk one request through the six stages. To discuss a rollout across a team, use Book a Demo on the demo page.
Frequently asked questions
What is a repeatable Salesforce build process?
A repeatable Salesforce build process is a fixed sequence of stages that every consultant at a firm follows for every client change, using the same templates at each stage. The sequence in this guide runs from intake and org baseline through design, sandbox build, testing, documentation and deploy. The same inputs go in, and the same records come out, no matter who does the work.
How many stages should a consulting partner's delivery process have?
Six stages cover most admin and configuration work: intake and org baseline, design decisions, sandbox build, test script, documentation and deploy with handoff. A firm that also runs data migrations or integrations can add stages for those, but each added stage needs its own template and owner, or it will be skipped.
Should every client get its own standard build kit?
No. Keep one standard kit for the whole firm, covering naming rules, permission set patterns and templates for fields and flows. Client-specific conventions belong in that client's org baseline. When a client's conventions differ from the kit, the baseline wins for that org and the exception is written down.
How do consulting partners keep Salesforce documentation current?
Make documentation part of the definition of done. A change is finished when its documentation entry exists, and the reviewer checks for it before sign-off. An AI client connected through Cirra AI can read the live metadata of an area you changed and write the findings to a Word, Excel or HTML document, which gives the reviewer something to compare against the entry.
Can an AI client work across several client orgs without mixing them up?
Cirra AI keeps each connected org as its own connection under one account. You tell your AI client which connected org to work in, and Cirra AI routes the request to that connection. Each connection is scoped to that org's own permissions, and the consultant still reviews every result in the sandbox before anything is deployed.
Which parts of the process can an AI client take on?
An AI client connected through Cirra AI can read live metadata for the org baseline, build objects, fields, flows, validation rules and permission sets in a connected sandbox, and write findings to a document. Intake, design decisions, test review, deployment and the client relationship stay with your consultants.
