AI-native Salesforce delivery process in 14 steps

An AI-native delivery process for Salesforce turns the Jira ticket into an executable specification. An agent does the legwork from preparing the workshop to the pull request, the pipeline checks deterministically, and people decide at five fixed gates: minutes, spec, code review, bugs and change requests, release. The process has 14 steps from the first requirement to production. It holds together a chain that classic projects rarely manage: every line of code traces back to a sentence someone at the client said. For manufacturers one thing changes most: the business sees something that runs much earlier and has to confirm faster in return.

What does AI-native mean in a Salesforce project?

AI-native delivery means building the delivery process around the agent instead of adding a coding assistant to the old process. How this changes the team set-up I described in AI-native delivery: smaller Salesforce teams. This article is about the flow itself. It is my target picture: I already use individual steps, I will set it up end to end from workshop to production in my next project, and a few gaps are still to close. It rests on four ideas:

The difference to AI-assisted: there the old process gets a coding assistant, the business analyst keeps typing up stories, and the client sees something that runs only in acceptance testing. Here the agent delivers minutes, stories and a prototype, and every piece of feedback is classified against the confirmed minutes.

How does the process run from workshop to production?

The process has three phases with 14 steps in total. Each graphic shows one phase in three lanes: what people do in conversation, what the agent does and what the pipeline checks. The dark bars are the gates where a person makes a binding decision. The blue column on the right shows the status of the Jira ticket and who sets it: the agent creates stories directly in Jira, the pipeline moves the status on by itself after validation and deployment.

Discovery: the agent prepares, people hold the conversation

Phase 1 of 3 · Discovery

1. People
2. Agent
3. Pipeline
4. Jira

1. 01 · AgentPrepare the workshopOrg analysis, agenda, hypotheses
2. 02 · PeopleDiscovery workshopClient, BA, architect; transcript runs
3. 03 · AgentEvaluationMinutes, story drafts with timestampsJira: Stories created · agent
4. Stories createdagent
5. Gate 1Client confirms the minutes
6. 04 · AgentPrototypeIn a scratch org, in hours
7. 05 · PeopleRefinement on the prototypeClient clicks through, transcript runs
8. 06 · AgentStory diff and impactChanges, test cases, metadataJira: Stories updated · agent
9. Stories updatedagent
10. Gate 2BA and architect approve the storyJira: Ready for Agent · BA
11. Ready for AgentBA

Before the workshop the agent analyses the existing org: objects, flows, validation rules, permissions. From that it drafts the agenda, hypotheses and targeted questions, for example: “Three flows on Opportunity overlap. Who owns them on the business side?” The business analyst sharpens the agenda and strikes hypotheses that are politically sensitive. What such an org analysis looks like is in AI org assessment: finding technical debt.

In the workshop the business analyst moderates and does not have to take notes. From the transcript the agent produces minutes with decisions, open questions and owners, plus drafts of epics and stories in Jira, each with a timestamp. It keeps “the client said” strictly apart from “the agent interprets”. The business analyst curates: strikes, sharpens, adds the fit-gap (standard, configuration or code), corrects misheard terms and mixed-up speakers.

Once the client confirms the minutes, the scope baseline stands. The agent then builds a prototype in a scratch org, a short-lived test org, within hours: objects, fields, layouts and a simple flow. In the refinement the client reacts to something real instead of paper. Afterwards the agent writes no new set of stories but a diff against the existing ones: “Acceptance criterion 2 changed because the client said at 00:41:07 …”, with the affected metadata, test cases and impact against the state of the repository.

Build: the agent codes, the developer reviews

Phase 2 of 3 · Build

1. People
2. Agent
3. Pipeline
4. Jira

1. 07 · AgentImplementationPlan, approval, code and testsJira: In progress · agent
2. In progressagent
3. 08 · AgentPull requestDescription, Jira link, AI reviewJira: In review · agent
4. In reviewagent
5. Gate 3Developer reviews and merges
6. 09 · PipelineCI validationDelta as check deploy, tests, analyzerJira: Validated · pipelineFailure: agent reads the log and fixes, at most 2 attempts
7. Validatedpipeline

Only when business analyst and architect set a story to “Ready for Agent” does the build start. The agent reads the ticket, creates a feature branch, writes an implementation plan and carries it out only after the developer approves it: Apex, Lightning Web Components or flow, each with tests. When a requirement is unclear it reads the linked passage of the transcript instead of guessing. It writes the pull request description with ticket link and component list, and an AI reviewer comments first.

Nothing is merged without a developer’s review. In this process the developer reviews more than they write. Why I never give up this gate is in Why pull request reviews are a must.

Then the pipeline runs: a delta package built with sfdx-git-delta, a check-only deploy against the integration sandbox, defined tests and a Code Analyzer gate. If it fails, the agent gets the log and may deliver a fix commit, at most two attempts. After that the developer takes over. Which checks I put into the pipeline for AI code I describe in Quality gates for AI code.

Release: the client tests, the agent classifies

Phase 3 of 3 · Release

1. People
2. Agent
3. Pipeline
4. Jira

1. 10 · PipelineDeploy to UATAgent writes test scripts into the ticketJira: In UAT · pipeline
2. In UATpipeline
3. 11 · PeopleAcceptance testClient tests, BA supports
4. 12 · AgentFeedback triageBug, change request or questionJira: Bug or CR created · agent
5. Bug or CR createdagent
6. Gate 4BA and client decide on bugs and CRsBugs back to 07, change requests as a new story to 06
7. Gate 5Client approves the releaseJira: Approved · client
8. Approvedclient
9. 13 · PipelineRelease to productionQuick deploy of the validated IDJira: Done · pipeline
10. Donepipeline
11. 14 · AgentRelease notes and guideBA proofreads

After the merge the pipeline deploys to the UAT sandbox, and the agent writes test scripts straight from the acceptance criteria into the ticket. The client tests, the business analyst supports the sessions. The agent classifies every piece of feedback: bug when it contradicts a confirmed criterion, change request when it is new, open question when the evidence is missing. Business analyst and client confirm the classification. Bugs go back to implementation, change requests are assessed as a new story, commercially as well. Scope creep becomes visible, with evidence instead of gut feeling. How an acceptance test with the business is set up is in Salesforce UAT with the business.

After approval the pipeline rolls out the already validated deployment ID by quick deploy. The agent writes release notes and a user guide in the language of the business, and the business analyst proofreads.

Only named people make binding decisions

Agent and pipeline decide nothing binding. Every decision that affects scope, quality or production is made by a named person.

Who decides in which phase

DiscoveryBuildRelease

ClientGateExplains and confirms the minutesAnswers questionsGateTests and approves the release

Business analystGateModerates, curates and approves the specClarifies business questionsGateSupports the test, decides on CRs

ArchitectGateSets guardrails and approves the specMaintains the rules fileWatches data model and sharing

DeveloperChecks the prototypeGateApproves plans, reviews and mergesTakes over on escalation

AgentAnalyses, takes minutes, draftsBuilds code and testsTest scripts, triage, release notes

PipelineNot involved yetValidates, sets the Jira statusDeploys, sets the Jira status

The roles change more than the tools do. The business analyst writes less and decides more; the core skill becomes spotting contradictions between what was said and what was meant. The architect becomes the keeper of the rules file, the Markdown file in the repository with trigger framework, naming conventions, sharing rules and prohibitions that the agent reads at the start of every session. It is the biggest lever on the quality of everything the agent produces, see AI rules file in the Salesforce repository. The client needs more discipline with confirmations, otherwise speed turns into chaos.

An example: from a sentence in the workshop to the release note

An assumed example, to show the chain. In the discovery workshop of a machine builder the head of sales says at minute 14: “We do not close an opportunity under 10,000 euros.”

• The agent turns this into the requirement “close opportunities only from 10,000 euros” in the minutes, with a reference to 00:14:52, and into a story with this acceptance criterion.
• In the refinement on the prototype the head of sales notices that lost opportunities must still be closable under 10,000 euros. The agent shows this as a diff to the story: the rule only applies to “Closed Won”. Business analyst and architect approve.
• The agent builds a validation rule on the opportunity, writes the test for 9,999 and 10,000 euros and links the ticket in the commit. The developer reviews, the pipeline validates and sets the ticket to “In UAT”.
• In the acceptance test a sales rep reports that small spare parts orders should still count as won. The agent classifies this as a change request, because no confirmed criterion provides an exception.
• The release note names the new minimum amount for won opportunities.

If someone asks a year later why the rule applies at 10,000 euros, the chain leads back to the statement in the workshop in two clicks.

Traceability: from a sentence in the workshop to the release note

1. 01Sentence in transcript00:14:52: "We do not close an opportunity under 10,000 euros."
2. 02RequirementClose opportunities only from 10,000 euros
3. 03StoryApplies to Closed Won only, added in the refinement on the prototype
4. 04CommitValidation rule: Closed Won with Amount < 10000 is rejected
5. 05Test9,999 euros is rejected, 10,000 euros goes through
6. 06Release noteWon opportunities need at least 10,000 euros

Which tools do you need for it?

The process does not depend on a particular coding agent. It needs four connections, as of October 2026:

• Jira as the shared ticket system. Agent and pipeline do not run in Jira, they only read and write the same tickets. The agent runs on the developer’s machine and reaches Jira through the Atlassian Rovo MCP Server; according to Atlassian1 it also reads the development panel there with linked branches, pull requests and commits. The pipeline runs on the Git platform and sets the ticket status itself after every run, so nobody maintains it by hand.
• Access to the sandboxes. Through the Salesforce CLI with the skills from sf-skills2, the Salesforce Claude Code plugin3 or Hosted MCP Servers. According to its README the local Salesforce DX MCP Server reaches end of life on 2 November 2026; what that means for your partners is in Salesforce DX MCP Server: end of life on 2 November 2026. The agent reaches every org the Salesforce CLI on its machine is logged in to. That is why only fixed sandbox aliases are logged in there, never production.
• A Git pipeline that validates and deploys without AI, with production access for the pipeline only. How I set it up is described under DevOps and release management.
• Transcription in the client’s tenant, for example through the recording in Teams. Consent and the works council I cover in AI coding tools, works council and GDPR.

Where does the process stumble?

In discovery:

• A transcript is no truth. A sentence in a meeting is no decision. The agent never creates binding stories from it without the business analyst’s check.
• Clients who do not want a recording. Then the business analyst dictates a summary right after the meeting, which takes the same route.
• Retention. Delete transcripts after acceptance or reduce them to the confirmed minutes.

In the Salesforce part:

• Click development. Admins keep building flows and layouts in sandboxes. The process needs a step in which the agent retrieves and commits such changes, otherwise Git drifts away from the org.
• Profiles, permission sets, destructive changes. The classic deployment traps belong in the rules file as explicit rules.
• Configuration data. CPQ and Field Service set-ups or custom settings are no metadata deployment and need their own track.

First step: the spec approval

Start with the gate that saves the most: the spec approval. Only when this track runs reliably is the rest worth it.

1. 01

   Spec approval

   one stream · BA and architect

   Write the stories so that an agent can build them without asking back.

2. 02

   Measure

   in code review · developer

   Count how often the developer still has to ask.

3. 03

   Secure

   in parallel

   Settle recording and tenant, lock every production access except the pipeline's.

4. 04

   Expand

   once it runs reliably

   Add the prototype and the feedback triage.

Sources3

1. 1Atlassian (opens in a new tab)atlassian.com
2. 2sf-skills (opens in a new tab)github.com
3. 3Salesforce Claude Code plugin (opens in a new tab)developer.salesforce.com