Ask two Salesforce customers what Agentforce costs and you can get two answers that are both correct and share no units.

One is billed per action against Flex Credits. One is billed per conversation against a rate card Salesforce last updated in December 2024, while separately consuming Einstein Requests and Data Services credits it was never told to track. Their Data 360 usage bills on entirely different models depending on which license sits in the org. If either bought Agentforce Voice Minutes, the per-action voice pricing on the public rate card stopped applying to them entirely.

None of it is hidden. It is scattered across separate rate card PDFs and a string of help articles, and which version applies to you depends largely on when you signed.

This page maps the currencies, the meters that feed them, the controls that exist, and what building an agent costs before any of it starts running. Where Agentforce sits inside a wider project budget is covered in the full implementation cost breakdown.

Four currencies bill Agentforce work and the contract date decides which

Salesforce has not replaced its billing units so much as accumulated them.

Flex Credits are the current unit. Actions, prompts, speech, personalization and Data 360 processing all draw from one balance at different multiplier rates.

Conversations are the older unit, and the model persists for customers who bought it. Its rate card is dated December 2024, covers a narrow named set of products, and states that use of certain Agentforce features also consumes Einstein Requests and Data Services credits. So a conversation-priced org is running three meters, and only one of them appears on the card it was sold.

Einstein Requests preceded Flex Credits. The current rate card scopes its prompt multipliers to products that no longer use Einstein Requests, which implies the unit remains live somewhere in the estate. If your order form mentions it, it is still metering you.

Data Services credits meter Data 360, and here the date is explicit. Salesforce states that orgs which purchased credits before 24 February 2026 consume Data Services credits for Data 360 services, while orgs purchasing or renewing after that date can have either Data Services or Flex Credits.

Two constraints follow. Flex Credits and Conversations are not supported in the same org, so migration means swapping every Agentforce Conversation SKU at once, with no gradual path. And because the currencies carry different entitlements, comparing quotes across them is not arithmetic, it is translation. Which unit you are on also changes what measuring agent return can even compare against.

Salesforce Foundations sits underneath all of this at no cost, carrying Agentforce Builder, Prompt Builder, Agent Script, Agentforce Coworker and Agentforce Vibes. That is the tier where an evaluation should start, because it establishes real action counts before anything is committed.

One buying-model caveat belongs in any plan built around commitment discounts. Salesforce lists three models, Pre-Purchase, Pre-Commit and PayGo, but describes Pre-Commit as becoming widely available later in the year, and it carries a true-up at term end if usage falls below the commitment. Pre-Purchase and PayGo are the models available to most buyers today.

The practical first step on any Agentforce cost question is therefore unglamorous: open Digital Wallet, look at which consumption cards are active, and establish which units the org actually spends before modeling anything.

Voice bills per action or per minute and the two cannot both apply

This is the mechanic most likely to produce a wrong forecast, because the public rate card shows only half of it.

The main rate card prices voice actions at 30 credits in production and 24 in sandbox. Salesforce publishes a second, supplemental rate card for Agentforce Voice Minutes, which prices voice at 60 credits per minute in production and 48 in sandbox. That card carries an override in its own footnote: the Agentforce Voice Actions usage types on the Flex Credits rate card do not apply to customers who have purchased Agentforce Voice Minutes, and the per-minute usage type applies instead.

The two models are mutually exclusive, and they invert under load.

Interaction shape	Billed per action, at 30 credits	Billed per minute, at 60 credits
4 actions, 1 minute	120 credits	60 credits
4 actions, 2 minutes	120 credits	120 credits
4 actions, 4 minutes	120 credits	240 credits
12 actions, 3 minutes	360 credits	180 credits

The crossover sits at two actions per minute. A dense interaction that resolves quickly is cheaper on minutes. A slow conversation with long pauses, hold music or a caller thinking is cheaper on actions, because silence bills on one model and not the other.

That makes containment strategy a pricing decision. Under per-minute billing, every second spent waiting for a customer to find their account number is billable. Under per-action billing it is free. Few contact centers know which card their org is on before they design the flow, and the supplemental card is not linked from the main pricing page.

Salesforce’s own budgeting scenario burns 35 percent of a year in thirty days

The most useful consumption figure Salesforce publishes sits inside a training module rather than a pricing page.

In its Agentforce Vibes licensing and monetization module, Salesforce sets a budgeting scenario: a company migrates 50 developers from the free tier to a paid credit-based plan, velocity rises, and at the end of week four the admin opens Digital Wallet to find the team has burned 35 percent of the annual Flex Credit budget in the first 30 days. Salesforce’s own text notes that at that rate the credits run out before month four, blocking development mid-sprint.

Two qualifications matter. This is Salesforce’s teaching scenario, not reported customer telemetry, and it describes Agentforce Vibes, the developer coding agent, rather than customer-facing service agents. Coding agents are token-hungry in ways a case-deflection agent is not.

The instructive part is not the number but what Salesforce prescribes against it. Its own optimization list reads: limit regenerations and avoid excessive retries, share only the files that matter instead of entire repositories, start fresh threads so context stays contained, use lighter models for daily work and reserve premium models for complex tasks, and set threshold alerts.

Every item on that list is a context-size control. Salesforce is telling you, in its own training material, that the dominant cost driver is how much context each interaction carries. That reframes the unit price entirely. Twenty credits is what an action costs; how much you send with it is what decides the bill.

Agent building is unmetered while previewing and testing are not

Salesforce divides billing by lifecycle phase, and the boundary falls in an unexpected place.

Salesforce states that during design and development, Agentforce Builder features for creating and building agents are not metered and consume no credits. The exception arrives immediately: Salesforce meters usage when you preview an agent in chat or voice.

Testing and validation is metered outright. Salesforce states that testing through Agentforce Builder, Agentforce Grid, Testing Center and sandbox is metered to account for required compute resources, covering both preview options and batch test runs. Agentforce Grid is metered regardless of which phase it is used in.

Set that against how agent development actually goes. You write a topic, preview it, change an instruction, preview again, and iterate dozens of times before behavior stabilizes. Every preview bills. A batch test across a few hundred utterances bills once per action, multiplied by the actions each utterance triggers.

The amounts are individually small, which is exactly why they go unbudgeted. They accrue during the phase everyone assumes is free, spread across weeks, against the same balance production will later draw down. A pilot scoped with a fixed allocation and no test line discovers this when the allocation runs dry before go-live. Planning that volume belongs in testing agents before production rather than in a later finance conversation.

Pre-production rates discount actions and leave prompts at full price

The rate card prices sandboxes separately, and the discount is not applied evenly.

Salesforce defines the pre-production rate broadly, covering scratch orgs as well as sandboxes.

Usage type	Production	Sandbox
Standard and custom action	20	16
Standard and custom voice action	30	24
Agentforce Voice Minutes, per minute	60	48
Starter and basic prompts	2	2
Standard prompts	4	4
Advanced prompts	16	16
Help Agent Resolutions	400	0

Actions and voice take a twenty percent pre-production discount. Prompts take none, so prompt-heavy development work in a sandbox pays production rates.

The prompt scale itself is steep. An advanced prompt costs eight times a basic one and eighty percent of a full standard action. Prompt template design in Prompt Builder is therefore a budget decision as much as a quality one, and few teams treat it that way, because the tier a template falls into is not surfaced where the template is authored.

Help Agent Resolutions sit at 400, the highest multiplier of any per-interaction agent usage type, and the only one priced at zero in sandbox. Speech is metered in its own units entirely, by the hour for transcription and by the million characters for synthesis and translation, with no pre-production discount on any of them.

Data 360 bills three different ways depending on the license in the org

The second meter is usually larger than the agent meter, and which version of it applies is a licensing question rather than a usage question.

An org running Data 360 under a Customer Data Platform license is billed against contracted entitlements for Unified Profiles, Segment Publishes and Engagement Events, with overages billed monthly at contracted rates. The billable profile count is computed from records in data lake objects mapped to profile-type data model objects, plus known unified profiles across every active identity resolution ruleset. Salesforce’s own worked example totals 25,000 billable profiles from two rulesets at 10,000 and 8,000 plus two unmapped profile objects at 2,000 and 5,000.

An org running under a Data Cloud license with an active Data Services consumption card is billed against the Data Services usage types.

An org running under a Data Cloud license without that card is billed by rate card multipliers, per million rows or per megabyte, with volume tiers that fall as usage rises and reset on the first day of each calendar month. Sandbox Data 360 skips tiering entirely and sits at the tier two rate across every usage type.

A Data 360 Profiles license layered on top stops some features consuming credits at all.

Three consequences for anyone budgeting. Two orgs with identical agent designs can receive structurally different Data 360 bills. Volume discounts do not accumulate across a quarter, so spiky processing is penalized against steady processing. And the entitlement model has no per-unit rate to model against at all, which means a forecast built from the rate card is simply the wrong instrument for a CDP-licensed org.

Joins, re-queries and cross-region reads multiply billable rows

Underneath the usage types sit counting rules that turn architecture choices into cost differences, and these are where real money moves.

Joins multiply. For streaming data transforms, Salesforce calculates rows read by multiplying the records from the streaming input object by the number of joined objects. A transform joining three objects bills three times the row count of a transform joining one.

Region and cloud boundaries bill. For data federation and data shares, Salesforce states there is no credit consumption when a query originates from the same region and the same cloud. Cross-cloud and cross-region queries consume. The same query costs nothing or something depending on where the target sits.

Ingesting Salesforce data is free. As of 7 August 2025, internal data pipeline usage covering structured data brought in through the CRM, Marketing Cloud, Commerce Cloud and Marketing Cloud Personalization connectors no longer consumes credits. Cost articles written before that date still bill for it.

A configuration flag changes the meter. Streaming ingestion bills as a streaming pipeline, but the same ingestion API used in bulk mode bills as a batch pipeline instead, at a different rate.

Repeat processing is discounted, once. Batch data transforms bill on changed rows only after the first run. Batch profile unification counts only new or modified source profiles after a ruleset’s first execution, where modified includes deleted profiles and those suppressed through Consent API preferences. Data share rows count only on the initial full batch, not on subsequent increments.

Chunking and vectorizing the same document counts once. A 100 MB PDF chunked and embedded bills as 100 MB, not 200. But indexing text fields from a data model object bills the sum of all bytes in those fields, which is how a search index over a large object becomes expensive quietly.

Read together, these rules say something that no price table conveys: the largest single lever on an Agentforce bill is the data architecture behind the agent, not the agent. Grounding design belongs in the cost conversation, which is also why readiness checks belong before spend rather than after.

Digital Wallet reports on a sync delay and enforces nothing

The control surface is real, and it is worth knowing precisely what it does and does not do.

Digital Wallet is reached from the App Launcher, with consumption cards per product. The Flex Credits card carries a Consumption Overview tab for drivers and forecasting and a Consumption Explorer tab for breakdowns by agent, action or data source. Four fields carry the signal: credits consumed since activation or reset, credits remaining, the usage type breakdown, and a last-processed timestamp.

That last field deserves attention. It records the most recent data sync, which means the figures lag behind live. An agent misbehaving now shows up in the console after a delay, so the console is a monitoring instrument rather than a circuit breaker.

Alerts are not a setting. Salesforce’s documented path is to build them: open Setup, find Flows, create a new flow from the Consumption Threshold Alerts template, then save and activate. Percentage triggers can be set org-wide or per card, and alerts can route to admin email, system notifications or a Slack channel. Custom tags let consumption be attributed to teams or individuals, which is the only practical way to answer the question of which team burned the quarter.

What none of this does is stop spending. Salesforce’s position is that there is no overage penalty, that exceeding entitlement bills at the contracted rate monthly in arrears, and that overages are prevented using alerts. Alerts notify. Nothing caps. A misconfigured agent on a Friday evening keeps billing through the weekend, and the available control is a notification that somebody has to read and act on. That makes consumption an operational responsibility with a named owner, which is part of who owns the agents after go-live.

One provisioning detail catches teams at setup. If the required permission set license is missing under Setup, the org lacks the relevant SKU: a Foundation Entitlement SKU for metered access, or the Agentforce 360 Platform Developer and Admin Tools SKU for unmetered. Salesforce notes the entitlement chain is cumulative, so unmetered access requires a working metered foundation underneath it. Unmetered is not a substitute for metered, it is a layer on top.

Implementation cost divides into scoping, build and the credits the build consumes

The licensing and consumption meters are published. The third cost is not, and it is usually the largest in year one.

Implementing an agent is a delivery project with a familiar shape and one unfamiliar line. The familiar parts are discovery to establish which use cases justify an agent, design of topics, actions and guardrails, integration work where actions call systems that are not Salesforce, knowledge preparation so retrieval returns answers worth giving, testing, and change management for the humans whose work the agent alters.

The unfamiliar line is that the build consumes the same credits production will. Preview iterations, batch test runs, sandbox actions at 16 credits and sandbox prompts at full production rate all draw on the balance before a single customer interacts with anything. Any implementation quote that separates services fees from consumption without estimating the consumption its own testing will cause has left a real number off the page.

Three questions surface whether a proposal has done that work. Ask how many actions each proposed use case takes end to end, because that number comes from design and should already exist. Ask what test volume the build assumes and what it will consume. Ask which Data 360 usage types the grounding design triggers, since that is where the larger meter runs.

A proposal that answers all three has modeled the thing. A proposal that quotes a day rate and points at Salesforce’s pricing page has not, and the difference is the same one that separates a defensible project estimate from a rate card. Sequencing a contained first build, not a broad one, is the point of a timeboxed pilot.

Salesforce prices five use cases publicly, and one of them miscalculates

The most useful published artifact for forecasting is not the rate card. It is the worked examples on Salesforce’s pricing page, because they show action counts per interaction, which is the number you cannot get anywhere else.

Published use case	Actions per interaction	Credits	Assumed volume	Monthly cost
Customer self-service, order status	2	40	20 requests a day	$120
Service case management	3	60	100 users, 3 cases a day, 20 days	$1,800
Field service appointment scheduling	5	100	10 reps, 3 appointments a day, 20 days	$300
IT support, employee onboarding	1	20	20 starters, 5 questions each	$10
Voice reservation management	4	120	300 calls	$180

Check the dates before you reuse these. Salesforce revised this page on 28 August 2026, and the field service example changed in that revision: an earlier version listed six actions at 120 credits for $360 a month, where the current one lists five actions at 100 credits for $300. The example was restructured, not merely repriced. Anyone quoting a figure from a cached copy is quoting a number Salesforce has already moved.

Two things in the table repay attention.

The field service example still lists a repeated call, retrieving appointment time slots a second time within one interaction. Repeats bill every time. An agent that loops because its instructions are ambiguous is not simply slower, it is proportionally more expensive, and the cost of a poorly scoped topic lands on the invoice instead of in a quality report.

The voice row contains an arithmetic error on Salesforce’s own page. Four voice actions at 30 credits each gives the 120 credits stated. At the conversion used in the other four examples, 120 credits is sixty cents, not the fifteen cents printed. The monthly total of $180 across 300 calls is consistent with sixty cents per call, so the per-interaction cell is the error rather than the total. Model voice from that cell and you underprice it fourfold.

Salesforce attaches its own caveat to every example, confirming that Data 360 and other consumption services sit outside these figures entirely.

Where GetGenerative.ai changes the number

Consumption is decided upstream of the build, which is where the agents on this platform operate.

The decisions that set an Agentforce bill are made during discovery and design: how many actions a topic requires, whether it re-queries data it already holds, how much context each call carries, whether grounding runs against a prepared dataset or resolves identity continuously, and how many iterations the build takes to stabilize. Salesforce’s own optimization guidance is a list of context-size controls, which means the specification determines the invoice.

The Discovery agent turns workshops into structured requirements instead of transcripts. The Design agent produces the topic and action definitions an action count can actually be read from, which is what converts a forecast from estimate to model. The Metadata agent supplies existing org context, so grounding is scoped against what is there instead of what is assumed. The Test agent produces the case library, which is how metered test volume becomes a planned line rather than a surprise.

Fixed-scope alternatives exist for teams that would rather not discover their consumption empirically, and agents live in about two weeks sets out what those cover.

The short version

Agentforce has no single price because it has no single meter. Your contract date determines your currency, your license determines how Data 360 bills, your voice SKU determines whether minutes or actions apply, and your data architecture determines the size of the largest meter running.

The published per-action rate is the least variable number in the model and the one every article leads with. The variable numbers are context size, test volume, join depth and region topology, and all four are set by design decisions made before procurement.

Model those, then buy. Buying first and measuring afterwards is how a 30-day burn reaches a third of an annual allocation, which is the scenario Salesforce chose to teach with.

Questions buyers ask about Agentforce cost

How much does an Agentforce action cost?

A standard or custom action consumes 20 Flex Credits in production and 16 in a sandbox or scratch org. Voice actions consume 30 and 24. Prompts are metered separately on a scale running from 2 credits for starter and basic prompts to 16 for advanced prompts, with no sandbox discount at any tier.

Is Agentforce Voice billed per action or per minute?

Both models exist and only one applies to a given customer. Customers who have purchased Agentforce Voice Minutes are billed at 60 credits per minute in production and 48 in sandbox, and Salesforce states that the per-action voice usage types stop applying to them. The crossover is two actions per minute, so dense short interactions favor per-minute billing and slow interactions favor per-action.

Does building and testing an agent consume credits?

Building does not. Previewing does. Salesforce states that Agentforce Builder features for creating agents are unmetered, that previewing an agent in chat or voice is metered even during development, and that testing through Builder, Agentforce Grid, Testing Center and sandbox is metered.

How much does an Agentforce Service Agent license cost?

There is no per-seat SKU by that name on the current pricing page. Customer-facing service agents are billed through consumption, using either Flex Credits or Conversations depending on which model your org is on. The per-user add-on at 125 dollars covers unmetered usage for employee-facing agents, which is a different thing. If a quote names a Service Agent license, ask which of the two consumption meters sits behind it.

Why is Data 360 billed differently for different orgs?

Because the billing model follows the license. A Customer Data Platform license bills against entitlements for Unified Profiles, Segment Publishes and Engagement Events. A Data Cloud license bills either against Data Services usage types or against rate card multipliers with monthly-resetting volume tiers, depending on whether a Data Services consumption card is active. Purchase or renewal date matters too, with 24 February 2026 as the dividing line Salesforce names.

Can Digital Wallet stop an agent from overspending?

No. It reports consumption on a sync delay and can raise threshold alerts routed to email, notifications or Slack, built from a Consumption Threshold Alerts flow template. Salesforce applies no overage penalty and bills excess at the contracted rate in arrears, so nothing enforces a ceiling automatically.

What drives an Agentforce bill more than the per-action rate?

Context size and data architecture. Salesforce’s own cost optimization guidance is a list of context controls, and its Data 360 counting rules mean joins multiply billable rows, cross-region queries consume where same-region queries do not, and search indexes over large objects bill the full byte count of the fields indexed.

Salesforce lets you record, on every field, who owns the data, how sensitive it is, which regulations apply and whether the field is still in use. All four values are queryable through the API and reportable through a custom report type.

Then Salesforce tells you, in one sentence on its own documentation page, what that classification does at runtime: *changing the value of Field Usage doesn’t hide or expose the field.*

Read that carefully, because it defines the entire discipline. Salesforce ships the vocabulary for a data policy and declines to enforce it. Classification is a label, not a control. Everything below follows from that gap, and the gap widened the moment agents started reading the same data your reports read.

Salesforce data governance is the set of policies determining what data means, who owns each definition, how sensitive it is, how long it is kept and who may see it. Platform change control is a separate discipline covered in the governance framework. This page is about the records rather than the configuration.

Salesforce classifies every field in four dimensions

The vocabulary is more complete than most orgs realize, and data classification carries no add-on cost. Editing the values requires the Customize Application or Modify Data Classification permission.

Attribute	What it records	Default values
Compliance Categorization	Regulations related to the field’s data	CCPA, COPPA, GDPR, HIPAA, PCI, PersonalInfo, PII
Data Owner	The person or group associated with the field	Free, a user or group
Data Sensitivity Level	How sensitive the contained data is	Public, Internal, Confidential, Restricted, MissionCritical
Field Usage	Whether the field is still in use	Active, DeprecateCandidate, Hidden

Salesforce’s definitions of the sensitivity values are unusually precise and worth adopting verbatim rather than inventing your own. Confidential covers data available to an approved group, not restricted by law but shareable under an NDA. Restricted is available only to an approved group and likely restricted by law, regulation, an NDA or a master service agreement. MissionCritical narrows that to a small group where third parties could face heightened contractual requirements.

Data Owner carries the most governance weight of the four. Salesforce describes the owner as the person who understands the importance of the field’s data and might be responsible for determining its minimum sensitivity level. That is a named accountability, recorded on the field, which is exactly what most data policies lack.

Two limitations to plan around. These metadata fields are unavailable for the User object in Object Manager, so applying them there requires the CustomField Metadata API or the Data Classification Upload tool. And compliance categorizations do not appear on fields suffixed __pc when querying Person Account, so the Contact object has to be queried instead.

Classification becomes enforceable policy through FieldDefinition

A policy nobody can query is a document. The reason classification is worth the effort is that every value maps to an API field.

Setup field	FieldDefinition API field
Compliance Categorization	ComplianceGroup
Data Owner	BusinessOwnerId
Data Sensitivity Level	SecurityClassification
Field Usage	BusinessStatus

Which makes governance questions answerable as queries rather than as meetings. Which fields on Account and Contact carry no owner. Which fields marked Restricted appear in a report type available to every user. Which fields were flagged DeprecateCandidate a year ago and still hold data.

Salesforce also documents the reporting path, and it is not obvious enough to guess. Create a custom report type with Entity Definition as the primary object, then add Field Definitions as the child object. That produces a report over your own classification metadata, which is the artifact a governance forum should review rather than a spreadsheet somebody maintained once.

Bulk operations exist for orgs that cannot classify field by field. The Data Classification Upload tool accepts a CSV of up to 10,000 rows, each naming an object, a field and a sensitivity level. The download tool returns only fields that already carry a sensitivity value, which makes the gap between the two counts a useful coverage metric.

Agents read through profiles, and masking is switched off for them

Here the label-versus-control distinction stops being academic.

An agent’s data access is governed by identity, not by sensitivity, and Salesforce publishes the mapping by agent type. Employee agents run as the logged-in end user, governed by that user’s profile, permissions, field-level security and sharing rules. Sales development agents run as an EinsteinSDRAgent User. Service agents without credential-based user verification run as an EinsteinServiceAgent User, and with verification enabled on Enhanced Chat v1 and Experience Cloud sites, as the logged-in site user.

Salesforce adds a line worth reading twice: context variables tell the agent who the user is but do not control data access. Knowing who is asking and deciding what they may see are separate mechanisms, and only the second one governs anything.

So a field marked MissionCritical is read by an agent exactly as readily as a field marked Public, provided the running user can see it. Sensitivity classification never enters the decision.

Then the detail that surprises most teams. On the page covering what the Einstein Trust Layer masks, Salesforce states plainly: data masking for LLMs is disabled for agents. Masking remains available for embedded generative features such as Einstein Service Replies and Work Summaries, and is configurable in Trust Layer setup. For agents, it is off.

Agent actions running flows can escalate past the running user

The natural conclusion from the section above is that field-level security and sharing are the last line of defence. Salesforce documents a path around both, and it is the single most important governance detail on this page.

When an agent action runs a flow, Salesforce states that both the flow’s run context and the agent’s execution context apply. Flows run in one of three contexts, and the published table is unambiguous about what each grants:

Flow run context	Object and field access	Sharing rules
User	Governed by running user’s permissions and field-level access	Running user’s sharing rules
System context with sharing	All objects and fields	Running user’s sharing rules
System context without sharing	All objects and fields	Not applied

Two of the three grant access to all objects and all fields. One of those two ignores sharing entirely.

So an agent whose running user has carefully scoped field-level security can still invoke an action that reaches a flow running in system context, at which point the scoping stops applying to the data that flow touches. Salesforce also notes that when a service agent runs in agent user context, the running user of the flow is the agent user rather than the customer, which means the flow inherits the agent user’s reach and not the person’s.

That makes the reviewable unit an agent’s action list rather than its user record. Approving an agent means approving every flow its actions can invoke, and checking the run context of each. The security review is the operative document, and agent ownership after go-live becomes a data decision rather than a support arrangement.

Data 360 converts tags into enforcement, and core Salesforce does not

The asymmetry is worth stating directly, because it determines where a serious policy can actually run.

In Data 360, governance is policy-driven. Salesforce’s wording is explicit: object-level and field-level security policies in Data 360 are driven by tags and classifications, enabling scalable governance across large numbers of objects and fields. The operational consequence follows in the next line, that when new data is ingested you give it the correct tag and existing rules apply automatically without extra work.

That is the thing core Salesforce classification does not do. Same conceptual vocabulary, same four-way sensitivity framing, entirely different runtime behavior.

Three tiers, then, and a policy has to specify which one it operates in:

Layer	Classification behavior	Enforcement
Core Salesforce fields	Four attributes, queryable and reportable	None; labels only
Agents on core data	Inherits running user’s access	FLS and sharing, no LLM masking, subject to flow run context
Data 360	Tags and classifications	Drives object and field-level security policies

A governance charter that says sensitive data is protected, without naming the layer, is describing a Data 360 behavior while most of the org runs on the first row.

Reports disagree for reasons unrelated to data quality

Before blaming records, rule out the mechanics, because two users running one report can legitimately see different numbers with perfectly clean data.

Salesforce’s own knowledge base attributes divergent record counts to differences in field-level security, private sharing settings, role hierarchy restrictions and time zone differences affecting date filters. A separate article addresses the harder case where users share the same role and profile and still differ, including administrators with View All Data, and identifies locale mismatch as the most common cause: locale determines the time zone applied to date filters, so filter boundaries shift per user.

Roll-up summary fields contribute their own quiet failures. Salesforce documents that if a roll-up filter references a formula field returning an error, no matches are returned for that criterion, so the summary silently excludes records. Salesforce also notes that campaign roll-up values are not recalculated when a lead or contact is deleted, and that a mass recalculation must be triggered manually.

None of those is a data quality problem. All of them produce the same symptom: a meeting where two people hold different numbers from the same system. A data policy that only addresses record accuracy will not fix any of them, which is why the definition layer below matters as much as the cleanliness layer.

Four policies carry most of the weight

Data governance sprawls when written as an aspiration. Four policies, each with a named owner and a queryable state, cover the majority of what goes wrong.

Definition. Every metric and every field that feeds one has a written definition and a single owner. What counts as an active customer. Which of the four revenue fields is authoritative. This is the policy that stops two reports disagreeing for reasons neither analyst can explain, and it is the one most orgs skip because it is a business conversation rather than a technical task.

Classification. Every field carries a Data Owner and a Data Sensitivity Level, set through Setup or the upload tool, and the coverage gap is reported quarterly through the Entity Definition report type described above.

Retention. How long each category of record is kept and what happens at the end. This becomes urgent once agents ground answers in historical records, because an agent citing a four-year-old closed case is technically correct and commercially wrong.

Access. Which profiles and permission sets can read each sensitivity level, reviewed whenever an agent is granted a permission set. Given that agents inherit user visibility and bypass LLM masking, this is the only policy standing between a Restricted field and a model.

Duplicate rules, matching logic and survivorship belong to adjacent disciplines rather than to this list. Those are covered in duplicate management and master data management, and both assume the definition policy above already exists.

Governance programs correlate with measured trust

The evidence base here is thinner than the topic deserves, so the figures worth citing are the ones carrying stated samples.

Salesforce’s State of Data and Analytics, second edition, surveyed 3,800 data and analytics leaders and 3,852 business leaders between 27 June and 13 August 2025. Those leaders estimate 26 percent of their organizations’ data is untrustworthy. Among those with AI in production, 89 percent report having experienced inaccurate or misleading outputs. And only 43 percent have established formal data governance frameworks and policies, while 88 percent believe AI advances demand new governance approaches.

The payoff figure comes from the 2026 State of Data Integrity and AI Readiness, produced jointly by Drexel University’s LeBow College of Business and Precisely, surveying 505 data and analytics leaders at organizations with at least 1,000 employees or $250 million in revenue. Organizations with governance programs report high trust in their data at 71 percent, against 50 percent without.

A third source deserves a caveat alongside its numbers. Validity, which sells CRM data quality tooling into the Salesforce ecosystem, surveyed 500 marketing professionals across five countries in August 2026 and reports that 92 percent of SVP and VP respondents have acted on an AI recommendation they later suspected was wrong because of bad underlying data. Treat it as vendor-commissioned, and note that it measures exactly the failure this page exists to prevent.

Scoring your own position before buying more agents is the subject of data readiness assessment, and cleaning what the assessment surfaces belongs to org cleanup.

Scope agents against classified data rather than against enthusiasm

The practical sequence runs classification first, agent scope second, because an agent’s blast radius is the set of fields its running user can read.

GetGenerative.ai packages this as fixed-scope delivery rather than open-ended discovery, with a catalog of pre-scoped agents mapped to Salesforce objects, three fixed-price packages and Trust Layer configuration included in every engagement. Teams can see the pre-scoped agent catalog and match candidate agents against the fields those agents would actually read.

The pairing matters more than either half. A pre-scoped agent against unclassified data inherits whatever the running user can see. A classified org with no agent scope discipline has documentation and no control. Doing both in sequence is what makes the answer defensible when someone senior asks where a number came from. Preparing the underlying records is covered in agent-ready data quality.

Recap. Salesforce classifies fields across compliance, ownership, sensitivity and usage, exposes all four through FieldDefinition, and enforces none of them in core. Agents read through the running user’s profile and sharing, with LLM masking switched off, and an agent action reaching a flow in system context can bypass that scoping entirely. Data 360 does drive security policies from tags. Reports diverge through locale, sharing and roll-up mechanics rather than through dirty records. Four policies cover most of it: definition, classification, retention, access.

Key facts

Fact	Value	Source
Field classification attributes	Compliance Categorization, Data Owner, Data Sensitivity Level, Field Usage	Salesforce Help, Data Classification Metadata Fields
Enforcement in core Salesforce	None; changing Field Usage does not hide or expose the field	Salesforce Help
API mapping	ComplianceGroup, BusinessOwnerId, SecurityClassification, BusinessStatus on FieldDefinition	Salesforce Help
Reporting path	Custom report type, Entity Definition primary, Field Definitions child	Salesforce Help
Availability	All editions, enabled automatically	Salesforce Help
LLM masking for agents	Disabled; available for embedded features such as Einstein Service Replies	Salesforce Help, Select What Data To Mask
Flow run contexts inside agent actions	Two of three grant access to all objects and fields; system context without sharing ignores sharing rules	Salesforce Help, Agent Execution Context and Data Access by Type
Service agent flow running user	The agent user, not the customer, when credential-based verification is off	Salesforce Help
Data 360 enforcement	Object and field-level security policies driven by tags and classifications	Salesforce Help, Data Governance in Data 360
Untrustworthy data, self-estimated	26 percent	Salesforce State of Data and Analytics, 2nd edition, n=7,652
Formal governance frameworks in place	43 percent	Salesforce State of Data and Analytics, 2nd edition
Trust with governance versus without	71 percent against 50 percent	Drexel LeBow and Precisely, 2026, n=505

FAQ

What is Salesforce data governance?

Salesforce data governance is the set of policies defining what data means, who owns each definition, how sensitive it is, how long it is retained and who may access it. It differs from platform governance, which controls who may change configuration. Both are needed, and each requires separate owners.

Does Salesforce field classification restrict access?

No. Classification records Compliance Categorization, Data Owner, Data Sensitivity Level and Field Usage, and Salesforce states that changing Field Usage does not hide or expose the field. Access remains controlled by field-level security, profiles, permission sets and sharing rules regardless of the sensitivity value recorded.

Can Salesforce data classification be reported on?

Yes. All four attributes map to FieldDefinition API fields: ComplianceGroup, BusinessOwnerId, SecurityClassification and BusinessStatus. Salesforce documents a custom report type using Entity Definition as the primary object and Field Definitions as the child object to expose them in standard reports.

Do AI agents respect data sensitivity classifications?

No. Agent access is governed by the running user’s profile, permissions, field-level security and sharing rules rather than by sensitivity labels. Salesforce also documents that data masking for large language models is disabled for agents, though it remains available for embedded generative features.

Can an agent see more data than its running user?

Yes, through flows. Salesforce documents three flow run contexts, and two of them grant access to all objects and fields, with system context without sharing ignoring sharing rules. An agent action invoking such a flow operates beyond the running user’s field-level scoping.

Why do two users see different numbers in the same Salesforce report?

Salesforce attributes this to field-level security differences, private sharing settings, role hierarchy restrictions and time zone differences affecting date filters. Where role and profile match, locale mismatch is the common cause, because locale sets the time zone applied to date filter boundaries.

Which data governance policies matter most?

Four carry most of the weight: definition, giving every metric a written meaning and a single owner; classification, recording owner and sensitivity on every field; retention, deciding how long each record category persists; and access, controlling which profiles read each sensitivity level.

Salesforce ships eight code analysis engines behind a single command, and one of them silently changes depth depending on which org you point it at.

Start there, because the automation question is further along than most Apex review discussions assume, and because the defaults matter more than the tool choice. Salesforce Code Analyzer scans Apex, Visualforce, Flows and Lightning components, and Salesforce documents the engines it bundles as enabled by default. In Salesforce’s own words:

Engine	What it does	CLI name
PMD	Static analysis of Apex and Visualforce, including the PMD AppExchange rules	pmd
Salesforce Graph Engine	Complex analysis of Apex code, identifying security vulnerabilities and code issues	sfge
ApexGuru Engine	Real-time scans on connected orgs through the CLI, with line-level highlights	apexguru
Flow Scanner	Audits Flows and reports security issues, new in v5	flow
CPD	Identifies blocks of duplication across files	cpd
ESLint	Evaluates JavaScript and TypeScript	eslint
RetireJS	Finds vulnerabilities in third-party JavaScript dependencies	retire-js
Regex	Searches the codebase for patterns, new in v5	regex

Two deserve attention before anything else. Graph Engine is described by Salesforce as performing complex analysis on Apex to identify security vulnerabilities and code issues, and it is the engine that reaches defects spanning multiple methods rather than sitting on one line. ApexGuru scans a connected org rather than a local directory, and it behaves differently from every other engine in the set.

Apex code review is the practice of checking Apex against platform constraints, security requirements and written standards before it reaches production. Automation covers the checkable part. This page is mostly about the rest.

Most published Apex review guidance describes a retired tool

Before adopting any of it, check the version, because this tooling changed underneath the internet.

Salesforce’s own documentation states it plainly: as of August 2025, Code Analyzer v4 is retired and no longer supported. Version 5 introduced a new CLI plugin, @salesforce/plugin-code-analyzer, moving commands from the old scanner topic into a code-analyzer topic.

That single change invalidates a large volume of tutorials, CI configurations and internal runbooks. Any pipeline still invoking a command in the scanner topic is invoking a retired tool, and any tutorial teaching that topic is teaching a dead interface.

The trap extends into Salesforce’s own doc set. A rules reference listing Graph Engine rules including ApexFlsViolationRule and AvoidDatabaseOperationInLoop is still live and still indexed, under a heading marked Retired inside the v4 section. The rule names are informative. The page is not current documentation, and citing it as such is the kind of error a reviewer should catch in a standards document.

There is a lesson here that applies directly to AI-assisted review. An assistant trained on the public corpus has read far more v4 material than v5 material, because v4 had years to accumulate content and v5 has had months. Ask a general model to write your Apex scanning pipeline and the odds favor a retired command.

ApexGuru runs in two modes and picks one without telling you

One engine in that table carries a behavior worth understanding before it appears in a CI pipeline.

Salesforce describes ApexGuru as an AI-driven performance and code optimization engine that works alongside PMD, ESLint and RetireJS to detect SOQL inefficiencies and scalability issues, returning line-level highlights, severity ratings and recommendations as JSON.

It then runs in one of two modes. Advanced Mode scans runtime code, and applies when your org or its parent org family has enabled the ApexGuru engine through the Setup page. Basic Mode performs standard static analysis on the connected org, and applies when neither your org nor its parent family has enabled it.

The line that matters for anyone automating this is Salesforce’s own note: scan modes are not configurable at trigger time through the CLI or configuration files, and are determined automatically from the org’s ApexGuru settings.

Read the consequence carefully. The same command, against two orgs, returns two different depths of analysis, and nothing in the invocation says which one you got. A pipeline promoting from a sandbox where ApexGuru was never enabled is running static analysis while the team believes it is running runtime analysis. Checking the Setup page is therefore part of trusting the result, not an optional configuration step.

Advanced Mode also means org Apex is retrieved for analysis, so the activation decision belongs with whoever owns the security review rather than with whoever wrote the pipeline.

Static analysis catches shape, and misses intent

Automated rules evaluate structure. That covers a real and valuable class of defects, and it covers it better than a human skimming a pull request at 5pm.

Structural problems a rules engine finds reliably: a query inside a loop, a DML statement inside a loop, a class declared without a sharing keyword, a hardcoded record ID, an empty catch block, a method whose complexity exceeds a threshold, a duplicated block, a vulnerable JavaScript dependency.

What no rules engine evaluates is whether the code does the right thing. Three failures pass every automated gate, and they are the reason review still needs a second reader.

The query targets the wrong object. SOQL against Opportunity where the requirement concerned OpportunityLineItem is syntactically perfect and semantically wrong. It returns rows, so nothing errors. Salesforce’s own research into LLM agents on CRM tasks identified exactly this confusion between related business objects as a recurring failure, and no linter has an opinion about which object a requirement meant.

The implementation satisfies a misread requirement. Salesforce puts this in its own developer guidance for agentic tooling, conceding that generated output can compile while missing what the author intended, and that a person still has to review it. Apex can be clean, fast, secure and answer the wrong question.

The test asserts the implementation rather than the requirement. When the same system writes the code and the test, a misunderstanding is encoded twice and then protected by a passing assertion. Coverage rises while correctness does not, which is why unit tests need meaningful assertions rather than coverage targets, and why the wider test strategy separates developer verification from acceptance.

Each of those is an intent problem. Automation reads shape.

Volume-dependent defects need volume-aware review

One Salesforce-specific failure deserves separate treatment because it is invisible in every environment where reviewers actually look.

Limits apply per transaction, so the defect only exists above a record count. Twenty records in a scratch org will never reach a SOQL ceiling that two thousand records reaches instantly, which means the same code is demonstrably correct in the environment where it was reviewed and reliably broken in the environment where it runs. A rules engine flags the shape, which is why bulkification sits in every Apex ruleset. A reviewer who executes the code, watches it succeed and approves it has confirmed nothing about the only condition that matters.

This has a practical consequence for how AI-generated Apex should be reviewed. The instruction files that ground coding assistants on Salesforce have to state bulkification and governor limits explicitly, which is itself evidence the platform constraint is not inherent model knowledge. A review process that assumes the generator knew is reviewing the wrong risk.

The control is environmental rather than procedural: a sandbox seeded with representative volume, and test methods that insert enough records to cross a limit if the pattern is wrong.

AI review changes the economics of the second reader

The argument for adding AI to code review is not that it reads better than a senior engineer. It is that it reads everything, immediately, without becoming the bottleneck.

Human review has a known failure curve. Attention drops as diff size grows, reviewers approve rather than block when they are the constraint on a release, and standards get applied inconsistently depending on who is rostered. None of that improves when generation speeds up. A team producing four engineers’ worth of Apex with one engineer’s worth of review capacity has moved the bottleneck into the least visible place in the pipeline.

AI review helps on three specific axes, and it is worth being precise because the category is oversold.

It applies a written standard uniformly, which removes the variance between reviewers rather than removing reviewers.

It reads the whole change rather than the parts a tired human samples, which matters most on large generated diffs.

It explains findings in prose, which converts a rule violation into something a junior developer learns from rather than a code someone looks up.

What it does not do is carry accountability. The approval that matters is still a person’s, and the platform vendor’s own position on human review being non-optional applies to review tooling as much as to generation tooling. The distinction between an assistant that flags and a person who decides is the one that keeps this defensible.

The wider question of where coding tools stop and delivery agents begin is covered in AI coding tools against delivery agents. Here the scope is narrower: what happens after the code exists and before it ships.

Standards become automatable only once they are executable

An AI reviewer inherits whatever standard it is given. Feed it preferences and it produces opinions at scale.

Use one test to sort them. Hand the rule to two engineers who hold opposite opinions about it and see whether they flag the same lines. Rules that survive that are mechanical and belong in automation. Rules that need the author present to adjudicate are guidance, and labeling them as guidance stops a preference being enforced as a violation.

Four groups of Apex standards meet the executable test:

Structural. Naming conventions, layer separation between service, domain and selector classes, maximum method complexity, no business logic in triggers.

Data access. Every query and DML operation runs under an explicit access mode, sharing is declared on every class, and no CRUD or field-level security check is skipped on the assumption the caller handled it.

Resilience. No queries or DML in loops, no hardcoded IDs, no empty catch blocks, no assumptions about record counts.

Test quality. Assertions present and meaningful, no dependence on org data, volume cases included for anything that touches a collection.

Those belong in a written standard that both the automated gate and the AI reviewer read from the same file. Where that standard lives and who approves changes to it is a governance question, and a review process without one degrades into whoever reviewed last week.

A four-gate pipeline puts each check where it costs least

Sequence matters more than tool selection, because a check running in the wrong place either blocks work or arrives too late to be cheap.

Gate	Runs	Catches	Blocking
Editor	As code is written	Syntax, obvious pattern violations, missing null checks	No
Pre-commit	On commit	Rules engine findings against the local change	Yes, on high severity
Pull request	On open	Full Code Analyzer run plus AI review against the written standard	Yes, on security and severity
Pre-deploy	Before promotion	Org-connected scan of what is actually deployed, volume-aware tests	Yes

The fourth gate is the one teams skip and the one the ApexGuru Engine exists to serve, since scanning a connected org reaches code as deployed rather than code as committed. Divergence between those two is common in orgs where anyone has ever made a change in production, which over a long enough period is most orgs. Quantifying that divergence is part of an org assessment, and closing it is how technical debt stops accumulating silently.

Security findings deserve their own escalation path rather than a severity threshold, because a field-level security violation is not a lower-priority version of a complexity warning. The security review sets what those rules check against.

Review belongs inside delivery, not beside it

Code review fails most often as a scheduling problem rather than a quality problem. A review queue staffed by whoever is free becomes a queue, and a queue becomes an approval.

GetGenerative.ai addresses that by keeping test and support agents inside the lane that produced the work, so review is a stage someone owns rather than a favor asked of a colleague between meetings. For change after go-live, its Support Agent runs the request through to a documented fix in one pass, which matters for review specifically because the reasoning behind a change stays attached to it. A reviewer inheriting a fix three weeks later otherwise reconstructs intent from a diff, which is the least reliable source available.

Teams wanting to test that against their own backlog can start the 7-day free trial and run it on a real pull request rather than a sample repository.

Recap. Salesforce bundles eight analysis engines behind one command, including a Graph Engine doing path-based analysis and an ApexGuru Engine scanning connected orgs. Code Analyzer v4 retired in August 2025, so a large share of published guidance teaches a dead command. Automated rules catch structure. Wrong-object queries, misread requirements and self-confirming tests survive every gate, which is what AI review and a human approver are for.

Key facts

Fact	Value	Source
Code Analyzer engine count	Eight, all enabled by default	Salesforce Code Analyzer documentation
Engines bundled	PMD, Salesforce Graph Engine, ApexGuru, Flow Scanner, CPD, ESLint, RetireJS, Regex	Salesforce Code Analyzer documentation
Code Analyzer v4 status	Retired as of August 2025 and no longer supported	Salesforce Code Analyzer documentation
Current CLI plugin	@salesforce/plugin-code-analyzer, commands in the code-analyzer topic	Salesforce Code Analyzer documentation
What Code Analyzer scans	Apex, Visualforce, Flows and Lightning components	Salesforce Code Analyzer documentation
ApexGuru Engine scope	Real-time scans on connected orgs through the CLI, line-level highlights	Salesforce Code Analyzer documentation
Graph Engine scope	Complex analysis of Apex identifying security vulnerabilities and code issues	Salesforce Code Analyzer documentation
New engines in v5	Flow Scanner and Regex	Salesforce Code Analyzer documentation
ApexGuru modes	Advanced Mode scans runtime code when enabled in Setup; Basic Mode performs static analysis when not	Salesforce ApexGuru Engine documentation
ApexGuru mode control	Not configurable at trigger time via CLI or config files; determined by org settings	Salesforce ApexGuru Engine documentation
Vendor position on human review	Review by a person is mandatory rather than advisable for generated code	Salesforce developer documentation

FAQ

What does Salesforce Code Analyzer check in Apex?

Code Analyzer scans Apex, Visualforce, Flows and Lightning components using eight bundled engines enabled by default. PMD handles static analysis of Apex and Visualforce, Graph Engine performs path-based analysis for security and code issues, and the ApexGuru Engine scans connected orgs directly through the CLI.

Is the Salesforce scanner command still valid?

No. Salesforce documents Code Analyzer v4 as retired since August 2025 and no longer supported. Version 5 ships a new plugin, @salesforce/plugin-code-analyzer, with commands under the code-analyzer topic rather than the older scanner topic that most published tutorials still teach.

What can AI code review catch that static analysis cannot?

Static analysis evaluates structure. AI review can compare code against a written standard expressed in prose, read an entire large diff rather than sampling it, and explain findings. Neither catches a query against the wrong object or an implementation of a misread requirement without a human checking intent.

Why does AI-generated Apex pass review and fail in production?

Governor limits apply per transaction. A query or DML statement inside a loop executes correctly against small sandbox datasets and breaches limits at production volume. The pattern is not a syntax error and passes any unit test written against a handful of records.

What Apex standards can be automated?

Standards that a reviewer who disagrees with them could still apply identically. That covers naming and layer separation, explicit access mode on every query and DML operation, declared sharing, no queries or DML in loops, no hardcoded IDs, and tests carrying meaningful assertions plus volume cases.

Where should Apex code review run in a pipeline?

Four gates work: editor-time for syntax and obvious patterns, pre-commit for rules against the local change, pull request for a full Code Analyzer run plus AI review against the standard, and pre-deploy for an org-connected scan with volume-aware tests before promotion.

The strongest published evidence that AI coding tools work on Salesforce comes from Cursor, and it is worth reading closely rather than quoting.

In a customer story dated 21 January 2026, Cursor reports that over 75 percent of developers at Salesforce now use the editor, with a 30 percent or greater increase in pull request velocity and 85 percent less time spent on legacy test coverage. Shan Appajodu, an SVP of Engineering at Salesforce, is quoted describing the change as transforming how developers use tools to improve product quality.

Those numbers appear real and the named executive attribution makes them checkable. Now read the subject of the sentence. The case study describes Salesforce as a software company maintaining a codebase built over more than 25 years, with thousands of engineers shipping products on top of it. Cursor’s own framing notes that junior engineers were the first adopters, many of whom started their careers remotely and used the tool to learn an unfamiliar codebase.

That is Salesforce’s product engineering organization building the Salesforce platform. It is not a customer configuring Sales Cloud, and the two activities share a brand rather than a workload.

The distinction governs this entire comparison. AI coding tools operate on a repository of source files. Salesforce delivery agents operate on an org, a project and a set of deliverables. Whether the first category is sufficient depends on how much of your work is actually source code.

A Salesforce org stores configuration, and a repository stores files

An IDE assistant assumes a filesystem. It indexes files, reasons over their contents, and edits them. That assumption holds completely for the codebase Cursor’s case study describes, and holds partially for a Salesforce project.

What lives in a Salesforce org that has no file representation until someone retrieves it: object and field definitions, validation rules, record types, page layouts, Lightning record pages, flows, permission sets and permission set groups, sharing rules, queues, approval processes, custom metadata records, and the data itself.

Some of that can be pulled into source form through the Salesforce CLI, and disciplined teams do exactly that. Two problems survive the retrieval.

Retrieved metadata is not readable in the way source code is readable. A flow arrives as XML describing nodes and connectors. A validation rule arrives as an errorConditionFormula inside the object’s metadata file rather than beside the field it constrains, so the rule and the field it protects sit in different places in the retrieved tree. An assistant reading those files can parse them. Working out what the automation does to a business process is a different operation.

And retrieval is a snapshot. The org keeps changing underneath it, through admins working in production, through managed package updates, and through three Salesforce releases a year. A repository is authoritative for a codebase. For an org it is a photograph.

This is the concrete version of a point made more generally in the comparison of general chat assistants against purpose-built agents. Here the constraint is narrower and more technical: the tool is excellent at files, and a meaningful share of the work is not files.

Coding tools read the repository; connected agents read the org

The gap above has a partial remedy, and Salesforce built it.

Salesforce publishes official setup instructions for connecting Cursor to its hosted MCP servers, describing Cursor as an AI-driven code editor that supports MCP. Configuration runs through a local mcp.json file, an external client app consumer key, and separate endpoints for production against sandbox or scratch orgs. Salesforce’s tested-client table lists Cursor with native OAuth support and no additional software required, alongside Claude, ChatGPT, Postman and Agentforce Vibes.

Connected that way, a coding tool gains real org awareness. It can retrieve the shape of your objects, so generated code references API names that exist instead of names that sound plausible. For a developer working in an unfamiliar org, that single capability removes a large class of wasted iterations.

What the standard tool set does not reach is the logic layer: the Apex already deployed, the branching inside your flows, the formulas behind your validation rules, the contents of your permission sets. The reasons and the exact tool inventory are covered in the general assistant comparison; the consequence for a developer is short. A connected editor learns the shape of your org without learning its behavior.

That gap produces one recurring failure. A developer asks for code that updates a field. The tool writes correct code against a correct field name. At runtime a validation rule neither of them could see rejects the update, or a flow nobody mentioned overwrites it seconds later.

Salesforce publishes its own skills library and makes it tool-agnostic

The most informative signal about where the platform vendor thinks this is going sits in a public repository rather than in a product announcement.

Salesforce maintains `forcedotcom/sf-skills`, an Apache-2.0 licensed collection it describes as a curated set of Salesforce agent skills for building applications, covering Agentforce agents, Lightning apps, Flow, Apex, SOQL, Lightning Web Components, UI bundles, objects and fields, permission sets and related areas. The repository states that skills are contributed by Salesforce and the broader community.

The sentence that matters commercially: the library is optimized for Agentforce Vibes and can be used with any AI tool that supports skills.

Read that as a strategy statement. Salesforce is not attempting to make you abandon Cursor or Copilot. It is publishing the platform knowledge those tools lack, in a portable format, and letting you attach it to whichever editor you already use. The repository also carries an explicit warning that it is evolving rapidly and that skills may be renamed or restructured, which is an honest caveat and a maintenance commitment for anyone depending on it.

The practical conclusion for a delivery lead: the difference between a coding tool that is dangerous on Salesforce and one that is useful is mostly the skills, rules and connections wrapped around it. That wrapper is work, it has an owner, and it needs updating three times a year.

Every tool solves Salesforce competence the same way, through an instruction layer

Compare how the three main options acquire platform knowledge and the pattern is identical.

Agentforce Vibes ships with Salesforce skills attached. Cursor takes project rules plus MCP connections. GitHub Copilot takes repository instruction files, and GitHub’s own Awesome Copilot collection publishes an Apex instruction set describing guidelines and best practices for Apex development on the Salesforce Platform.

Read what that Apex instruction file actually has to say, because it is the most direct evidence available about what these models do not know. It instructs the assistant to focus on bulkification and write code that handles collections of records rather than single records. It instructs the assistant to be mindful of governor limits and design solutions that scale efficiently. It prescribes separation of concerns through service, domain and selector layers, and it sets naming conventions.

Bulkification is the first thing any Salesforce developer learns, and governor limits are the defining constraint of the platform. An instruction file exists to tell the model both. That is not a criticism of the tools. It is a precise measurement of where the Salesforce knowledge lives: in a text file somebody wrote and somebody has to maintain, not inside the model.

Which produces the real selection criterion for a delivery lead. The editor is close to interchangeable. What differs is who authors your instruction layer, how current it is against three releases a year, and whether it is attached to every prompt or only to the ones a careful developer remembers to ground.

Generated Apex compiles at desk volume and fails at production volume

Salesforce-specific code failure has a signature that general code quality research does not capture, and it is worth naming precisely because reviewers miss it.

The platform enforces execution limits per transaction. Code that queries inside a loop works against the handful of records in a developer sandbox and breaches limits against production data volumes. Code that performs a DML operation per iteration does the same. Neither pattern is a syntax error, neither fails a compile, and neither necessarily fails a unit test written against a small dataset.

Salesforce concedes the general risk in its own developer documentation, warning that agentic development stops short of autonomy, that generated output can invent method names or assume the wrong things about an org, and that review by a person remains mandatory rather than advisable.

Three consequences follow for anyone running coding tools on Salesforce.

Test data volume becomes a review control rather than a testing detail, which is why test strategy and Apex unit testing practice need explicit limit-aware cases rather than coverage targets.

Review has to check patterns as well as correctness, and pattern checking against a published rule set is what AI-assisted code review is suited to.

And the environment matters: generated code needs a sandbox with representative volume before anyone can claim it works.

Coding tools accelerate a minority of Salesforce delivery

Even granting perfect code generation, the question remains what proportion of a project that addresses.

A Salesforce implementation includes discovery and requirements, solution design, declarative configuration, data migration and reconciliation, integration, unit testing, system and acceptance testing, deployment, training and adoption. Apex and Lightning Web Components appear in one of those ten activities, and many implementations of standard functionality write very little custom code at all by design, since Salesforce guidance has long favored configuration where configuration suffices.

No credible public dataset gives a reliable split between declarative configuration and custom code across Salesforce orgs, and this page is not going to invent one. The absence is itself informative: anyone quoting a precise percentage for how much of Salesforce work is coding is estimating.

What can be stated without a statistic is directional and sufficient for a buying decision. A tool that accelerates code generation compresses one activity. If that activity is a quarter of your effort and the tool makes it twice as fast, the project gets an eighth shorter, and only if nothing downstream becomes the new constraint. Requirements that were ambiguous before remain ambiguous. Solution design and user stories with acceptance criteria are still produced by people, and they still gate everything after them.

Delivery agents produce reviewable artifacts, not edited files

The category difference becomes clear when you look at what each tool returns.

A coding assistant returns a diff. The unit of output is a changed file, reviewed in an editor, by a developer, in the context of a repository. That is the right unit for engineering work and the wrong unit for a requirements workshop, a configuration specification or a test plan, none of which are files in a repo.

A delivery agent returns a deliverable. GetGenerative.ai assigns named agents across six delivery stages, of which only the build and test stages overlap the territory a coding assistant occupies. The stage that matters most for this comparison is the one that inspects the org before design starts, because that inspection decides whether the requested thing should exist in the requested form. A coding tool joins the project after that question has been settled, or after it has been skipped.

Pricing follows the unit of output. Coding assistants bill per developer per month, which is coherent when the thing produced is code and the producer is a developer. Credit-based delivery platforms bill per artifact generated, which is coherent when the thing produced is a document that a project consumes once and revises many times.

Those two meters are not comparable on price per seat, and a procurement exercise that treats them as substitutes will pick the cheaper one and then discover the missing deliverables in month two. Teams can weigh GetGenerative.ai plans and credits against one real deliverable, which settles the question faster than any feature grid.

Choose by artifact type, not by tool preference

Sort the work by what it produces, and the answer stops being a matter of preference.

Work	Output is	Better fit
Apex class, trigger or handler	A source file	Coding tool, connected to the org
Lightning Web Component	Source files	Coding tool
Apex or Jest test class	A source file	Coding tool, with volume-aware cases
Refactoring existing code	A diff	Coding tool
SOQL against an unfamiliar object model	A query, silently wrong if the model is misread	Coding tool with MCP schema access
Requirements and user stories	A document	Delivery agent
Solution design and platform choice	A decision plus a document	Delivery agent, human-approved
Configuration specification	A document	Delivery agent
Data migration mapping and reconciliation	A plan plus validation evidence	Neither, without a data owner
Release governance and approvals	A decision	Neither

The rows split cleanly. Where the deliverable is a file, a coding tool wins and the only question is how well it is grounded. Where the deliverable is a document, a decision or a reconciliation, a coding tool has no unit of output to produce, and that is not a quality problem to be solved with a better model.

Teams surveying the wider market can work from the AI platform roundup once the artifact question above has been answered.

Recap. Cursor’s published 75 percent adoption and 30 percent velocity gain at Salesforce measure a 25-year product codebase and thousands of platform engineers, not Salesforce implementation work. Coding tools operate on files; much of an org has no file representation until retrieved, and retrieval is a snapshot. Connected through MCP they gain schema awareness but still cannot see Apex source, flow logic, validation rules or permission sets. Salesforce publishes a tool-agnostic skills library rather than competing for the editor. Choose per task by whether the deliverable is a file.

Key facts

Fact	Value	Source and date
Cursor adoption inside Salesforce	Over 75 percent of Salesforce developers	Cursor customer story, 21 January 2026
Reported velocity gain	30 percent or greater increase in pull request velocity	Cursor customer story, 21 January 2026
Reported test coverage effect	85 percent less time on legacy test coverage	Cursor customer story, 21 January 2026
What that case study measures	Salesforce’s own product codebase, built over 25-plus years by thousands of engineers	Cursor customer story, 21 January 2026
Cursor as a Salesforce MCP client	Officially documented setup; listed as tested with native OAuth support	Salesforce Hosted MCP Servers documentation
Salesforce skills library	forcedotcom/sf-skills, Apache-2.0, covering Agentforce agents, Flow, Apex, SOQL, LWC, objects and fields, permission sets	GitHub, Salesforce-maintained
Skills library portability	Optimized for Agentforce Vibes, usable with any AI tool that supports skills	GitHub, Salesforce-maintained
What a connected editor can reach	The shape of the org: objects, their fields and how they relate	Salesforce Hosted MCP Servers documentation
What it cannot reach	The behavior layer: deployed Apex, flow branching, validation formulas, permission set contents	Salesforce Hosted MCP Servers documentation
Copilot’s Salesforce grounding path	Repository instruction files; GitHub’s Awesome Copilot collection publishes an Apex instruction set	awesome-copilot.github.com
What that instruction set must state	Bulkify, handle collections not single records, respect governor limits, separate service, domain and selector layers	awesome-copilot.github.com
Declarative versus code split in Salesforce orgs	No credible public dataset located	Verified absence, September 2026

FAQ

Can Cursor or GitHub Copilot be used for Salesforce development?

Yes, and Salesforce publishes official instructions for connecting Cursor to its hosted MCP servers, listing it as a tested client with native OAuth support. Connected that way, a coding tool can read object and field schema so generated code references real API names rather than plausible guesses.

Does the Cursor Salesforce case study apply to Salesforce implementations?

Not directly. Cursor reports over 75 percent adoption and a 30 percent pull request velocity gain at Salesforce, but the case study describes Salesforce’s own product codebase built over more than 25 years by thousands of engineers. Configuring Sales Cloud is a different workload.

What can AI coding tools not see in a Salesforce org?

A connected editor can retrieve the shape of an org, meaning its objects and how they relate. It cannot read the behavior layer: Apex already deployed, branching inside flows, validation formulas, or what a permission set actually grants. It learns structure without learning runtime behavior.

Why does AI-generated Apex fail in production but pass locally?

Salesforce enforces execution limits per transaction. Queries or DML inside loops work against small sandbox datasets and breach limits at production volume. The pattern is not a syntax error and does not fail a compile or a unit test written against limited data.

Does Salesforce provide anything to make coding tools better at Salesforce?

Yes. Salesforce maintains an Apache-2.0 skills library at forcedotcom/sf-skills covering Agentforce agents, Flow, Apex, SOQL, Lightning Web Components, objects and fields and permission sets. It is optimized for Agentforce Vibes and documented as usable with any AI tool that supports skills.

When should a delivery agent be used instead of a coding tool?

When the deliverable is a document, a decision or a reconciliation rather than a file. Requirements, solution design, configuration specifications and test plans have no unit of output a coding assistant produces, which is a category limit rather than a model quality problem.

Governance gets framed as a discipline problem. It is closer to a scheduling problem, and the schedule is not yours.

Salesforce ships three seasonal releases a year, and every org receives them whether or not anyone asked. Retirements land on their own calendar: Salesforce’s public list of past product and feature retirements shows six features reaching end of life between February and June 2026 alone, and Workflow Rules and Process Builder support ended on 31 December 2025. Then there is unscheduled change. A practitioner post in May 2026, which drew 186 votes and 76 comments, described mandatory MFA for all users, phishing-resistant MFA for admins, step-up authentication on reports, auto-containment of high-risk connections and email domain verification arriving across roughly twelve weeks between April and July 2026. The most upvoted reply reported revising an implementation plan three times because the requirements kept moving between required and recommended.

An org absorbing that much external change also absorbs internal change: every field an admin adds, every flow a partner deploys, every permission set someone clones on a Friday.

Salesforce governance is the set of rules determining who may change what, against which standards, and on what review rhythm. It exists because change arrives faster than any individual can evaluate it, and without a framework the accumulated result is drift.

Salesforce governance splits into two domains that share one name

The word covers two disciplines that need separate owners, and conflating them is why governance charters sprawl without deciding anything.

Data governance answers whether the records are trustworthy: stewardship, duplicate rules, matching policies, quality ownership.

Platform governance answers whether changes to the system are controlled. Who approved this new object. Which standard says a validation rule belongs here rather than in a flow. Whether anyone checks that the 40 reports built last quarter are still opened.

This page covers the second. It assumes the first has its own owner, because a single forum attempting both will do neither on any useful timescale.

Well-Architected now names five pillars, and most content still cites three

Anyone building a governance framework usually anchors it to the platform vendor’s own architecture guidance, which makes the current state of that guidance worth checking rather than recalling.

Salesforce’s Well-Architected framework has been rebuilt. The Architecture Center presents five pillars and an Agentic Enterprise lens, described as helping architects navigate trade-offs and make sound architectural decisions in the agentic era. Salesforce states the framework addresses humans, agents and platforms working together inside governed business systems, and names ongoing governance as one of its three intended uses alongside design reviews and trade-off conversations. The pillars, in Salesforce’s own words:

Pillar	Salesforce’s definition
Trust	Protect people, data, and systems through secure, compliant design
Reliability	Build systems that continue working and recover gracefully when something fails
Operational Excellence	Observe, automate, and continuously improve how systems run
Resource and Cost Optimization	Invest intentionally to maximize long-term business value
Fairness	Ensure systems are transparent, accessible, and equitable

Check the Change Log before reusing any existing charter. Every pillar there is listed as Published rather than Updated, which marks this as a new framework rather than an edit to an older one. Salesforce does not document what it supersedes, so the practical test is simple: open your governance standards and see whether the quality dimensions they name match the five above. Anything written earlier, including guidance produced by an AI assistant trained before the change, will describe a different structure.

Two pillars carry the sharpest governance consequences. Resource and Cost Optimization gives budget a seat in architecture review, which matters in a consumption-priced era where an ungoverned agent or data pipeline produces a bill rather than a performance complaint. Fairness makes transparency and accessibility architectural properties subject to review, rather than compliance paperwork handled after launch.

Salesforce’s own summary of why the pillars travel together is the most quotable line in the framework: a solution that is secure but brittle under load, or efficient but opaque in its decisions, is not well-architected.

A working framework answers three questions, not one

Most published governance frameworks describe a body, usually a Center of Excellence, and stop. The body is the venue. It is not the framework. A framework specifies what gets decided, by whom, against what, and when.

Three components carry that:

Decision rights assign each category of change to a named approver, so that no change waits for a meeting that was not going to discuss it.

Standards convert accumulated opinion into written, testable rules, so approval is a comparison rather than a debate.

Cadence gives each decision type a scheduled venue, so the framework runs on a calendar rather than on escalation.

Remove any one and the other two degrade. Standards without decision rights produce documents nobody enforces. Decision rights without cadence produce a queue. Cadence without standards produces a recurring meeting that relitigates the same questions.

How the body itself is structured, staffed and chartered is a separate subject covered in building a Center of Excellence, and project-level role assignment sits in the implementation RACI. What follows is the decision system those structures operate.

Decision rights assign each change class to a named approver

The failure mode this prevents is specific: every change routed to the same forum, which then becomes a bottleneck, which is then bypassed. Bypass is the real risk, because a governance process people route around produces worse outcomes than no process, having also consumed the time.

The remedy is to classify changes by blast radius and pre-assign authority. A workable starting matrix:

Change class	Examples	Approver	Route
Reversible and local	Report, list view, dashboard, personal automation	Admin, no approval	Direct
Additive and contained	New field on an existing object, new validation rule	Platform owner	Async, 1 business day
Structural	New object, new record type, sharing model change, new profile or permission set group	Architect	Design review
Integration	New named credential, external system connection, API contract change	Architect plus security	Design review plus security sign-off
Agent-affecting	Any change to data an agent reads, or to an agent’s actions and permissions	Agent owner	Agent review, see below
Irreversible	Field deletion, object deletion, mass data operation	Platform owner plus data owner	Scheduled, with rollback plan

Two design rules make this hold. Every row names a person rather than a committee, because a committee cannot be paged. And the top row grants real autonomy: if an admin cannot build a report without raising a ticket, the framework will be abandoned within a quarter.

The matrix also states, by omission, who does not decide. That is its most useful property in practice, and the reason it should be published rather than assumed.

Standards turn approval into a comparison rather than an argument

A standard is only useful if it can be checked without its author present. That rules out most of what organizations call standards, which are preferences recorded informally and enforced by whoever remembers them.

Testable standards for a Salesforce org fall into four groups.

Naming and metadata hygiene. Field and object API naming conventions, mandatory description fields, required help text on any field a user sees. These are checkable by query and are the cheapest standards to enforce automatically.

Automation placement. Which tool owns which job, stated as a rule rather than a preference: where validation belongs, when a flow becomes Apex, what may run synchronously. Without this, the same requirement gets solved four different ways by four different people, and technical debt accumulates as inconsistency rather than as bad code.

Security and access. Permission sets over profiles, least privilege by default, a documented owner for every permission set group. The detail belongs in a security review, and governance’s role is to require that the review happened.

Environment and release. What must exist in a sandbox before promotion, what test evidence accompanies a change, what the rollback path is. That connects directly to sandbox strategy and makes release a check rather than a negotiation.

The test for any candidate standard is whether a reviewer who disagrees with it could still apply it consistently. If applying it requires the author’s judgment, it is guidance, not a standard, and it should be labeled that way so nobody pretends otherwise. Automated checks make standards cheap to apply at volume, which is the argument for AI-assisted code review against a published rule set rather than against reviewer preference.

Cadence gives every decision type a scheduled venue

Cadence is the component most often missing, and its absence is why governance frameworks decay into escalation paths.

Four rhythms cover a normal org:

Weekly, intake and triage. New requests classified against the decision rights matrix and routed. The output is a routing decision, not a solution.

Fortnightly, design review. Structural and integration changes reviewed against standards. Attendance is the architect plus the requester. This is the forum the matrix protects by keeping small changes out of it.

Per release, readiness. Three times a year, Salesforce ships. Someone reads the release notes against your org’s configuration and your automations, and produces a list of what to test and what to turn off. Skipping this converts a scheduled event into an incident.

Quarterly, drift review. The only rhythm that looks backward. What was built last quarter, what is unused, what standards were bypassed and why. Bypasses are data about the framework, not misconduct: a standard bypassed repeatedly by competent people is usually wrong.

The quarterly review is where governance connects to measurable outcomes, because it is the point at which an org assessment becomes an action list and unused configuration becomes an org cleanup with an owner.

Agents become governed objects with their own review rhythm

Deployed agents change what governance has to cover, and the change is structural rather than incremental.

A field has one behavior. An agent has a range of behaviors that depends on what it reads, which actions it holds and how it was instructed. Three governance consequences follow.

Agent-affecting change becomes its own class in the decision rights matrix, because a modification to an object an agent reads is a modification to the agent, even when nobody edited the agent. A field renamed, a picklist value added, a sharing rule tightened: each can alter agent behavior without appearing in any agent-related change log.

Agent review needs a rhythm of its own, closer to weekly than quarterly during early operation, because agent failures surface in conversation transcripts rather than in error logs.

And Well-Architected’s Fairness pillar now gives transparency and equitable treatment explicit architectural standing, which is directly relevant to a system that answers customers in natural language.

Ownership, escalation and the post-go-live operating model for agents are covered in Agentforce governance. The point here is narrower: the decision rights matrix needs a row for agents, and most existing frameworks do not have one.

Drift appears before outage, which is why the framework is preventive

The relationship this page rests on is that governance prevents org drift and debt. Both accumulate silently, which is what makes them expensive.

Ungoverned orgs do not fail dramatically. They accumulate fields nobody populates, automations nobody can trace, reports nobody opens and permission sets nobody owns. Each individual addition was reasonable. The aggregate is an org where every change costs more than the last one, because the impact of any modification is no longer knowable without investigation.

That is the practical case for the framework, and it is a cost argument rather than a compliance one. Decision rights reduce the number of changes made without evaluation. Standards reduce the variance between changes. Cadence ensures someone looks at the accumulation before it compounds. None of the three produces visible value in the quarter it is introduced, which is precisely why governance is usually adopted after an incident rather than before.

Organizations running ongoing change without a dedicated platform team can route the business-as-usual lane through the Support Agent for BAU work, which handles triage, dependency and impact analysis, fix generation, testing and documentation for bugs and enhancement requests. Impact analysis on every request is the part that matters for governance, because knowing what a change touches is the precondition for deciding who approves it.

Recap. Salesforce ships three releases a year plus unscheduled change, so governance responds to a rate you do not set. Well-Architected now has five pillars, Trust, Reliability, Operational Excellence, Resource and Cost Optimization and Fairness, replacing the three-part framing most documents still cite. A framework needs decision rights, standards and cadence together. Agents require their own row in the matrix and their own review rhythm.

Key facts

Fact	Value	Source
Well-Architected pillars, current	Trust, Reliability, Operational Excellence, Resource and Cost Optimization, Fairness, plus an Agentic Enterprise lens	Salesforce Architecture Center
Salesforce release cadence	Three seasonal releases a year, applied to every org	Salesforce
Features retired February to June 2026	Six, per the public retirement list	Salesforce Past Product and Feature Retirements
Workflow Rules and Process Builder	Support ended 31 December 2025; existing automations continue running	Salesforce Help
Reported security change load	Five enforcement changes across roughly twelve weeks, April to July 2026	Practitioner account, r/salesforce, May 2026
Governance components required	Three: decision rights, standards, cadence	Framework defined on this page
Review rhythms	Weekly intake, fortnightly design review, per-release readiness, quarterly drift review	Framework defined on this page

FAQ

What is a Salesforce governance framework?

A Salesforce governance framework defines who may change what, against which written standards, and on what review rhythm. It combines three components: decision rights assigning change classes to named approvers, testable standards, and a cadence giving each decision type a scheduled venue rather than an escalation path.

How is platform governance different from data governance?

Data governance addresses whether records are trustworthy, covering stewardship, duplicates, matching and quality ownership. Platform governance addresses whether changes to the system are controlled, covering approval authority, configuration standards and release rhythm. Most published Salesforce governance material describes the first while using the general term.

Who should approve Salesforce changes?

Approval should vary by blast radius. Reversible local changes such as reports and list views need no approval. Additive changes go to a platform owner. Structural, integration and irreversible changes go to an architect, with security sign-off for integrations. Naming an individual rather than a committee keeps decisions fast.

How often should a Salesforce governance board meet?

Four rhythms work: weekly intake and triage for routing, fortnightly design review for structural changes, release readiness three times a year aligned to Salesforce releases, and a quarterly drift review examining what was built, what is unused and which standards were bypassed.

Do AI agents change Salesforce governance requirements?

Yes. Agents need their own class in the decision rights matrix, because changing an object an agent reads changes the agent without editing it. Agent behavior surfaces in conversation transcripts rather than error logs, so review runs closer to weekly than quarterly during early operation.

What does weak Salesforce governance actually cost?

Ungoverned orgs accumulate unused fields, untraceable automation, abandoned reports and unowned permission sets. Each addition was individually reasonable. The compound effect is that every subsequent change costs more, because the impact of any modification cannot be determined without investigation first.

Salesforce makes one sentence do the heavy lifting on its Agentforce Vibes product page: simply describe what you need, and Agentforce builds, tests, and deploys the code.

Three verbs. Builds, tests, deploys. The sentence is accurate, which is why it is worth auditing rather than dismissing. A Salesforce implementation is not three verbs long, and the distance between what those three cover and what a project requires is the entire subject of this page.

So take the claim clause by clause, against Salesforce’s own documentation, and see where the coverage ends.

Agentforce Vibes is Salesforce’s agentic development environment, delivered as a VS Code extension and as a cloud-hosted IDE. Vibe coding describes generating working software by describing intent in natural language rather than writing the implementation. Salesforce has adopted the term formally: the canonical URL for that product page ends in vibe-coding, and the page headline reads Enterprise Vibe Coding.

Three named sub-agents all sit inside the code layer

Start with what the product actually contains, because the architecture answers the scope question before any argument does.

Salesforce’s agentic development documentation names the specialized sub-agents the lead agent coordinates: Logic Builder, Component Builder and QA Validator, each operating in an isolated Git worktree. The overview page separately describes the layers those sub-agents work across, listing Apex logic, Lightning Web Components, Jest testing and SOQL queries as examples.

Read the three names as a delivery lead rather than as a developer. Build the logic, build the component, validate the build. Every one is a construction or verification role inside a codebase. There is no Requirements Analyst, no Solution Architect, no Data Migration sub-agent, no Acceptance Tester, no Release Manager.

That is not a criticism. It is a scope statement, and Salesforce published it. The product is built on what Salesforce calls its Coding Agent Platform, using the Claude and Mastra orchestration engines. A coding agent platform produces code, competently, and the naming is honest.

Three documented guardrails deserve credit before the audit proceeds, because a fair reading has to account for them.

Plan Mode produces a structured plan containing Goals, Non-Goals, an Approach section and numbered Tasks, reviews metadata and logs dependencies, and changes no files until you click Approve Plan. Goals and Non-Goals are design vocabulary, and their presence is a real step beyond raw generation.

Checkpoints are created before the agent makes changes, so work can be rolled back when output is not what you expected. Permission modes control what the agent may execute, with per-tool settings for Always ask or Auto-approve, and Salesforce advises starting restrictive.

The multi-modal input path accepts screenshots and diagrams, translating visual UI layouts and design mockups directly into frontend code. Note the direction of travel there: a design that already exists becomes code. Producing the design is upstream of the tool.

Builds covers construction, not the decision about what to construct

The first verb is the strongest, and it still stops short of the decision that matters most.

A practitioner writing on r/salesforce in July 2026 described the failure mode precisely, from experience with both Vibes and Claude Code. Both tools, they wrote, will over-engineer something if you are not careful about your requirements and use case. Their example: the tool will stand up an Experience Cloud site with a custom Lightning Web Component just to show open cases to a user, when a simple list view would do.

Sit with that example, because it is the whole argument in one sentence. The generated code may be correct. It may compile, pass review and deploy cleanly. It is still the wrong answer, and nothing inside a code generator can tell you so, because the question it answers is how to build what was described rather than whether that thing should be built at all.

Salesforce says the same thing in its own documentation, more plainly than any critic would. Agentic development, the guide states, is not fully autonomous development: the agent makes mistakes including hallucinated method names, incorrect assumptions about your org, and code that compiles but does not meet your intent. The next sentence is four words long. Human review is not optional.

Code that compiles but does not meet your intent is the exact failure the list-view example describes, named by the vendor on its own documentation page.

A list view is configuration. A custom component is a maintained asset with a test class, a deployment footprint, an upgrade path and an owner. Choosing the first over the second is a solution design decision, made by someone who knows both the platform and the business, before anyone describes anything to a tool.

This is why solution design documents and written user stories with acceptance criteria are not bureaucracy on an AI-accelerated project. They are the artifacts that constrain generation. A tool asked to build from a vague description will build something, enthusiastically, and the cost of that arrives in year two.

Tests covers unit tests, not acceptance

The second verb is where the gap is widest and least noticed, because the word carries two meanings that a project cannot treat as interchangeable.

The sub-agent carrying testing responsibility is named QA Validator, and the testing layer Salesforce lists alongside it is Jest. Jest is a JavaScript unit testing framework used in Salesforce for Lightning Web Components. Salesforce’s own FAQ describes the capability as generating test cases. All of that describes verification at unit level: does this component behave as its author intended.

User acceptance testing asks a different question entirely. Does this solution let a named business user complete a real task, in an environment seeded with realistic data, judged by someone with authority to reject it. A generated Jest suite cannot answer that, and a generated Apex test class cannot either. The distinction between developer testing and acceptance testing is the reason a test strategy and a UAT process are separate documents with separate owners.

There is a second-order problem worth naming. Tests generated by the same system that generated the implementation encode the same misunderstanding twice. If the model misread the requirement, the code implements the misreading and the test asserts it. Coverage rises, confidence rises, and the defect is now protected by a passing test. Independent verification exists to break that loop, which is precisely why it has to be independent.

Deploys covers metadata movement, not release governance

The third verb is the narrowest, and Salesforce’s documentation is clear about what it means.

The Salesforce DX MCP Server ships with Agentforce Vibes and provides CLI tools for Salesforce development, testing and deployment. Deployment here means invoking the Salesforce CLI to move metadata between environments. That is a real capability and it removes real friction.

Release governance is a different activity performed by different people. Which environment receives this change and when. Whether the sandbox has been refreshed and seeded. Who approves promotion to production. What the rollback plan is. Who is on hypercare for the first two weeks. Whether the data migration ran, reconciled, and passed validation. None of those are CLI invocations, and none appear anywhere in the Vibes documentation, because they are not development tasks.

A project can have flawless metadata deployment and still fail its go-live, which is why a sandbox strategy, a go-live checklist and a hypercare plan exist as separate disciplines from writing the change.

Six lifecycle stages have no sub-agent

Collecting the audit into one view makes the coverage boundary legible. The middle column reflects what Salesforce documents, not what a vendor-neutral observer might wish for.

Lifecycle stage	Covered by Agentforce Vibes	Who owns the gap
Discovery and requirements	No	Business analyst or consultant
Solution design and platform choice	Partially, via Plan Mode for code changes	Architect
Configuration and code	Yes, across Apex, LWC and SOQL	Developer, supervised
Unit testing	Yes, via the QA Validator sub-agent	Developer
Data migration and reconciliation	No	Data lead
System and integration testing	No	QA
User acceptance testing	No	Business owner
Deployment mechanics	Yes, via the DX MCP Server and CLI	Release engineer
Release governance and approvals	No	Delivery lead
Adoption, training and hypercare	No	Change manager

Four covered, six not. That ratio is the reason a delivery organization cannot be replaced by a coding agent, and also the reason a coding agent is worth having: it removes work from the four stages where effort is most mechanical.

The mistake worth avoiding is arithmetic. Four of ten stages covered does not mean forty percent of a project is automated, because the stages are not equal in effort and the uncovered ones cluster at the beginning and the end, where the decisions that determine success actually get made.

Salesforce effectively confirms the boundary by listing what a human has to supply. Under the heading of what you must tell the agent, the documentation names four inputs: business logic intent, meaning why a field exists, what a process should do and which edge cases matter; org-specific conventions not expressed in code; external system integration contracts, authentication flows and third-party behavior; and deployment targets with the environment differences between sandboxes and production.

Those four inputs are discovery, architecture standards, integration design and release planning, described from the tool’s point of view as prerequisites. Salesforce adds that when the agent lacks information it either asks or makes assumptions from what it observes, and that reviewing those assumptions is part of your role. A tool that documents its own required inputs has told you which lifecycle stages produce them.

Practitioners describe Vibes as a wrapper around Claude, and the description holds

Community assessment of Vibes is more useful than either vendor copy or reflexive skepticism, and it converges on a specific characterization.

In a May 2026 thread comparing Claude Code and Agentforce Vibes, which drew 32 comments, the most upvoted reply at 42 votes made the architectural point plainly: the new Agentforce Vibes uses Claude in the backend and comes with Salesforce-geared skills. A July 2026 thread put it more completely. One commenter described Vibes as Claude Code inside a wrapper that supplies prebuilt skills, instructions and an assumed set of org MCP servers, executing CLI operations from a catalog using your OAuth credentials.

That is a fair description, and the wrapper is the value. Another commenter in the same thread noted the practical benefits: Vibes is faster to set up because Salesforce platform development guidelines and governor limits are built in, and the web-based version removes the need to install and configure the Salesforce CLI at all. For a team without an established AI toolchain, those are real advantages.

The sharpest observation came from the May thread, at 13 votes, reporting an impression from Salesforce’s own developer conference: that Salesforce knows it will not win on coding tools and is focusing instead on skills and MCP servers that work across tools. Whether or not that reading is right, it points at something the documentation supports. Salesforce publishes an agent skills repository and has made its MCP servers client-agnostic, naming Claude, ChatGPT and Cursor as tested clients. The platform investment is in grounding, not in owning the editor.

One documented detail deserves quoting because it is unusually candid for vendor documentation. On installing MCP servers from a marketplace, Salesforce warns that marketplace installs depend on the model interpreting the server’s GitHub README, which is nondeterministic and token-heavy, and recommends direct configuration instead. A vendor telling you its own convenient path is nondeterministic is worth more than a page of assurances.

Practical constraints are published too. Approximately 20 tools can run simultaneously, and Salesforce advises turning off unused servers to reduce tool burden. Familiarity with VS Code and the Salesforce CLI is assumed. On Windows, the extension fails to activate without the Microsoft Visual C++ Redistributable.

The free allocation runs out at 50 requests or a million tokens

Anyone evaluating Vibes hits the cost question early, and Salesforce answers it in documentation rather than on the pricing page.

Agentforce Vibes is available at no additional cost in Developer Edition orgs, with no trial period and no expiration. The daily free allocation is powered by Claude Sonnet 4.6 and capped at 50 requests per day or one million tokens per day, whichever limit you reach first. Both counters run at once, so a single request carrying a large context window can exhaust the token limit before the request count moves. The allocation resets every 24 hours. Continuing past it means switching to unmetered usage or to metered usage drawing on Flex Credits.

Two planning consequences follow. Developer Edition is the free surface, which makes the allocation a learning and prototyping budget rather than a project budget. And because tokens and requests are counted separately, a team working on a large codebase will meet the token ceiling long before it reaches fifty requests, so a per-request estimate will overstate how much work the free tier supports.

The measurement question is who reviews what the agent produced

An honest accounting of vibe coding has to address volume, because volume is the mechanism by which a productivity tool becomes a delivery problem.

A coding agent that runs sub-agents in parallel across Apex, LWC, Jest and SOQL, each in its own Git worktree, produces more code per unit of human time than a person does. Every line of that code enters an org that has finite capacity for complexity, and every generated component becomes something a future engineer maintains. The over-engineering example above is not a rare failure: it is the default behavior of a system optimized to produce a working implementation rather than the smallest sufficient one.

The governing question for a delivery lead is therefore not how fast the agent writes, but whether review capacity scales with generation capacity. If one engineer supervises output that previously occupied four, review becomes the constraint, and the quality of that review determines whether acceleration compounds into throughput or into technical debt.

This is where the distinction between a coding tool and a delivery method becomes commercial rather than philosophical. A comparison of AI coding tools against delivery agents turns on exactly this point.

GetGenerative.ai covers the stages a coding agent leaves open

GetGenerative.ai positions its platform with a line that names the boundary directly: more than just vibe coding.

The structure behind that claim maps to the gaps identified above. The published model runs six stages, Discover, Analyze, Design, Build, Test and Deploy, with named agents across them: Discovery, Metadata, Design, Build, Test and Support. Only two of those six sit inside the code layer that Vibes occupies. Discovery produces business and solution context. Analyze reads the org and its metadata before design starts. Design produces solution designs, stories and acceptance criteria. Support continues after deployment.

A Forward Deployed Engineer leads each pod, with a published bar of at least 12 years of Salesforce delivery experience and a hands-on configuration and development background. That person carries the decisions the previous sections identified as uncoverable by generation: whether a list view suffices, whether the acceptance criteria match the business outcome, whether this change should promote today.

The two tools are not competitors in any meaningful sense, and claiming otherwise would be dishonest. Agentforce Vibes is a development environment. A delivery method is the thing that decides what to develop, verifies it against a business expectation, moves it safely and keeps it working. Consultants evaluating that difference can start with the Pro plan for consultants and test it against one real deliverable rather than a demo.

What to buy Vibes for, and what to staff around it

The practical conclusion is a split, not a verdict.

Buy Agentforce Vibes for what it plainly does well. Platform guidelines and governor limits are built in, so generated Apex starts closer to correct than a general assistant’s would. The DX MCP Server arrives configured. Plan Mode shows intended changes before touching files. The web version removes CLI setup entirely, which matters for admins and analysts who would otherwise never adopt the tooling.

Staff around it for everything the audit identified. Requirements and solution design decide what gets built, and that hour returns more than any other on the project. Data migration has no representation in any coding agent and routinely consumes more elapsed time than configuration. Acceptance testing requires a human with authority to say no. Release governance requires an approver. Adoption requires someone who will still be present in month three.

And review capacity has to be planned as deliberately as generation capacity, because a tool that produces four engineers’ worth of code and receives one engineer’s worth of scrutiny has not removed the bottleneck. It has moved it somewhere less visible.

Recap. Salesforce says Vibes builds, tests and deploys the code, and all three are true at the scope Salesforce documents. Every named sub-agent covers a code layer: Apex, LWC, Jest, SOQL. Builds excludes the decision about what to build, tests means unit tests rather than acceptance, and deploys means metadata movement rather than release governance. Six of ten lifecycle stages have no sub-agent, and they sit at the start and the end of a project.

Key facts

Fact	Value	Source
Vendor claim under audit	Agentforce builds, tests, and deploys the code	Salesforce Agentforce Vibes product page
Named sub-agents	Logic Builder, Component Builder, QA Validator, each in an isolated Git worktree	Agentforce Vibes, Understand Agentic Development
Underlying platform	Salesforce Coding Agent Platform, using Claude and Mastra orchestration engines	Agentforce Vibes Developer Guide
Plan Mode guardrail	Produces Goals, Non-Goals, Approach and numbered Tasks; no files change until the plan is approved	Agentforce Vibes Developer Guide
Deployment capability	Salesforce DX MCP Server ships with Vibes, providing CLI tools for development, testing and deployment	Agentforce Vibes MCP Servers doc
Published tool limit	Approximately 20 tools can run simultaneously	Agentforce Vibes MCP Servers doc
Documented caveat	Marketplace MCP installs depend on the model interpreting a GitHub README, described as nondeterministic and token-heavy	Agentforce Vibes MCP Servers doc
Assumed prerequisites	Familiarity with VS Code and the Salesforce CLI	Agentforce Vibes Developer Guide
Free allocation	Developer Edition orgs, 50 requests or 1 million tokens per day, whichever comes first, on Claude Sonnet 4.6	Agentforce Vibes free tier doc
Vendor limitation statement	Agent makes mistakes including hallucinated method names and code that compiles but does not meet your intent; human review is not optional	Agentforce Vibes, Understand Agentic Development
Lifecycle stages without a sub-agent	Six of ten, clustered before and after the build	Derived from Salesforce documentation

FAQ

What does Agentforce Vibes actually do?

Agentforce Vibes is an agentic development environment available as a VS Code extension and a cloud-hosted IDE. A lead agent coordinates three named sub-agents, Logic Builder, Component Builder and QA Validator, with a Plan Mode producing Goals, Non-Goals and numbered Tasks before any local file changes.

Can Agentforce Vibes replace a Salesforce implementation team?

No. The three sub-agents Salesforce names, Logic Builder, Component Builder and QA Validator, all sit inside the code layer. Discovery, requirements, data migration, acceptance testing, release governance and adoption have no equivalent, and Salesforce documents human review as not optional.

Does Agentforce Vibes handle testing?

It generates unit tests through a sub-agent named QA Validator, with Jest listed as the testing layer for Lightning Web Components. Unit testing verifies that code behaves as its author intended. Acceptance testing verifies that a business user can complete a real task, and needs realistic data plus a human with authority to reject the result.

What is the risk of AI-generated Salesforce code?

Over-engineering is the most commonly reported risk. Practitioners describe generators building a custom Lightning Web Component and Experience Cloud site where a standard list view would suffice. The code can be correct while the solution is wrong, because a generator answers how to build rather than whether to build.

Is Agentforce Vibes the same as vibe coding?

Salesforce has adopted the term formally. Its product page is headed Enterprise Vibe Coding and the canonical URL ends in vibe-coding. Vibe coding describes producing working software by stating intent in natural language rather than writing the implementation directly, which Salesforce now markets as an enterprise practice.

What should a delivery lead staff around Agentforce Vibes?

Requirements and solution design, data migration, system and acceptance testing, release governance and adoption. Review capacity also needs planning, because a tool generating several engineers’ worth of code while receiving one engineer’s worth of scrutiny relocates the bottleneck rather than removing it.

Salesforce publishes live weekly counters for the Agentforce agent running on its own Help site, on a page it calls Customer Zero. For the week of 23 August 2026 they read:

Counter	Value
Conversations handled by Agentforce	83,044
Agentforce resolved conversations	53,691
User abandoned conversations	6,489
Agentforce conversation handoffs	16,428
Immediate customer-initiated conversation handoffs	6,436

The page states its own formula: total conversations equal resolved plus abandoned plus handoffs. Run it and the answer is 76,608, not 83,044. The missing 6,436 is the fifth counter, the people who asked for a human before the agent got a turn.

So the resolution rate is 53,691 divided by 76,608, which is 70.1 percent. Or it is 53,691 divided by 83,044, which is 64.7 percent. The prose on the same page says more than 63 percent. Three defensible numbers, one dataset, and the whole spread comes from one unsettled question about who belongs in the denominator.

Salesforce deserves credit for publishing raw counters at all, which almost no vendor does. The useful point is narrower. An Agentforce deployment produces a number long before it produces an agreed number. Most rollouts that feel stuck are somewhere in that gap, and the gap is not closed by building anything.

This page is about diagnosis. Agentforce rollouts stall in four distinct ways, each needs a different intervention, and a Forward Deployed Engineer is worth paying for in three of them. For the definition of the role itself, its origin and how the pods are staffed, start with the Forward Deployed Engineer delivery model. What follows assumes you already have an agent that is not moving.

Four stall types account for most stuck Agentforce rollouts

The four sort by what is actually blocking production, not by project phase. Misdiagnosis is expensive because the interventions do not substitute for each other: more engineering hours will not settle a measurement argument, and a clean dashboard will not fix an entity-resolution failure.

Stall type	What you observe	What clears it
Platform defect	Agent behaves correctly in design, fails on a Salesforce-side path	Direct product engineering access
Process ambiguity	Every review reopens what the agent should do	Decision authority present during build
Data resolution	Agent works on clean examples, misfires on real records	Entity matching against a system of record
Measurement	Agent is live, nobody agrees whether it works	An agreed denominator, set before launch

Only the first has an obvious owner. The other three are routinely mistaken for build problems and staffed with more builders, which is how a two-week configuration turns into a two-quarter program.

Product access clears a defect stall that a support queue cannot

Salesforce’s published example of an FDE rescue is specific enough to learn the mechanism from.

A reservation booking platform had an Agentforce pilot that was failing. Something was wrong with the Agentforce data library, and updates to knowledge articles were not syncing with Data 360. Salesforce assigned Forward Deployed Engineers, who listened to the concerns, enlisted Salesforce’s product team to fix the defects, and got the agent back on track. An FDE director’s account of the elapsed time: all issues resolved within a week.

Strip the vendor framing and the transferable part is the routing. The blocker was a defect in a sync path between two Salesforce products. The standard route for that is a support case, a reproduction request, a tier escalation and a wait measured against release cycles. The FDE route was a direct line into product engineering.

What compressed was not build effort. It was the queue.

That is the honest definition of FDE acceleration, and it sets the boundary on the claim. An embedded engineer shortens the interval between finding a blocker and holding authority to clear it. On a project with no blockers, that interval is already zero and an FDE accelerates almost nothing. On a project stuck eight weeks behind a defect nobody can escalate, it is the entire value. Price the engagement against the blocker, not against the backlog.

Undocumented process turns an agent into a mirror

The community verdict on what actually blocks Agentforce is consistent, and it is not the product.

A June 2026 r/salesforce thread asked whether Agentforce had replaced any real admin work or whether everyone was still running demos. The most upvoted reply, at 44 votes, came from the account of a Salesforce implementation vendor reporting on internal testing and several client environments. Note the source before weighing the content, and then note which direction it cuts: a firm that sells Agentforce work said the agent had not replaced admins or consultants, only reduced time spent on repetitive tasks, with the best results in answering common internal questions, guiding users through processes, summarizing records and helping service teams find information faster.

Then the failure condition, stated plainly. Where processes are poorly documented or data quality is inconsistent, the agent tends to expose existing problems rather than solve them. The comment closed by noting that organizations seeing value have clear use cases and clean data, while those expecting a fully autonomous administrator are usually still in demo mode. A vendor conceding that against its own commercial interest is worth more than the upvote count suggests.

A July 2026 comment, quieter at three votes, put the scoping rule well: the best agent use cases are narrow workflows with clear inputs, clear permissions and an obvious handoff point, and once an agent needs broad judgment across messy data, governance and exception handling matter more than the demo.

Both describe the same mechanic. An agent deployed onto an ambiguous process inherits the ambiguity and makes it visible at conversation volume. This is why a process stall presents as an agent problem and gets staffed as one.

The intervention is not engineering capacity. It is putting someone in the room who can settle what the process is, on the day the question arises, rather than routing it to a working group. That is a decision-authority problem, and it is the second thing an embedded senior engineer is actually buying you. Where the underlying issue is record quality rather than process, the prerequisite is agent-ready data and an org assessment ahead of the build, not alongside it.

Salesforce staged its own agent from 200 users, not from a launch date

The company with the most product access in the world did not big-bang its own deployment.

Salesforce launched Agentforce on its Help site as a pilot opened to just 200 authenticated users across a four-week period, expanded gradually after that, and reports the agent has since passed five million conversations, available around the clock in seven languages and now also reachable by phone. Salesforce Help receives over 60 million visits annually, and the support team still takes around two million support requests a year.

Two things follow for anyone planning a rollout.

A four-week window at 200 authenticated users is an evaluation design, not a soft launch. Authenticated means the agent had identity and entitlement context, and a bounded cohort means every failure could be inspected individually rather than inferred from a dashboard.

And the exit criterion was behavioral, not calendar-based. Expansion followed evidence. A plan that commits to a go-live date before it commits to an expansion threshold has inverted that order, which is a reliable way to reach production and stall immediately afterward. Setting the threshold belongs in the pilot plan rather than in a retrospective.

The measurement stall is the one nobody schedules

Return to the counters at the top, because they illustrate the fourth stall precisely.

Every component of that disagreement is legitimate. Someone who opens a chat and immediately requests a human has not been failed by the agent in any interesting sense, so excluding them yields 70.1 percent. Someone building a business case for deflection against total contact volume has an equally good reason to include them, which yields 64.7 percent. Neither party is wrong, and both can quote the same official page.

An agent that is live and unmeasured is stalled in a way that looks like success for roughly one quarter. It then fails its first board review, because the number someone quoted in month two and the number someone recomputes in month five do not match, and no definition exists to adjudicate between them.

The fix costs an hour and has to happen before launch: write down the numerator, the denominator, the exclusions and the review cadence, and get the person who will challenge the number to sign the definition rather than the result. Fixing the baseline and reporting method early is cheap. Reconstructing it after a figure is already in circulation is not.

This is also the stall where an embedded engineer helps least. Measurement definitions are a governance decision, and deciding who owns the agent after go-live is not something a delivery pod can resolve on the customer’s behalf.

The outcome evidence is vendor-sourced and circular by construction

This section exists because almost nothing else written on this topic has one.

Salesforce states that firms in its FDE Partner Network have driven one-third of all successful Agentforce implementations to date. Read the surrounding sentence and the difficulty is visible without any hostile reading: every member is described as a vetted partner selected for a proven track record of delivering Agentforce, and those selected-for-success firms are then credited with a third of the successes. The selection criterion and the outcome measure are nearly the same variable. No sample size, no time window and no definition of successful accompanies the figure.

The same announcement quotes IDC FutureScape that over one-third of organizations will be stuck in the experimental, point solution phase of AI experimentation, requiring a shift of focus to enterprise use cases to deliver ROI. That is a market forecast, not a measurement of FDE outcomes, and the underlying report is not public.

After a deliberate search, no independent study with a stated sample size compares embedded-engineer delivery against conventional systems integrator delivery on time to production, cost, or success rate. Every quantitative claim in this space traces back to the platform vendor.

One absence is sharper than any statistic, and it survives a careful reading of the primary document. Salesforce’s fourth quarter fiscal 2026 results, published 25 February 2026, disclose Agentforce in unusual detail: over 29,000 deals closed since launch and up 50 percent quarter over quarter, $800 million Agentforce annual recurring revenue up 169 percent year over year, 2.4 billion agentic work units delivered, nearly 20 trillion tokens consumed, 112 trillion records ingested by Data 360, and more than 60 percent of quarterly bookings coming from existing customer expansion.

In that same list sits the line a buyer actually needs: Agentforce accounts in production increased nearly 50 percent quarter over quarter. That is a growth rate. Across a disclosure set detailed enough to count tokens, the ratio of purchased Agentforce to deployed Agentforce is the one number not given. Deals are counted, production accounts are counted, and the two are never divided.

A second absence is worth naming. Across r/salesforce threads from February 2026 onward, practitioners discuss the FDE role as a career move rather than as something they received. First-hand accounts of being on the customer side of a Salesforce FDE engagement are absent from the public record.

None of that makes the model ineffective, and the design logic in the preceding sections stands on its own. It does mean a buyer should ask for a reference customer with a named blocker and a date, rather than for a statistic.

Diagnosis should precede the engagement, not follow it

GetGenerative.ai runs Salesforce delivery through pods in which a Forward Deployed Engineer leads and named agents handle the production work across Discover, Analyze, Design, Build, Test and Deploy. The Analyze stage exists to read the org and its metadata before design begins, which is the stage that separates the four stall types above from one another.

That ordering is the point worth borrowing regardless of who does the work. A defect stall, a process stall, a data stall and a measurement stall look identical from a status report and need entirely different people. Any engagement that begins by adding build capacity has skipped the only step that would have told it which problem it was solving.

Teams whose Agentforce rollout has stopped moving can meet our Forward Deployed Engineers and start with that diagnosis rather than with a statement of work.

Five questions to ask before accepting any FDE engagement

Each maps to something established above rather than to general good practice.

Question	Why it matters	Weak answer
Which of the four stalls is ours?	The interventions do not substitute for each other	A delivery plan with no blocker named
What escalation path do you hold that we do not?	Defect stalls are cleared by routing, not effort	Standard support channels
Who can settle a process question in the room?	Process stalls are decision-authority problems	A weekly steering committee
What is the expansion threshold, in numbers?	Salesforce expanded its own agent on evidence	A go-live date
What is the denominator, agreed in writing?	Three defensible rates exist for one dataset	A resolution rate with no definition

Recap. Salesforce’s published agent telemetry supports three different resolution rates from one week of data, which is what an unsettled measurement definition looks like in public. Agentforce rollouts stall on platform defects, process ambiguity, data resolution or measurement. Embedded engineers accelerate the first by routing around support queues, help materially with the second and third, and cannot resolve the fourth for you. No independent evidence compares the model to conventional delivery, and the one vendor statistic available is circular by construction.

Key facts

Fact	Value	Source and date
Salesforce Help agent, week of 23 August 2026	53,691 resolved of 83,044 handled	Salesforce Customer Zero page
Resolution rate, same week	70.1 percent or 64.7 percent depending on denominator; page prose says over 63 percent	Derived from Customer Zero counters
Salesforce Help agent pilot scope	200 authenticated users across a four-week period	Salesforce Customer Zero page
Salesforce Help agent scale to date	Over five million conversations, seven languages	Salesforce Customer Zero page
Published FDE rescue elapsed time	All issues resolved within a week, after Data 360 knowledge sync failures	Salesforce blog, 19 November 2025
FDE Partner Network share claim	One-third of all successful Agentforce implementations, no sample or definition given	Salesforce newsroom, 15 April 2026
Agentforce accounts in production	Increased nearly 50 percent quarter over quarter, a growth rate not a conversion rate	Salesforce investor results, 25 February 2026
Independent FDE outcome evidence	None located	Verified absence, September 2026

FAQ

How do Forward Deployed Engineers speed up an Agentforce deployment?

Embedded engineers compress the interval between finding a blocker and holding authority to clear it. In Salesforce’s published example, a stalled pilot whose knowledge articles were not syncing to Data 360 was resolved within a week because the FDE team enlisted product engineers directly rather than routing through support escalation.

Why has our Agentforce agent gone live but stopped delivering value?

Four stalls produce that pattern. A platform defect blocks a specific path, process ambiguity reopens scope at every review, data resolution failures misfire on real records, or nobody agreed a measurement definition before launch. The last one looks like success for roughly one quarter.

What is a realistic Agentforce rollout sequence?

Salesforce piloted its own Help agent with 200 authenticated users across four weeks, then expanded gradually on evidence rather than to a calendar. A bounded authenticated cohort allows individual failure inspection, and an expansion threshold set in advance prevents reaching production and stalling immediately afterward.

Does an FDE fix Agentforce measurement problems?

No. Measurement definitions are governance decisions covering numerator, denominator, exclusions and review cadence, and a delivery pod cannot settle them on a customer’s behalf. Salesforce’s own published counters support three defensible resolution rates for a single week of data, which shows the ambiguity survives even careful public reporting.

Is there proof the FDE model beats traditional Salesforce delivery?

No independent study with a stated sample size makes that comparison. Salesforce states FDE Partner Network firms drove one-third of successful Agentforce implementations, but those firms were selected for proven Agentforce track records, so the selection criterion and the outcome measure are nearly the same variable.

What blocks Agentforce deployments most often?

Practitioners point to undocumented processes and inconsistent data rather than product limitations, observing that agents expose existing problems rather than solve them. Narrow workflows with clear inputs, clear permissions and a defined handoff point reach production; broad judgment across messy data does not.

Salesforce AI Research ran the experiment that settles most of this argument, and published the numbers.

The team built CRMArena-Pro, a benchmark that drops LLM agents into a realistic Salesforce environment and scores them on expert-validated tasks across sales, service and configure-price-quote processes. Leading agents reached roughly 58 percent single-turn success. Across multi-turn conversations, success fell to roughly 35 percent.

Read that with one qualification attached: Salesforce publishes the benchmark and Salesforce sells the alternative. The score is the least interesting output. The error analysis is the part worth your time, because Salesforce’s researchers went further and asked what happens to the same model when the missing context is supplied. That result is the actual answer to the question in this title, and it points somewhere most comparisons never look.

A purpose-built Salesforce agent is an AI system constrained to a defined body of Salesforce knowledge, connected to a specific org or project, and shipped to produce a named delivery artifact. A general assistant is an open-domain model that answers whatever is typed into it. Both now reach a Salesforce org. Only one is accountable for what comes out.

Nine flagship models were scored, and none cleared sixty percent

The published detail is specific enough to act on. Writing on the Salesforce AI Research blog in August 2025, Caiming Xiong and colleagues reported completion rates across nine flagship models from different providers using a standard ReAct agent framework.

GPT-4o solved fewer than 30 percent of tasks. Its reasoning counterpart, o1, still failed at just over 50 percent. The strongest performer, Gemini-2.5-pro, did not reach a 60 percent completion rate.

One discrepancy is worth noting, since this page asks you to trust these numbers. The paper describes nineteen expert-validated tasks. The blog describes 22 tasks and 2,140 task instances spanning workflow execution, policy compliance and information retrieval. The task count moved between publications; the model results below come from the blog.

One further finding from the paper deserves separate attention, because it has nothing to do with accuracy. Agents showed near-zero inherent confidentiality awareness. Prompting can improve that, the authors note, but doing so often degrades task performance. Confidentiality and competence traded against each other.

Workflow execution was the bright spot at over 83 percent single-turn success. Following a defined procedure is the thing these models do well. Deciding which procedure applies is not.

Four named causes explain where a general model breaks on Salesforce

Rather than reporting a score and stopping, the Salesforce team analyzed the failures and named four causes. Each one maps onto work a consultant does every week.

Query syntax limitations. SOQL and SOSL resemble SQL closely enough to mislead a model and differ enough to break it. Agents produced queries with illegal syntax. Some errors were self-corrected after an error message. For others, the attempted correction introduced further mistakes.

Data model confusion. This is the finding that matters most for delivery work. Agents confused related concepts, the researchers write, such as an order item against a pricebook entry, or a lead against an opportunity, and consequently looked up information in the wrong table. Nothing about that failure announces itself. A query against the wrong object returns rows, not an error.

Ambiguity in underspecified tasks. Given a task containing a real ambiguity, agents picked an interpretation and proceeded rather than flagging that a decision was needed. The example given is whether a transferred case counts toward the first representative, the second, both or neither when calculating average handling time. A consultant treats that as a question for the client. The model treated it as an assumption.

Unfamiliarity with business workflow. Even with the schema and the task understood, agents chose the wrong mechanism, using SOQL where SOSL was the correct tool, producing long and inefficient executions.

Three of those four are context failures rather than reasoning failures. That distinction sets up the experiment that follows.

Grounding moved the same model from 31 percent to 72 percent

Having established the baseline, the researchers tested what actually closes the gap. They isolated a set of query and computation tasks, studied five of them closely, and held three back as unseen tasks to test whether improvements generalized.

The ladder they published:

What the agent was given	Accuracy on unseen tasks
Raw SOQL and SOSL access only	31 percent
Function headers for task-specific functions	31 percent
Function headers plus generated subroutine headers	32 percent
Full source implementation of those functions	48 percent
Full source of the same functions, refactored with bugs	34 percent
A non-technical description of the workflow	54 percent
A technical description of the workflow	72 percent

Same model. Same tasks. The difference between the first row and the last is 41 percentage points, and the variable is context.

Three details in that table carry the argument. Handing the agent function headers changed nothing, because a header describes what a function does without describing how. Handing it a written workflow, prose that any competent administrator could produce without touching a query language, more than doubled accuracy. The researchers’ own summary is that telling agents how to perform a task, rather than what task to perform, makes a significant difference.

The third detail is the one nobody quotes. When the researchers supplied the same functions after a refactor that introduced bugs, and the agent treated that code as the source of truth, accuracy fell from 48 percent to 34 percent. Wrong context is worse than thin context. A grounded tool pointed at a stale document or a misread org does not degrade politely toward the baseline; it argues confidently from bad evidence.

That is the whole case for purpose-built tooling, stated by the platform vendor’s research team. The advantage does not come from a better model. It comes from what surrounds the model at the moment of the request.

ChatGPT reaches a Salesforce org through three doors in 2026

Most published comparisons on this topic are two years old and argue that ChatGPT cannot touch a Salesforce org. That argument expired. Three routes exist today, and they differ in ways that determine what you can safely do.

The Agentforce Sales app in ChatGPT. Salesforce shipped this into open beta on 17 December 2025. It requires the Agentforce for Sales Add-on or Agentforce 1 Edition, so the gate is a Salesforce license rather than a ChatGPT plan. OpenAI’s own listing describes it as connecting CRM context to review accounts, opportunities, contacts and activity. Records, for sellers.

Salesforce Hosted MCP Servers. Announced generally available on 29 April 2026, with an edition floor at Enterprise and above. Salesforce publishes a tested-client table that names ChatGPT explicitly, supported via developer mode and connectors. Setup runs through an External Client App with OAuth 2.0 and PKCE. Connected Apps are not supported, and Salesforce states plainly that there are no service accounts, no machine-to-machine flows and no autonomous operation outside a user context.

The API. Available to anyone willing to build and maintain the integration.

The plan gating on route two is worth knowing before anyone plans around it. OpenAI documents full MCP support, including write actions, as a beta on ChatGPT Business, Enterprise and Edu plans. Pro users, in OpenAI’s wording, can connect MCPs with read and fetch permissions in developer mode. Agent mode will not use custom apps at all, and deep research can use them for read and fetch actions only. MCP apps are web only, with no mobile support.

Plus is absent from every tier list in that documentation, which is worth stating as an absence rather than a prohibition. The practical consequence stands either way: the consultant paying personally for a subscription and the enterprise buying seats are not holding the same product, and a workflow demonstrated on one may not exist on the other.

Hosted MCP servers expose records and schema, not org logic

Connectivity settled, the real boundary becomes visible, and it sits exactly where the tracker relationship for this page predicts.

The standard SObject servers ship 11 tools. The one that matters here is getObjectSchema, which Salesforce documents as returning full field schema with types, required flags, picklist values, relationships and any admin-authored guidance. That is real metadata, and it is more than a general model would otherwise have.

Two things in that tool’s documentation reward a close reading. Salesforce describes the output as schema information optimized for LLM consumption, deliberately smaller than the raw Describe API, because the real thing is too large to hand over. And the admin-authored guidance field exists so a human can correct the schema’s implications, with Salesforce’s own worked example being an instruction to use Calculated_ACV__c instead of Amount for accurate forecasting. Field names alone do not tell a model which field the business actually trusts. Salesforce built a channel for a person to say so.

Note what the list does not contain. Apex class source. Flow definitions and their branching logic. Validation rule formulas. Permission set definitions. Page layouts and record types. Sharing rules. An assistant connected this way can tell you that a field exists and what values it accepts. It cannot tell you which flow writes to that field, which validation rule blocks the write, or which profile can see it.

Those are the questions a solution design answers. A tool that cannot read org logic cannot produce a solution design document that survives review.

One exception exists and it is new. The Headless 360 MCP Server, documented as a beta service available starting in July 2026, reaches considerably further through four generic tools, covering permission set assignment, Apex trigger read and write, and named credential creation. It is beta, it is disabled by default, and an administrator has to deliberately switch it on. Treat its capabilities as a roadmap signal rather than a current baseline, and read the guardrails question before enabling anything that writes.

Published constraints apply throughout. The SOQL tool caps at 50,000 records per transaction. The search tool returns a maximum of 2,000. Deleted records reach the Recycle Bin and stay recoverable in the UI for 15 days, and Salesforce notes that no undelete tool is available through MCP.

One control cuts the other way and deserves equal billing, because it is the strongest argument for connecting properly rather than pasting. Salesforce states that even with every tool enabled, each operation remains constrained by the authenticated user’s field-level security, object permissions and sharing rules: an agent cannot update a field the user cannot edit in Lightning, and cannot delete a record the user cannot delete in the UI. A governed connection inherits your security model. A copy-paste into a chat window inherits nothing.

Salesforce ships three times a year and a training cutoff does not

Salesforce maintains a public list of past product and feature retirements, and reading it by date shows the rate of change a training corpus has to keep up with. Six entries land between February and June 2026 alone: Data Detect end of support on 2 February, Chat and Live Agent on 14 February, the Classic Knowledge Data Model on 1 March, Legacy Agentforce Analytics on 31 May, the Optimizer App on 1 June, and Standard Omni-Channel in Summer ’26.

Workflow Rules and Process Builder sit just above them, with end of support dated 31 December 2025. The knowledge article is unambiguous about what that does and does not mean: active rules and processes continue to run as they do today, and the only change is that Salesforce no longer provides customer support or bug fixes. A model trained on the vast pre-2025 corpus discussing both will still offer them as live options, and the half-truth is more dangerous than a clean error, because the automations really do still run.

The sharpest example runs the other direction, and it is the one to test any assistant with. Salesforce announced the retirement of permissions in profiles, scheduled enforcement for Spring ’26, and then reversed itself. Knowledge article 003834041, published 6 June 2026 and titled “Permissions in Profiles Retirement Cancelled,” states that the enforcement was cancelled based on customer feedback and remaining feature gaps, while still recommending a permission-set-led security model.

A model trained after the announcement and before the reversal will tell you profile permissions are going away. A model trained before the announcement will tell you nothing is changing. Both answers are wrong, both will be delivered with the same confidence, and an administrator acting on the first one would have spent a quarter migrating against a deadline that no longer exists.

None of this is a defect in the model. A general assistant is trained on a corpus with a date on it, and Salesforce ships three seasonal releases a year plus continuous change outside them.

The Einstein Trust Layer covers Agentforce, not a browser tab

Compliance is where this comparison stops being a preference and starts being a policy question, and the documentation is unusually clear.

Salesforce Help carries an explicit scope note on the Einstein Trust Layer: its capabilities apply only to generative AI and Agentforce features. Every control in that architecture, dynamic grounding, data masking, prompt defense, zero data retention with external model providers, audit trail, sits on the prompt path inside the Salesforce trust boundary.

A consultant pasting an org’s field list, a validation rule set or a sample of production records into a public chat window never enters that path. Salesforce publishes no statement addressing that scenario directly, so read the conclusion as an inference from the documented architecture rather than as a Salesforce position. The inference is not a close call.

An enterprise architect posting to r/salesforce in May 2026 put the practical version of this better than any vendor page manages. Placing the tool in the middle of the pipeline, they wrote, puts you in scope for the compliance standards those organizations need to meet, naming SOX and ISO 27001, and even setting compliance aside, the architecture means the data passes through where it can be watched. Larger customers, they added, will be skeptical.

Set that alongside the near-zero confidentiality awareness finding from CRMArena-Pro and the shape of the risk is clear. The model will not decline to repeat something sensitive, and prompting it to be careful measurably reduces how well it does the work.

Purpose-built delivery agents produce the artifact, not the answer

The category difference is easy to state once the evidence is assembled. A general assistant returns an answer to whatever was asked. A purpose-built delivery agent is built to return a specific deliverable, in a reviewable format, against a project that persists between sessions.

That difference shows up in the commercial model. GetGenerative.ai prices a Pro plan at US$200 per month billed annually, bundling 10,000 platform credits, unlimited access to its agents, an admin dashboard with usage statistics and the ability to add team members. Credits are consumed per deliverable: an initial generation draws 5 credits, a full regeneration draws 5, and a point regeneration, revising one element without rebuilding the whole artifact, draws 5. A seven-day free trial covers up to three deliverables with no card required.

Point regeneration is the mechanic that reveals the design intent. Editing one acceptance criterion without discarding the surrounding document is a document operation, not a chat operation. Chat has no equivalent, because a conversation has no addressable parts.

Two consequences follow for anyone comparing the two on price. A general assistant subscription is billed per person per month regardless of output, which makes it cheap when lightly used and unchanged when heavily used. A credit model is billed per artifact, which makes the cost of a project estimable in advance and the cost of indecision visible. Those are different instruments, and a like-for-like price comparison between them is not meaningful.

The honest limit on the purpose-built side is that constraint is only worth paying for where the work is repeatable. Drafting user stories and acceptance criteria, producing configuration specifications, generating test strategy and scripts, keeping documentation current as the org changes: these have a defined shape, a reviewer and a next step. Open-ended thinking does not, and a general assistant handles it well.

Choose by task class, not by subscription

The useful decision is per task, and it turns on one question: does a wrong answer announce itself?

Task	Wrong answer is	Better fit
Explaining a Salesforce concept you will verify anyway	Obvious on contact with docs	General assistant
Drafting a client email or a meeting summary	Obvious on reading	General assistant
Brainstorming solution options before design	Obvious in discussion	General assistant
Writing SOQL against an unfamiliar object model	Silent, returns rows from the wrong table	Purpose-built, grounded in schema
Producing user stories from workshop notes	Silent until UAT	Purpose-built, project-scoped
Citing a governor limit, retirement date or release behavior	Silent, stated with confidence	Purpose-built, grounded in current docs
Anything touching production data or metadata	Potentially unrecoverable	Neither, without a governed connection

The pattern is consistent with what the benchmark found. Where the work has a documented right answer that a reader cannot check by eye, context decides the outcome, and a general assistant has none by default. Where judgment and language dominate, the general assistant is a reasonable tool.

A related warning applies to the code path specifically, which sits outside this page’s scope but inside the same decision: AI coding tools and Salesforce delivery agents fail differently again, and generated Apex that works against sandbox volumes has a habit of meeting governor limits against real ones. Anything generated against an org you have not assessed compounds whatever technical debt is already there.

Recap. Salesforce’s own researchers scored general models below 60 percent on realistic CRM tasks and named four causes, three of them context failures. Supplying context moved the same model from 31 percent to 72 percent. ChatGPT can now reach an org through three routes, but the standard route returns records and schema, never org logic. Choose per task, by whether a wrong answer would be visible.

Consultants evaluating the purpose-built side can start with the Pro plan for consultants and measure it on one real deliverable rather than on a demo. For a wider view of the category, the full platform comparison covers what else is available.

Key facts

Fact	Value	Source and date
Leading agent success on CRMArena-Pro	~58 percent single-turn, ~35 percent multi-turn	CRMArena-Pro, Salesforce AI Research, May 2025
GPT-4o completion rate	Fewer than 30 percent of tasks	Salesforce AI Research blog, August 2025
Best of nine flagship models	Gemini-2.5-pro, below 60 percent	Salesforce AI Research blog, August 2025
Effect of a technical workflow description	31 percent to 72 percent on unseen tasks	Salesforce AI Research blog, August 2025
Confidentiality awareness	Near-zero; prompting improves it but degrades task performance	CRMArena-Pro, May 2025
Salesforce Hosted MCP Servers GA	29 April 2026, Enterprise Edition and above	Salesforce Developers
Full MCP in ChatGPT	Beta on Business, Enterprise and Edu; Pro is read and fetch only	OpenAI Help Center
Salesforce features retired February to June 2026	Six, including Workflow Rules and Process Builder end of support on 31 December 2025	Salesforce Past Product and Feature Retirements
Permissions in profiles retirement	Cancelled 6 June 2026	Salesforce Help, article 003834041
GetGenerative.ai Pro plan	US$200 per month billed annually, 10,000 credits	GetGenerative.ai pricing, September 2026

FAQ

Can ChatGPT connect to Salesforce in 2026?

Yes, through three routes. The Agentforce Sales app in ChatGPT entered open beta on 17 December 2025 and requires an Agentforce sales license. Salesforce Hosted MCP Servers reached general availability on 29 April 2026 and list ChatGPT as a tested client via developer mode. Direct API integration remains available.

Can ChatGPT read Salesforce metadata?

Partially. The standard SObject MCP tools return object and field schema including types, required flags, picklist values and relationships. Apex source, Flow logic, validation rule formulas and permission set definitions are not exposed by those tools. A July 2026 beta server reaches further but must be enabled deliberately.

Is ChatGPT accurate enough for Salesforce work?

Salesforce AI Research scored nine flagship models on realistic CRM tasks. GPT-4o completed under 30 percent and the strongest model stayed below 60 percent. Supplying a written workflow raised one model from 31 to 72 percent on unseen tasks, which indicates the constraint is context rather than capability.

Does the Einstein Trust Layer protect data pasted into ChatGPT?

No. Salesforce documents that Einstein Trust Layer capabilities apply only to generative AI and Agentforce features. Its controls, including data masking and zero data retention with model providers, operate on prompts inside the Salesforce trust boundary. Content pasted into a public chat interface never enters that path.

What does a purpose-built Salesforce AI agent do differently?

A purpose-built agent is scoped to Salesforce knowledge, connected to a specific project, and built to return a named deliverable such as a user story set or a configuration specification. Output arrives as a reviewable artifact with addressable parts rather than as conversation text.

Should Salesforce consultants stop using ChatGPT?

No. Divide work by whether a wrong answer is visible. Explanations, drafting and option generation are checkable on reading and suit a general assistant. Queries against an unfamiliar object model, cited limits, retirement dates and release behavior fail silently and need a grounded tool.

Search this question on Google today and the first organic result is titled “Why 70% of Salesforce Implementations Fail.” The number appears in vendor decks, in agency blog posts, and in at least one widely cited book on the industry. It also travels with a quiet substitution: the research it comes from measured CRM projects generally, never Salesforce specifically.

That number was traced to its origin in 2009 by industry analyst Michael Krigsman, who could not find the source document. He asked Butler Group, the research firm credited with it. Butler Group’s own Senior Research Manager, Maxine Holt, searched for the report and could not find it either. Her emailed explanation was that the figure was probably “quoted by one of our analysts in discussions with the press and that’s how it has been circulated.” Krigsman published that admission in his compilation of CRM failure rates from 2001 to 2009 and then accepted the number anyway, on the grounds that Microsoft’s marketing materials quoted it and a respected author had printed it in a book.

So the most repeated statistic in enterprise CRM entered circulation as a remark to a journalist, was laundered into vendor marketing, was laundered again into a published book, and is now the thing your Google search returns. Nobody has produced the study.

This page does two things. It establishes what the evidence on Salesforce implementation failure actually supports. It then sets out nine causes that recur in verifiable practitioner accounts, with a specific diagnostic test and a fix for each one.

Salesforce implementation failure is the condition where a deployed Salesforce org does not produce the business result that justified its purchase. Absolute failure, meaning a project that is scrapped or delivers no financial return, is rare. Partial failure, meaning a live org that underdelivers against its business case, is common, and it is what most people are describing when they use the word failure.

Gartner’s 2001 survey asked about expectations, not about failure

The Gartner number that seeded the whole genre is real, and the analyst who ran the study explained exactly what it measured. Ed Thompson, then Gartner’s Vice President and CRM Research Director, gave a full accounting in a 2004 interview with CustomerThink that remains free to read.

Gartner surveyed roughly 500 organizations across the US and Europe at the end of 2001. The question was not whether the project failed. The question was whether the project met expectations. Fifty-five percent said it did not. Thompson’s description of what happened next is direct: people “took our statement, ‘failed to meet expectations,’ and they chopped the ‘meet expectations’ off it and just said, ‘failure.'”

The survey used a five-point scale, and the distribution matters more than the headline:

Response band	Share of respondents
Absolute success	around 5 percent
Met expectations, somewhat a success	around 40 percent
Somewhat successful but failed to meet expectations	around 40 percent
Failed to meet expectations, somewhat unsuccessful	around 10 percent
Absolute failure	around 5 percent

Forty-five percent checked the top two boxes. Fifty-five percent checked the other three. The largest single group sat in the middle, and Thompson explained what those respondents meant by quoting their own written answers: “We aimed to get a payback in 24 months, and we didn’t, but we have increased sales by XYZ.”

Asked directly whether he agreed that 55 percent of CRM projects had failed, Thompson said no. His estimate of absolute failure was “5 percent, maybe,” with perhaps another 10 percent if the next band up were included. He cited an IBM study from the same period landing in the same range.

Three further details disqualify the number as a general failure rate. The sample consisted of Gartner clients, all large organizations with large projects, and Thompson noted that smaller projects performed considerably better. The 65 percent figure that also circulates was never a measurement at all: it was a Gartner Strategic Planning Assumption published in late 2001 forecasting that the expectations gap would widen, and Gartner never repeated the study to check. The separate Gartner claim of 50 percent was likewise a forward-looking statement about how implementations would be viewed through 2006.

AMR Research produced the only clean failure number in the record

One entry in Krigsman’s compilation defines its terms. AMR Research measured the share of respondents who experienced an implementation failure that prevented them from going live, and published three consecutive years: 18 percent in 2005, 31 percent in 2006, 29 percent in 2007.

Those figures describe hard failure with a stated definition, and they land between a quarter and a third, not at seventy percent. Every other entry in the compilation measures something different. The Economist Intelligence Unit’s 56 percent in 2007 counted respondents reporting acceptable-only or disappointing results. Forrester’s 47 percent in 2009 counted projects that fully met expectations. Selling Power’s 69.3 percent has no methodology attached.

No study published since 2020 measures Salesforce implementation failure with a stated sample size, a stated definition and a public methodology. The Standish Group’s CHAOS research sits behind a $450 paywall with no published sample. Consultancy surveys quoting a current failure percentage do not disclose how many organizations were asked. A reader who cannot open the evidence cannot evaluate the claim, so this page does not cite those figures.

That gap is the practical point. Benchmarking your project against a fabricated industry failure rate tells you nothing. Diagnosing your project against specific, observable causes tells you where the money is going.

Nine causes account for most Salesforce implementation failures

The nine causes below come from three kinds of verifiable evidence: the failure factors Gartner’s own research identified as hardest, measured software utilization data, and detailed first-person accounts posted by practitioners to r/salesforce in 2026. Each cause carries a test that produces a yes or no answer in under an hour.

#	Cause	Fastest test
1	CRM bought for a non-CRM problem	Name the constraint the business is actually hitting
2	Success never converted into a number	Ask three executives for the target metric separately
3	Requirements set by change-resistant staff	Trace each hard requirement to a business outcome
4	Decision authority nobody can evaluate	Name who can tell the implementer no, and why
5	Data model collapsed into one object	Count custom fields on your largest object
6	Duplicates outrunning the merge queue	Count records created today with a blank source
7	Architecture work assigned to administrators	Ask who approved the object model
8	Licenses bought, assigned, never opened	Pull last-login dates across all assigned licenses
9	Vendor dashboard trusted without audit	Manually review 100 scored interactions

Four causes originate before anyone opens a sandbox

The tracker relationship for this page reads: failed discovery precedes failed delivery. Gartner’s research supports it from an unexpected direction. When Thompson’s team repeatedly asked organizations what they found difficult about CRM, the technology implementation ranked as the second easiest task. The hardest was metrics, followed by process definition, followed by people. Building the thing was never the problem.

Cause 1: The business bought CRM to fix a problem CRM does not touch

A first-person account posted to r/salesforce in June 2026 documents this in unusual detail. An accidental administrator at a metal fabrication plant migrated the company from ACT! to Salesforce, spent three months building, and watched the org get shut down a few months after it became usable. Total cost, counting licenses, consulting, salaries and lost time, exceeded $200,000 for no benefit.

The diagnosis in the post is one sentence: “The company was supply-constrained and couldn’t make more sales. They didn’t really need a CRM; they needed an ERP.”

A CRM improves how an organization finds, converts and serves demand. A supply-constrained business has more demand than it can fulfil. Better pipeline visibility changes nothing about the bottleneck.

The test. Write down the constraint limiting revenue right now, in one sentence, without using the word Salesforce. If the constraint is capacity, cost of goods, hiring, or regulatory approval, a CRM implementation will not move it.

The fix. Build a business case a CFO will sign before selecting a platform, and make it name the constraint and the mechanism. A business case that cannot explain the mechanism is a purchase justification, not a business case.

Cause 2: Success never got converted into a number anyone could check

Metrics ranked as the single hardest CRM discipline in Gartner’s repeated surveys, and Thompson’s explanation of why is worth restating. Organizations set objectives at a level of abstraction that cannot be measured. Improve customer retention, for example, leaves open whether retention means the household, the product, the customer, or the customer’s family. When the discussion gets specific, in Thompson’s words, “all hell breaks loose.”

The consequence is that success and failure become unanswerable. Thompson’s conclusion was that many organizations do not know whether their CRM worked, because nobody was granular enough about the objective to check afterwards.

The test. Ask three executives, separately and in writing, what number this implementation is supposed to move and by how much. Three different answers, or three vague answers, is a finding.

The fix. Set a baseline before the build starts, not after. Measure the metric in the current system for a full cycle, record it, and agree the target in the same document. Baselines that survive an audit are cheap to capture beforehand and impossible to reconstruct later.

Cause 3: The hardest requirement came from the person most afraid of the change

The $200,000 account names this precisely. The finance function consisted of two long-tenured bookkeepers who had used nothing but QuickBooks Desktop across a combined seventy years. Fearing for their job security, they lobbied for and won a hard requirement that Salesforce integrate with QuickBooks Desktop, a locally installed application with no native cloud interface. The author’s parenthetical advice to future implementers is unambiguous.

Requirements produced by change anxiety share a signature. They preserve an existing tool, an existing file format, or an existing manual step, and they are defended on grounds of necessity rather than outcome.

The test. For each requirement classified as mandatory, ask what business outcome breaks if it is dropped. A requirement whose only justification is that the current process works that way is a preference wearing a costume.

The fix. Separate requirements from constraints in the discovery record, and make each constraint carry a named owner and a stated reason. A discovery process that produces written decisions surfaces these before they reach a statement of work, where removing them costs a change order.

Cause 4: Decision authority sat with a person nobody could evaluate

An employee posted to r/salesforce in March 2026 seeking help with an org they could see was broken and could not get anyone to act on. One sentence in that thread explains more Salesforce failures than any statistic does. Describing the external consultant who designed the org, the employee writes: “he can tell our leadership anything and they don’t know any better.”

The surrounding facts complete the picture. The consultant discouraged the company from hiring anyone internal. He had previously held an entry-level, non-technical role at the same company. Leadership offered no pushback on any design decision. One commenter concluded that the consultant’s position “cannot be based on ability” and guessed at a personal relationship with leadership, a guess several others in the thread shared.

The $200,000 account describes the same vacuum from the opposite side: “Our leadership had minimal interest or knowledge about software. We had no end-state goal for what our org would look like. With limited executive buy-in, I was sent off on my own to Salesforceify things.”

Unchecked authority is the condition that lets the other eight causes run unopposed. Someone proposes a single object for everything, or a QuickBooks Desktop integration, and no one in the room can say why that is wrong.

The test. Name the person who can tell the implementer no, and state what qualifies them to do it. If the only people capable of evaluating the design are the same people producing it, no check exists. Salesforce publishes a public credential verification tool, and an implementer’s certifications can be confirmed by email address in under a minute.

The fix. Record decision rights before requirements gathering starts, and separate the approver from the builder. Who owns which decision belongs in a written matrix agreed at kickoff. Organizations without internal Salesforce depth should buy one independent design review from a second party, which costs a fraction of the rebuild it prevents.

Three causes originate inside the build

Gartner’s finding that technology implementation ranks as the second easiest CRM task holds for standard configuration. It does not hold once an org departs from the standard model, because every departure compounds.

Cause 5: The data model collapsed into a single object

The same March 2026 thread describes what that unchecked authority built. One custom object held everything. Leads went on it. Applicants went on it. Accepted applicants went on it. The object carried over 250 fields, and the consultant’s proposed remedy for a new lead process was another dropdown feeding a second dropdown. He was also reluctant to use the standard Lead object.

One responder described the design as what “a lazy person would do in order to centralize information and simplify automations.” Another commenter in the same thread reported a parallel outcome from different advice: told the company would never need Opportunities, the organization was by then paying to rebuild its process to include them.

Single-object designs fail in a specific way. Record types and page layouts multiply to simulate separation. Validation rules acquire conditions for states that belong to other entities. Reporting collapses because a single stage field carries seven lead stages and ten applicant stages side by side, which is exactly what the thread describes. Every one of those is a technical debt warning sign that compounds rather than stabilizes.

The test. Count custom fields on your largest object, then count how many are populated on fewer than a quarter of records. A high count of sparsely populated fields on one object means distinct entities were merged.

The fix. Model entities separately and use the standard objects Salesforce ships. Lead conversion, duplicate management, forecasting and the sharing model all assume the standard structure, and a custom replacement forfeits the features without removing the requirement for them.

Cause 6: Duplicate records outran the person merging them

The same March 2026 thread documents the downstream effect. Leads arrived without an identifiable source, previously known contacts re-entered as new leads, and one employee merged duplicates every morning so that a newly onboarded call center handling roughly 3,000 leads every one to two months would not work from a corrupted list. Told that learning to merge duplicates required four hours of training, the employee was instructed to stop.

Duplicate volume is a leading indicator, not a maintenance annoyance. Duplicates arriving faster than anyone can merge them means record creation is happening through an uncontrolled path, and every downstream count, from pipeline to attribution to call center productivity, is wrong by an unknown amount.

The test. Count records created in the last 24 hours with a blank or default source field. Divide by total records created. Anything above a few percent means an unmanaged intake route exists.

The fix. Configure matching rules and duplicate rules before opening the intake channel, not after. Salesforce ships both natively, and both are configuration rather than development.

Cause 7: The staffing plan assigned architecture work to an administrator

The most useful reply in the $200,000 thread describes the standard commercial sequence. A company approaches a partner sounding as though requirements are settled. The partner scopes accordingly and staffs the project with administrators. The project starts failing. Architects and project managers are then brought in to diagnose, and the diagnosis is that the requirements were wrong at the start.

The author of the original post reaches the same conclusion about his own case. Handed a functioning org, his administrator skills would have been sufficient to maintain it. Handed a business, they were not, because the work required was deciding what should be built.

Administrator certification measures platform mechanics. Object modeling, integration design and sharing architecture are separate disciplines with their own failure modes, and Trailhead badges do not confer them. A second commenter on the thread made the related point that business analysis, not configuration, was the missing function.

The test. Ask who approved the object model and the sharing model, by name and by role. An answer that names only administrators, or names nobody, identifies the gap.

The fix. Separate the decision role from the build role in the staffing plan, whichever delivery model the organization chooses. The cost of an architecture review before the build is a fraction of the cost of the rebuild it prevents.

Two causes surface only after go-live

A live org conceals both of the following indefinitely, because both produce clean-looking reports.

Cause 8: Licenses were bought, assigned, and never opened

No public benchmark measures Salesforce license utilization specifically. The figures circulating online come from vendors selling license optimization services, without stated samples or methods, so this page does not use them.

Cross-portfolio measurement does exist. Zylo’s 2026 SaaS Management Index, built from observed telemetry across more than 40 million managed licenses rather than from a survey, reports that license utilization rose from 47 percent in 2024 to 54 percent in 2025, a 13 percent relative improvement. The same dataset puts average license waste per organization at $19.8 million, down from $20.9 million. Nearly half of purchased software licenses across the average enterprise portfolio remain unused after the improvement.

Two related findings from the same index describe how the money escapes. Seventy-eight percent of IT leaders reported unexpected charges tied to consumption-based or AI features in the past year, and 61 percent were forced to cut projects because of unplanned software cost increases. An implementation that quietly funds unused seats is competing for budget with the next phase of its own roadmap.

The test. Export last-login date for every user with an assigned license. Count users whose last login predates the current quarter. That count, multiplied by your per-seat cost, is an annual number you can hand to finance today.

The fix. Treat non-login as an adoption defect with an owner and a due date rather than as a licensing question. A 90-day adoption plan works on the reason for the absence, and reclaiming the seat only helps once the reason is known.

Cause 9: The vendor dashboard scored the agent, and the audit disagreed

The clearest documented example of measurement failure in the current Salesforce ecosystem was posted to r/salesforce in April 2026. A practitioner reported a 30 percent case deflection rate shown in the standard dashboard, a figure that “really impressed people.” The team then ran a manual review of nearly 700 agent conversations, tagging each one in a spreadsheet.

The audited deflection rate was 2 percent.

The explanation given is mechanical. The dashboard counted a case as deflected whenever the agent answered from knowledge first, including cases where the answer was wrong or insufficient and the customer then asked for a case or a live agent. Having answered first, the system scored itself as successful and disregarded what happened next.

A fifteenfold gap between a reported metric and an audited one is not a rounding problem. It is a definition problem, and definition problems survive every review that reads the dashboard instead of the underlying records.

The test. Take 100 interactions the system scored as successful. Read them. Count how many a reasonable person would agree with.

The fix. Audit any success metric manually once before it enters a board pack, and write down the definition the system is using. Vendor-supplied metrics measure vendor-defined events, which is not the same thing as measuring the business outcome.

Diagnosis follows a fixed order, and the order saves money

Fixing causes out of sequence wastes the fix. An org with a collapsed data model and no agreed success metric gains nothing from a data model rebuild, because the rebuild has no target to aim at and no way to prove it worked.

Work the nine causes in three passes. Settle the purpose questions first: the constraint, the number, the requirements and the decision rights. Those four are cheap to answer and they invalidate the others if left open. Move to structure second: the data model, the intake paths and the architecture ownership. Take measurement last, because measurement only means something once the first two passes have defined what is being measured.

Organizations already live on the platform can start with an org health check, which produces the field counts, login data and automation inventory that causes 5 through 8 need as inputs.

Recap. The 70 percent failure statistic has no source document, and the firm credited with it could not find one. Gartner’s 55 percent measured unmet expectations, not failure, among large clients in 2001. Absolute failure ran near 5 percent. Nine specific causes, each with a one-hour test, explain far more than any industry percentage does.

Teams rebuilding an implementation that went wrong the first time can work through the diagnosis with the AI-native delivery team at GetGenerative.ai, which begins by analyzing what the org already contains rather than by restating requirements.

Key facts

Fact	Value	Source and date
Gartner CRM study sample	Roughly 500 organizations, US and Europe, Gartner clients only	Ed Thompson, Gartner, via CustomerThink, 2004
Question actually asked	Did the project meet expectations	Ed Thompson, Gartner, via CustomerThink, 2004
Absolute failure rate in that study	Around 5 percent	Ed Thompson, Gartner, via CustomerThink, 2004
Butler Group 70 percent source document	Not located by the analyst who searched, or by Butler Group	Michael Krigsman, ZDNet, August 2009
Hard failure with a stated definition	18 percent, 31 percent, 29 percent across 2005 to 2007	AMR Research, via ZDNet, 2009
Enterprise software license utilization	54 percent in 2025, up from 47 percent in 2024	Zylo 2026 SaaS Management Index
Documented deflection dashboard error	30 percent reported, 2 percent after manual review of nearly 700 conversations	r/salesforce practitioner report, April 2026

FAQ

Do 70 percent of Salesforce implementations fail?

No evidence supports that figure. The 70 percent statistic is attributed to Butler Group in 2002, and the analyst who investigated it in 2009 could not obtain the source document. Butler Group’s own research manager searched and suggested it originated as an analyst remark to the press rather than as published research.

What is the actual Salesforce implementation failure rate?

No current study measures it with a published sample size and methodology. The closest defensible figures come from AMR Research, which measured failures that prevented go-live at 18 to 31 percent between 2005 and 2007. Gartner’s analyst put absolute CRM failure near 5 percent in the same era.

What is the most common cause of Salesforce implementation failure?

Gartner’s repeated surveys identified metrics as the hardest CRM discipline, ahead of process definition and people. Organizations set objectives too abstract to measure, then cannot determine afterwards whether the implementation worked. Technology implementation itself ranked as the second easiest task.

How do you tell early that a Salesforce implementation is going wrong?

Four early signals appear before go-live. Executives give different answers about the target metric. Mandatory requirements exist that preserve an old tool without a stated business outcome. One custom object accumulates fields belonging to several entities. Nobody can name who approved the object model.

Can a failed Salesforce implementation be recovered without starting over?

Recovery is usually possible, and sequence determines cost. Settle the purpose questions first, because a data model rebuilt against undefined objectives produces a second failure at higher cost. Structural work on objects and intake paths follows. Measurement comes last, once agreed definitions exist to measure against.

Does unused licensing indicate implementation failure?

Unused licensing indicates adoption failure, which is the most frequently overlooked form. Across enterprise software portfolios, 46 percent of purchased licenses went unused in 2025 according to Zylo telemetry. Last-login data on assigned Salesforce licenses converts that risk into a number in minutes.

Answer five questions before reading anything else. Each one has a published reference value, and together they place your team against the rest of the market.

1. How long does a change take to go from committed to running in production?
2. How often do you deploy?
3. When a deployment fails, how long until service is restored?
4. What share of your deployments need immediate intervention?
5. What share of your deployments are unplanned, triggered by something breaking in production?

Hold those answers. The rest of this page supplies the numbers to check them against, and explains why two of the five are almost impossible to measure with Salesforce’s native tooling.

DORA measures five delivery metrics, and Salesforce documentation still teaches four

Most Salesforce delivery advice cites “the DORA four keys.” That model is retired.

DORA’s current guidance states plainly that it has identified five software delivery performance metrics, split across two categories. Throughput holds change lead time, deployment frequency, and failed deployment recovery time. Instability holds change fail rate and deployment rework rate.

Two changes produced that structure. In 2023, mean time to recover was renamed and redefined as failed deployment recovery time, because the old definition failed to separate a failure caused by a software change from one caused by a data center outage. In 2024, DORA added deployment rework rate, the share of deployments that are unplanned and happen because something broke in production. The reasoning is worth keeping: change fail rate had been serving as a rough proxy for rework, and DORA decided rework deserved its own number.

One detail catches people who assume the categories are intuitive. Recovery time sits under throughput, not stability. DORA groups by what the metric describes about flow rather than by whether it sounds like a reliability measure.

Now compare that to what Salesforce publishes. Salesforce’s own DevOps metrics explainer still describes DORA metrics as a set of four, naming deployment frequency, lead time for changes, change failure rate, and mean time to recovery, and offering time to market as a sometimes-fifth metric that DORA has never used. Neither failed deployment recovery time nor deployment rework rate appears anywhere on the page.

The date is the part worth noting. That page carries a last-modified date of 28 August 2026, twelve days before this article was written, and still teaches the model DORA revised in 2023 and extended in 2024. This is not a neglected corner of the site. It is current documentation carrying a superseded framework.

DevOps Center measures three of the five, which caps what a Salesforce team can benchmark

The gap is not only editorial. It is built into the tooling.

Salesforce Help’s page on measuring project performance with DORA metrics states that DevOps Center supports promotions to production, average lead time from first commit to final promotion, and change failure rate, described verbatim as the percentage of promotions that failed or required a fix.

Map those three onto DORA’s five and the shortfall is specific:

DORA metric	Measurable in DevOps Center
Deployment frequency	Yes, as promotions to production
Change lead time	Yes, as average lead time
Change fail rate	Yes
Failed deployment recovery time	No native equivalent
Deployment rework rate	No native equivalent

Both missing metrics are the ones that describe what happens after a bad deployment. A Salesforce team using only native tooling can see how fast it ships and how often it breaks something, and cannot see how long the breakage lasts or how much of its next release is repair work.

Salesforce does publish prescriptive guidance on the same page, and it is the closest thing the vendor offers to a cadence recommendation: if change failure rate increases, improve testing and perform smaller, more frequent promotions. The page also advises monitoring trends over a period such as the last 30 days rather than reacting to single-day spikes. It attaches no target number to either instruction.

Reference values place a Salesforce team against the wider market

The Elite, High, Medium and Low labels most teams still quote do not appear in DORA’s current research. DORA has not announced their retirement, so the accurate statement is narrower: the word Elite appears nowhere in the 2025 report, which instead groups respondents into seven team archetypes derived from eight factors including burnout and friction rather than delivery speed alone.

Those archetypes are not a scoring instrument. The distribution tables are. Drawn from 4,867 respondents in DORA’s most recent annual report, they show where teams actually sit on each metric. DORA labels the running column Top %, accumulating from the highest-performing band downward.

Change lead time	Share at this level	Cumulative
Under one hour	9.4%	9.4%
Under one day	15.0%	24.4%
One day to one week	31.9%	56.4%
One week to one month	28.3%	84.7%
One to six months	13.2%	98.0%

Deployment frequency	Share at this level	Cumulative
On demand, multiple per day	16.2%	16.2%
Hourly to daily	6.5%	22.7%
Daily to weekly	21.9%	44.6%
Weekly to monthly	31.5%	76.1%
Monthly to six-monthly	20.3%	96.4%

Failed deployment recovery	Share at this level	Cumulative
Under one hour	21.3%	21.3%
Under one day	35.3%	56.5%
One day to one week	28.0%	84.5%

Change fail rate clusters between 8 and 16 percent, where 26 percent of respondents sit, and the cumulative share at 16 percent or better is 62.2 percent. Rework rate clusters in the same band, with 26.1 percent between 8 and 16 percent.

Read those tables honestly and most teams discover they are median rather than laggard. A team deploying weekly with a one-week lead time sits inside the largest group on both measures, which is a more useful finding than being told it is not Elite.

Salesforce delivery clusters at weekly rather than trailing the market

Cross-industry numbers only take a Salesforce team so far, because the platform ships three seasonal releases a year and much of the work is metadata rather than code.

Gearset’s State of Salesforce DevOps 2026, published 29 April 2026 from 522 quality-controlled responses, supplies the platform-specific values. One disclosure belongs with every citation of it: 48 percent of respondents were Gearset customers, a material selection effect in a survey about tooling adoption.

Asked how frequently the organization releases to production, Salesforce teams answered multiple times a day at 6 percent, daily at 6 percent, multiple times a week at 23 percent, weekly at 25 percent, multiple times a month at 24 percent, monthly at 9 percent, and multiple times a year at 7 percent.

Two derived figures matter, and they point in opposite directions. 12 percent deploy daily or more often, against 22.7 percent in DORA’s cross-industry distribution. 60 percent deploy weekly or more often, against 44.6 percent cross-industry.

So the common claim that Salesforce delivery is simply slower is wrong. Salesforce teams are roughly half as likely to reach daily deployment and meaningfully more likely to hold a weekly cadence. The distribution is tighter, not lower. Gearset’s own reading matches: release frequency continues to follow a bell curve centered on weekly and multiple times a week, with no significant shift toward daily deployment compared with the previous year.

On defect rates, 39 percent of Salesforce teams report bugs in under 5 percent of releases and 38 percent report between 5 and 10 percent, which leaves 23 percent shipping bugs in more than one release in ten. On recovery, 63 percent restore normal service within six hours of a production incident.

One caution before anyone builds a slide from a side-by-side. Gearset asks how long a feature takes to reach production after it has been built. DORA asks how long from commit to production. The Gearset lead time figures, 19 percent under a day and 38 percent between a day and a week, describe a narrower window and are not directly comparable.

Rework hours quantify what weak delivery practice costs per year

The most useful number in the 2026 Salesforce data is not a rate. It is an hours figure, and it converts delivery maturity into something a finance conversation can hold.

Gearset segments teams by how many of the six lifecycle stages they have both tooling and process for, then reports annual rework and downtime.

Measure	Low adopters, 0 to 2 stages	Partial, 3 to 4	High, 5 to 6
Average annual rework hours	155.1	81.2	68.7
Average annual production downtime hours	237.0	104.5	91.8
Teams with error rate under 5%	25.4%	38.2%	44.7%
Teams restoring production in under 6 hours	47.0%	55.0%	69.8%

A low-adoption team burns 86 more hours of rework and 145 more hours of downtime each year than a high-adoption team.

Read those four rows as the weakest-sourced numbers on this page, because they are. The word rework appears exactly once in the whole report, as the chart label. Gearset publishes no definition of a rework hour, no method for deriving downtime hours, and no sub-sample size for any of the three adoption tiers, while publishing totals for its other charts. A 522-person sample split three ways could leave the high-adoption cell small. The direction is credible and the decimal places are not.

The distribution matters as much as the totals. Gains do not stop at partial adoption. Teams that cover five or six stages keep improving over teams that stop at three or four, which argues against the common decision to tool the build stage and leave operate and observe uninstrumented.

Testing bottlenecks rank as the top blocker to scaling delivery

Asked to name the biggest blockers to scaling Salesforce delivery, 452 respondents selected testing bottlenecks, described as manual effort or slow feedback, more often than any other option: 173 selections, or 38.3 percent. Complex cross-cloud dependencies followed at 35.4 percent, skills and capacity gaps at 32.1 percent, governance slowdowns at 31.4 percent, and sandbox and production drift at 30.8 percent. Merge conflicts and overwritten work reached 29.9 percent.

Gearset reads its own data cautiously, noting that no clear leader emerges among the blockers, and the spread supports that. Testing is first by count rather than first by a margin that settles the question.

That ranking matches what practitioners describe. An r/salesforce thread from 2 April 2026 titled around developers overriding each other’s code drew 44 comments against only 5 upvotes, a ratio that usually marks a nerve rather than a broadcast. The author reported using DevOps Center for deployment and falling back to change sets when it failed, which the author said was often. The highest-scoring reply, at 35 upvotes against a next-best of 18, reframed the problem in one line: that is a devops problem, and specifically the lack of a devops practice.

The remedies split cleanly across existing disciplines. Testing throughput belongs to a Salesforce test strategy and regression testing that catches silent breakage. Environment drift belongs to sandbox strategy. Repair work that never gets scheduled accumulates as technical debt.

Well-Architected defines healthy cadence qualitatively rather than numerically

Salesforce does describe what good delivery looks like, in the application lifecycle management patterns under Well-Architected’s Resilient dimension. Each entry names a product area, a place to look, and the condition to check.

Five of those patterns are worth auditing against directly, and all five are checkable in an afternoon. Deployment history shows clear release cadences and fairly uniform deployment clusters within release windows. Deployment logs show no failed deployments within the available history. Change sets are not used to release changes. Risky configuration changes are never made directly in production. No releases occur during peak business hours.

No thresholds appear anywhere on that page. Salesforce says deploy more often, calls uneven deployment clustering a departure from the pattern, and publishes no number for either. That gap is why this page exists, and it is why a Salesforce team benchmarking itself has to borrow DORA’s distributions and platform-specific survey values rather than reading a figure from the vendor.

Where agents move the numbers, and where they do not

GetGenerative.ai runs Salesforce delivery through pods where a Forward Deployed Engineer leads and six purpose-built agents (Discovery, Metadata, Design, Build, Test and Support) carry production work across a six-stage sequence from discover to deploy. The relevant question for a benchmark page is which of the five metrics that actually moves.

Change lead time and deployment frequency respond to agent capacity. Both are gated by how quickly designs, configuration, code and test cases get produced. That is generation work, and it is the part that compresses.

Change fail rate and rework rate respond to review capacity, not generation. Producing more changes faster raises the volume needing judgment. The 12-year minimum experience floor GetGenerative.ai sets for its FDEs exists for that side of the equation rather than the first.

Failed deployment recovery time barely responds at all. Recovery depends on rollback design, environment strategy and who is on call at the time. No agent shortens it materially, and claiming otherwise would fail against the data on this page.

Two of five improve through throughput, two through supervision, and one is largely outside the model. Testing sits at the intersection, which is why the Test Agent matters more than its position in the list suggests: testing bottlenecks are the top-ranked blocker in the market, and they gate lead time and change fail rate simultaneously.

The honest limitation is measurement rather than capability. Because DevOps Center captures no recovery or rework metric, a team adopting any AI-led delivery model, ours included, cannot demonstrate improvement on two of the five without instrumenting them separately. Establish the baseline before the engagement starts, or the benchmark becomes an argument rather than a number. If you want that baseline captured as a defined exercise, talk to us about a delivery assessment.

Your scorecard, filled in

Metric	Cross-industry median band	Salesforce-specific value	Native Salesforce measurement
Change lead time	One day to one week (31.9%)	38% take a day to a week post-build	Yes, commit to promotion
Deployment frequency	Weekly to monthly (31.5%)	60% weekly or better, 12% daily or better	Yes, as promotions to production
Change fail rate	8 to 16% (26.0%)	23% ship bugs in over 10% of releases	Yes
Failed deployment recovery	Under one day (56.5% cumulative)	63% restore within six hours	No
Deployment rework rate	8 to 16% (26.1%)	Not separately published	No

Sources: DORA 2025, n=4,867; Gearset State of Salesforce DevOps 2026, n=522 with 48% Gearset customers; Salesforce Help, DevOps Center DORA metrics.

Where this leaves you

DORA measures five delivery metrics. Salesforce’s own documentation still teaches the retired four-metric model, and DevOps Center instruments three, leaving recovery time and rework rate invisible to teams on native tooling alone. Salesforce delivery is not slower than the wider market so much as tighter: fewer teams reach daily deployment, more hold a weekly cadence. Weak lifecycle coverage is reported to cost roughly 86 extra rework hours and 145 extra downtime hours a year. Testing is selected as a blocker more often than anything else.

What delivery leads ask about these numbers

How often should a Salesforce team deploy to production?

No Salesforce-published number exists. The platform ships three seasonal releases a year, and Salesforce advises smaller, more frequent promotions without setting a target. Survey data shows 60 percent of Salesforce teams release weekly or more often and 12 percent daily or more often, so weekly is the modal cadence rather than a standard.

What is a good change failure rate for Salesforce?

Among Salesforce teams, 39 percent report bugs in under 5 percent of releases and 38 percent report 5 to 10 percent. Cross-industry, the largest cluster sits between 8 and 16 percent. Under 5 percent puts a Salesforce team in the leading group; above 10 percent puts it in the trailing 23 percent.

Why does DORA now have five metrics instead of four?

Mean time to recover was renamed failed deployment recovery time in 2023, because the original definition did not separate failures caused by a change from failures caused by infrastructure. Deployment rework rate was added in 2024, since change fail rate had been acting only as a proxy for how much repair work teams absorbed.

Can DevOps Center measure all the DORA metrics?

No. DevOps Center reports promotions to production, average lead time from first commit to final promotion, and change failure rate. It has no native equivalent for failed deployment recovery time or deployment rework rate, so a team wanting to benchmark those two must instrument them separately.

What does poor delivery practice actually cost per year?

Gearset reports that teams with tooling and process for two or fewer of the six lifecycle stages average 155.1 rework hours and 237 production downtime hours annually, against 68.7 and 91.8 for teams covering five or six. That is a gap of roughly 86 rework hours and 145 downtime hours, though Gearset publishes no definition of a rework hour and no per-tier sample size.