Checked against Salesforce Help, the Salesforce blog and the Trailhead modules Data 360 Setup and Data Governance Strategies, September 2026. Data Cloud is now called Data 360.
Most data leaks don’t look like a hacker attack. They look like a normal working day: a sales rep opens a customer profile, a call-center agent reads out a number, a marketer builds a segment. Nobody does anything wrong on purpose. The data simply goes where no rule stopped it.
This article has two parts. First: what can actually go wrong, with four short examples from pharma and banking. Second: the rules Salesforce Data 360 gives you to stop it — and the one default setting that catches many teams out.
The short version: the same customer data, three employees, and what each of them may see once a Data 360 rule is in place. Names and data are fictional.
What can go wrong
1. Pharma: the sales rep sees a side-effect report
A doctor tells the medical team that a patient felt dizzy after the second dose. The report ends up in the unified customer profile. Two weeks later, the sales rep visits the same doctor and brings it up.
Many pharma companies keep Medical and Sales apart on purpose. Once the data sits in one profile, that separation only exists if a rule enforces it.
Could this happen to us? Which teams can open a doctor’s full profile today, including what Medical knows?
2. Banking: an external agent reads out a full IBAN
A bank uses an external call center. The agents need to find the right customer, but they don’t need the full account number. Without a rule, they see it anyway — and one of them reads it out on a recorded call.
Could this happen to us? What does an external agent see on screen when they open a customer?
3. Banking: a sensitive field ends up in a campaign
A marketer builds a cross-sell segment and filters on a field called “collections status” because it was there. The customers in that segment now get an offer that shows the bank’s marketing knows they are behind on payments.
Could this happen to us? Which fields can marketing use to build a segment, and who decided that?
4. Pharma: a doctor without consent gets an email
This one is different, and it matters. The problem here is not who can see the data, but whether the company is allowed to contact the person. Access rules don’t solve that. Consent management does.
Could this happen to us? Is consent checked at the moment a segment is sent, or only when the data comes in?
Why it happens
Nobody marked the data as sensitive. If a field isn’t labelled as medical or financial, no rule knows it needs protecting.
Rules exist, but a default overrides them. More on this below — it is the most common surprise.
The merged profile inherits an unlabelled field. Data 360 combines data from several sources into one profile. If a sensitive field was never labelled at the source, it travels into the profile unprotected.
The rules in Salesforce Data 360
This part is for admins and architects. If you lead the team, the self-test at the end is enough.
Step 1: Label sensitive data with tags
In Data 360 you attach tags to fields, for example Email Address or Credit Card Number. Tags can have a parent: Personal Information → Email Address, Phone Number.
This hierarchy does the heavy lifting. If you put a child tag on a field, the parent tag is applied too. Any rule you wrote for Personal Information now protects that field automatically, with no extra setup.
Propagation: tags on a source object can be carried over to related objects further down, such as the unified profile. This closes the gap from cause 3.
AI suggestions:Suggest Tags proposes tags. It reads only metadata — field names and descriptions — not the data inside the fields. An admin approves each suggestion. That is the answer when compliance asks whether the AI sees patient data.
Don’t tag everything. Start with data that affects privacy, compliance or critical decisions. Tagging everything creates work without adding protection.
Step 2: Decide who sees what
Data 360 uses attribute-based access control (ABAC). A rule combines facts about the user (department, role) with facts about the data (its tags). You write the intent once, and it applies to every field that carries the tag — including fields added later.
What you need
Policy type
Example from above
Some people must not see it at all
Data access policy
Sales has no access to fields tagged Medical Information
People need the record, but not the full value
Dynamic data masking
The external agent sees DE89 •••• •••• •••• •••• 00
People should only see their own slice
Row-level security
A regional manager sees only their region
Three policy types, three of the four examples. Consent (example 4) is a separate job.
Salesforce states that governance policies are enforced across Data 360 features, including segmentation. In practice: if a marketer’s policy blocks a field, it is not available to them when building a segment (example 3).
Deny beats allow. If one rule allows access and another denies it, the user is denied.
Keep it simple. Fewer, clear rules beat many overlapping ones. Rules that are too strict push people to work around them.
Test with real roles before you roll out to everyone.
Step 3: Remove the “Allow All” default — on a plan
This is the catch. Every Data 360 org, new or existing, starts with an active “Allow All” policy. It exists so that nothing breaks while you design your rules.
The consequence: as long as Allow All is active, the new allow rules you build have no effect — everyone already has access. Only deny rules work. A team can build a clean ruleset and still be wide open. Deleting Allow All without a plan is just as bad: it can cut off access for every user at once.
Trailhead describes five phases:
Audit and design. Keep the policy. Find out who really needs access to what.
Build and test. Create the new allow and deny rules while Allow All is still active.
Communicate. Tell users what changes and when. Book a maintenance window.
Switch. In that window, delete Allow All and activate the new rules.
Validate and support. Check with users that everyone has the access they need.
Setup notes that save pain later
Choose the home org before you buy the licence. With several Salesforce orgs, decide first which one Data 360 connects to — provisioning starts automatically.
Data residency: if data must stay in a region, plan one Data 360 per region.
Permission sets: start from the standard ones (Data Cloud Architect, Activation Manager, Activation Specialist, User). A new user gets a login email as soon as the permission set is saved, so make sure the account is ready.
Marketing Cloud connection: Data 360 creates its own automations in Automation Studio to move data. Tell your Marketing Cloud users not to edit them.
Self-test: could this happen to us?
Five questions. You don’t need a project to answer them — just ten minutes with your admin.
Is the “Allow All” policy in our Data 360 org still active?
Which fields have we tagged as sensitive, and which have we forgotten?
Who can see the full unified customer profile?
What does an external partner see when they open a customer?
Which fields can marketing use in a segment, and is consent checked before sending?
If you can’t answer one of them, that’s where to start.
How I’m learning this
I’m currently working through the Salesforce Data 360 Consultant certification. The content here comes from the Trailhead modules Data 360 Setup and Data Governance Strategies. If you want to go further, start with the trail “Prepare for your Salesforce Data 360 Consultant Certification” and the Help article on Data 360 data governance linked below.
The examples in this article are fictional. Product behaviour as documented by Salesforce, September 2026. Salesforce, Data 360 and Trailhead are trademarks of Salesforce, Inc. This is an independent analysis; no partnership with or endorsement by Salesforce.
Checked against Salesforce Help, the Salesforce Developers documentation and Trailhead, September 2026. Data Cloud is now called Data 360.
Most architecture slides draw the Einstein Trust Layer as one box between Salesforce and the model — OpenAI, Claude or Gemini. That box hides the question a compliance lead in a pharma company actually asks: what exactly leaves our org, and who sees it? The answer depends on which of seven steps run for a given call — and, since 2025, on whether the call comes from a prompt template or
The short version: what leaves Salesforce, what the model sees, and what is checked before the answer reaches the user. The detailed seven steps follow below.
The scenario
Norvane Pharma (fictional) runs its medical information desk on Service Cloud, with Data 360 underneath. Two generative AI use cases are on the table: a case summary button for the inquiry team, and later an Agentforce service agent on the HCP portal. Both call a large language model. Both ground on the same unified HCP profile. They do not get the same protection — and the difference is documented, just not on the slide.
The Einstein Trust Layer round trip, step by step
Simplified. Salesforce Help describes masking before prompt defense on the way out and toxicity scoring before demasking on the way back. Trailhead’s current diagram also shows prompt injection detection and toxicity detection (both Beta) on the prompt, before masking.
Secure data retrieval and grounding. Prompt Builder resolves merge fields from record fields, related lists, Flow or Apex outputs, Data 360 DMOs and retrievers. Retrieval runs with the permissions of the user executing the prompt; role-based controls and field-level security stay in place.
Data masking. Pattern-based detection (machine learning for names of people and companies, regex patterns plus context words for email, phone, credit card, IBAN and passport numbers) and field-based masking for fields tagged with Shield Platform Encryption or data classification. Detected values become placeholders; the Trust Layer temporarily stores the mapping.
Prompt defense. System policies are added to the prompt to resist jailbreaking and prompt injection, and to keep the model from answering where it has no information. Separately, Prompt Injection Detection (Beta) scores prompts for injection attempts and reports them in Data 360 — currently for English (United States) only.
LLM gateway and model. The request goes to the selected model. For partner models such as OpenAI, zero data retention applies: data is deleted after the response is sent back and is not used for training.
Toxicity detection. The response is scored per category — hate, violence, physical harm, sexual content, profanity and further categories that differ slightly between APIs — plus an overall safety score. Input safety scoring can be switched on for the prompt as well. The documentation describes scoring and storing — not blocking.
Demasking. Placeholders are swapped back using the mapping saved in step 2.
Feedback and audit. The original and the masked prompt, the raw and the demasked response, toxicity scores and user feedback land in Data 360 as a timestamped audit trail.
Step 1 in detail: grounding decides what can leave
Grounding is dynamic: the template is resolved at run time, for the user who triggers it. Trailhead calls this dynamic grounding, and it is why the same template produces different prompts for different users. What reaches the model depends on which data provider fills each part of the template:
Record merge fields and related lists — data from the input record and its relationships. Related lists follow the page layout of the running user, record-level filters are not applied, and the result is rendered as JSON. If the user lacks the related list on the layout or Read access to the object, no related list data is sent to the model at all.
Flow — a Template-Triggered Prompt Flow receives the template inputs and adds text through the Add Prompt Instructions element. It can pull CRM data, Data 360 data and external sources.
Apex — an invocable method bound to the template type returns a Prompt string. Same reach as Flow, with full code control.
Retrievers — semantic search over indexed, unstructured content such as knowledge articles. The retrieved chunks are inserted into the prompt: this is the RAG part of the pipeline.
An Apex grounding class, following the pattern in the Salesforce Developers blog. The class decides exactly which fields become prompt text — a useful control point when a use case must not send certain data:
public with sharing class HcpInquiryContext {
// Illustrative: bound to a Flex template via its API name.
// Fields used here must be available on the input record.
@InvocableMethod(capabilityType='FlexTemplate://Case_Summary')
public static List<Response> build(List<Request> requests) {
Case c = requests[0].caseRecord;
// Only what is added here becomes prompt text
Response res = new Response();
res.Prompt = 'Product: ' + c.Product__c
+ '\nInquiry type: ' + c.Type
+ '\nOpened: ' + String.valueOf(c.CreatedDate.date());
return new List<Response>{ res };
}
public class Request {
@InvocableVariable public Case caseRecord;
}
public class Response {
@InvocableVariable public String Prompt;
}
}
Step 2 in detail: what Salesforce data masking actually does
Masking replaces each detected value with a placeholder that says what it was, so the model keeps the context of the sentence without seeing the value. For Norvane’s case summary, the difference looks like this — values invented, placeholder format as shown in Salesforce’s Trailhead example:
Before (in the org) After (sent to the model)
------------------------------------ ------------------------------------
Caller: Dr. Anna Weber Caller: <NAME_1>
Clinic: Praxis Weber Hamburg Clinic: <COMPANY_1>
Email: a.weber@example.de Email: <EMAIL_1>
Phone: +49 40 1234 5678 Phone: <PHONE_1>
Product: Norvastin 20 mg Product: Norvastin 20 mg
Three details matter for European orgs:
Language coverage. Name, company name, email, phone, credit card, IBAN and passport numbers are detected in English, French, German, Italian, Japanese and Spanish. Driver’s licence, ITIN and Social Security numbers are US English only. Product names, diagnoses or free-text symptoms are not a masking category.
Field-based masking has a narrow scope. It supports only record merge fields and related lists. Data that enters the prompt through Flow, Apex or a retriever gets pattern-based detection only — a classified field is not protected by its classification once Apex has turned it into prompt text.
Locale. For direct Models API calls, localization.defaultLocale determines the region used for data masking. If no localization is passed, Salesforce assumes en_US — so German phone numbers and other region-specific formats may be detected less reliably.
The detail that changes the design: no data masking for Agentforce agents
“In Einstein Trust Layer, pattern-based and field-based data masking for large language models (LLMs) is disabled for agents.”
Salesforce Help
Salesforce gives two reasons: accuracy — an agent asked to build a list of accounts similar to a reference account fails if it only sees that account as a placeholder — and performance. Both are reasonable. The consequence is still worth stating plainly.
For Norvane, the case summary button sends the model placeholders instead of the HCP’s name and contact details. The portal agent sends them in clear text. The same prompt template behaves differently depending on where it runs: called from a Lightning page or a Flow it follows the masking settings; called as an agent action it doesn’t. Masking remains available for embedded features such as Einstein Service Replies and Work Summaries.
The model behind the agent matters too. Agentforce’s Salesforce Default option is a managed mix of models that currently includes GPT-4o. The AWS-Hosted option uses an Anthropic Claude model on Amazon Bedrock. Those two options sit in different trust zones.
For Agentforce security, protection moves from the model never sees the value to two other levers: where the model runs and what the contract with its provider says. That turns model selection from a quality decision into a data-flow decision.
Why OpenAI is in the picture — and why it’s one of three zones
Salesforce builds its own models, but for open-ended language tasks the frontier models are stronger and improve faster than a CRM vendor could retrain. So Salesforce buys inference. The Trust Layer is the condition under which that is acceptable. What most people miss is that “external model” covers three different trust arrangements.
Same gateway, three trust arrangements. What changes is the highlighted step: who operates the model and who gives the retention commitment.
Salesforce trust boundary. Models built by Salesforce, and — less obviously — Anthropic and Amazon models on Amazon Bedrock, which Salesforce describes as operated on Amazon Bedrock infrastructure “entirely within the Salesforce Trust Boundary”. For agents, Salesforce Help adds that data sent to such a model doesn’t leave the Salesforce trust boundary.
Shared trust boundary. Models operated by Salesforce partners, such as OpenAI and Azure OpenAI, covered by Salesforce’s zero data retention policy: data isn’t retained and is deleted after the response is sent back.
Bring your own LLM. A model you connect through AI Models with your own credentials, on Amazon Bedrock, Azure OpenAI, OpenAI or Vertex AI. Requests still route through the Models API, and Trust Layer features are supported. But Salesforce’s Agentforce privacy FAQ states that it does not apply to BYO LLM — your own contract with the provider governs retention.
For Norvane’s portal agent, which grounds on HCP data without masking, the question “which model?” therefore has a second half: “in which zone?”
Why zero data retention moves moderation into Salesforce
Trailhead explains a detail that is easy to miss. Model providers normally keep prompts and responses for a while to monitor abuse. Salesforce’s zero data retention agreement removes that: the provider forgets prompt and response once the answer is back. The moderation the provider would otherwise do has to happen somewhere, so Salesforce does it inside the Trust Layer — which is why toxicity scoring and the audit trail live on the Salesforce side, in your Data 360.
The way back: toxicity, citations, feedback
Toxicity scoring runs on the response before demasking. The model returns an isToxicityDetected flag when it is highly confident; false only means nothing was detected. Salesforce also notes that free-text input can carry toxic language from end users, so prompts can be scored too.
Citations link a generated answer to the source records or articles it used, so users can verify it. They are supported in English, French, German, Italian, Brazilian Portuguese and Spanish.
Feedback comes in two forms. Explicit: thumbs up or down, with reasons such as factually incorrect, incomplete, biased or harmful, or wrong tone. Implicit, depending on the feature: whether the user accepted, edited or discarded the draft. Both land in the audit data.
What it looks like in code
Running a prompt template from Apex, following the pattern in Salesforce’s Apex reference:
public with sharing class CaseSummaryService {
public static String summarize(Id caseId) {
// Record inputs are passed as a map with an 'id' key
Map<String, String> caseRef = new Map<String, String>{ 'id' => caseId };
ConnectApi.WrappedValue caseValue = new ConnectApi.WrappedValue();
caseValue.value = caseRef;
Map<String, ConnectApi.WrappedValue> params =
new Map<String, ConnectApi.WrappedValue>();
params.put('Input:Case', caseValue);
ConnectApi.EinsteinPromptTemplateGenerationsInput input =
new ConnectApi.EinsteinPromptTemplateGenerationsInput();
input.inputParams = params;
input.isPreview = false;
input.additionalConfig = new ConnectApi.EinsteinLlmAdditionalConfigInput();
input.additionalConfig.applicationName = 'PromptTemplateGenerationsInvocable';
// Everything from here is platform behaviour:
// grounding, masking, prompt defense, model call,
// toxicity scoring, demasking, audit
ConnectApi.EinsteinPromptTemplateGenerationsRepresentation result =
ConnectApi.EinsteinLLM.generateMessagesForPromptTemplate(
'Case_Summary', input);
return result.generations[0].text;
}
}
What the code doesn’t contain is the point: no named credential to OpenAI, no API key, no masking call, no logging. Six of the seven steps are platform behaviour. The response carries the toxicity result alongside the text — field names as documented in the Apex reference, values illustrative:
Category scores run from 0 to 1, with 1 the most toxic and 0.5 the threshold. The safety score runs the other way: 1 is safest, 0.5 and above counts as safe.
Without a template, the Models API calls a model directly — still through the gateway and the Trust Layer. The request below uses the documented endpoint and headers and passes a German locale so masking and toxicity scoring use the right region:
POST https://api.salesforce.com/einstein/platform/v1/models/sfdc_ai__DefaultBedrockAnthropicClaude45Sonnet/generations
Authorization: Bearer <JWT>
Content-Type: application/json
x-sfdc-app-context: EinsteinGPT
x-client-feature-id: ai-platform-models-connected-app
{
"prompt": "Summarise this inquiry in three sentences: ...",
"localization": {
"defaultLocale": "de_DE",
"expectedLocales": ["de_DE"]
}
}
Here the toxicity result comes back as generation.contentQuality.scanToxicity, with isDetected and a list of category scores. There is no programmatic way to read the masked version from the Models API; that lives in the audit trail.
Where the architecture work actually sits
The gateway and the scoring models are platform. The decisions that shape what reaches a model are yours:
Grounding. Merge fields, Flow and Apex grounding, Data 360 DMOs and retrievers decide what goes into the prompt — and the running user’s access decides what can. In Data 360, identity resolution decides whether the model sees one HCP or five partial duplicates.
Masking configuration. Which data types are on. At initial setup, the most commonly used types are on and less frequent ones are off. Every type you mask costs the model context — and with masking turned on, all models are limited to a 65,536-token context window. A trade-off to agree with the business, not a default to accept.
Model selection by zone. Especially for agents, where masking doesn’t apply.
Audit data. Audit and feedback records live in your Data 360 instance, where you control how long they are kept; Salesforce additionally stores them for 30 days for compliance purposes. They map to standard DMOs — Ai Gateway Request, Ai Response Generation, Ai Content Quality, Ai Feedback — and Salesforce recommends building reports on those rather than the legacy GenAI objects. Prompt Injection Detection (Beta) adds a monitoring view on the same data.
Standard DMO
Legacy DMO
What it holds
Ai Gateway Request
GenAIGatewayRequest
Prompt before masking, masked prompt, model, provider, template name and version, masking and safety-scoring flags
Ai Response Generation
GenAIGeneration
Generated response
Ai Content Quality
GenAIContentQuality
Toxicity flag, per prompt (input) or response (output)
Ai Content Quality Category
GenAIContentCategory
Detector results by category: PII counts, toxicity scores, prompt defense
Ai Feedback
GenAIFeedback
Accept, edit, reject, thumbs up or down
Ai Feedback Additional Info
GenAIFeedbackDetail
Feedback reasons and free text
Selected audit and feedback objects in Data 360. Several of them can contain sensitive data, including the unmasked prompt.
What the Trust Layer does not do
It does not mask data for Agentforce agents.
It does not check facts. Grounding and system policies reduce invented answers; nothing verifies them.
It does not replace permissions. If the running user can see a field, the prompt can contain it.
It does not guarantee detection. Salesforce states that no model reaches 100% accuracy.
It does not document blocking. Toxicity and prompt injection detection score and record.
It does not keep sensitive data out of the audit trail. The Gateway Request object stores the prompt before masking, so access to the audit data needs its own governance.
Questions to settle before the first prompt goes live
Which use cases run as agents, and which as embedded features or prompt templates? Only the second group is masked.
For each use case, which trust zone does the selected model sit in?
Which fields are grounded, and does the running user’s access match what should reach a model?
Which masking types are on, and which are deliberately off because they break the output?
Which data enters through Flow, Apex or retrievers and therefore gets pattern-based masking only?
Do API integrations pass the right locale, or does masking run on the en_US default?
If BYOLLM is on the table, who owns the provider contract and its retention terms?
Who may see the audit and feedback data in Data 360, who reviews it, and how long is it kept?
None of this makes the Trust Layer weaker than the slides suggest. It makes it specific. The one-box version lets a steering committee approve “AI with guardrails”. The seven-step version tells them which guardrail applies to which use case — and where the remaining decisions sit with them.
FAQ: Salesforce and LLMs
Does Salesforce use OpenAI?
Yes, among others. OpenAI and Azure OpenAI models are Salesforce-managed models in the shared trust boundary, covered by Salesforce’s zero data retention policy. Salesforce also offers Anthropic and Amazon models on Amazon Bedrock, Google Gemini models on Vertex AI and its own models, and customers can connect their own model through AI Models.
Which LLM does Agentforce use?
By default, the Salesforce Default option: a managed mix of models that currently includes GPT-4o. The AWS-Hosted option uses an Anthropic Claude model on Amazon Bedrock, inside the Salesforce trust boundary. Custom actions that run prompt templates, Apex or the Models API can use any Salesforce-managed or bring-your-own model.
Does Salesforce send customer data to ChatGPT?
Not to the ChatGPT app. Prompts can go to OpenAI models through the Salesforce LLM gateway, and grounded prompts can contain customer data. Under Salesforce’s zero data retention policy, that data is not retained or used for training and is deleted after the response is sent back. For prompt templates, sensitive values can be masked first; for Agentforce agents they are not.
How does Agentforce protect data sent to an LLM?
Data masking is disabled for agents, so protection comes from other layers: grounding only with data the running user may see, the trust zone of the selected model, zero data retention, prompt defense, toxicity scoring and an audit trail in Data 360. Choosing a model inside the Salesforce trust boundary keeps the data there.
AI just joined the team that approves pharma marketing content. The interesting question is not whether. It is where.
Veeva Vault 26R2 — prerelease July 13, general release July 31 and August 7, 2026 — took Vault AI to general availability. The headline agents are conversational: ask questions about documents, records or data. The item worth an architect’s attention sits further down the release notes, under a heading that reads like a maintenance task: Agent Workflow Task Completion. AI agents can now automatically execute single-item document and object record workflow tasks. In a PromoMats or MedComms Vault, those tasks are the medical-legal-regulatory review — the gate every channel waits behind.
What shipped, exactly
Vault AI is generally available in 26R2, but contract-gated: enabling it requires an agreement — a zero-dollar order form — through your Veeva Account Partner. Nothing switches on by default.
GA agents: Query Agent (plain language to VQL), Document Chat, Object Chat, Document Version Compare. The Vault AI Tab is the exception — early adopters only in 26R2; where it appears, the Home tab is renamed to Tasks.
Agent Workflow Task Completion: an Admin configures an agent action with SOP-style instructions, selects the Single Item Workflow Task Completion tool, and assigns workflow tasks to an agent user. An internal AI workflow job starts the related agent actions hourly. Veeva positions this for high-volume, low-complexity tasks; on a downstream error such as a validation failure, the system notifies the workflow owner to reassign or cancel.
Guardrails shipped alongside: a Human-in-the-Loop Ask User tool, a semantic metadata layer for agents, a JSON Response tool type, and bring-your-own-model support for Gemini 2.5 Flash and Pro on Google Cloud with Google Model Armor screening.
Cadence: agent improvements are planned bi-weekly between 26R2 and 26R3, with additional agents in 26R3. The next platform release lands December 4, 2026; its Release Impact Assessment is due October 5.
What this looks like in a European pharma company
Picture one PromoMats Vault, ten markets, roughly 600 promotional assets through MLR review each quarter. Here is how the new capability would sit in that review, step by step:
An Admin writes plain-language instructions into an agent action — in practice, an SOP the agent has to follow.
Selected low-complexity tasks are assigned to a dedicated agent user rather than to a person.
An internal AI job wakes up every hour and works through that agent’s queue.
On a downstream error — a validation failure, say — the workflow owner is notified to reassign or cancel.
The MLR verdict itself stays with human reviewers. Because the team configured it that way. Not because the platform insists.
That last step is the real release note. When a CMO asks why a campaign launch takes six weeks, the answer usually lives at this gate: approved emails, CLM decks, websites and congress materials all queue behind it. Vault 26R2 does not move the gate. It makes the position of the human inside it a setting — which means it can finally be a deliberate one.
The architecture behind it
The enablement chain is four steps and every one of them is manual: the agreement via the Account Partner, then Vault AI enabled in Admin > Settings, then agents activated individually in Admin > Vault AI Setup > Agents, then permissions granted in the Agents and Tabs sections of the applicable permission sets. One constraint matters for anyone planning a trial: this option is not available in limited release or prerelease environments — it is part of the general release only. You cannot rehearse Vault AI in a prerelease sandbox before deciding.
Underneath the agents sits a piece of configuration that will get less attention than it deserves. Vault AI Metadata is a new semantic layer over the data model. Until now, agents reasoned over physical component names — product__v, start_date__v — which carry no business context, no synonyms, no descriptive detail. Subject matter experts can now describe objects, document types, fields, relationships, metrics and picklists in business terms through a new set of MDL components (Vsmentity, Vsmfield, Vsmrelationship, Vsmmetric, Vsmpicklist, Vsmvalue) in Admin > Configuration > Vault AI Metadata; active components synchronise automatically to a vector store. The quality of an agent’s reasoning is now a documentation exercise owned by the business, not a model choice owned by IT.
The Ask User tool is the counterweight to the hourly job. It lets an agent action pause and collect information from a human before continuing — free text, single selection or multiple selection, with an optional fallback answer. Task completion runs unattended and pulls a human in on error; Ask User puts a human in the happy path by design. Two different governance postures from the same toolkit, and choosing between them is an architecture decision, not a preference.
Two pieces round out the picture. The JSON Response tool type produces structured output consumable through the Vault REST API or Java SDK — the difference between an agent that talks to people and one that feeds a downstream system. And since 26R1.3, Admins can connect their own LLM: Gemini 2.5 Flash or Pro on Google Cloud, with Google Model Armor templates for prompt and response screening defined in Vault AI Settings. Bring-your-own-model moves screening policy into your own governance scope — an advantage and an obligation at once.
The fine print
Contract first, configuration second. The zero-dollar order form is a commercial step with a lead time. Budget for it in the project plan, not in the sprint.
No prerelease rehearsal. Vault AI enablement is excluded from limited release and prerelease environments — your evaluation happens in a general-release Vault.
The AI tab is not general. Early adopters only in 26R2. A demo you saw is not necessarily a feature you have.
Scope is deliberately narrow. Single-item document and object record workflow tasks, high-volume and low-complexity, human notified on error. That focus is the design, not a gap — but it is the boundary your SOPs have to describe.
Hourly, not real-time. Any cycle-time model built on this should assume that latency.
Bi-weekly agent updates. Whatever a validation team signs off today needs an owner who keeps watching.
The field side is moving too. Vault CRM 26R2.2 (release notes September 3, sandbox September 10, production September 17, 2026) ships its own Vault AI wave: Agentic Voice can now update an existing call report instead of creating a new one — automatically, when a single match is found — plus one-tap Agentic Media actions, Agentic View in create and edit mode on browser, custom fields for LLM Call, and vector database controls for selective vectorisation.
Questions to settle before signing the order form
Which workflow tasks are genuinely low-complexity — and who owns that classification?
How does an agent user fit your validation and change-control story when agent behaviour updates every two weeks?
Does “human on the error path only” satisfy your review SOPs, or do you need Ask User checkpoints in the happy path?
Who reviews the agent’s SOP instructions — the same people who review human SOPs?
Who writes and approves the Vault AI Metadata descriptions? Wrong business definitions produce confidently wrong agents.
If you bring your own model: who owns prompt and response screening policy, and where is it documented?
What does the audit trail show for an agent-completed task — and has QA seen a sample?
The line between AI and human in pharma content review is no longer drawn by the platform. It is drawn by whoever configures the Vault. That is a governance responsibility that has quietly moved into an Admin screen — and it will be exercised whether or not anyone treats it as a decision. Draw it on purpose.
Working on this?
Before this gets switched on, someone has to decide who signs the record when the agent is wrong. That is a process question, not a configuration one – and it is the kind of thing I help MLR and commercial teams settle.
Salesforce’s biggest bet in years is that your team will stop opening Salesforce. Not the data — the data is the whole point. The screens. On August 26, 2026, Salesforce and Anthropic announced Claudeforce, and the interesting part is not the name. It is that the largest CRM vendor has decided the interface people use to reach its data no longer has to be its own.
This article is the long version of my LinkedIn post from September 10: what actually shipped, what it means for a company that runs sales and marketing on Salesforce, how the architecture underneath works, how I would roll it out, and — the part most announcements skip — how you train twelve hundred people who never wanted to be technical.
If you read one paragraph · for CIOs, CMOs and heads of sales operations
Claudeforce does not add a new AI to your stack; it moves the place where your sales team works – into Claude and Slack – while every action still runs through Salesforce under the permissions you already have. Three things to decide before the pilot: who audits those permissions before the plugin reads everything it can reach; which skills may write, and where a human approves first; and how a rep working in Claude hands off to a campaign team still working in Marketing Cloud, because marketing skills are not in the first wave. The rest of this article is how those three get done.
What shipped, exactly
Claudeforce is a partnership brand. Underneath it are three separate things, and they are at three different stages of maturity.
Salesforce in Claude. A plugin for Claude with 37 prebuilt sales skills: daily briefing, pipeline review, forecast narrative, stakeholder mapping, close plans, objection handling, account planning, lead triage, call prep, conversation summary, win-loss review, activity logging, hygiene checks. Available to select pilot customers now; open beta expected in September 2026; additional skills starting late 2026. Salesforce says it runs the plugin itself as “Customer Zero” against its own live pipeline.
Claude in Salesforce. Claude is available as the reasoning model for the Atlas Reasoning Engine in Agentforce (Salesforce’s framework for AI agents that act inside the CRM), is the default model in Agentforce Vibes and Agentforce Coworker, and is selectable in Agent Builder. It is served through Amazon Bedrock inside the Salesforce Trust Boundary — Salesforce calls Anthropic the first LLM provider integrated at that level.
Claude in Slack. Claude is the default model for Slack AI and Slackbot, powers Claude Tag, and Anthropic is a founding partner for Slack Code. Salesforce reports 8.1 million annualized hours of productivity gains from its own Claude-powered Slackbot, doubling quarter over quarter — a self-reported internal figure, so treat it as a direction, not a benchmark.
On the roadmap, marked “coming soon” on the product page: Service, Marketing, Commerce, Revenue, Field Service, Tableau, MuleSoft, Informatica, Data 360, Headless 360 and Industries. Enterprise Frontier Safeguards — Anthropic’s misuse-detection layer running on customer-controlled infrastructure — are announced for fall 2026. Benioff and Amodei present the partnership live at Dreamforce, September 15–17.
The scenario: a medtech company with two interfaces
Picture a European medical device manufacturer. 1,200 reps in 14 markets. Sales Cloud holds accounts, hospital tenders and opportunities; Marketing Cloud — now Agentforce Marketing — runs the HCP campaigns. Here is a Tuesday morning after the pilot goes live.
A rep asks Claude for her morning briefing. The plugin pulls overnight pipeline changes, deals flagged at risk, and last night’s Slack threads about the tender she is chasing.
She asks for a close plan on that tender. Claude drafts it from the opportunity record, the contact roles, and the email history it is allowed to see.
She says “log it”. The activity and the stage change go through Salesforce — validation rules, Flows and Apex triggers fire exactly as they would from the Lightning UI.
Every one of those calls runs as her user. Object permissions, field-level security and sharing rules apply. The audit trail carries her name, not “integration user”.
Compliance wants a human approval before any external email leaves the building. That control already exists: approval can be required before an agent action executes, and the product page names external emails and record updates explicitly.
Here is what one of those requests looks like on the inside – six stations, one identity:
One request, six stations: ask, discover, describe, dispatch as the user, platform rules, record. The approval gate is optional and set per tool; the permission model is the one you already have.
Meanwhile the campaign manager for the same hospital account is still in Journey Builder. Marketing skills are on the roadmap, not in the plugin. The customer is one; the interfaces are now two; and the permission model has to hold both. That is the omnichannel point of this announcement, and it is the reason the rollout is an architecture project, not a licensing decision.
Two interfaces, one customer: the rep works in Claude, the campaign team still works in Marketing Cloud. The activity log is the handoff contract; the bridge is Data 360 today and a marketing skill when it ships.
The architecture behind it
This is not a chatbot bolted onto a CRM. Three layers matter.
The three layers: interfaces where people work, the platform core inside the Salesforce trust boundary with the Headless 360 MCP server as control point, and governed action in the clouds – Sales today, the rest on the roadmap.
Layer 1: the substrate, Headless 360
Since July 2026, Salesforce offers a hosted MCP server called platform/headless-360 in beta. MCP — the Model Context Protocol — is the open standard that lets an AI assistant call another system’s tools. Instead of exposing thousands of endpoints, the server presents exactly four:
Discover runs a semantic search over the operations your org can perform.
Describe returns the technical contract for one of them: APIs, parameters, dependencies, steps.
Dispatch executes it.
Dispatch (Read-Only) executes GET operations only and, in Salesforce’s words, “never changes data or configuration”.
The 37 sales skills are task recipes on top of this: a skill knows which operations to discover and in which order, so the rep does not have to.
Layer 2: the identity model
Every Hosted MCP transaction runs as the authenticated user, scoped through an External Client App with the mcp_api OAuth scope, on API version 67.0 or later. There is no new permission concept. Object CRUD, field-level security, sharing rules, profiles and permission sets apply unchanged, and the audit trail attributes every action to the human who asked. This is the single most important sentence in the whole announcement, and it cuts both ways. It means your existing governance carries over for free. It also means every over-provisioned profile that survived the last three cleanups is now reachable through a conversational interface that will, on its first run, sweep everything the connection can access to build the rep’s tailored dashboard.
Layer 3: where the model runs
Claude is served through Amazon Bedrock inside the Salesforce Trust Boundary, with zero data retention on the Sonnet, Opus and Haiku models in this configuration. For a regulated company, this is the difference between a tool the security team can review and a tool it has to block. It does not answer the question of what your own contracts, DPIAs and internal policies require — that stays with your compliance team.
Architecture check · Permissions
A rep asks the plugin for a list of accounts they have never been able to open in Lightning. What comes back?
Your answer
What Salesforce documents
Every transaction runs as the authenticated user, scoped through an External Client App with the mcp_api OAuth scope on API version 67.0 or later. Object CRUD, field-level security, sharing rules, profiles and permission sets apply unchanged.
Why it matters
Read it the other way round and it becomes a to-do: every over-provisioned profile that survived the last three cleanups is now reachable in conversation, and the plugin’s first context sweep reads everything the connection can see. The permission audit is not paperwork before the pilot – it is the pilot’s first phase.
No list price has been published. Salesforce’s Patrick Stokes describes two lines: consumption pricing on the Salesforce side, with API access scaling by license edition, plus Anthropic’s inference costs billed separately. He also says token consumption is “certainly not zero, but nowhere close to development use case” levels. Both statements are reported in interviews, not documented in a price list. Plan for instrumentation before you plan for a budget number.
Architecture checkpoint · what has to be true
Someone has exported the pilot users’ profiles, permission sets and sharing exposure – and removed what they do not need today.
The External Client App carries the mcp_api scope, on API version 67.0 or later.
The security review has the zero-data-retention Bedrock configuration in writing, and your own DPIA position is settled separately.
Consumption is instrumented per user and per skill before anyone quotes a budget number.
What it brings — by role
For the rep
The promise is the one Stokes puts as “10,000 clicks inside Salesforce, now 30 seconds”. The realistic version: the morning briefing, the call prep and the activity logging stop being chores that happen at 19:00 and start being questions asked at 08:15. Data hygiene improves because logging is one sentence away, not seven clicks.
For the head of sales operations
The plugin turns the pipeline review from a dashboard ritual into a dialogue with consistent numbers — the same records, the same sharing rules, whether the question is asked in Lightning, in Slack or in Claude. The catch: forecast narratives generated by an AI are only as good as the stage discipline underneath them.
For the CIO and the CISO
This is the first AI rollout where the governance layer already exists. The work is not writing an AI policy; it is auditing the permission model, deciding where human approval sits, and instrumenting consumption per user and per skill so the second invoice does not surprise anyone.
For the CMO
The honest answer is: not yet. Marketing skills are on the roadmap. What the CMO gets today is a sales team that increasingly works outside the CRM screens, and a campaign team that still works inside them. The handoff between the two — who knows what the rep promised the hospital, and when — is a process question that no plugin answers.
How to roll it out
I would run this in five phases, and I would not skip the first one.
Rollout maturity in five levels. Level 0 is the cheapest step and the one most pilots skip; nothing writes before Level 2, nothing scales before Level 3.
Phase 0 — Permission audit, before anyone installs anything
List the pilot users. Export their profiles, permission sets and sharing exposure. Remove what they do not need for their job today. The plugin’s first context sweep reads everything the connection can reach; do the cleanup before that moment, not after.
Phase 1 — Read-only pilot: ten users, four weeks
Enable the plugin with the read-only dispatch tool only. Skills allowed: daily briefing, pipeline review, call prep, conversation summary. Measure two things: time-to-first-useful-answer per user, and consumption per user per day.
Phase 2 — Write access, skill by skill
Add activity logging first — it is low-risk and high-value. Then stage updates and follow-up tasks. Each skill that writes gets a named owner and a rollback path (Salesforce Backup, sandbox rehearsal).
Phase 3 — Approvals where regulation bites
Require human approval before external emails, and before record updates on objects your compliance team flags. Test that the approval actually interrupts the flow, in a sandbox, with a real user.
Phase 4 — Scale and instrument
Expand by market, not by role. Keep the Agent Builder model choice as a maintained escape hatch: if you have Agentforce agents pinned to a specific model, somebody re-tests them when the default changes. Sequence the rollout around your release upgrade window so the team is not troubleshooting a beta plugin and a platform upgrade in the same week.
Rollout checkpoint · before you widen the pilot
The permission cleanup happened before the first install, not after the first sweep.
Every skill that writes has a named owner and a rehearsed rollback path.
An approval step has been tested in a sandbox by a real user, and it actually interrupted the flow.
Expansion is planned by market, not by role, and it avoids your release upgrade window.
Agentforce agents pinned to a specific model have an owner who re-tests them when the default changes.
How to train teams that never wanted to be technical
This is the part most enablement plans get wrong. They schedule a “prompt engineering” workshop. Reps do not need prompt engineering. They need three habits and a catalogue.
The adoption loop: a printed catalogue, three habits, a champion channel in Slack and one number that predicts whether the rollout survives month two.
The catalogue
The 37 skills are the training material. Print them — literally, one page — grouped as Salesforce groups them: daily workflows, deal strategy, account management, call prep, governance. A rep who can see that “close plan” is a skill will ask for a close plan. A rep who is told “Claude can help with anything” will ask for nothing.
Three habits to teach
Habit one: ask in your own words, then check one fact. The onboarding exercise is not “write a good prompt”. It is: ask for your morning briefing, then open one of the deals it mentions and confirm the stage is right. Do that for a week. Trust is built by verification, not by demos.
Habit two: say what you want done, not how. Reps who worked in Lightning for years describe the clicks: “go to the opportunity, change the stage, add a task”. The skill layer does not need that. “Log the call and move it to proposal” is enough. This takes two weeks to unlearn and is the single biggest source of early frustration.
Habit three: know where the line is. Every rep must be able to answer, without looking it up: which actions run without approval, which ones wait for a human, and what happens when the answer looks wrong (open a ticket, do not try again with a different wording). That is a ten-minute conversation per team, and it is the one that prevents the incident.
Format and cadence
Not a training day. Fifteen minutes in the weekly sales meeting for six weeks, each week one skill, each week one rep showing what they asked and what they got. One champion per market who collects the questions that did not work. Slack is the natural place for that channel — which is exactly why Claude in Slack matters more for adoption than the plugin itself.
What to measure
Not “number of prompts”. Activity-logging completeness (the hygiene skill will tell you), time from meeting to logged outcome, and the share of reps who used the plugin three days in a row. The third number is the only one that predicts whether the rollout survives month two.
Integrating it into daily work
Three rituals change, and it is worth deciding on purpose how they change.
The morning briefing becomes personal instead of team-wide. Decide whether the manager still runs a stand-up on the same numbers, or whether the stand-up becomes exceptions-only.
The pipeline review stops being a dashboard walk-through. The manager asks the questions in Claude during the meeting; the reps correct the data live. This is a good thing only if stage discipline is real. If it is not, the AI narrative will be fluent and wrong.
The handoff to marketing needs a rule, because the rep now works where the campaign team cannot see. The practical answer in my projects: the activity log is the contract. If the rep logs it through the skill, the campaign team can build on it — through Data 360 today, through a marketing skill when it ships.
One rule that is not optional
When the agent writes something wrong, it is an incident, not a chat message. Severity, owner, correction in Salesforce, note in the channel. Bulk updates through an agent trigger the same validation rules, Flows and triggers as a data-loader job; the failure modes are the same, and so is the cleanup.
The fine print
Salesforce in Claude is in pilot; open beta is expected in September 2026 — not a GA date. Do not put revenue-critical processes on it this quarter.
Headless 360 Hosted MCP Server is Beta under Salesforce’s Beta Services Terms; API v67.0 or later is required.
The 37 skills are sales skills. Marketing, Service, Commerce, Revenue, Field Service, Tableau, MuleSoft, Informatica, Data 360, Headless 360 and Industries are “coming soon” with no dates.
Pricing is consumption-based on two sides (Salesforce API access by license edition; Anthropic inference). No list price is published; the “two invoices” description is from an interview, not documentation.
Zero data retention applies to Sonnet, Opus and Haiku in the Claudeforce setup. Whether that satisfies your DPIA or contractual requirements is your compliance team’s call, not the vendor’s.
Slack agents (Claude Tag) are set up separately from the per-user plugin; check which credentials each agent carries before it touches regulated objects.
Enterprise Frontier Safeguards are announced for fall 2026 — do not build a control on them yet.
Model optionality exists in Agent Builder but is only real if somebody maintains and re-tests the alternative.
Questions to settle before you sign
Before you sign · questions to settle
Which profiles and permission sets will the first pilot users carry — and who audits them before the plugin’s first context sweep?
Read-only first: which skills are allowed to write, and from which sprint on?
Where does human approval sit — external email only, or every record update on regulated objects?
Who owns the Anthropic consumption line, and how is it instrumented per user and per skill?
Which Agentforce agents are pinned to a specific model, and who re-tests them when the default changes?
What is the handoff between a rep working in Claude and a campaign team working in Marketing Cloud — and where is it logged?
Who owns the incident when an agent writes wrong data, and what is the correction path?
The line that matters
The screens are optional now. Your permission model isn’t. Salesforce has spent 27 years teaching people where to click. Claudeforce is the announcement that the clicks were never the product — the data, the rules and the permissions were. Companies that treat this as an AI project will buy licenses. Companies that treat it as a governance project will get the 30 seconds.
A partnership brand announced on 26 August 2026, covering three things at three different stages. Salesforce in Claude is a plugin with 37 prebuilt sales skills, in pilot now with open beta expected in September 2026. Claude in Salesforce makes Claude the reasoning model for the Atlas Reasoning Engine in Agentforce, the default in Agentforce Vibes and Coworker, and selectable in Agent Builder. Claude in Slack makes it the default model for Slack AI and Slackbot. The interesting part is not the name: it is that the largest CRM vendor has decided the interface people use to reach its data no longer has to be its own.
Does Claudeforce introduce a new permission model?
No, and that is the single most important sentence in the announcement. Every Hosted MCP transaction runs as the authenticated user, scoped through an External Client App with the mcp_api OAuth scope on API version 67.0 or later. Object CRUD, field-level security, sharing rules, profiles and permission sets apply unchanged, and the audit trail attributes every action to the human who asked. It cuts both ways: existing governance carries over for free, and every over-provisioned profile that survived the last three cleanups is now reachable through a conversational interface.
What has to happen before the plugin is installed?
A permission audit – the cheapest step in the whole rollout and the one most pilots skip. List the pilot users, export their profiles, permission sets and sharing exposure, and remove what they do not need for their job today. The reason is timing: the plugin’s first context sweep reads everything the connection can reach, so the cleanup belongs before that moment rather than after it.
How should a Claudeforce rollout be sequenced?
In five phases, and the order matters. Phase 0 is the permission audit before anything is installed. Phase 1 is a read-only pilot: ten users, four weeks, read-only dispatch only, limited to briefing, pipeline review, call prep and conversation summary, measuring time-to-first-useful-answer and consumption per user per day. Phase 2 adds write access skill by skill, starting with activity logging, each writing skill with a named owner and a rollback path. Phase 3 puts human approval where regulation bites and tests that the approval actually interrupts the flow, in a sandbox, with a real user. Phase 4 scales by market and instruments consumption. Nothing writes before Phase 2, nothing scales before Phase 3.
How do you train a sales team that never wanted to be technical?
Not with a prompt-engineering workshop. Representatives need a catalogue and three habits. The catalogue is the 37 skills on one printed page, grouped the way Salesforce groups them – someone who can see that close plan is a skill will ask for a close plan, someone told that Claude can help with anything will ask for nothing. Habit one: ask in your own words, then verify one fact. Habit two: say what you want done, not how – this takes about two weeks to unlearn after years in Lightning. Habit three: know which actions wait for a human and what to do when an answer looks wrong. The format is fifteen minutes in the weekly sales meeting for six weeks, one skill per week, one representative showing what they asked and what they got.
Which number predicts whether a Claudeforce rollout survives month two?
The share of representatives who used the plugin three days in a row. Not the number of prompts. Two other numbers are worth tracking alongside it – activity-logging completeness, which the hygiene skill reports, and the time from meeting to logged outcome – but the three-days-in-a-row figure is the one that predicts survival.
How does a representative working in Claude hand off to a team working in Marketing Cloud?
Through the activity log, which becomes the contract between them. Marketing skills are not in the first wave – Service, Marketing, Commerce, Revenue, Field Service, Tableau, MuleSoft, Informatica, Data 360, Headless 360 and Industries are marked coming soon with no dates – so the representative now works where the campaign team cannot see. If the representative logs the interaction through the skill, the campaign team can build on it: through Data 360 today, through a marketing skill when it ships.
What happens when an agent writes wrong data?
It is an incident, not a chat message. That means a severity, an owner, a correction in Salesforce and a note in the channel. Bulk updates through an agent trigger the same validation rules, Flows and Apex triggers as a data-loader job, so the failure modes are the same and so is the cleanup.
What is Headless 360 and how does it work?
A hosted MCP server called platform/headless-360, in beta since July 2026. MCP, the Model Context Protocol, is the open standard that lets an AI assistant call another system’s tools. Rather than exposing thousands of endpoints, the server presents exactly four: Discover runs a semantic search over the operations your org can perform, Describe returns the technical contract for one of them, Dispatch executes it, and Dispatch Read-Only executes GET operations and, in Salesforce’s words, never changes data or configuration. The 37 sales skills are task recipes on top of these four.
Where does Claude run, and what happens to the data?
Claude is served through Amazon Bedrock inside the Salesforce Trust Boundary, with zero data retention on the Sonnet, Opus and Haiku models in this configuration. Salesforce calls Anthropic the first LLM provider integrated at that level. For a regulated company that is the difference between a tool the security team can review and one it has to block – but whether it satisfies your own data protection impact assessment and contractual requirements is your compliance team’s call, not the vendor’s.
What does Claudeforce cost?
No list price has been published. Salesforce’s Patrick Stokes describes two lines: consumption pricing on the Salesforce side, with API access scaling by license edition, plus Anthropic’s inference costs billed separately. He also says token consumption is certainly not zero, but nowhere close to development use case levels. Both statements come from interviews rather than a documented price list, so plan for instrumentation before you plan for a budget number.
Working on this?
If your team is weighing this up, the useful question is not what the agent can do but which of your objects it is allowed to write to. I work through that with Salesforce teams in regulated industries.
Three weeks ago, the screen where pharma teams approve marketing content changed. Nobody at those companies clicked “enable.”
Veeva Vault 26R2 went to general release on July 31 and August 7. For PromoMats – the system where promotional material passes medical-legal-regulatory (MLR) review – the notable part is not one feature. It is how many changes arrive already switched on.
What shipped, exactly
A rebuilt document viewer, auto-on in every Vault. Familiar toolbar actions (Bring Forward Annotations, Suggest Links, View Links) now live in the All Actions menu; Bookmarks, Destinations, Glossary, Thumbnails and Annotations moved to the Doc Info pane toolbar.
eCTD redline annotations, enabled in all PromoMats Vaults – compliance packages now render redlines instead of the legacy blue links.
The “Auto-Link on Initial Upload” admin checkbox is fully removed. Auto-linking now follows the lifecycle-state settings introduced in 26R1.
Claim links change color with the claim’s lifecycle state – approved, withdrawn, or in between, visible at a glance.
One rename on top: what the interface called “Veeva AI” is now “Vault AI.”
The Monday after the release weekend
Picture a global brand team: one PromoMats Vault, twelve markets, about 900 promotional assets through MLR review each quarter.
Reviewers open the new viewer – and familiar toolbar icons have moved into the All Actions menu.
The auto-linking behavior the admin once tuned with a checkbox now runs on state-based rules someone has to re-document.
The next eCTD compliance package renders redline annotations the regulator has never received from this company before.
None of this was on the team’s release calendar. It shipped on Veeva’s date, not theirs.
The architecture behind it
MLR review is the gate every channel depends on: approved emails, CLM decks for field teams, websites, congress materials. When the gate’s controls change on the vendor’s schedule, release notes stop being reading material and become change requests. Concretely: the removed auto-link checkbox is replaced by the Text Asset Auto-Linking Settings page from 26R1, where you define the lifecycle states in which auto-linking runs – if nobody migrated your settings, you need to verify current behavior now. Claim-link styling follows the Claim record’s lifecycle state (light blue approved, medium blue not-approved, gray withdrawn), with a green/red/orange circle indicator. And the release timing itself runs in POD waves – prerelease July 13, general release July 31 and August 7 – with session-timeout changes following separately in the week of September 23.
The teams that treat release notes as change requests – retrain reviewers, re-document auto-linking rules, re-generate a test eCTD package – keep channels moving. The Head of Commercial Content who does not will learn about 26R2 one support ticket at a time. In regulated pharma and medical organizations, that difference is measured in stalled campaigns.
The fine print
Not everything is switched on. The AI pieces – chat, version-compare summaries, the new AI tab – need a signed agreement (a zero-dollar order form) plus admin enablement and agent activation.
The AI tab is early adopters only in 26R2; agent improvements are planned bi-weekly between 26R2 and 26R3.
Claim-variation suggestions (the magnifying-glass icon) appear only in Vaults using Claims Agent.
The authoritative list of what turns itself on is not the release notes – it is Veeva’s Release Impact Assessment (RIA) spreadsheet. Check it before any internal comms.
Questions to settle before your next MLR cycle
Which lifecycle states does auto-linking run in now – and does that match the old checkbox behavior?
Has anyone re-generated a test eCTD package to see the redline output before a regulator does?
Who owns reviewer retraining for the new viewer – content ops or IT?
Is the AI order form signed, and if so, which agents are actually activated?
Does your validation and change-control process treat vendor auto-on changes as change requests?
The feature list is Veeva’s. The change management is yours.
What changed in the PromoMats MLR review screen with Veeva 26R2?
A rebuilt document viewer, switched on automatically in every Vault. Familiar toolbar actions such as Bring Forward Annotations, Suggest Links and View Links now live in the All Actions menu, while Bookmarks, Destinations, Glossary, Thumbnails and Annotations moved to the Doc Info pane toolbar. General release ran on 31 July and 7 August 2026.
Which 26R2 changes arrive switched on, and which need enabling?
The viewer, the eCTD redline annotations and the claim-link colour coding arrive on. The AI pieces – chat, version-compare summaries and the new AI tab – need a signed zero-dollar order form plus admin enablement and agent activation. The authoritative list of what turns itself on is not the release notes but Veeva’s Release Impact Assessment spreadsheet.
What happened to the Auto-Link on Initial Upload setting?
The admin checkbox is fully removed. Auto-linking now follows the lifecycle-state settings introduced in 26R1, configured on the Text Asset Auto-Linking Settings page, where you define the states in which auto-linking runs. If nobody migrated those settings, current behaviour has to be verified rather than assumed.
Working on this?
Release defaults that nobody enabled are the most common source of surprise in Vault. A pass over what changed in your own instance is short work, and I do it regularly.
Sources: Veeva Vault – What’s New in 26R2 · Veeva Vault – Latest Announcements (both fetched Aug 27, 2026). Veeva, Veeva Vault and PromoMats are trademarks of Veeva Systems Inc. This is an independent analysis; no partnership with or endorsement by Veeva. First published as part of my LinkedIn series, August 2026.
Unpopular opinion: the most important thing Salesforce shipped for marketers this month is the feature that stops you from writing. Not the one that writes for you. Both are in the same release.
Everyone will talk about the first one. Describe your campaign in plain language, and Marketing Cloud Next (Salesforce’s rebuilt marketing platform) drafts the email and the SMS – using your brand guidelines and your own assets. Impressive. Genuinely. But in a bank, an insurer or a pharma company, “who wrote it” was never the problem. The problem was what went out without the sentence the regulator requires.
What shipped, exactly
Agentforce drafting in Marketing Cloud Next: campaign briefs in plain language become email and SMS drafts, grounded in brand guidelines and existing assets.
Template-level guardrails – the quieter feature: lock the subject line, require certain phrases to be present, cap how long a line may run.
Approved content sets per block: hand a distributed team a fixed set of approved wordings and approved images per content region – and nothing else gets through.
Status: in the Winter ’27 release notes, still in preview. Production orgs start upgrading on August 29, rolling across three weekends.
Why the constraint beats the capability
A brand book is a PDF nobody opens. A template guardrail is a rule the tool won’t let you break. That difference decides whether AI-drafted volume is a blessing or a liability: an AI that drafts four hundred emails a week only pays off if the approval queue doesn’t grow with it. Guardrails are what turn “more content” into “content that still ships.” And for a Head of Compliance, this is the first version of that conversation that ends well.
The architecture behind it
Approved wordings and images are configured per content region – the editable box inside the template. The reported cap is up to 30 approved phrases and 30 approved images per block. Which means the number of free-text regions you leave open is, quite literally, your residual manual review load. Template design becomes a compliance decision, not a design decision – and the people who define regions and approved sets need training and documented rules, not just editor access.
The fine print – where the guardrail stops
“Required phrase present” is a presence check, not a context check. The mandatory sentence can be in the email and still sit in the wrong place, under the wrong offer, in the wrong size.
Character limits are structural. They stop layout breakage, not misleading claims.
A locked subject line still contains personalization tokens. Lock the wording, and the merge field can still produce something you didn’t intend.
None of this is an approval record. There is no MLR-grade audit trail here of the kind Veeva Vault provides by default. Guardrails shrink the volume that needs a reviewer – they don’t remove the reviewer, and they don’t prove to an auditor that a reviewer existed.
Questions for the next steering call
Which content regions stay free-text – and who signed off on that list as a compliance decision?
Who maintains the approved-phrase and approved-image sets per block, and on what review cadence?
Would you let an AI draft your customer email if the template guaranteed the mandatory line was in it – or does that still need a person’s name on it?
Where does your audit trail live, given the guardrail itself is not an approval record?
Are you measuring approval-queue depth – the metric that decides whether AI drafting pays off at all?
The gap between “the tool prevented it” and “we can prove we checked it” is where most implementations quietly fail an audit. That gap is the real project.
What are template-level guardrails in Marketing Cloud Next?
Rules set on the template rather than in a brand book: lock the subject line, require certain phrases to be present, cap how long a line may run, and hand a distributed team a fixed set of approved wordings and approved images per content region. The reported cap is up to 30 approved phrases and 30 approved images per block. In the Winter 27 release notes the feature is still in preview.
Where do template guardrails stop?
At presence rather than context. A required-phrase check confirms the mandatory sentence is in the email, not that it sits in the right place, under the right offer or at a readable size. Character limits stop layout breakage, not misleading claims. And a locked subject line still contains personalization tokens, so the merge field can still produce something unintended.
Do guardrails replace an approval record?
No. There is no MLR-grade audit trail of the kind Veeva Vault provides by default. Guardrails shrink the volume that needs a reviewer; they do not remove the reviewer, and they do not prove to an auditor that a reviewer existed. The gap between the tool prevented it and we can prove we checked it is where implementations quietly fail an audit.
Working on this?
Guardrails that stop you writing are usually pointing at a modelling decision made much earlier. Finding that earlier decision is most of the job, and it is the part I get called in for.
Every pharma company keeps two copies of every approved asset: one in the content vault, one in the CRM the reps use. Ask your team a simple question – are they identical right now? If the answer takes longer than 30 seconds, you have a version-lag problem.
With Veeva’s 26R2 release (Wave 1 live July 31, Wave 2 August 7), a feature most release summaries skip changes this: documents approved in PromoMats now flow into Vault CRM automatically – near real-time, no manual handoff.
What shipped, exactly
26R2 Document Transfer: PromoMats-approved documents are created or updated in the connected Vault CRM automatically.
Timing: Wave 1 July 31, Wave 2 August 7, 2026.
Prerequisite: both vaults plus a configured Vault-to-Vault connection. No separate SKU mentioned in the release notes.
The architecture behind it
Document Transfer runs over the standard Vault-to-Vault connection. When a document in PromoMats is created or modified, the integration creates or updates a CrossLink document in the connected Vault CRM.
The detail that matters: CrossLinks can bind statically (pinned to one version) or dynamically (always the latest steady-state version). That binding choice decides whether field teams see the newest approved version automatically – or a frozen one. Configure it wrong and you have automated the version lag instead of removing it.
Why this matters
Until now, someone had to move approved content from the approval system into the CRM – a manual step, and every manual step creates lag. Lag is where the risk lives: a rep presenting a slide that was superseded three weeks ago isn’t breaking any rules – the outdated file was sitting right there in their system. That’s not a training gap. It’s an architecture gap.
When a Head of Regulatory asks “can outdated content reach the field?”, the honest answer used to be “yes, for a few days at a time.” From 26R2 on, it can be “no, by design.” For a CMO that means faster content-to-field and one less audit finding waiting to happen; for content ops, hours of file admin gone every week.
Questions to settle
Static or dynamic CrossLink binding – which document classes need “always latest”, which need a pinned version?
Is the Vault-to-Vault connection configured and monitored – who sees sync failures?
How long does approved content take to reach your field teams today – hours, days, or has nobody measured it?
What happens to the manual export process and the people who ran it – retired, or kept as a shadow copy that reintroduces the lag?
Documents approved in PromoMats are created or updated in the connected Vault CRM automatically, in near real time, without a manual handoff. Wave 1 went live on 31 July and Wave 2 on 7 August 2026. It requires both vaults plus a configured Vault-to-Vault connection; the release notes mention no separate SKU.
What is the difference between static and dynamic CrossLink binding?
A CrossLink can bind statically, pinned to one version, or dynamically, always pointing at the latest steady-state version. That binding choice decides whether field teams see the newest approved version automatically or a frozen one – configure it wrongly and the version lag is automated rather than removed.
Why is content version lag an architecture problem rather than a training problem?
Because every manual step creates lag, and lag is where the risk lives. A representative presenting a slide that was superseded three weeks ago is not breaking any rule – the outdated file was sitting in their system. Removing the manual step removes the gap.
Working on this?
Automatic transfer is useful right up to the point where two systems disagree about which version is approved. Deciding who owns that answer is a short conversation that saves a quarter.
Sources: Veeva Vault 26R2 release notes (Document Transfer) and release timing on rn.veevavault.help. Veeva, Vault, PromoMats and Vault CRM are trademarks of Veeva Systems Inc. This is an independent analysis; no partnership with or endorsement by Veeva. First published as part of my LinkedIn series, July 2026.
SMS marketing will be dead by 2028. Not because a better channel launched – because fraud killed the trust. Every fake “your parcel is waiting” text trains your customers to ignore the real ones, and banks feel it first: fraud teams now tell customers to distrust any link in a text message. So the marketing budget pays for messages the fraud department tells people to ignore.
Last month, Salesforce quietly shipped the fix. RCS messaging is now built into Marketing Cloud Next – the rebuilt marketing platform Salesforce also calls Agentforce Marketing. RCS (Rich Communication Services) is the successor to SMS: messages land in the same inbox, but with a verified sender name, your logo, images and tap-to-reply buttons. An app-like experience without asking anyone to download an app. And the detail most people missed: Germany and France are in the first supported wave.
What shipped, exactly
RCS as a native channel in Marketing Cloud Next – part of the Summer ’26 release, generally available since June 15, 2026. Salesforce’s own release note frames it as “RCS channel support” for the multichannel strategy, not a beta.
RCS Message as a content type in Salesforce CMS: once RCS is configured and sender identities are verified, marketers build messages with text, media (images, videos, documents), rich cards and interactive suggestions – reusable content, not per-send assets.
Verified brand identity: the carrier confirms the message really comes from the registered brand – company name and logo displayed, read receipts included. This is what plain SMS never had.
Delivery countries at GA: United States, United Kingdom, Mexico, Brazil, Germany and France.
Sending and measurement: segment-triggered flows and automation-triggered events send RCS messages; metrics land in the Marketing Performance dashboard; data kits sync RCS engagement data into Data Cloud.
The scenario: a bank’s “suspicious login” message
Take the message every bank sends and every customer has learned to fear. The visual above shows the two versions side by side.
Today (SMS): a plain-text bubble from an unknown number – “Unknown +49 170 …” – with a shortened link. It looks exactly like the smishing text the same bank’s fraud team warned about last week. The rational customer does not click. The message was paid for anyway.
Now (RCS in Marketing Cloud Next): the same message arrives under the bank’s verified sender name with its logo and a verification badge. There is no link to distrust: a rich card carries the context, and two suggested-reply buttons – “That was me” / “Talk to us” – handle the response inside the messaging app.
The reply flows back as engagement data, into the Marketing Performance dashboard and, via data kit, into Data Cloud – where it can trigger the next step of a flow.
The Chief Risk Officer’s question – “can fraudsters spoof this too?” – finally gets an honest answer: much, much harder. The sender identity is registered and carrier-verified, not a phone number anyone can rent.
For a CMO at a bank or insurer this is not a feature toggle. It’s a channel decision.
The architecture behind it
The setup path is short on paper: Marketing Cloud Setup → Unified Messaging → RCS. There you request an RCS agent – and the naming deserves a warning, because this “agent” has nothing to do with Agentforce. It is your brand’s verified sender identity, the RCS equivalent of an SMS sender ID. That request is the step most teams underestimate. Verification runs through carriers and is country-dependent; budget weeks, not days, and plan it per market rather than assuming Germany and France clear at the same time.
Consent is the second structural piece. RCS opt-ins are stored as communication subscriptions, with default preference pages to capture them. A “rich” opt-in is still a mobile-messaging opt-in – but check your existing consent records before switching channels. If your SMS consent was collected for “text messages from us”, your legal team decides whether that covers a branded, interactive channel, not the platform. The built-in test number lets you validate connectivity before the agent goes live; only after that can marketers import consent and start building.
Content architecture is where the reuse pays off. Rich cards, carousels and suggested replies are modeled as RCS Message content in Salesforce CMS – the same content layer as the rest of Marketing Cloud Next – so an approved card is built once and referenced by many flows. Plan your content model accordingly: a card for each recurring intent (transaction alert, offer, appointment), not a new asset per campaign. Sending then rides on the standard rails – segment-triggered flows and automation-triggered events – which means RCS joins email, SMS and WhatsApp as one more channel in the same orchestration model rather than a side system.
Finally, the commercial layer: RCS is a consumption-based product. Salesforce meters it as “Salesforce Message Credits – RCS”, visible in Digital Wallet under the Consumption Cards tab, and the channel requires the RCS and Digital Engagement add-ons on top of a Marketing Cloud Next Growth or Advanced edition. That is a contract conversation before it is a configuration task.
The fine print
Licensing applies. Enterprise or Unlimited edition, Marketing Cloud Next Growth or Advanced, plus the RCS and Digital Engagement add-ons. Message credits are metered separately from SMS.
Country list moves. The GA wave was US, UK, Mexico, Brazil, Germany and France; the release note has since added India. Check the current list per market before promising a rollout date.
Carrier dependency. Delivery and sender verification depend on carrier support in each country – the platform does not control that timeline.
Fallback is a consent question, not just a technical one. Where a device cannot receive RCS, the practical fallback is SMS – so the plain-text version of every message still needs to exist and still needs to be one your fraud team would not object to.
“RCS agent” ≠ AI agent. Salesforce says so explicitly. Do not let the word confuse a governance review that already has Agentforce on the agenda.
Verification raises the bar; it does not remove it. Verified sender makes brand spoofing much harder. It does not stop fraudsters from using other channels, and it does not train customers back to trust overnight.
Questions for the next channel review
Does “SMS” in your 2027 channel plan still mean plain text – and has your fraud team seen that plan?
Which markets are you actually licensed and verified for, and when does carrier verification start for each?
Does your existing mobile-messaging consent cover a branded, interactive channel, or do you need a re-permission campaign first?
Which three recurring messages would you rebuild as reusable rich cards first – and who owns them?
What does an RCS message cost versus an SMS in your contract, and what response rate makes the difference pay off?
Who answers when a customer taps “Talk to us” at 11 pm?
If “SMS” in your 2027 channel plan still means plain text, you are funding a channel your own fraud team is warning customers about. The successor is live, and it is live in Germany. The question is whether your customers will still trust a verified bank message – or whether texting has already lost them for good.
RCS – Rich Communication Services – is the successor to SMS, available as a native channel in Marketing Cloud Next and generally available since 15 June 2026. Messages land in the same inbox as a text, but with a carrier-verified sender name, the brand logo, images, rich cards and tap-to-reply buttons. Delivery countries at general availability were the United States, the United Kingdom, Mexico, Brazil, Germany and France; India has since been added.
Is an RCS agent the same as an AI agent?
No, and Salesforce says so explicitly. The RCS agent is the brand’s verified sender identity – the RCS equivalent of an SMS sender ID – requested under Marketing Cloud Setup, Unified Messaging, RCS. Verification runs through carriers and is country-dependent, so budget weeks rather than days and plan it per market instead of assuming several clear at once.
Does existing SMS consent cover RCS?
That is a legal question rather than a platform one. RCS opt-ins are stored as communication subscriptions, with default preference pages to capture them. If the existing consent was collected for text messages, whether it covers a branded, interactive channel is for legal to decide before the switch – not something the platform settles.
What does RCS cost in Marketing Cloud Next?
It is a consumption-based product. Salesforce meters it as Salesforce Message Credits for RCS, visible in Digital Wallet under the Consumption Cards tab, and the channel requires the RCS and Digital Engagement add-ons on top of a Marketing Cloud Next Growth or Advanced edition. That makes it a contract conversation before it is a configuration task.
Working on this?
RCS changes what a message can do and what a brand has to prove before it sends one. If you are looking at it for regulated messaging, the verification step is where to start.
Wir verwenden Cookies und ähnliche Technologien. Technisch notwendige Cookies sind für den Betrieb dieser Website erforderlich. Statistik-Cookies setzen wir nur mit Ihrer Einwilligung. Ihre Auswahl können Sie jederzeit ändern.
Notwendig
Always active
Die technische Speicherung oder der Zugriff ist unbedingt erforderlich, um die Nutzung eines von Ihnen ausdrücklich gewünschten Dienstes zu ermöglichen oder eine Nachricht über ein elektronisches Kommunikationsnetz zu übertragen.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistik
Die technische Speicherung oder der Zugriff erfolgt ausschließlich zu statistischen Zwecken – etwa zur Auswertung, wie diese Website genutzt wird.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
Die technische Speicherung oder der Zugriff dient dazu, Nutzerprofile für Werbung zu erstellen oder Nutzer über Websites hinweg zu vergleichbaren Marketingzwecken zu verfolgen.
