A lot of people using Salesforce would rather talk than type. Agentforce Voice lets an Agentforce agent hold a spoken conversation, and it is available today. If you have already built a text agent, you can reach those people without starting over.

Voice does add a few new challenges. Once an agent takes spoken input, things can break. When a user says “async”, the agent can receive it as “a sink.” A reply that looks fine on screen can sound robotic out loud. These problems are easy to miss until a real conversation goes wrong.

This post covers key best practices for voice-enabling Agent Script agents, using one small Agent Script as an example. It walks through what it takes overall, what your org needs first, how to add the voice settings to your script, and how to write instructions for the ear.

What does it take to voice-enable an Agent Script agent?

It takes two steps, and not much else. The first step, configuring the agent for voice, is org setup plus a few settings: you turn on voice in your org, then add blocks that connect the agent to a voice channel and pick its voice. The second step, adjusting how it speaks, is instructions: a reply read out loud follows different rules than one read on a screen. Everything else stays the same. You keep the same personality, the same goal, and most of the same instructions.

Our example is a Rubber Duck Debugger agent. It is a debugging buddy that helps developers find bugs by asking one question at a time, instead of just giving the answer. It comes in two versions: a plain text version and a voice version tuned for speaking. This table shows what changes between them:

The screenshot below shows the instructions side by side: the text version on the left, and the spoken-style version on the right. Notice how the spoken version adds transcript repair and spells symbols out in words. 

What does my org need before I can use voice?

Before you write any voice code, there is one thing to check in your org that will save you from following this entire post and then hitting a wall at deploy. The voice version only works in a Salesforce org where Agentforce Voice is turned on. That is org setup, and a script cannot do it for you.

An admin configures Agentforce Voice in Setup. See the Agentforce Voice product page for what it can do. Agentforce Voice runs on Salesforce Voice with Telephony Providers (formerly Service Cloud Voice), so the voice connection can be a browser voice preview, or full phone support through Amazon Connect or a partner provider.

Want to check quickly whether your org is already set up? Open any agent in Agentforce Builder. In the Explorer on the left, click the plus button (+) next to Connections, choose Add Connections, and search for Telephony. If it does not show up, your org is not configured for voice yet.

Heads up: As of this writing, a free Developer Edition org does not include Agentforce Voice. It includes the licenses, but it does not show the full Agentforce Voice setup, so you cannot turn on a voice connection there.

How do I add voice settings to an Agent Script agent?

With voice turned on in your org, the next step is the code. Three blocks turn a text agent into a voice agent, and they also let you pick the voice model and persona right in the script. Keeping them in the script means the voice setup travels with the recipe, instead of living in a bunch of clicks in the UI.

Block 1: Set the language.

language:
   default_locale: "en_US"

The top-level language block sets the language the agent replies in. Voice mode only works with certain languages, so pick one you know is supported. It is also required once you add voice: without it, the agent uses your org’s default language, and if that language is not supported, Agentforce Builder warns you about it. To use more than one language, see the LanguageSettings recipe.

Block 2: Connect to a voice channel.

connection telephony:
   adaptive_response_allowed: True

The connection telephony block is what actually makes it a voice agent. Without it, you just have a text agent with short instructions. This block is the one that needs voice turned on in your org, since it points to the telephony connection you checked for earlier.

Block 3: Pick the voice model and persona.

modality voice:
   language:
      default_locale: "en_US"
   outbound:
      persona_id: "74752e92d40e"
      model:
         id: "eleven_flash_v2"
   inbound:
      filler_words_detection: True

The modality voice block picks the voice model and the persona that speaks your agent’s replies. It has three parts:

• outbound is how the agent speaks. persona_id is the voice, and model.id is the voice model. Here we use eleven_flash_v2, a lower-latency English model. Each language has a default model, so you can leave model out and get the default, but setting it lets you pick a faster model, with finer control over speed and stability (Flash), or a Japanese voice (Kotoba). At the time this post was written, Agentforce Voice supports ElevenLabs v3 Conversational (eleven_v3_conversational), ElevenLabs Flash v2.5 (eleven_flash_v2_5), ElevenLabs Flash v2 (eleven_flash_v2, English only), and Kotoba (kotoba, Japanese).
• inbound is how the agent listens. filler_words_detection helps it handle “um” and “uh” in what it hears.
• language sets the locale for the voice, and this one matters more than it looks. You do not need to memorize a persona_id. Each model has a voice catalog you copy one from.

You may have noticed language appears twice: once at the top level and once inside modality voice. That is not a mistake. You need both. The top-level block sets the language the agent replies in; the nested one sets the language for the voice. The nested block is also what makes the persona_id work: a persona belongs to a specific model and language, so without a language inside modality voice, the persona has nothing to resolve against and the voice quietly falls back to the default.

To find a persona_id in a model’s catalog, or to read more about voice models, see Voice Catalog for Agentforce Voice.

Set the voice model in the Script view. The Canvas view does not expose a voice-model selector.

A legacy format for modality voice uses a flat voice_id with outbound_speed, outbound_stability, and outbound_similarity. It still works, but it cannot pick a voice model, so to choose one, use the model structure above.

How do I write agent instructions for voice?

A listener cannot reread a sentence. That one fact shapes every voice instruction you write. The spoken debugging subagent keeps the same job as the text version, but its instructions field is written in three parts.

Part 1: Keep the same rubber-duck role.

| You are the developer's rubber duck, talking with them out loud.
  Help them discover the bug on their own instead of handing over the fix.

This is the same job as the text version. The agent guides developers to the bug instead of handing over the fix. Voice does not change the personality or the goal, so this part barely changes.

Part 2: Repair the speech-to-text transcript.

| Their words reach you as speech-to-text, so technical vocabulary is
  often garbled - "agent for script" means "Agent Script", "returns on
  the even" means "returns undefined", "a sink" means "async". Read every
  message charitably in a software-debugging context and quietly repair
  obvious mishears.

The agent never receives raw audio. Instead it receives a speech-to-text (STT) transcript, and that transcript is not always right. Technical words break first; “async” can arrive as “a sink.” This is the part most teams skip. It tells the agent to expect the noise and quietly fix obvious mishears from the context. Think of it as a safety net: most transcripts are fine, but when a word gets garbled, the agent recovers instead of getting confused.

Part 3: Speak for the ear.

| Keep replies short and easy to follow by ear: speak in full sentences,
  never read code or markdown aloud, and say symbols in words (for example
  "index plus plus" for "i++"). Guide with simple questions like "What did
  you expect to happen?" or "What did you change last?", and stay warm and
  playful.

Out loud, formatting is just noise. The agent should never read code or markdown aloud, and it should say symbols in words, so index++ becomes “index plus plus.” Full sentences help too, since a listener cannot piece together a fragment. These small changes are the difference between a reply that sounds natural and one that sounds like a screen reader.

Notice what did not change across all three parts. The personality and the goal are the same as the text version. You are only changing how the agent talks and how it reads what it hears, not rebuilding it.

Try it yourself

The best way to learn this is to deploy the recipe yourself. Clone the Agent Script Recipes repo and then deploy the voice agent:

sf project deploy start --source-dir force-app/main/02_actionConfiguration/voiceAgent

Then open Agentforce Studio, start a voice chat, and describe a bug out loud. Notice how the voice version keeps each reply short and recovers when a word gets misheard.

Conclusion

Adding voice to an Agent Script agent is not a rewrite. First, make sure your org has Agentforce Voice turned on, or the voice version will not deploy. Then add the language, connection telephony, and modality voice blocks so the voice setup lives in your script, and pick the voice model and persona right there in the code. Finally, write the instructions for a listener: short replies, no code read aloud, symbols said as words, and one line that fixes misheard terms. That is what keeps a spoken conversation on track. Put the text and voice versions side by side and the pattern is clear: it is the same agent, just tuned for the ear. Have questions? Ask on the Trailblazer Community or reach out to @SalesforceDevs.

Resources

• Agent Script Recipes (GitHub)
• Agentforce Voice
• Agent Script (Agentforce Developer Guide)
• Agentforce Developer Guide
• Salesforce Developers YouTube

About the author

Alex Martinez was part of the MuleSoft Community before joining Salesforce as a Developer Advocate. Today they help developers build with Agentforce and MuleSoft. You can find more of their content on ProstDev, a site that shares MuleSoft tutorials and walkthroughs. Follow Alex on LinkedIn or in the Trailblazer Community.

The post Agentforce Voice for Agent Script: Voice-Enabling Best Practices appeared first on Salesforce Developers Blog.

If a text snippet lacks proper context when retrieved from the vector database, your agent cannot generate an accurate response. This is the structural reality of retrieval-augmented generation (RAG): garbage in, garbage out.

This post shows how pro-code chunking for Data 360 search indexes using Data 360 Code Extension functions can be used to address three common chunking failures: fragmented data tables, multispeaker dialogue, and exposed personally identifiable information (PII). For each, it compares native chunking against custom pro-code chunking and shows the impact on agent responses.

Where native chunking falls short

Data 360 offers reliable native chunking for standard content. Mechanisms like Section-aware chunking and Semantic-based passage extraction cut documents along structural headings or thematic boundaries. They prevent sentences from splitting awkwardly and keep related paragraphs together.

However, enterprise data is rarely clean. It lives in complex multipage PDFs, regulatory records, dense tables, and multispeaker transcripts. When this data is fed into a character-count or token-length splitter, semantic continuity shatters.

How to write and deploy Code Extension functions

Note: The code examples in this post are intended to illustrate the concepts described in a simple way. They are designed for representative, happy-path examples, not for the full range of possible real-world inputs. Because the implementations rely on regular expressions (regex) and other pattern-based heuristics, they can produce both false positives and false negatives. For example, a heuristic might incorrectly classify an ordinary value as an account number or fail to recognize a valid table, speaker label, timestamp, or identifier in an unexpected format. Production-grade implementations of these functions are beyond the scope of this post.

Data 360 Code Extension functions let you deploy pro-code Python scripts natively within the Salesforce trust boundary for unstructured data pipelines where the built-in chunking behavior isn’t enough.

A function is a small, serverless-style unit that takes an input, performs a computation, and returns an output, running fully sandboxed and stateless. You author and debug it locally in your favorite IDE with the Data Custom Code SDK, deploy it through the Salesforce CLI or the UI, and wire it into your pipeline at the search index creation step. A code extension function can also call a generative or predictive model when your use case needs it. To go deeper, see the developer documentation.

How we tested

To test Code Extension custom chunking capabilities and compare them with native chunking capabilities, we evaluated three different documents. You can explore the structure of a chunking function and learn how to deploy it and run it during search index creation in the developer docs.

For each use case, we followed the same methodology:

1. Chunk the same source document via two separate paths:
   
   1. Path A (Native): The standard Agentforce Data Libraries (ADL) route with default chunking configuration
   2. Path B (Code Extension): Custom Python chunking function deployed via Code Extension
2. Query the resulting vector search indexes for Path A chunks using:
   

   SELECT Chunk__c FROM vector_search(TABLE("index_name__dlm"), 'query', 
     'SourceRecordId__c="<adl-id>/<filename>"', 100)
   

3. Query the chunks for Path B by querying the unstructured data model object (UDMO) directly:
   

   SELECT Chunk__c FROM vector_search(TABLE("index_name__dlm"), 'query', 
     'SourceRecordId__c="<adl-id>/<filename>"', 100)
   

4. Compare the chunks retrieved and evaluate what an agent would answer from each.

Use case 1: fragmented data tables

Imagine you are indexing a quarterly financial report (ABC_corp_q4_fy2025_financial_report.pdf): a 5-page PDF containing an executive summary, four dense multicolumn data tables, and forward-looking guidance.

Here are a few snapshots from the financial report document:

The Problem: Standard splitters often slice text strictly by character or token limits. Tables spanning multiple columns lose the relationship between headers and data rows. When your agent retrieves a chunk containing raw numbers, it has no column context to understand what those numbers mean.

You can solve this problem by implementing a structure-aware Python function that detects table boundaries (for example, markdown pipe tables, grid tables, and HTML tables), keeps each table as a unified block, and when a table exceeds the chunk size limit, splits it into sub-chunks with column headers repeated at the top of each sub-chunk.

Sample code

Native chunks: what you get without Code Extension

SELECT Chunk__c FROM vector_search(TABLE("ADL_ABC_Financial_index__dlm"), 
  'test something', 
  'SourceRecordId__c="1JDKd000000kADxOAM/ABC_corp_q4_fy2025_financial_report.pdf"', 100)

Here is what native chunking produced, a wall of numbers with no structural context:

Native Chunk Example 1 (Raw Data Dump):

DataCloud Pro 892 0.68 34.2 78.5 245.8 99.97 42 185 AgentForce 456 0.72 28.7 82.1 189.3 
99.95 38 162 Einstein Analytics 1,245 0.55 22.4 65.3 312.6 99.98 55 210 Flow Builder 678 
0.61 41.8 71.2 98.4 99.99 28 95 MuleSoft Connect 334 0.58 18.9 59.8 567.2 99.96 65 280 
Tableau Cloud 1,567 0.45 26.3 68.9 78.5 99.94 120 450 Commerce Cloud 289 0.71 45.2 74.6 
423.1 99.99 32 128 Marketing Cloud 1,102 0.52 31.5 72.8 198.4 99.96 48 195Service Cloud AI 
567 0.66 25.8 69.4 156.2 99.97 35 142Slack Platform 2,340 0.78 52.1 85.2 892.4 99.99 22 
78 5. Forward-Looking Guidance - Q1 FY2026 Page 4/5

Native Chunk Example 2 (Fragmented Table):

Enterprise Software 156.2 152.8 149.5 2.2 4.5 81.2 38.7 1,350 Professional Svcs 89.4 87.1 
82.6 2.6 8.2 42.1 15.3 980 Hardware & Infra 52.3 54.7 58.9 4.4 11.2 35.6 8.9 620 Emerging 
Mkts & IoT 24.8 21.2 15.4 17.0 61.0 55.4 5.2 340 Security & Compliance 13.4 11.9 9.8 12.6 
36.7 78.1 22.4 210 AI & Automation 42.1 35.8 22.4 17.6 87.9 82.5 28.1 410 Integration 
Platform 38.9 36.2 33.1 7.5 17.5 71.8 26.9 380Developer Tools 28.6 25.4 19.8 12.6 44.4 
76.3 18.2 290 Industry Solutions 52.8 48.9 41.2 8.0 28.2 69.4 24.5 450 Page 2/5

The Problem: As just one example, the numbers following “AI & Automation” (42.1 35.8 22.4 17.6 87.9 82.5 28.1 410) sit in a chunk with no column headers. What is 42.1? Revenue? A margin? A growth rate? Without the header row (Segment | Q4 FY25 Rev($M) | Q3 FY25 Rev($M) | ... | Headcount), these numbers are meaningless. Your agent cannot answer even basic questions about this data.

Code Extension chunks: structure preserved

The custom function detects table boundaries, preserves the header row, and produces structured chunks:

SELECT Chunk__c FROM ADL_ABC_Financial_MultiPage_chunk__dlm

Custom Chunk Example 1 (Executive Summary — Clean Prose):

ABC Corp - Q4 FY2025 Quarterly Financial Report (Confidential)

**Executive Summary**

Total revenue for Q4 FY2025 reached $847.3M, representing a 12% year-over-year increase 
driven primarily by growth in our Cloud Services and Data Platform segments. Operating margin 
improved to 28.4%, up from 25.1% in the prior quarter, reflecting improved cost discipline 
and scale efficiencies across all business units.

Key highlights include the successful launch of three new enterprise products, expansion into 
the APAC market with two new regional data centers, and a 15% reduction in customer churn 
attributed to our enhanced support model. The Data Platform segment showed particularly strong 
momentum with 18.1% YoY growth, driven by increased adoption of our AI-powered analytics features.

Free cash flow generation remained robust at $198.4M for the quarter, enabling continued 
investment in R&D while returning $85M to shareholders through buybacks. Our balance sheet 
remains strong with $2.1B in cash and short-term investments and a net-debt-to-EBITDA ratio of 0.8x.

Custom Chunk Example 2 (Table with Headers Preserved — Revenue by Segment):

**1. Revenue Breakdown by Business Segment**

The following table summarizes revenue performance across all business segments for Q4 FY2025, 
with year-over-year and quarter-over-quarter comparisons, gross margin, and headcount allocation:

* **Cloud Services**
* The Segment has Q4 FY25 Rev($M) of 312.5.
* The Segment has Q3 FY25 Rev($M) of 289.1.
* The Segment has Q4 FY24 Rev($M) of 261.8.
* The Segment has QoQ Growth% of 8.1.
* The Segment has YoY Growth% of 19.4.
* The Segment has Gross Margin% of 72.3.
* The Segment has Op Margin% of 34.2.
* The Segment has Headcount of 2,450.

* **Data Platform**
* The Segment has Q4 FY25 Rev($M) of 198.7.
* The Segment has Q3 FY25 Rev($M) of 185.3.
* The Segment has Q4 FY24 Rev($M) of 168.2.
* The Segment has QoQ Growth% of 7.2.
* The Segment has YoY Growth% of 18.1.
* The Segment has Gross Margin% of 68.9.
* The Segment has Op Margin% of 31.5.
* The Segment has Headcount of 1,820.

Custom Chunk Example 3 (Regional Performance — Each Region Self-Contained):

**2. Regional Performance Matrix**

Geographic revenue distribution across all operating regions, including customer metrics, 
deal economics, and satisfaction indicators:

* **APAC - ANZ**
* Revenue ($M): 52.8
* % of Total: 6.2%
* YoY Growth %: 18.4%
* Customers: 486
* Avg Deal ($K): 108.6
* NPS: 67
* Renewal %: 90.2%
* Expansion %: 114.6%

* **APAC - Japan**
* Revenue ($M): 34.2
* % of Total: 4.0%
* YoY Growth %: 21.5%
* Customers: 312
* Avg Deal ($K): 109.6
* NPS: 71
* Renewal %: 91.8%
* Expansion %: 116.2%

Impact on agent responses

User Query: “What is the YoY growth rate for the AI & Automation segment and how does its operating margin compare to Cloud Services?”

Use case 2: multispeaker dialogue

Now consider a use case in which you’re grounding your service agents on a recorded customer escalation call: a 45-minute platform migration planning session with five participants (Sarah Chen, VP of Engineering; Marcus Webb, Solutions Architect; Priya Desai, Database Lead; Tom Nakamura, DevOps Manager; Lisa Okafor, Customer Success Director).

Source document: Globex_Migration_Escalation_Call_2025_Q4.pdf

Here is a snapshot from the source document:

The Problem: Standard chunking produces massive walls of unstructured text. Speaker boundaries are lost, timestamps disappear, and topical shifts get merged into a single chunk. The result: chunks thousands of characters long where you cannot tell who said what or when.

You can solve this by using a windowed sliding dialogue mechanism with these parameters: WINDOW_SIZE = 6 turns, STRIDE = 3 turns, MAX_CHUNK_CHARS = 1500. This helps ensure that every question and its answer are almost always co-located in at least one chunk. Adjacent chunks overlap so context is virtually never orphaned.

Sample code

Native chunks: what you get without Code Extension

SELECT Chunk__c FROM vector_search(TABLE("ADL_MultiSpeakerCon_index__dlm"), 
  'test something', 
  'SourceRecordId__c="<library-id>/Globex_Migration_Escalation_Call_2025_Q4.pdf"', 100)

Native Chunk Example (Wall of Text — No Speaker Attribution):

Marcus Webb: I think yeah I th I think if you can just get a number whether it's through 
the benchmarks we ran last month or whether we have to do new load tests. If you can just 
get a number and saying if you had to migrate the legacy Oracle instances to the new 
Postgres cluster, how much data volume can we migrate within that within 72 hours or I 
guess even conservatively within 48 hours. Let's go with 48 hours because we probably 
need a buffer for rollback as well. Um do you know just just coming up with numbers of 
how much data we can migrate within a period of timewill give us some kind of uh 
measurement to know how many tenant databases we can cut over within that window or we 
can commit to Sarah Chen: Yeah,Marcus Webb: enough Sarah Chen: because the the challenge 
is like uh we'll be penalized right if we commit to uh certain migration windows if 
we're not able to meet that. 00:25:46 Sarah Chen: So this is a very crucial part of it 
wherein uh we have to kind of come up with these numbers based on uh the actual load 
testing uh given that we're not going the blue-green deployment route and we're doing it 
on a rolling basis. So I think we need that sort of analysis to be Marcus Webb: Priya,
Tom Nakamura: A Marcus Webb: is that something Kevin can can work with the DBA team 
Sarah Chen: done. Tom Nakamura: minute. Marcus Webb: on? Priya Desai: Yeah, I'll follow 
up with Kevin after this Marcus Webb: Okay, thanks.

The Problems:

1. No speaker separation: Turns from Marcus, Sarah, Tom, and Priya are mashed together in a single paragraph
2. Timestamps embedded randomly: 00:25:46 appears midsentence with no structural break
3. Questions divorced from answers: Marcus asks “can Kevin work with the DBA team?” and Priya’s answer is buried without clear attribution
4. Topic bleed: The Oracle-to-Postgres migration capacity discussion runs directly into the SLA penalty discussion with no boundary

Code Extension chunks: windowed dialogue

The custom function parses speaker turns, then creates overlapping windows:

Custom Chunk Example 1 (Clear Speaker Attribution and Overlap):

Sarah Chen: uh so I would uh so that's what my categorization of phases and milestones is. 
Phase one is more longer term more strategic where we want to land up eventually right we do 
want to uh achieve uh reach a point wherein for all the enterprise tier customers we want to 
uh have a zero-downtime migration kind of an approach uh but you know in terms of milestones 
now milestone is more like uh you know various different checkpoints that we have so our first 
milestone is towards end of Q4 when we want to

Sarah Chen: in Yeah. Yeah. So basically that was the next thing that I was going to talk 
about. If you see this these bottom uh you know tiers. So for all the enterprise tier 
customers what we offer them is guaranteed migration within the committed downtime windows 
you know uh they pay for a contractual guarantee. Whereas for all the customers who don't uh 
uh purchase the premium migration package, it'll be on a best effort basis without any 
committed timelines, no contractual SLAs, but they'll

Sarah Chen: anywhere uh we have like three layers. The first two layers talks about schema 
migration and data replication setup. We know the CDC streams are running every 5 minutes. 
The full table snapshots you know every 12 hours and we are also trying to you know make uh 
target uh to reduce the 12-hour sync window to 2 hours for Q4 and uh the development is 
complete and we are in the process of you know testing it and the third layer is where uh you 
know the the actual cutover needs to happen

Custom Chunk Example 2 (Decision and Response Together):

Tom Nakamura: correct as long as uh we are meeting their downtime window requirement they 
don't bother how we are providing Sarah Chen: might Tom Nakamura: them that migration how 
efficient

Sarah Chen: uh so I would uh so that's what my categorization of phases and milestones is. 
Phase one is more longer term more strategic where we want to land up eventually right we do 
want to uh achieve

Sarah Chen: in Yeah. Yeah. So basically that was the next thing that I was going to talk 
about. If you see this these bottom uh you know tiers. So for all the enterprise tier 
customers what we offer them is guaranteed migration within the committed downtime windows

Sarah Chen: anywhere uh we have like three layers. The first two layers talks about schema 
migration and data replication setup.

00:55:02

Sarah Chen: Yeah. Yeah. We Tom Nakamura: Hey. Uh, so our milestone it talks about in terms 
of per tenant for Q4,

Key Difference: Each chunk now contains multiple turns from the same topical exchange. The sliding window (stride of 3) helps ensure that a question asked in one chunk is always paired with its answer. Speaker names are preserved as structural anchors.

Impact on agent responses

User Query: “What is the committed downtime window for enterprise tier customers during the database migration?”

Use case 3: PII masking and regulatory cleansing

In this use case, you’re operating in a regulated sector (for example, healthcare, banking, or public sector) where internal identifiers must be sanitized before ingestion into a vector database that agents will query.

Source document: Sample_PII_Masking_Test_Document.pdf is a five-page document with simulated clinical intake records, banking credit memos, and public sector benefits cases. It contains both standard PII and proprietary identifiers.

Here is a snapshot from the source document:

The Problem: Standard pattern recognition is not applied during chunking via the ADL route. All identifiers, standard and proprietary, pass through into the vector index unmasked.

You can address this by implementing regex-based pattern matching over the raw text inside your custom function before chunking. This cleanses SSNs, credit card numbers, phone numbers, email addresses, employer identification numbers (EINs), ICD codes, and other industry-specific formats on-the-fly. The data is sanitized before it ever reaches the chunk data model object (DMO).

Sample code

Native chunks: all PII exposed

SELECT Chunk__c FROM vector_search(TABLE("ADL_PIIMasking_index__dlm"), 
  'test something', 
  'SourceRecordId__c="1JDKd000000kAE7OAM/Sample_PII_Masking_Test_Document.pdf"', 100)

Native Chunk Example 1 (Healthcare — Full PII Exposed):

Note: The X characters below are synthetic placeholders; they represent identifiers that are present and unmasked, not values that have already been redacted.

CONFIDENTIAL - INTERNAL USE ONLY Meridian Regional Health System Patient Intake & Clinical 
Summary - Q4 2025 Patient Demographics Standard Identifiers Patient Name: Margaret A. Thornton 
Date of Birth: 01/01/1970 Social Security Number: XXX-XX-XXXX Phone: (XXX) XXX-XXXX Email: 
m.thornton@example.com Address: 123 Main St, Anytown, IL 00000 Proprietary & 
Regional Identifiers MRN (Medical Record No.): MRH-XXXX-XXXXXX-X Internal Episode ID: 
EP.Q4.NAP.093871.TNT State HIE Patient Token: ILHIE-PKT-XXXXXXXX-XXXX Payer Member ID: 
BCBSIL-GRPXXXX-MXXXXXXX Referring Provider NPI+Loc: NPI1629384750-LOC.NAP.03 Bed Assignment 
Code: 4N-BED.217-ISO-RESP Regional Trauma Registry ID: ITRS-R5-2025-00847

Native Chunk Example 2 (Banking — All Identifiers Visible):

Credit Analysis Narrative Subject: Apex Manufacturing Solutions (CIF: CNB-CIF-2025-093871-COMM) 
requests $4.2M term loan expansion. Current exposure tracked under facility ID 
FAC-CNB-MW-2025-APEX-001. Borrower maintains primary operating account 
(DDA-CNB-MW-7741093871) with average collected balance of $847K. Guarantor Robert J. Whitfield 
(Internal KYC Profile: KYC-IND-XX-XXXX-XXXXXX, SSN:XXX-XX-XXXX) provides unlimited 
assessment net worth WA-CNB-2025-0291-WHTFLD. personalguarantee. Guarantor verified via 
internal wealth Collateral: IL. Appraisal ordered under engagement APR-CNB-2025-093871-IND 
(Appraiser Vendor ID: VND-APR-MW-0087-CERT). Environmental Phase I completed (Report ID: 
ENV-PH1-2025-APEX-093871).

Native Chunk Example 3 (Cross-System — Re-identification Risk):

Event 2: Employment Verification Timestamp: 2025-11-03T09:15:00Z Source: IL Dept of Revenue 
(System ID: SYS-ILDOR-EMPL-VERIFY) Destination: DHS Benefits (System ID: 
SYS-DHS-IL-ELIG-ENGINE) Subject: SSN XXX-XX-XXXX / DHS-IL-XXXX-XXXX-XXXXXX-XX Employer Match: 
ILDOR-EMP-2025-00-0000000-APEX Income Verified: 
3,847.00/month(PayPeriodID:PP-APEX-2025-B22) Verification Token: ILDOR-VT-2025-1103-093871-CONF

The Problem: Every sensitive identifier sits unmasked in the vector index:

• SSNs: XXX-XX-XXXX, XXX-XX-XXXX, XXX-XX-XXXX
• Credit card number: XXXX-XXXX-XXXX-XXXX
• Email address: m.thornton@example.com
• Phone number: (XXX) XXX-XXXX
• Medical record number: MRH-XXXX-XXXXXX-X
• Internal KYC profile: KYC-IND-XX-XXXX-XXXXXX
• Payer member ID: BCBSIL-GRPXXXX-MXXXXXXX
• DHS case number: DHS-IL-XXXX-XXXX-XXXXXX-XX

When your agent retrieves these chunks, it may echo PII directly back to end users, which constitutes a compliance violation under HIPAA, PCI-DSS, and many state privacy laws.

Code Extension chunks: PII masked before indexing

The custom function applies regex-based pattern matching to sanitize sensitive data before chunking:

Custom Chunk Example 1 (Healthcare — Standard PII Redacted):

CONFIDENTIAL - [SWIFT_REDACTED] USE ONLY Meridian Regional Health System Patient Intake & 
Clinical Summary - Q4 2025 Patient Demographics Standard Identifiers Patient Name: Margaret A. 
Thornton Date of Birth: 01/01/1970 Social Security Number: [SSN_REDACTED] Phone: 
([PHONE_REDACTED] Email: [EMAIL_REDACTED] Address: 123 Main St, Anytown, IL 00000 
Proprietary & Regional Identifiers MRN (Medical Record No.): MRH-XXXX-XXXXXX-X Internal 
Episode ID: EP.Q4.NAP.093871.TNT

Note the ‘[SWIFT_REDACTED]’ token replacing ‘INTERNAL’: an over-broad SWIFT-code pattern matched a plain word. Also note that certain PII,  such as names, addresses, dates of birth are not handled by the example function).

Custom Chunk Example 2 (Banking — Standard PII and Financial IDs Redacted):

Primary Contact SSN: [SSN_REDACTED] DUNS Number: 07-481-2937 Credit Card on File: 
[CREDIT_CARD_REDACTED] (Exp: 09/27) Internal & Proprietary Identifiers Relationship Manager 
ID: RM-COMM.MW.4471.SR Internal Credit Score: CNB-ICS-782-TIER2A Collateral Tracking ID: 
COLL-RE.IL.2025.093871.INDUST Loan Pipeline Position: PL-Q4.2025-MW-00291-PEND Risk Rating 
(Proprietary): RR-CNB-3B-WATCH-MOD BSA/AML Case Reference: AML-SAR.2025.MW.04471 Treasury 
Mgmt Client Code: TM-APEX-MW-4471-SWEEP

Custom Chunk Example 3 (Cross-System Events — SSN and EIN Masked):

Event 2: Employment Verification Timestamp: 2025-11-03T09:15:00Z Source: IL Dept of Revenue 
(System ID: SYS-ILDOR-EMPL-VERIFY) Destination: DHS Benefits (System ID: 
SYS-DHS-IL-ELIG-ENGINE) Subject: SSN [SSN_REDACTED] / DHS-IL-XXXX-XXXX-XXXXXX-XX Employer 
Match: ILDOR-EMP-2025-[EIN_REDACTED]-APEX Income Verified: $3,847.00/month (Pay Period ID: 
PP-APEX-2025-B22) Verification Token: ILDOR-VT-2025-1103-093871-CONF

Custom Chunk Example 4 (Public Sector — Government IDs Masked):

CONFIDENTIAL - [SWIFT_REDACTED] USE ONLY State of Illinois - Department of Human Services 
Benefits Determination & Case Management Summary Claimant Information Standard Identifiers 
Claimant Name: David R. Okonkwo Social Security Number: [SSN_REDACTED] Date of Birth: 
01/01/1980 Driver's License: O-000-0000-0000 (IL) Phone: ([PHONE_REDACTED] Agency-Specific 
& Regional Identifiers DHS Case Number: DHS-IL-XXXX-XXXX-XXXXXX-XX

What got caught and what needs custom patterns

In this test, the Code Extension function successfully redacted:

• SSNs: XXX-XX-XXXX → [SSN_REDACTED]
• Credit card numbers: XXXX-XXXX-XXXX-XXXX → [CREDIT_CARD_REDACTED]
• Email addresses: m.thornton@example.com → [EMAIL_REDACTED]
• Phone numbers: (XXX) XXX-XXXX → [PHONE_REDACTED]
• EINs: 00-0000000 → [EIN_REDACTED]
• ICD Codes: J96.01 → [ICD_CODE_REDACTED]

Proprietary identifiers that require organization-specific patterns (these passed through, demonstrating why you must extend the pattern registry for your formats):

• MRH-XXXX-XXXXXX-X — Medical record number
• BCBSIL-GRPXXXX-MXXXXXXX — Payer member ID
• DHS-IL-XXXX-XXXX-XXXXXX-XX — DHS case number
• ILHIE-PKT-XXXXXXXX-XXXX — HIE patient token

The key insight: Code Extension gives you the framework to add any pattern your organization needs. Standard numeric identifier patterns are handled by the existing sample code. Proprietary formats are added as one-line regex entries:

code here 22

Impact on agent responses

User Query: “What was the clinical pathway for the patient admitted on October 17th?”

Compliance implications

The bottom line: without Code Extension, everything goes into the vector store unmasked. With the Code Extension function, PII formats covered by the sample patterns are masked  during search index chunking, and the extensible pattern registry gives you a path to add proprietary formats as you discover them.

Conclusion

Code Extension functions are not a replacement for native chunking; they provide an escalation path when enterprise data complexity outpaces standard algorithms. Investing in pro-code chunking ensures your search indexes remain contextually rich and drive accurate Agentforce responses.

Get started with Code Extension

What are you waiting for? Start building Code Extensions today: Enable Code Extension in Data 360 setup feature manager, install the Data Custom Code SDK and the Salesforce CLI, and start building right away. To learn more:

• Check out the Code Extension function documentation.
• Watch the Extend Data 360 with Code Extension YouTube playlist.

About the authors

Jitin Mehndiratta is a Product Management Director at Salesforce working on Data 360. He focuses on enabling developers to build intelligent data pipelines that power Agentforce experiences.

Samaritha Patlori is a Product Manager for Code Extension at Salesforce Data 360. With 7+ years across engineering and product, she is currently focused on enabling developers to run custom code securely within Data 360.

The post Pro-Code Chunking of Data 360 Search Indexes for Agentforce appeared first on Salesforce Developers Blog.

Salesforce Multi-Framework (React) が GA になり、Salesforce 上で React アプリを動かせるようになりました。アプリケーションランチャーからフルページで起動するアプリとして使えるようになっていたのですが、やはり LWC のように Lightning Experience（LEX）のページに埋め込みたい ——と考える方も多いのではないでしょうか。

それを叶えてくれるのが Salesforce Microfrontend（UI Embedding） です。

• 公式ガイド（本記事の元にした情報）: Salesforce Microfrontend: Get Started

Microfrontend / UI Embedding は本記事執筆時点で Beta の機能です。今後仕様が変わる可能性があります。検証は Winter ’27 Preview のスクラッチ組織（API 68.0）で行っています。

Salesforce Multi-Framework の React などをはじめ、外部フレームワークで作った UI（UI Bundle）を、lightning-ui-embedding を介して LWC と同じようにレコードページなどへ埋め込めるようにする仕組みです。前回の記事では、React 製の UI Bundle をスクラッチ組織にデプロイして、単体で動かすところまでを試しました。

• 参考: Salesforce で React アプリをマルチフレームワークで動かす

今回はその続きとして、作った React アプリを Case（ケース）レコードページに埋め込む部分に絞って紹介します。埋め込みには lightning-ui-embedding を使い、LWC 側から React アプリへ「今開いているレコードの ID」を渡す、という連携がキモになります。

本記事の内容は、あくまで 2026年9月時点（Beta）で試した範囲の記録 です。ここで紹介する手順やコードは執筆時点で動作したものであり、正式リリース時には作法や API が変わっている可能性があります。その前提でお読みください。

今回作ったもの

題材として「Case Timeline」という読み取り専用のデモコンポーネントを用意しました。1 件のケースにひもづく複数の履歴 —— メール（EmailMessage）、ToDo（Task）、行動（Event）、ケースコメント、ケース履歴 —— を 1 本の時間軸にまとめて表示する React アプリです。

React アプリ自体の作り込み（React 19 + Vite + TypeScript + Tailwind + shadcn/ui）については前回記事の範囲なので、ここでは深追いしません。「こんな見た目のアプリを作った」という前提で読み進めてください。

全体像

埋め込みの登場人物は次の 4 つです。

Case レコードページ
  └─ caseTimelineEmbed （ラッパー LWC / 今回の主役）
       └─ <lightning-ui-embedding>  … iframe を生成
            └─ React UI Bundle（*.salesforce.app から配信）

• React UI Bundle は *.salesforce.app という専用ドメインから配信され、lightning-ui-embedding が iframe として画面に埋め込みます。
• レコードページに直接 UI Bundle を置くことはできないので、間に薄い ラッパー LWC（caseTimelineEmbed）を挟みます。
• このラッパー LWC が「どのアプリを」「どのレコードで」表示するかをアプリ側へ伝えます。

ということで本記事は、ほぼこのラッパー LWC の実装解説です。

ステップ1: 埋め込むアプリの URL を確認して信頼済み URL に登録する

iframe で外部 URL を読み込むため、信頼済み URL（CSP Trusted Site） として登録しておきます。これは公式ガイダンスに沿って [設定] の画面から登録するだけ です。

登録するには、まず埋め込むアプリの正確な URLを知る必要があります。そこで 一度、React アプリを単体でフルに開いてみます。アドレスバーに出る URL を控えます。

あとは [設定] → [セキュリティ] → [信頼済み URL] で、その URL を新規登録し、CSP コンテキストとして frame-src を有効にするだけです。

ステップ2: ラッパー LWC を作る

いよいよ本題のラッパー LWC です。まずはテンプレート（HTML）から。<lightning-ui-embedding> に src（アプリの URL）を渡すだけの、とてもシンプルな構成です。

lwc/caseTimelineEmbed/caseTimelineEmbed.html:

<template>
    <div class="ct-embed-container" style={containerStyle}>
        <!-- 読み込み失敗時のエラー表示 -->
        <template lwc:if={errorMessage}>
            <div class="slds-p-around_medium slds-text-color_error" role="alert">
                {errorMessage}
            </div>
        </template>

        <lightning-ui-embedding
            lwc:ref="embedding"
            src={embeddingUrl}
            sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-modals"
            shell-title="Case Timeline">
        </lightning-ui-embedding>
    </div>
</template>

次に JavaScript です。全体はこれだけです。

lwc/caseTimelineEmbed/caseTimelineEmbed.js:

import { LightningElement, api } from 'lwc';

// 埋め込むアプリの base URL。末尾は「変化しない」パスにする（後述）。
const BASE_URL = 'https://enterprise-fun-7452-dev-ed--c.scratch.my.salesforce.app/app/c__CaseTimeline';

// アプリ側と共有するカスタムイベント名。
// host→app: recordId を渡す / app→host: recordId の送信を要求する。
const RECORD_ID_EVENT = 'caseRecordId';
const REQUEST_RECORD_ID_EVENT = 'requestRecordId';

export default class CaseTimelineEmbed extends LightningElement {
    _recordId;
    // src はマウント後に変化させない（相対アセットを常にアプリのルート基準で解決させるため）。
    embeddingUrl = `${BASE_URL}/timeline`;
    errorMessage;

    // デザイン属性: 初期の高さ。420〜720px にクランプ。
    @api height = 520;

    @api
    get recordId() {
        return this._recordId;
    }
    set recordId(value) {
        if (value === this._recordId) return;
        this._recordId = value;
        // レコード遷移時に新しい id を送る（アプリ未接続なら無害に何もしない）。
        this.sendRecordId();
    }

    get containerStyle() {
        const h = Math.min(Math.max(Number(this.height) || 520, 420), 720);
        return `height:${h}px;`;
    }

    renderedCallback() {
        if (this._listenersAttached) return;
        const embedding = this.refs?.embedding;
        if (!embedding) return;
        this._listenersAttached = true;
        // アプリからの要求（確実）と ready（保険）、どちらでも recordId を送る。
        embedding.addEventListener(REQUEST_RECORD_ID_EVENT, this.sendRecordId);
        embedding.addEventListener('sf-embedding.component.ready', this.sendRecordId);
        embedding.addEventListener('sf-embedding.component.error', this.handleError);
    }

    disconnectedCallback() {
        this._listenersAttached = false;
    }

    // recordId を sf-embedding チャネル経由で app へ送信する。
    sendRecordId = () => {
        const embedding = this.refs?.embedding;
        if (!embedding || !this._recordId) return;
        embedding.dispatchEvent(
            new CustomEvent(RECORD_ID_EVENT, { detail: { recordId: this._recordId } })
        );
    };

    handleError = (event) => {
        this.errorMessage =
            event?.detail?.message ||
            'Case Timeline アプリの読み込みに失敗しました。時間をおいて再度お試しください。';
    };
}

そして、レコードページに配置できるようにするメタデータです。

lwc/caseTimelineEmbed/caseTimelineEmbed.js-meta.xml:

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>67.0</apiVersion>
    <isExposed>true</isExposed>
    <masterLabel>Case Timeline</masterLabel>
    <targets>
        <target>lightning__RecordPage</target>
    </targets>
    <targetConfigs>
        <targetConfig targets="lightning__RecordPage">
            <objects>
                <object>Case</object>
            </objects>
            <property name="height" type="Integer" label="Height (px)"
                description="Component height in pixels (420–720)."
                default="520" min="420" max="720" />
        </targetConfig>
    </targetConfigs>
</LightningComponentBundle>

※ css ファイルは割愛

ステップ3: recordId をアプリへ渡す

埋め込みで一番のポイントが「LWC が持っているレコード ID を、iframe の中の React アプリへどう渡すか」です。

以降は 本記事執筆時点（Beta）で動いた方法 の記録です。UI Embedding はまだ Beta で、データ受け渡しの作法は今後変わる可能性があります。ここで紹介するのは「公式の仕組みの範囲内で、現時点で確実に動かせた一例」くらいに読んでください。正式リリースでは、もっと素直な方法が用意されるかもしれません。

公式の Exchange Data ガイド では、sf-embedding チャネルを通じてデータをやり取りします。用意されている口は主に 2 つです。

1. state.props … LWC が流し込む値（テーマ・ロケール・モードなど）。
2. カスタムイベント … sf-embedding チャネル越しにイベントをやり取りする口。

最初は「recordId は state.props に入ってくるのでは？」と思い、そこから取り出そうとしました。ところが実際にレコードページで中身をログに出してみると props は空（{}） で、recordId は入っていませんでした。そこでコーディングエージェントとも一緒に調べていった結果、現時点では「カスタムイベントで渡す」のが一番確実だった ——というのが、今回たどり着いた形です。

src に /timeline/{recordId} のようにレコード ID を載せる方式もあるかもしれませんが、今回は公式ガイドの手法（カスタムイベント）をベースとしました。

送るタイミングでハマった話（現時点の注意点）

もう 1 つ、送信タイミングでつまずきました。公式ガイドは「ロケールなどのデータは embedding component が ready を報告した後に送る」と案内していて、一見「LWC 側で ready を待って送れば十分」に見えます。ところが今回の構成では、うまくいきませんでした。

embedding.addEventListener('sf-embedding.component.ready', this.sendRecordId);

今回試した限りでは、LWC が ready を受け取って caseRecordId を送るタイミングと、アプリ側でそのイベントを受け取る準備が整うタイミングが、ちょうど前後してしまうことがあるようでした。アプリ側は createViewSDK() の解決を待ってからリスナーを登録するため、LWC からの通知の方が先に届くと、そのイベントを受け取れないことがあったようです。イベントは後から登録したリスナーには届かないため、そのまま取りこぼしてしまう、という状況でした。

※ このあたりは SDK 内部の挙動に関わる部分なので、あくまで今回の環境で観測した範囲からの推測としてお読みください。

そこで、送られてくる順序に左右されないよう、アプリ → LWC へ問い合わせる方式（ハンドシェイク） に切り替えました。アプリは自分のリスナーを登録し終えてから「recordId を送ってください」と LWC へ要求し、LWC がそれに応えて caseRecordId を返します。要求はリスナーの準備が整ってから送るため取りこぼしが起きにくく、今回はこの形で安定しました（ready を契機とした送信も、念のため残してあります）。

• LWC → アプリ: caseRecordId イベントで recordId を渡す
• アプリ → LWC: requestRecordId イベントで送信を要求する（dispatchEvent による app→host は公式にサポート）

LWC 側は、requestRecordId でも ready でも、どちらが来ても recordId を送り返します（前掲の renderedCallback を参照）。

アプリ（React）側の受け取り

受信ロジックはモジュール読み込み時に走る小さなストアにまとめ、app.tsx の先頭（ui-embedding の import 直後）で読み込みます。リスナーを登録したら、その場で requestRecordId を投げるのがポイントです。

src/features/timeline/hostRecordId.ts（抜粋）:

const RECORD_ID_EVENT = 'caseRecordId';
const REQUEST_RECORD_ID_EVENT = 'requestRecordId';

// モジュール読み込み時（＝アプリ起動時）にリスナーを登録する。
void (async () => {
  const { createViewSDK } = await import('@salesforce/platform-sdk/view');
  const viewSdk = await createViewSDK();

  // (1) LWCが push するカスタムイベントを待ち受ける
  viewSdk?.addEventListener?.(RECORD_ID_EVENT, (event) => {
    publish(event.detail?.recordId);
  });

  // (2) リスナーが立ったので「今 recordId を送って」とLWCへ要求する
  viewSdk?.dispatchEvent?.(new CustomEvent(REQUEST_RECORD_ID_EVENT));
})();

getUiState().state.props から取れたら良かったのですが、実際に中身をログに出して確かめたところ、レコードページでは props は空（{}）で recordId は入っていませんでした（props はテーマ・ロケール等の host-configurable inputs 用とされています）。なので recordId を運べるのは上記のカスタムイベントだけ、という結論になりました。(2026年9月時点)

app.tsx の先頭で読み込むことで、要求をできるだけ早く出せます。

import '@salesforce/platform-sdk/ui-embedding';
import '@/features/timeline/hostRecordId'; // ここで受信リスナー + requestRecordId が走る

あとは React 側のフックでこのストアを購読するだけです。埋め込みでない環境（ローカル開発）ではルートパラメータにフォールバックします。

export function useEmbeddedRecordId(): string | undefined {
  const { recordId: routeRecordId } = useParams();
  const [hostRecordId, setHostRecordId] = useState(getHostRecordId);
  useEffect(() => subscribeHostRecordId(setHostRecordId), []);
  return hostRecordId ?? routeRecordId;
}

recordId が届くまでは GraphQL クエリを投げない、というガードも入れておくと安心です。

// recordId が来るまではクエリしない（caseId が null で uiapi に弾かれるのを防ぐ）
const { data, loading, error } = useAsyncData(
  () => (recordId ? fetchTimeline(recordId) : Promise.resolve(undefined)),
  [recordId, reloadKey],
);

if (!recordId) return <NoRecordState />;

ステップ4: iframe の高さ（無限に伸びる問題）

lightning-ui-embedding には iframe の高さをコンテンツに合わせるオートリサイザーが入っています。ここで、iframe の中のアプリが 100vh や min-h-screen（ビューポート基準の高さ）を使っていると、

「オートリサイザーが iframe を広げる → 中身の 100vh も一緒に広がる → さらにリサイザーが広げる…」

というループになり、縦にどこまでも伸び続けます。

対策はシンプルで、iframe 内でビューポート基準の高さを使わないことにしました。

/* 修正前: ビューポート高さがリサイザーにフィードバックして無限に伸びる */
html, body, #root { @apply min-h-screen; }

/* 修正後: コンテンツ基準の高さにする */
html, body, #root { height: auto; min-height: 0; }

LWC 側の初期高さは LWC のデザイン属性（height、420〜720px にクランプ）で調整できるようにしてあります。

ステップ5: レコードページに配置して動作確認

デプロイしたら、Case レコードページを Lightning アプリケーションビルダーで開き、コンポーネント一覧から 「Case Timeline」 をドラッグして配置します。必要なら右側のプロパティで高さ（Height）を調整します。

保存してレコードページを開くと、そのケースの履歴が 1 本の時間軸に並んで表示されます。

おわりに

Microfrontend / UI Embedding を使うと、React で作った UI を、レコードページの文脈（recordId）を受け取りながら埋め込めます。今回試してみて分かったことを振り返ると、

• 埋め込みは lightning-ui-embedding に src を渡すだけの薄いラッパー LWC で実現できる
• アプリのオリジンは、一度アプリを単体で開いて確認し、[信頼済み URL] に画面から登録しておく
• recordId は、現時点（Beta）では sf-embedding チャネルのカスタムイベントで渡すのが素直そう。ready 待ちだけだと取りこぼすことがあり、アプリ → LWC の要求（requestRecordId）を挟むと安定した
• 細かいハマりどころは「src は固定 base URL にする」「iframe 内で 100vh を使わない」あたり

あくまで Beta 時点での一例なので、正式リリースでは作法が変わっているかもしれません。とはいえ、LWC と React アプリを橋渡しする感触はつかめました。今後の進化が楽しみです。

参考資料

• Salesforce Microfrontend: Get Started（本記事の元にした公式ガイド）
• Salesforce Microfrontend: Exchange Data ガイド
• 前回記事: Salesforce で React アプリをマルチフレームワークで動かす

The post Salesforce Microfrontend (UI Embedding) で React アプリの埋め込みを試す appeared first on Salesforce Developers Blog.

※本記事は2026年6月16日に米国で公開された Build a Decision-Scoring Skill for Any Agentの抄訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。

プロジェクトには技術的な判断がつきものですが、その時点で文書化されることはほとんどありません。後になって誰かが「なぜこの実装を選んだのか」を知りたくても、その根拠はSlackのスレッドや会議中の記憶、あるいはすでにチームを離れているかもしれない人の頭の中にしか残っていないのです。

AIを使えば、プロジェクトに重要なコンテキストの喪失を防ぎ、アーキテクチャーの原則を厳密に適用できます。意思決定スコアリングスキルを実装することで、プロジェクトチームは、コーディングエージェントをエンジニアリング設計のガードレールとして活用できます。この記事では、幅広い要件の聞き取りから始めて検証可能な形で意思決定を記録する、構造化されたフレームワーク「/decideパイプライン」を構築する方法を紹介します。

技術的な意思決定を支援するスキル

Salesforce Ada Agent Skills（英語）は、コードの記述にとどまらない、さまざまなエージェントスキルを集めたオープンソースのレポジトリです。/decideは、AIを使って技術的な意思決定を進める、構造化されたパイプラインです。たとえば、「/decide managed package vs. unlocked package vs. unpackaged metadata for distributing utilities across 3 orgs」（3つのSalesforce組織に共通のユーティリティを配布する場合、管理パッケージ、ロック解除済みパッケージ、パッケージ化しないメタデータのどれを選べばよいか）と入力してみましょう。すると、コーディングエージェントが、ユーザーから情報を収集して、公式ドキュメントにもとづく選択肢を提示します。さらにユーザーが実際の運用をもとにリスクを評価できるように表を出力し、スコア付きの推奨プランを提案して、その推奨案を意思決定の記録としてディスクに書き込みます。

出力はファイルとして残るため、バージョン管理やレビューが可能で、経緯を知りたい人がいつでも参照できます。

要件の聞き取り、評価基準の検討、スコアリングという基本パターンは、システム管理者（Admin）、開発者（Developer）、アーキテクト（Architect）を問わず、あらゆる技術的な意思決定に応用できます。これが「ADA」の由来です。以下の例ではClaude Codeを使っていますが、このスキルはどのAIエージェントでも使えるように設計されており、GitHubにはGeminiやCodex CLI向けのひな形も用意されています。

パイプラインの流れ

パイプラインでは、ステップを進めながら意思決定の範囲とコンテキストを絞り込んでいきます。各ステップの出力によって、次のステップの入力の範囲が決まります。幅広い情報収集と調査から始まり、最終的に1つの検証可能な意思決定スコアを決定します。

主な設計パターン

前述のパイプラインは、このスキルが実行する処理を示したものです。以下に、このスキルの実装方法と、信頼性と適応性を備え、技術的な意思決定を安心して任せられるスキルにするための設計パターンを紹介します。これらのパターンを組み合わせることで、内容を検証して共有し、その後の作業にも活用できる出力が得られます。

フォルダー構造

このスキルは、複数のMarkdownファイルからなるディレクトリとして構成されています。

salesforce-ada-agent-skills/
 ├── CLAUDE.md # グローバルルール
 ├── .mcp.json # MCPサーバーの構成
 ├── .claude/
 │ 　　└── skills/
 │ 　　　　　├── learn/
 │ 　　　　　│　　 └── SKILL.md # 学習ワークフロー
 │　　　　　 └── decide/
 │ 　　　　　　　　└── SKILL.md # パイプラインのステップと制約
 ├── knowledge/
 │ 　　├── formats/ # 共通の出力テンプレート
 │　　 │ 　　├── options-format.md # ソリューションの選択肢一覧用テンプレート
 │ 　　│　　 ├── criteria-format.md # 評価基準用テンプレート
 │　　 │　　 ├── risk-matrix-format.md
 │　 　│　 　└── decision-format-*.md # 意思決定記録の出力テンプレート
 │　　 ├── scoring/ # 意思決定スコアの算出方法
 │ 　　└── modifiers/ # 組み合わせ可能な観点
 └── output/
 　　　└── decisions/ # 生成された意思決定の記録

CLAUDE.md （レポジトリのルート）では、スコアリングに使う各評価軸の重み、MCPのソース選択ルール、さらに、意思決定スキル全体に適用される厳格な制約を定義しています。スキルファイル（SKILL.md）はパイプラインの処理順序を管理し、CLAUDE.mdは各ステップを規定するルールを管理します。

「/decide」と入力するとSKILL.mdが読み込まれ、パイプラインの順序を制御します。フォーマットファイルは、 AIエージェントが解釈することなく、コピーして使用するテンプレートです。そのため、会話の長さにかかわらず一貫した出力を生成できます。スコアの算出方法は、最後のステップでのみ読み込まれます。スコアの算出方法には、約350行にわたって詳細な評価基準が記されているため、早い段階で組み込むと、情報収集の段階でAIエージェントの注意を分散させてしまうことになります。

このようにファイルを分けておくと、パイプラインのロジックに手を加えずにフォーマットを改善したり、ステップを変更せずにスコアリングの評価軸を入れ替えたりすることが可能になり、各段階でAIが参照する情報量を必要最小限に抑えられます。

最終的には人が判断

各ステップの最後で、AIエージェントはいったん作業を停止し、次のステップに進んでよいかを確認します。どの確認ポイントでも分析内容を調整して、選択肢の追加や評価基準の削除、評価の見直しが可能です。この仕組みによって、最初のステップで生じた誤った前提が、途中で検証されないまま推奨案まで持ち越されることを防げます。これにより、開発者の実務経験を最大限に活かし、より質の高い出力を得ることができます。

早い段階で幅広く情報を収集し、その後で事実関係を検証

解決策の選択肢を探るステップで最初に行う調査では、広範なクエリーを使用し、個々のアプローチを都合よく選ぶのではなく、複数のアプローチを一度に提示します。それぞれの選択肢は、提示する前にドキュメントをもとに妥当性が検証されます。さらに、リスクマトリックスに記載される事実関係についても、評価を付ける前に的を絞った検索で確認します。このように複数の段階で検証することで、幅広くすべての選択肢を公平に洗い出しながら、掘り下げた調査で根拠のない記述が最終スコアに入り込むことを防ぎます。

このスキルは、ドキュメント検索に対応したMCP（Model Context Protocol）サーバーがなくても機能します。MCPサーバーを利用できない場合は、Web検索やAIエージェントの学習済み知識を代わりに使用し、どの方法で情報を裏付けているかを明確に示します。とはいえ、質の高い意思決定には質の高いドキュメントが欠かせません。そこで、管理者、開発者、アーキテクト向けの最新の公式ドキュメントを対象に、キーワード検索とベクトル検索を実行できるカスタムMCPサーバー、salesforce-content（英語）を構築しました。MCPで利用できるドキュメントであればどれでも機能します（このレポジトリには、設定不要で使える代替手段としてContext7の設定も含まれています）。ただし、Web検索ではソースが解析しにくい場合に重要な情報を取りこぼすことがよくあるため、信頼できるSalesforceの情報源が直接インデックス化されたsalesforce-contentの利用が推奨されます。

各ステップの出力に個別のフォーマットファイルを用意

各ステップには、出力に使われる表の構造を厳密に定めたテンプレートファイルが用意されています。AIエージェントは、文章で書かれた指示よりも、具体的なテンプレートのほうに確実に従います。フォーマットファイルをパイプラインのロジックから分離することで、ステップに手を加えずにフォーマットを繰り返し改善できます。

AIエージェントが自ら検証できるルールベースのスコア

リスク評価には、信頼度を表す数値が割り当てられます（低リスク = 85、中リスク = 55、高リスク = 25）。この数値に評価軸ごとの重み付け（信頼性20%、安定性20%、オペレーショナルエクセレンス20%、リソースの最適化15%、コストの最適化15%、公平性10%）を掛けて合計した値が、各選択肢の意思決定スコアになります。常に最もスコアが高い選択肢が推奨案になります。AIエージェントは数値を比較して結果を検証します。また、プロンプトでも、判断や推論を加えないよう指示されます。値を固定することで、曖昧さがなくなります。各リスクレベルに1つの固定値が割り当てられているため、リスクマトリックスからスコアが機械的に算出されます。

この例では、新しいWell-Architectedフレームワーク（英語）の方向性を踏まえて最適化したスコア帯を使用していますが、必要に応じて変更できます。

共有可能な出力

重要な意思決定は文書化しておく必要があります。新しく加わったチームメンバーにも、技術的な選択の理由を理解してもらわなければなりません。そのため、出力を永続的に保存できるように設計することが重要でした。このスキルには、簡潔な出力か詳細な出力かの選択肢を備えた、Markdown形式のArchitectural Decision Record (ADR)（英語）を採用しました。

独自の意思決定スコアリングスキルを構築

このスキルは、他にも応用できる設計パターンです。希望するステップやスコアの算出方法、AIエージェントに応じて調整できます。

さっそく始める

レポジトリ（英語）をクローンし、READMEの手順に従って、/decideとタイプした後に質問を入力してみましょう。

このスキルは、人からのフィードバックを繰り返し取り入れることを重視して作成しています。そのため、推論を長い文章として提示するのではなく、具体的で引用可能な記述に分解し、表形式で確認できるようにしています。こうしたスキルがあれば、意思決定の質が向上し、誤りに早く気づいて、次の担当者が活かせる形で意思決定を記録として残せます。

関連情報

• ドキュメント – Anthropicのスキル公式ドキュメント（英語）
• ドキュメント – Anthropicのスキル活用に関するベストプラクティス（英語）
• ドキュメント – Salesforce Well-Architected（英語）
• 動画 – The Next Chapter of the Well-Architected Framework（英語）

執筆者について

Dave Norrisは、Salesforceのデベロッパーアドボケイトです。技術的なテーマを、多様な読者に広くわかりやすく説明することに情熱を注いでいます。Salesforceで10年以上勤務し、現在、SalesforceとMuleSoftの認定資格を40以上保有。2013年に、Salesforce認定テクニカルアーキテクトの資格を取得しています。

The post AIエージェント用の意思決定スコアリングスキルを作成する appeared first on Salesforce Developers Blog.

※本記事は2026年7月15日に米国で公開された Connect Slack to Salesforce with Hosted MCP Serversの抄訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。

営業担当者は、定期的にパイプラインを更新し、Tableauで指標を確認し、商談に向けてアカウントチームの準備を整えなければなりません。これまで、開発者がこうしたワークフローを支援するには、カスタムアプリの構築が必要でした。しかしHeadless 360を利用すれば、Slack上の会話からSalesforce Platformのデータやプロセスにアクセスできます。もうSalesforceのタブを開く必要はありません。

これを可能にするのが、Slackに組み込まれたAIのチームメイトであるSlackbotに接続された、Salesforce Hosted MCP Server（英語）です。Slackは、チームやAIエージェント、Salesforceエコシステム上に構築されたすべてのツールを1か所でつなげるエンゲージメントレイヤーです。

この記事では、なぜSlackがSalesforceに最適な会話型インターフェースなのか、Salesforce Hosted MCP ServerがSlack内でどのように機能するのか、Slackbotとどのように接続するのか、そしてSalesforce Platformと、業務を支えるオペレーティングシステムであるSlackが組み合わさることで何が可能になるのかを見ていきます。

Slack – エージェンティック・エンタープライズのためのエンゲージメントレイヤー

Slackは人、AIエージェント、データをつなげ、仕事を進めるためのオペレーティングシステムです。Slackには、Salesforce Platformの機能がネイティブに組み込まれ、MCPサーバーも接続されています。チームが一緒に作業を進めている場所で、自然な会話を通じて、Agentforce 360、Data 360、TableauなどのSalesforceエコシステム全体を利用できます。

下のスクリーンショットには、Slackデスクトップアプリに表示されたSalesforceレコードとTableauインサイト、Slackモバイルアプリで交わされたユーザーとSlackbotの会話が表示されています。

この体験の中心にあるのがSlackbotです。Slackbotは、企業内のあらゆる会話、ファイル、チャンネル、アプリに1か所からアクセスできるAIインターフェースです。Slackbotが提示した情報は、チーム全体で共有し、話し合い、アクションにつなげることができます。さらに、Slackbotはデータを会話や接続済みのツールと統合することができます。チームがSlackで仕事を進めるなかで蓄積されるコンテキストは、Slackbotに取り込まれ、日々の業務の自然な流れの中でレコードに反映されます。

これが、Slackの強みです。そして、ビジネスのコンテキストがすべてMCPを通じてSlackbot MCPクライアント（英語）から利用可能になったことで、これまで別々に動いていたツールを、1つの会話の中で連携させて使えるようになりました。

Salesforce Hosted MCP Serverとは – 簡単なおさらい

Model Context Protocol（MCP）は、さまざまなベンダーの外部ツールやデータソースとAIエージェントがやり取りするためのオープン標準（英語）です。 Salesforceは、この標準をSalesforce Hosted MCP Serverとして実装し、提供しています。MCPに対応しているクライアントであれば、Salesforce組織に安全で適切に管理された形でアクセスし、クエリーの実行、レコードの変更、アクションの実行といった操作を直接行うことができます。個別のログインや、連携のためのカスタムコードは必要ありません。

Salesforceでは、Salesforceオブジェクト（英語）、Tableau（英語）、Data 360（英語）向けに、標準のHosted MCP Server一式をすぐに利用できる状態で提供しています。さらに、標準サーバーだけでなく、Apexアクション、フロービルダー、Apex RESTエンドポイント、APIカタログのAPI、プロンプトビルダーのテンプレート、AgentforceのAIエージェントといったツールを組み込んでカスタムMCPサーバー（英語）を構築し、連携用のコードを記述することなく、Salesforce組織の機能を公開できます。

Salesforce Hosted MCP Serverの詳細については、こちらのドキュメント（英語）をご覧ください。

SlackとSalesforce Hosted MCP Serverとの連携を設定する

SlackbotとSalesforce Hosted MCP Serverとの連携は簡単に設定できます。URLのコピーや手作業でのOAuthの構成、カスタムコードの記述は必要ありません。Slack管理者向けのUIを使って、すべての設定を数ステップで完了できます。

事前準備

設定を始める前に、以下を用意してください。

• SlackbotとSalesforceを利用できるSlackの有料プラン（ビジネスプラス、Enterprise Select、Enterprise Grid、Enterprise+）
• Slackに接続された1つ以上のSalesforce組織
• ワークスペースのオーナー/管理者権限、またはオーガナイゼーションのオーナー/管理者権限
• 接続されているSalesforce組織に対するSalesforce管理者権限
• 1つ以上の有効なSalesforce Hosted MCP server（英語）

SalesforceをまだSlackに接続していない場合は、まずヘルプ記事「SalesforceとSlackを連携させる」 の手順を実行してください。接続が確立されると、ユーザー認証は自動的に行われます。SlackbotはSlackとSalesforceの既存のアカウントマッピングを使用するため、メンバーが別途ログインする必要はありません。

Note: Slackワークスペースをまだ作成していない場合は、こちらの手順で簡単に作成できます。

ステップ1 – MCPサーバーの設定を開く

MCPサーバーの設定にアクセスする手順は、プランによって異なります。

ビジネスプラスとEnterprise Select:
管理者 → ワークスペースの設定 → Salesforce → Salesforce MCPサーバー

Enterprise GridとEnterprise+:
オーガナイゼーション名 → ツールと設定 → オーガナイゼーションの設定 → Salesforce → MCPサーバー

ステップ2 – Salesforce Hosted MCP Serverを追加する

1. ［MCPサーバーを追加］をクリックします。
2. 有効なSalesforce Hosted MCP Serverのリストから追加したいサーバー（SObject All、Data 360、カスタムサーバーなど）を選択します。
3. ［追加］をクリックし、サーバーが公開するツールを確認します。
4. ［次へ］をクリックします。

Enterprise GridまたはEnterprise+を利用している場合は、次のステップに進む前に、そのサーバーを利用可能にするワークスペースも選択します。

ステップ3 – アクセス権を設定する

1. SlackbotからこのMCPサーバーを利用できるユーザーを選択します。
   • 全員：Slackbotを利用できるすべてのメンバー
   • 特定のグループとメンバー：チームまたは個人単位で細かく制御
   • すべて許可しない：先にインストールだけして、アクセスは後で有効化
2. ［接続］をクリックして完了します。

これでMCPサーバーが有効になり、アクセス権を持つユーザーに代わってSlackbotがこのサーバーを利用できるようになります。

SlackbotのMCP呼び出しに適用されるSalesforceの権限

Slackbotで利用するSalesforceのMCPサーバーは、権限を考慮して動作するように設計されています。Slackbotが実行するすべてのアクションは、標準のSalesforceセキュリティモデル（英語）に従い、項目レベルのセキュリティ、オブジェクト権限、共有ルールがユーザーごと、リクエストごとに適用されます。ユーザーは、Salesforceで許可されている情報のみを表示し、許可されている操作のみを実行できます。Slack管理者は、Slackオーガナイゼーションの管理者向けUIから、いつでもアクセス権の調整、権限の更新、サーバーの完全削除を実行できます。

Slackのユーザーレベルでもセキュリティ対策が講じられており、MCPツールを誤って使用しないよう、確認を促すプロンプトが表示されます。以下のスクリーンショットでは、SlackbotがCreateAccountSyncMeetingTaskカスタムMCPツールを使用してよいかどうかを、ユーザーに確認しています。

SlackbotとSalesforce Hosted MCP Serverの活用例

MCPサーバーの設定が完了すると、SlackとSalesforceの両方で認証されているチームのメンバーは、それぞれの権限にもとづいて、Slackで自然言語を使ってSalesforce組織にアクセスできるようになります。では、実際にSlackbotをどのように活用できるのでしょうか。架空のアウトドアグッズメーカー「Northern Trail Outfitters」を例として見てみましょう。

カスタムビジネスプロセスの開始

Northern Trail Outfittersの営業担当者が、1時間後に顧客であるAlpine Trekkersへの訪問を予定しています。Salesforceを開いて取引先ページに移動し、訪問に備えて商談やケースを確認する必要はありません。代わりに、Slackbotに次のように指示します。

「Alpine Trekkersとの取引の健全性を調べてください」

Slackbotは、標準のSObject All MCP server（英語）のツールを使用し、企業名にもとづいて取引先を特定します。続いて、取引先の健全性をチェックするカスタムフローツールを呼び出します。このフローによって、関連するケース、商談、活動から追加データが取得され、厳密なビジネスルールに従って健全性スコアが算出されます。

健全性チェックの結果、重大なサポートケースが未解決で、この取引先が要注意の状態にあることがわかりました。

商談の準備

Alpine Trekkersの健全性を確認した営業担当者は、顧客訪問に向けた準備をSlackbotに依頼します。Slackbotは別のカスタムツールを使って、Salesforceで取引先に関連付けられた取引先責任者をもとに相手の関係者を特定し、商談に必要な情報を記録します。以下のスクリーンショットでは、SlackbotがカスタムMCPツールを呼び出し、取引先についての情報を共有するためのミーティングを設定するタスクを作成しています。

Tableauのリアルタイムデータを使ったパイプライン分析

Slackbotに準備を手伝ってもらったことで、商談は順調に進み、懸念にも対処できました。Alpine Trekkersのリスクは解消されました。

Northern Trail Outfittersの営業マネージャーは、第2四半期のパイプラインの健全性について最新の状況を把握したいと考えています。Tableauダッシュボードを開く必要はなく、Slackbotに次のように尋ねます。

「Tableauでは、第2四半期の地域別のパイプラインのコンバージョン率はどうなっていますか」

Tableau MCPサーバー（英語）に接続されているため、Slackbotは行レベルのセキュリティを維持しながらセマンティックレイヤーにクエリーを実行し、実際のビジネス指標にもとづく、信頼性とガバナンスが確保された回答を、視覚化したデータとともに返します。営業担当者はこうして得たインサイトをチームと共有して、すぐに行動に移せます。また、データを見ながら、その場で次の一手について話し合うことができます。

まとめ

SlackbotをSalesforce Hosted MCP Serverに接続する方法を紹介しました。Slackがエージェンティック・エンタープライズのエンゲージメントレイヤーである理由、そしてHeadless 360を活用し、Salesforce Hosted MCP Serverを通じてAIエージェントと一緒に仕事を進める仕組みを見てきました。また、SlackbotをSalesforce Hosted MCP Serverと連携させる設定と、連携のメリットを示す実践的な例も確認しました。

さっそく、皆さんのSalesforce組織にSlackbotを接続してみましょう。設定の詳しい手順は、「MCPサーバーでSlackbotをSalesforceに接続する」を参考にしてください。

関連情報

• ドキュメント – SalesforceとSlackを連携させる
• ドキュメント – MCPサーバーでSlackbotをSalesforceに接続する
• ドキュメント – Salesforce Hosted MCP Servers（英語）

執筆者について

Ashley Maoは、Salesforceでシニアプロダクトマーケティングマネージャーを務め、SalesforceとSlackの製品リリースを主導しています。AIエージェントをチームメイトとしてともに働くことの意義や、データと会話が融合することで生まれる可能性を探求しています。

Philippe Ozilは、Salesforce Platformの開発に取り組むプリンシパルデベロッパーアドボケイトです。技術的なコンテンツを執筆し、カンファレンスにもよく登壇します。フルスタック開発者で、API、DevOps、ロボティクス、VRプロジェクトに注力しています。X、LinkedIn、Blueskyでのフォロー歓迎。GitHubのプロジェクトもチェックしてください。

The post Hosted MCP Serverを使ってSalesforceにSlackを接続する appeared first on Salesforce Developers Blog.

※本記事は2026年6月30日に米国で公開された How to Secure Salesforce Hosted MCP Serversの抄訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。

Salesforce Hosted MCP（Model Context Protocol）Server（英語）は、Headless 360を構成する主なコンポーネントの1つで、標準機能（英語）やカスタム機能（英語）をサーバー経由で利用可能にし、AIエージェントの能力を拡張できます。ツール、プロンプト、リソースをユーザーに公開する際には、データや操作を保護するために、MCPサーバーへのアクセスを安全に保つことがきわめて重要です。

MCPサーバーを構築する開発者やそのサーバーの管理者は、セキュリティモデルを理解しておくことで、誰が、何に、いつ、どのような方法でアクセスできるかを制御できます。この記事では、Salesforce Hosted MCP Serverの認証、認可、権限の制御、ログの記録のベストプラクティスについて説明します。

Salesforce Hosted MCP Serverのセキュリティモデルを理解する

Salesforce MCPのセキュリティモデルは、3つのレイヤーで構成されています。

1. 認証 – 誰がリクエストを行っているかを確認します。
2. 認可 – そのユーザーが何を実行できるかを決定します。
3. 権限の制御 – サーバーが公開する基本要素（ツール、プロンプト、リソース）を利用する際に、オブジェクトや項目のレベルで細かなアクセス制御を適用します。

これらのセキュリティレイヤーに加え、監査やコンプライアンスに対応できるよう、すべての操作がログに記録されます。

最初の2つのレイヤーはMCP標準に直接関連しており、3つ目のレイヤー（権限の制御）はSalesforce Platform固有のものです。それぞれのセキュリティレイヤーは、1つ前のレイヤーの上に成り立っています。ユーザーが誰なのかを確認するまでは、そのユーザーに何を許可するかを決めることはできません。そして、認可ルールがなければ、権限を適用することはできません。

これらのレイヤーとログがどう連携しているかを理解すれば、多層防御戦略を構築しやすくなります。各レイヤーを詳しく見ていきましょう。

認証 – 本人確認

認証は、最初の防御線となります。ユーザーの身元を確認します。

MCPの仕様（英語）では、認証と認可は実装に必須の技術的要件としては定義されていません。しかし、適切なセキュリティ対策がなければ、権限のないユーザーが機密データにアクセスしたり、望ましくない操作を実行したりするおそれがあります。そのため、この記事では、エンタープライズ環境に必須の要件として扱います。

MCPでは、認証と認可の仕組みとしてOAuth 2.0（英語）を規定しています。MCPでサポートされているのはOAuth 2.0の一部のみで、すべての認可フローやグラントタイプを利用できるわけではありません。また、ClaudeやChatGPTなどの広く使われているクライアントがサポートするフローは、Salesforceよりも少数です。

MCPは比較的新しいものですが、OAuth 2.0は10年以上使われており、Salesforce Platformには、クライアントとして、あるいはサーバーとして動作する場合でも、OAuthと連携するためのさまざまな仕組みが用意されています。そのため、Salesforce開発者は、OAuthのセキュリティを自分で実装する必要がなく、外部クライアントアプリ（ECA）を通じて宣言的に制御できます。

Salesforceは、1つのECAを複数のMCPクライアントで共有するのではなく、MCPクライアントごとに専用のECA（Claude用、ChatGPT用、Cursor用など）を作成することを強く推奨します。こうすることで、アクセス制御とクライアントのアクティビティの監査が容易になります。
Salesforce Hosted MCP Serverでは、ECAを介した認可コードフローのみをサポートしています。そのため、ユーザーがMCPサーバーに接続する際には、Salesforceでの認証が必要になります。各ユーザーのSalesforceユーザーアカウントが、MCPセッションに関連付けられます。

Notes:

• インテグレーションユーザーなど、プリンシパル（実行主体）となるユーザーを設定したサービスアカウントを、すべてのセッションで共通して使用するように指定することはできません。これは避けるべきアンチパターンです。
• 現時点では、マシン間のフローをサポートする予定はありません。組織への接続とMCPツールに対するアクセスの許可には、引き続き人間が関与します。

デフォルトでは、組織内のすべてのユーザーがECAに接続し、MCPサーバーにアクセスできるようになっています。ただし、認可ルールを指定すれば、アクセスを制御できます。

認可 – アクセス制御

認可により、ユーザーが実行できる操作を決定します。ユーザーの認証が完了すると、Salesforceはそのユーザーの権限を評価し、どのリソースにアクセスできるかを判断します。
認可を制御する仕組みはいくつかあります。

OAuth範囲でアクセスを認可する

認可の第一段階として、ECAの設定時に指定するOAuth範囲により、特定のリソースへのアクセスが制御されます。

新たに追加された「SalesforceでホストされているMCPサーバーにアクセス（mcp_api）」範囲によって、Salesforce Hosted MCP Serverへのアクセスが許可されます。この範囲は、Platform API（REST、Tooling、Metadataなど）へのフルアクセスを許可する「APIを使用してユーザーデータを管理（api）」範囲の使用を避けるために導入されました。

原則として、AIエージェントにAPIへのフルアクセスを許可のではなく、MCPを介して限られた「安全な」操作だけを公開することが推奨されます。

承認済みユーザーのみにアクセスを許可する

デフォルトのECA設定では、組織内のすべてのユーザーが認証を行い、MCPサーバーにアクセスできます。アプリケーションポリシーを設定すると、事前に承認した特定のユーザーにのみアクセスを限定できます。この設定では、特定のプロファイルや権限セットが割り当てられたユーザーを選択できます。

たとえば、次の設定では、「MCP Client User」権限セットを持つユーザーだけがECAに接続できます。

IP制限を適用する

ECAを利用できるユーザーを限定するだけではなく、接続可能なIP範囲を指定してIPアドレスによる制限を適用することもできます。これらの制限は、デフォルトのECA設定の［アプリケーション認証］で有効になっています。

［ネットワークアクセス］設定メニューで、信頼済みIP範囲をすべてのユーザー、または特定のユーザープロファイルに対して指定できます。

更新トークンの有効期間を短縮する

ユーザーがECAでログインするとアクセストークンが取得され、その後のすべてのMCP操作にそのトークンが渡されます。トークンは、有効期間が終了したら更新する必要があります。

デフォルトのトークン有効期間は1年ですが、調整が可能で、本番環境で短く設定することもできます。これにより、トークンが盗まれ、悪意のある目的で再利用されるリスクを軽減することができます。トークンの有効期間を制御するには、ECAの設定を開き、［アプリケーション認証］にある［更新トークンポリシー］を探します。更新トークンのセキュリティを強化する推奨設定については、こちらのドキュメント（英語）で紹介しています。

アクセス権を取り消す

有効期限が切れる前にECAのトークンを取り消す必要がある場合は、［設定］に移動して［OAuthの利用状況］を検索し、ECAを選択して個々のトークンを取り消すか、一括で取り消します。

MCPサーバーを有効化する

デフォルトでは、すべてのMCPサーバーが無効になっています。AIエージェントに公開するMCPサーバーだけを有効にしてください。

たとえば、以下の図では1つのカスタムサーバーと2つの標準サーバーのみを有効にしています。

MCPツールにアノテーションを追加する

厳密な意味でのセキュリティ対策ではありませんが、公開するMCPツールには、その動作を示すアノテーションを付けることが推奨されます。これにより、AIエージェントにツールをどのように使用すべきかを伝えられます。たとえば、AIエージェントに対して、レコードの削除など破壊的な可能性のある操作を実行する際にユーザーに確認を求めるべきか、あるいはツールを複数回実行しても安全かどうか、といった情報を提供できます。

Note: MCPツールのアノテーション（英語）をクライアント側でサポートするかどうかは任意であるため、すべてのAIエージェントがその内容に従うとは限りません。

権限の制御 – きめ細かなアクセス管理

ECAの設定によって特定のMCPサーバー自体へのアクセスを制限することはできませんが、サーバーを構成する各ツールへのアクセスは制御できます。

MCPツールは、ECAを使用して認証したユーザーと同じ権限で実行されます。つまり、Salesforceの中核的なセキュリティモデルが、次のすべてのレベルで適用されます。

• オブジェクトレベルのアクセス制御（CRUD権限）
• 項目レベルのセキュリティ（FLS）による制限
• レコード共有ルール

個別のセキュリティ要件に対応する（英語）ために、Agentforce、Apex、Flowを使ってカスタムツールを実装する（英語）こともできます。この方法を採用する場合は、必ずセキュリティのベストプラクティスに従ってください。

機密性の高い操作を保護し、最小権限の原則に従うために、権限セットを使ってください。ユーザーには、業務に必要な権限だけを付与します。権限は定期的に見直し、不要になったアクセス権は取り消してください。

また、本番環境にデプロイする前に、権限をテストしてください。たとえば、runAsメソッドを使ってMCPツールに対してApexテストやFlowテストを実行し、さまざまなアクセスレベルでユーザーの動作をシミュレーションします。

ログの記録 – アクセスのトラッキング

ログを記録することにより、誰が、何に、いつアクセスしたかを示す監査履歴が作成されます。こうした記録は、セキュリティの監視、コンプライアンス、トラブルシューティングに不可欠です。

MCPツールによって実行されたすべてのアクションは、監査履歴の中でECAに接続したユーザーに紐付けられます。Salesforceは、イベントモニタリングを使用してMCPサーバーのアクティビティを自動的に記録します。

ログにアクセスするには、［設定］に移動し、「イベントログファイルブラウザー」を検索します。[イベントの種別］で［API合計使用量］を選択して絞り込みます。イベントログのCSVファイルで、API_CLIENT_CATEGORY列の値がSALESFORCE_HOSTED_MCPである行をフィルタリングして、MCPトラフィックを特定できます。MCPツールを呼び出したユーザーや、影響を受けたオブジェクト（エンティティ）などの詳細を確認できます。

ログは定期的に確認してください。STATUS_CODEでエラーを探し、USER_NAMEやCLIENT_IPを見て予期しないアクセスパターンがないかを確認しましょう。何か見つかった場合、セキュリティ上の問題や権限設定の誤りがあるかもしれません。

まとめ

Salesforce Hosted MCP Serverのセキュリティを確保する方法を確認し、多層的セキュリティアーキテクチャーを構成するすべてのコンポーネントを見てきました。

• 認証で、ユーザーの本人確認を行う
• 認可で、ユーザーがアクセスできるツールを制御する
• 権限の制御で、きめ細かなデータアクセス制御を適用する
• ログの記録で、コンプライアンスとセキュリティ監視のための監査履歴を作成する

この記事で紹介したセキュリティのベストプラクティスを実践して、便利なMCPツールをAIエージェントに提供しながら、データを確実に保護してください。

関連情報

• ドキュメント – Salesforce Hosted MCP Servers（英語）
• ドキュメント – APIカタログでのMCPサーバーの管理
• ドキュメント – 外部クライアントアプリケーション
• ドキュメント – 権限セット
• GitHub – Community Wiki（英語）

執筆者について

Philippe Ozilは、Salesforce Platformの開発に取り組むプリンシパルデベロッパーアドボケイトです。技術的なコンテンツを執筆し、カンファレンスにもよく登壇します。フルスタック開発者で、API、DevOps、ロボティクス、VRプロジェクトに注力しています。X、LinkedIn、Blueskyでのフォロー歓迎。GitHubのプロジェクトもチェックしてください。

The post Salesforce Hosted MCP Serverをセキュアにする方法 appeared first on Salesforce Developers Blog.

※本記事は2026年5月8日に米国で公開された Intent-Driven Tool Selection Using Abilities in Agentforce Vibesの抄訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。

AIのコーディングエージェントが真価を発揮するには、適切なタイミングで適切なツールを利用する必要があります。しかし、利用できるSalesforce DX MCP Server（英語）ツールはとても多く、さらに増え続けているため、AIエージェントに必要なツールを開発者が手作業で選び、設定するのは簡単ではありません。ここで、Agentforce Vibes（英語）の新しい機能「アビリティ」（英語）が役に立ちます。アビリティは、Salesforce開発環境の自動化を支援する、インテリジェントなコンテキスト有効化システムです。

アビリティはRAGベースのセマンティック検索を活用し、リクエストごとに最も関連性の高いSalesforce DX MCP Serverツールを特定して、ツール選択の問題に対処します。このアプローチにより、実行環境のツールを絞り込みながら、出力品質を向上させ、トークン使用量も削減できます。

この記事では、ツールの増加によって生じる課題を検討し、アビリティの仕組みを説明したうえで、セマンティック検索と、依存関係にもとづいて関連ツールを追加する仕組みを詳しく掘り下げます。

課題 – 増え続けるツールと手動による構成

Agentforce Vibesでは、コンテキストがすべてです。Agentforce 360 Platformが拡大するにつれ、MCP（Model Context Protocol）サーバーの数も増えています。現在、Agentforce Vibes内で利用できるSalesforce DX MCP Serverツールは80を超え、CLIコマンド、テスト、コード分析、アクセシビリティチェック、DevOpsオペレーション、モバイル開発など、個別のタスクに対応するツールが揃っています。

すべてのツールを一度に有効にすると、プロンプトが大きくなり、モデルの選択肢が多くなりすぎ、出力品質が低下し、トークンコストも増加します。一方で、ツールが少なすぎるのも問題です。Agentforce Vibesが、メタデータの生成、Apexコードの作成、LWCのリファクタリング、コードに含まれるセキュリティ違反の分析といった処理に必要な機能を利用できなくなるかもしれません。

Salesforce DX MCP Serverツールの増加に伴い、次のような課題が新たに生じています。

• デフォルト設定の制限 – 利用可能なツールが膨大な数に上るため、Salesforceはその一部だけをデフォルトで有効にしています。多数のツールを有効にすると、ユーザーエクスペリエンスが低下したり、モデルに過度な負荷をかけたりする可能性があるためです。
• ユーザーエクスペリエンスへの影響 – その結果、最適とはいえないコードが生成され、コンパイルやデプロイに失敗したり、Salesforceの開発規約が無視されたりすることがあります。
• 手動での設定の難しさ – 利用できるツールはカスタマイズできますが、そのためにはローカルのmcp_config.jsonファイルを手作業で編集し、MCPサーバーツールの内部名を把握しておく必要があります。その結果、ツールを追加すれば出力が改善される場合でも、ほとんどの開発者は変更を行わず、デフォルトのツールセットだけに依存してしまっています。

こうした課題を背景に、Salesforceでは、Agentforce Vibesが必要とするツールを、必要なタイミングで過不足なく提供する仕組みを必要としていました。

ソリューション – アビリティで、インテリジェントなコンテキストを有効化

アビリティは、特定の開発シナリオにおいてAgentforce Vibesが何を実行できるかを定める、ドメイン固有の機能です。手動で設定したり、開発モードを切り替えたりする必要はありません。システムが、開発者の意図を直接判断して対応します。これにより、Agentforce Vibesが開発タスクの完了に必要な機能を確保しながら、実行環境をスリムに保つことができます。

たとえば、次のような機能に対応するアビリティがあります。

• ApexおよびLWCの開発
• DevOps運用
• モバイル開発
• コアプラットフォームの管理

各アビリティには、その機能に関連するDX MCP Serverツールがまとめられています。

リクエストを受け取ると、Agentforce Vibesは開発者のプロンプトを評価し、そのタスクで有効にする機能を判断して、それらの機能に関連するツールだけを利用可能にします。このプロセスは、アビリティコーディネーターと呼ばれる内部オーケストレーションレイヤーによって管理されます。アビリティコーディネーターはリクエストを解釈し、モデルが呼び出される前に実行環境を準備します。この処理はすべてのタスクで自動的に実行されるため、開発者が設定を行う必要はありません。

アビリティは組み合わせ可能で、リクエストによっては複数の機能が有効化されます。「現時点でAgentforce Vibesに対してどのツールを利用可能にすべきか？」という問いに答えるのが、アビリティの役割です。

スキルとアビリティが連携する仕組み

アビリティとスキルは、それぞれが異なる役割を担いながら、相互に補完し合う関係にあります。アビリティはコンテキストを有効化します。開発者の意図を検知し、そのタスクに適したSalesforce DX MCPツールを自動的に選択します。これにより、モデルの焦点が明確になり、Salesforceのベストプラクティスに沿った出力を維持できます。

スキルは、再利用可能なタスク単位の作業手順書です。スキルには、トリガーのリファクタリングやテストの生成、デプロイの実行といった具体的な作業の進め方が定義されているため、その都度同じ指示を出し直す必要はありません。

アビリティはどのツールを利用可能にするかを決定し、スキルは作業の進め方を定義します。この2つが連携することで、開発者が主導権を保ちながら、Agentforce Vibesがタスクに適した実行環境をインテリジェントに構成します。

アビリティの仕組み

アビリティは、検索拡張生成（RAG）を使用してツールを選択します。モデルに利用可能なツールの全カタログを送るのではなく、セマンティック検索を活用して最も関連性の高いツールを取得します。そのため、プロンプトのサイズを抑えながら、増え続けるカタログに対応できます。

セマンティック検索の流れ

モデルに過度な負荷をかけることなく、Agentforce Vibesが適切なツールを選択できるように、RAGベースの検索プロセスが採用されています。このプロセスは、ツールのインデックス化、プロンプトとの照合、モデルの実行コンテキストへのツールの追加という、3つのフェーズで行われます。

フェーズ1 – ツールのベクトル埋め込みとインデックス化

ユーザーとのやり取りに先立ち、ツールカタログをあらかじめ検索可能な状態にしておきます。MCPツールカタログが更新されるたびに、次の処理が実行されます。

• ベクトル変換 – 名前、説明、パラメーター、想定される利用コンテキストを含む各ツールの定義を正規化し、ベクトル埋め込みに変換します。
• データベースへの保存 – これらのベクトル埋め込みは、ベクトルデータベースに保存されます。これにより、システムは単にキーワードを照合するのではなく、ツールの「意味」と機能にもとづいてツールを特定します。

フェーズ2 – プロンプトとツールの照合（検索）

プロンプトを送信すると、Agentforce Vibesは次の手順でリアルタイムの類似度検索を実行します。

• プロンプトの埋め込み – ツール定義のベクトル変換に使用したものと同じモデルで、プロンプトをベクトル埋め込みに変換します。
• 類似度検索 – システムはコサイン類似度検索を実行し、プロンプトのベクトルとツールのベクトルインデックスを比較して、意味的に最も近い候補を特定します。
• 上位候補の選択 – パフォーマンスと精度のバランスを取るため、システムは結果を順位付けし、通常は適合度の高い10個前後のツールを候補として選択します。

フェーズ3 – 実行時コンテキスト

選択されたツールは、一時的な「関数カタログ」として、モデルの実行コンテキストに組み込まれます。これにより、速度とコストの面でプロンプトサイズを最適化しながら、リクエストの処理に必要な機能をLLMにすべて提供できます。

ツールの依存関係への対応

一部のMCPツールは、ワークフロー全体を制御・調整するオーケストレーターの役割を担い、タスクを完了するために追加のツールを必要とします。検索で取得されたツールのセットにオーケストレーターツールしか含まれていない場合、必要なツールがないために実行に失敗する可能性があります。

アビリティは、ツールの選択後に必要なツールを追加することで、この問題を解決します。

これにより、ツールセット全体を小さく保ちながら、タスクの完了に必要なツールをAIエージェントに提供できます。

まとめ

開発者の意図を把握し、タスクを実行できるようにするまで、アビリティは、Agentforce Vibesがその都度必要とするツールを過不足なく利用できるようにします。RAGベースのセマンティック検索を利用し、依存関係にもとづいて必要なツールを自動的に追加することで、増え続けるSalesforce DX MCPツールを効果的に管理し、手動で構成することなく、質の高い開発環境を実現します。

Agentforce Vibesの進化に合わせて、アビリティのインテリジェントなコンテキスト有効化システムも、次のような機能強化が見込まれます。

• Salesforce製およびサードパーティー製MCPサーバーへの対応の拡大
• 適切なツールが有効化された後に、スキルと連携してタスクの進め方をガイド
• 検索に使用するツールメタデータの拡充
• ツールの依存関係を検出する仕組みの強化

関連情報

• Agentforce Vibes開発者ガイド：アビリティ（英語）
• Trailhead：クイックスタート：Agentforce Vibesを使用してコードをトラブルシューティングする
• Trailhead：Get Started with Agentforce Vibes（英語）
• 動画：Agentforce Vibes Decoded（英語）

執筆者について

Jeff DouglasはSalesforceのプロダクトマネジメントディレクターで、Agentforce VibesとAIを活用した開発者向けツールを担当しています。2007年からSalesforce開発者として活動し、最初期のSalesforce MVPの1人でもあるJeffは、Trailheadの立ち上げを支援し、中核となる学習・評価システムをいくつも構築しました。陸軍の退役軍人で、ビール醸造所を経営していたことがあり、里親として子どもを育て、養子も迎えています。木工にも取り組み、小型のハイランド牛を飼育しています。LinkedInのプロフィールはこちら。

Ken Lewisは、Salesforceのテクニカルサービスのリードメンバーで、カリフォルニア州オークランドを拠点に活動しています。以前は非営利組織向けのSalesforce製品に携わっていました。現在はさまざまなお客様に向けて、Salesforce製品が使いやすく、役立つものになるよう取り組んでいます。プライベートでは、ラケットボールを楽しみ、自宅のDJセットで腕を磨き、ベイエリアの新しいレストランやアクティビティを開拓しています。LinkedInのプロフィールはこちら。

The post 開発の意図に応じてツールを自動で選択 – Agentforce Vibesの新機能「アビリティ」 appeared first on Salesforce Developers Blog.

AI agents can write this code on behalf of the developer, but without deep Salesforce Connect context, AI agents hallucinate. They write Apex that looks correct but misses required columns, uses wrong field types, or returns a malformed TableResult. What promised speed becomes hours of debugging validate and sync failures.

That changes with the platform-salesforce-connect-adapter-generate skill.

Developers can now use a coding agent to carry out the entire end-to-end integration workflow and build a complete, working adapter, including Apex classes.

This blog post covers what the skill does, how it structures the generated code, and how it uses the Salesforce Headless 360 MCP Server to register your adapter, reducing the manual work required in Salesforce Setup to a single click

What is a custom Apex adapter in Salesforce Connect?

The Salesforce Connect custom Apex adapter type lets you build your external data source by connecting with any REST API as a first-class external object. External objects look and behave like native Salesforce records where they show up in related lists; work in SOQL, flows, reports; and support platform features like sharing and field-level security. The data is never stored in Salesforce. Every query fires a live callout.

To build one, you implement two Apex classes from the DataSource namespace:

• DataSource.Provider: This class declares what your adapter supports: which objects it exposes, which query capabilities it has, and which authentication method it uses.
• DataSource.Connection: This class handles the actual API calls. It receives a QueryContext, calls your external system, maps the response to Salesforce field types, and returns a TableResult.

The interface is well-defined and public. But writing it correctly requires knowing the right method signatures, valid field types, pagination contracts, and error handling patterns. All of that is knowledge that takes time to build.

Introducing platform-salesforce-connect-adapter-generate

Salesforce skills are specialized AI capabilities that ground Agentforce Vibes and other dev agents with deep, domain-specific knowledge. They’re open-source, available as sf-skills, preloaded in Agentforce Vibes, and installable in any third-party AI tool. You describe your API in plain language. The agent does the rest.

When the platform-salesforce-connect-adapter-generate skill is loaded, your dev agent knows:

• The exact method signatures for DataSource.Provider and DataSource.Connection
• Correct DataSource.DataType mappings for your API’s field types. The skill knows which enum value to use for text, numbers, URLs, and more
• That ExternalId and DisplayUrl columns are required on every table definition
• That every table needs a column designated as its “name” column or the validate and sync operation fails
• How to structure TableResult, QueryUtils, and SearchUtils
• Named credential patterns so no credentials end up hardcoded

Without this skill, any dev agent produces plausible Apex that fails on first sync. With it, the agent gets the contract right on the first try.

Real-world use case: iRail Belgian Rail API

A developer at a travel company needs live data from 714 Belgian train stations in Salesforce for their customer service agents. The iRail API has this data: a public REST endpoint, free to use, returning clean JSON. No built-in adapter covers this endpoint and a custom Apex adapter is the only path.

With the platform-salesforce-connect-adapter-generate skill loaded, the developer describes the API in plain language:

“I have a public REST API for Belgian train stations at GET https://api.irail.be/v1/stations. It returns 714 stations with id, name, locationX, and locationY fields. Create a custom Salesforce Connect Apex adapter.”

The agent generates both Apex classes DataSource.Provider and DataSource.Connection with correct field types, required columns, and named credential auth wired in:

public class TrainTravelDataSourceConnection extends DataSource.Connection {
    public override DataSource.TableResult query(DataSource.QueryContext context) {
        HttpRequest req = new HttpRequest();
        // context unused here — iRail returns all stations; use QueryUtils.filter/sort for filtered queries

req.setEndpoint('callout:iRail_Named_Credential/v1/stations?format=json&lang=en');
        req.setMethod('GET');
        HttpResponse res = new Http().send(req);
        Map<String, Object> body = (Map<String, Object>) JSON.deserializeUntyped(res.getBody());
        List<Object> stations = (List<Object>) body.get('station');
        List<Map<String, Object>> rows = new List<Map<String, Object>>();
        for (Object s : stations) {
            Map<String, Object> station = (Map<String, Object>) s;
            Map<String, Object> row = new Map<String, Object>();
            row.put('ExternalId', (String) station.get('@id'));
 row.put('DisplayUrl', 'https://api.irail.be/v1/stations?format=json&lang=en&id=' + (String) station.get('@id'));
            row.put('Name', (String) station.get('name'));
            row.put('LocationX', Double.valueOf((String) station.get('locationX')));
            row.put('LocationY', Double.valueOf((String) station.get('locationY')));
            rows.add(row);
        }
        return DataSource.TableResult.get(context, rows);
    }
}

The code above shows the Connection class, which handles query logic. The full adapter also includes a DataSource.Provider class that declares adapter capabilities and returns the connection instance. See the complete code at https://github.com/shra1904/dreamforce-demo.

Here’s an example of how to run such a prompt with Claude Code:

This skill gives your agent the edge

Some of the key things the skill gets right automatically:

• Every custom adapter must declare a DataSource.Column named ExternalId, and the skill enforces this
• Field types are deterministic and mapped accurately to avoid field type mismatches, which are the most common failure mode
• The callout uses named credentials via the callout: prefix so no hardcoded URLs, no secrets in code
• The return type is DataSource.TableResult, which is the exact contract Salesforce expects

When both classes are deployed to the org via sf project deploy start, the adapter code is live. The next step is registering it in Salesforce as an external data source, traditionally a multistep Setup wizard. With the Salesforce Headless 360 MCP Server connected to your coding agent, that step becomes an API call too.

Registering without going to Setup in Salesforce

The agent invokes the external-data-source-setup platform metadata operation directly thanks to an MCP tool:

# Coding agent generates and deploys the adapter, then calls:
# Headless 360 MCP → external-data-source-setup
# → External Data Source created without opening Setup

The MCP server exposes Salesforce configuration operations as structured tools an AI agent can call so the same operations you’d perform through the UI are accessible programmatically.

This is the direction the platform is heading. Every Setup operation becomes an API call that an agent can invoke. Salesforce Connect is one of the first areas where we’re making this real.

The final step is validate and sync, which creates the external object by querying the adapter for its schema. That is one click in Salesforce Setup. The result: live station data in Salesforce, queryable in SOQL and available across all platform features like flows, reports, and so on.

Getting started

The skill is available now in sf-skills as platform-salesforce-connect-adapter-generate. You’ll need a Salesforce Connect license, Salesforce CLI v2+, and a coding agent like Agentforce Vibes, Claude Code, or Cursor. If you use Agentforce Vibes, the skills are already loaded, but if you are working with a third-party agent, you’ll need to install the skill by running npx skills add forcedotcom/sf-skills in your project directory. Once the skills are available, describe your API to your agent in natural language.

The skill handles any REST API that returns a structured JSON response, whether the API is authenticated or public, and whether the response is paginated or returned as a single response. Tell the agent what fields you need, what types they are, and how authentication works. The generated code is a working first pass. Add error handling and a test class before deploying to production. Apex requires test coverage to deploy to a production org.

Conclusion

Custom Apex adapters have always been capable. The barrier was the knowledge required to write them correctly. The platform-salesforce-connect-adapter-generate skill removes that barrier because your coding agent now knows the full DataSource framework and can generate a working adapter from a plain-language description.

Combined with the Salesforce Headless 360 MCP server, virtually the entire workflow, including code generation, deployment, and org registration, can be completed without leaving your terminal. That’s the foundation we’re building toward: agentic Salesforce configuration, end to end.

In Winter ’27, we’re extending this further with full headless external data source lifecycle management and Salesforce Connect extensibility for standard adapters. (This represents current product direction and is subject to change. Please base purchasing decisions on currently available features.)

Have a data source you’d like to connect to Salesforce? Share your ideas and vote for related requests on IdeaExchange.

Resources

• Salesforce Connect Custom Apex Adapter documentation
• platform-salesforce-connect-adapter-generate skill on sf-skills
• DataSource Namespace reference
• Headless360 MCP documentation
• iRail API (demo target used in this post)

About the author

Shraddha Nakra is a Senior Product Manager at Salesforce on the Platform Connectivity Solutions team, where she owns Salesforce Connect and Private Connect. She focuses on making external data integration secure, faster, and developer-friendly from zero-copy connectivity to agentic configuration. Find her on LinkedIn.

The post Build Custom Salesforce Connect Adapters Smarter with Salesforce Skills appeared first on Salesforce Developers Blog.

You can package Python code as a script, deploy it into Data 360, and invoke it through a batch data transform. The transform remains the operational control point, while the script contains the customer’s processing logic.

The Northstar Outfitters customer scenario

Northstar Outfitters receives product data from several commerce systems. Brand names, currencies, units, required attributes, and product categories are represented differently across those systems. These inconsistencies affect product search and produce uneven analytics across channels.

Northstar needed one trusted product catalog in Data 360. The transformation had to:

• Standardize product names, brands, currencies, and units.
• Enrich products by mapping them to the approved category reference.
• Validate required attributes and identify invalid records.
• Calculate a product-completeness score using custom business rules.

Native batch data transforms support common operations through visual nodes and formulas. The complexity of Northstar’s transformation logic made a code-based approach more practical, so the team implemented it as modular, unit-tested, and source-controlled Python and PySpark with Code Extension.

A batch data transform remained the operational control point, providing execution, scheduling, status, and run history for the deployed script.

How Data 360 Code Extension fits the solution architecture

Northstar selected Code Extension so its production transformation could run on Salesforce-managed infrastructure within Data 360 using Spark for distributed processing. Developers used their local IDE only to validate the logic against sampled data. Full-scale processing began when the batch data transform invoked the deployed script.

This model provided:

• In-platform processing. Custom Python logic executes within Salesforce-managed infrastructure instead of a separate customer-managed processing pipeline.
• Distributed execution. Spark distributes PySpark DataFrame operations across Salesforce-managed compute resources.
• Isolated, temporary runtime. Tenant isolation, runtime sandboxing, network controls, and ephemeral compute help protect the platform and other workloads.
• Managed operations. Data 360 manages deployment, invocation, scheduling, execution status, logs, and run history.

The batch data transform starts the deployed Code Extension. The script uses the Data Custom Code SDK to read permitted DLOs as Spark DataFrames and write to the permitted target DLO. This scenario illustrates a DLO-to-DLO transform. Code Extension scripts also support DMO-to-DMO transforms, but a script must read from and write to the same object type—it can’t mix DLOs and DMOs.

For more about the architecture and security model, see How to Power Data 360 with Code Extension and Securely Running Python with Data Cloud’s Bring Your Own Code Architecture.

Northstar’s object map was:

The DLO names in the package constants matched this access model.

How to structure a Data 360 Code Extension package

The Code Extension script used the following structure:

my_package/
├── payload/
│   ├── config.json
│   └── entrypoint.py
├── requirements.txt
└── tests/
    ├── test_deploy_config.py
    └── test_entrypoint.py

Because my_package/ contains payload/, the team used it as the deployment root and passed --package-dir ./payload to the packaging and deployment commands.

The package access model

In config.json, Northstar identified the SDK version, entry point, data space, and DLOs that the package could read or write.

{
  "sdkVersion": "6.1.0",
  "entryPoint": "entrypoint.py",
  "dataspace": "default",
  "permissions": {
    "read": {
      "dlo": [
        "Product_Catalog_Raw__dll",
        "Product_Category_Reference__dll"
      ]
    },
    "write": {
      "dlo": [
        "Product_Catalog_Curated__dll"
      ]
    }
  }
}

The curated target remained write-only, keeping read and write responsibilities separate. The explicit permission list also gave reviewers a clear view of the package’s intended data access.

Before deployment, the team confirmed that each DLO existed in the configured data space and that the schemas contained every column used by the program. This caught naming and environment differences before transform creation.

What the Python and PySpark entrypoint script does

The entry point followed a simple read, transform, and write flow:

products_df = client.read_dlo(PRODUCT_SOURCE_DLO)
categories_df = client.read_dlo(CATEGORY_REFERENCE_DLO)

changes = transform_products(products_df, categories_df)

client.write_to_dlo(
    FINAL_DLO,
    changes,
    write_mode=WriteMode.MERGE)

Managed execution supplied the authenticated SDK context and enforced the permissions declared in config.json; the script did not hardcode credentials. The transformation function validated and standardized product data, matched approved categories, and calculated the required output. Spark distributed this processing across the managed execution environment.

The script logged failures with their processing context and rethrew exceptions so the data transform could report the run as failed.

How to validate a Code Extension script locally

Before deployment, Northstar ran the script locally against a Data 360 sandbox. Local execution read a sample of up to 1,000 records and sent output to the console without modifying Data 360 objects.

The team used this for functional validation. They measured performance and scale after deploying the script to the managed Data 360 runtime.

Local setup

The local toolchain included Salesforce CLI, Python 3.11, the SDK version declared in config.json, and the Salesforce CLI Code Extension plugin.

sf update
sf plugins install @salesforce/plugin-data-code-extension
python3.11 -m pip install salesforce-data-customcode==6.1.0

sf org login web \
  --alias myorg \
  --instance-url https://test.salesforce.com

sf org display --target-org myorg

With the sandbox authenticated as myorg, the team ran the entry point from the repository root:

sf data-code-extension script run \
  --entrypoint ./my_package/payload/entrypoint.py \
  --config-file ./my_package/payload/config.json \
  --target-org myorg

They ran the unit tests separately:

cd my_package
python3.11 -m pytest tests -q

Northstar’s test suite covered schema handling, normalization, category enrichment, quality-score calculation, invalid and empty inputs, write behavior, structured logging, and disjoint read/write permissions.

The team used the Code Extension quick start as its reference for prerequisites and sandbox setup.

How to deploy a Code Extension with Setup or Salesforce CLI

Deploying through Setup

In Setup, Northstar entered Code Extension in Quick Find and opened Code Extension. The page displayed existing deployments, including their code type, owner, deployment time, and current status.

After selecting New, the team uploaded the ZIP package and selected Python, Script, Batch Transform, and the required compute size before submitting the Code Extension.

Deploying with Salesforce CLI

For its repeatable developer workflow, Northstar used the Code Extension plugin to package and deploy the script:

cd my_package

sf data-code-extension script zip \
  --package-dir ./payload

sf data-code-extension script deploy \
  --name Northstar_Product_Catalog_V1 \
  --package-version 1.0.0 \
  --description "Product catalog standardization and enrichment" \
  --package-dir ./payload \
  --target-org myorg \
  --cpu-size CPU_2XL

The available CPU flags were CPU_L, CPU_XL, CPU_2XL, and CPU_4XL. Northstar began with CPU_2XL, measured the managed run, and used its timing logs to decide whether a different size was justified.

The deployment name was metadata supplied by the command, not a value that had to appear in entrypoint.py. Northstar later used that same name to select the Code Extension for its transform and filter execution logs.

The team also accounted for the documented CLI limitation for DMO-to-DMO transforms, where the UI deployment path is required. The current behavior is described in Deploy a Custom Script to Data 360 Sandbox by Using CLI.

After upload, the package passed through platform security validation before execution. Managed runs used isolated, temporary compute resources, and Northstar planned to migrate the validated Code Extension and dependencies through a DevOps data kit for its production release.

How to connect a Code Extension to a batch data transform

Deployment made Northstar’s script available, but did not execute it. The team connected the deployed Code Extension to a batch data transform, which became the invocation and scheduling layer.

Creating the transform in the UI

In Data 360, Northstar opened Data Transforms, selected Create from Code Extension, entered a unique label and API name, and selected the deployed Code Extension. It saved the transform and used Run Now for the first managed validation.

The team kept the API name within the documented character, length, and uniqueness rules described in Invoke Code Extension by Creating a Batch Data Transform.

Automating transform creation with the Connect API

To automate transform creation, Northstar captured the Connect API request as transform-request.json. The following abridged excerpt highlights the relationship between the target DLO, input DLOs, data space, and deployed Code Extension:

{
  "definition": {
    "type": "DCSQL",
    "manifest": {
      "nodes": {
        "node1": {
          "relation_name": "Product_Catalog_Curated__dll",
          "config": { "materialized": "table" },
          "compiled_code": ""
        }
      },
      "sources": {
        "source1": {
          "relation_name": "Product_Catalog_Raw__dll"
        },
        "source2": {
          "relation_name": "Product_Category_Reference__dll"
        }
      },
      "macros": {
        "macro.byoc": {
          "arguments": [
            {
              "name": "Northstar_Product_Catalog_V1",
              "type": "BYOC_SCRIPT"
            }
          ]
        }
      }
    },
    "version": "56.0"
  },
  "label": "Northstar Product Catalog Transform V1",
  "name": "Northstar_Product_Transform_V1",
  "description": "Invokes the Northstar custom Code Extension",
  "type": "BATCH",
  "dataSpaceName": "default"
}

The team submitted the payload with Salesforce CLI’s REST client:

sf api request rest \
  /services/data/v67.0/ssot/data-transforms \
  --method POST \
  --header "Content-Type: application/json" \
  --body @transform-request.json \
  --target-org myorg

Because the excerpt is intentionally abbreviated, Northstar used the complete manifest required by the current Data 360 Connect REST API reference in transform-request.json.

During testing, transform creation sometimes outlived the UI or CLI wait window. Instead of immediately resubmitting, the team queried MktDataTransform and checked the Data Transforms UI to determine whether backend creation was still progressing.

How to run and monitor a batch data transform

For its on-demand validation, Northstar invoked the transform through the API:

sf api request rest \
  /services/data/v67.0/ssot/data-transforms/Northstar_Product_Transform_V1/actions/run \
  --method POST \
  --body '{}' \
  --target-org myorg

The operations team retrieved transform details and run history with the companion endpoints:

sf api request rest \
  /services/data/v67.0/ssot/data-transforms/Northstar_Product_Transform_V1 \
  --method GET \
  --target-org myorg

sf api request rest \
  /services/data/v67.0/ssot/data-transforms/Northstar_Product_Transform_V1/run-history \
  --method GET \
  --target-org myorg

Northstar waited to schedule recurring production runs until it had measured duration, verified input and output counts, and understood billing for the selected compute size.

How to troubleshoot a failed Code Extension run

Northstar checked three separate signals: Code Extension deployment in DataCustomCode, data transform status in MktDataTransform, and Python execution messages in DataCustomCodeLogs__dll.

Verifying the Code Extension record

sf data query \
  --target-org myorg \
  --query "SELECT Id, Name, CodeType, DeploymentStatus, Status, DeploymentFailureCode, DeploymentFailureReason, CreatedDate, LastModifiedDate FROM DataCustomCode WHERE Name = 'Northstar_Product_Catalog_V1' ORDER BY CreatedDate DESC"

The team treated Status = Active and DeploymentStatus = Deployed as separate signals. DeploymentStatus showed whether package deployment had completed successfully.

Verifying the data transform record

This query confirms the transform exists and shows its current status and most recent execution details.

sf data query \
  --target-org myorg \
  --query "SELECT Id, Name, DataTransformStatus, LastRunStatus, LastRunTime, CreationSource, Type, CreatedDate, LastModifiedDate FROM MktDataTransform WHERE Name = 'Northstar_Product_Transform_V1' ORDER BY CreatedDate DESC"

Inspecting execution logs

Application logs are stored in the DataCustomCodeLogs__dll DLO, so Northstar queried them in Data Explorer using Data 360 SQL. Because log ingestion is asynchronous, messages may appear shortly after an execution completes.

The latest execution messages

Run this query to review the latest execution messages and correlate them with a specific Code Extension run.

SELECT
    "Timestamp__c",
    "Message__c",
    "CorrelationId__c",
    "ExecutionId__c",
    "ProcessDefinitionName__c",
    "DataCustomCodeName__c"
FROM "DataCustomCodeLogs__dll"
WHERE "DataCustomCodeName__c" =
      'Northstar_Product_Catalog_V1'
ORDER BY "Timestamp__c" DESC
LIMIT 200;

How the script produced application logs

Northstar used Python’s standard logging module inside entrypoint.py:

import logging

log = logging.getLogger(__name__)
log.info(
    "PRODUCT_PIPELINE | phase=PROCESS | status=SUCCESS | records_written=%s",
    records_written,
)

During managed execution, Data 360 captured this application message and ingested it into DataCustomCodeLogs__dll. The script did not call a separate API or write directly to the log DLO.

Conclusion

Data 360 Code Extension brings the flexibility of Bring Your Own Code to complex data transformations. Teams can use Python and PySpark for modular and testable logic, multiple data inputs, custom validation, specialized libraries, and distributed processing within a governed Data 360 environment. Combined with batch data transforms for execution, scheduling, monitoring, and run history, it provides a scalable way to operationalize sophisticated data processing without managing a separate external processing platform.

Resources

• • YouTube series: Extend Data 360 with Code Extension
  • How to Power Data 360 with Code Extension
  • Securely Running Python with Data Cloud’s Bring Your Own Code Architecture
  • Code Extension in Data 360
  • Code Extension quick start
  • Deploy a custom script using Salesforce CLI
  • Create a batch Data Transform from Code Extension
  • Data 360 Connect REST API reference
  • Salesforce Data Custom Code SDK on PyPI
  • Salesforce CLI Code Extension plugin

About the authors

Ravindra Varshney is a Senior Director, Software Engineering at Salesforce. You can find him on LinkedIn.   

Gaurav Tewari is a Senior Product Manager at Salesforce. You can find him on LinkedIn.

Chandan Agarwal is a Principal Member of Technical Staff at Salesforce. You can find him on  LinkedIn.

The post Run Complex Data Transformations in Data 360 with Code Extension appeared first on Salesforce Developers Blog.

What is Web Console?

Web Console is a modern, browser-based IDE designed to help developers work faster inside the platform they already know, without switching tools just to inspect code, run queries, debug an issue, or make a quick fix. It’s built on a proven foundation of VS Code for the Web with our existing Salesforce Extensions for Visual Studio Code, delivering a seamless in-browser experience for Salesforce developers. This provides the robustness of a modern IDE in a fast, easy-to-access experience like you had with Developer Console. Yes, this is your modern alternative to Developer Console!

You may also be wondering about how Web Console differs from Agentforce Vibes IDE, since they are both dev environments accessible from the browser. In short, Web Console is a lightweight environment optimized for quick file editing and development tasks within a single org, while Agentforce Vibes IDE is a full development environment backed by a virtual machine (VM), providing additional compute, AI, integration capabilities, and multi-org connections. They really serve two different needs, and depending on what you’re looking to do you can select the appropriate tool for the job.

Web Console provides the same trusted functionality you’ve become accustomed to in Developer Console, but through a more modern experience. Additionally, Web Console provides new capabilities that have not been available in Developer Console, including support for Lightning Web Components (LWC). 

Below is a table highlighting key capabilities of Web Console, with Quick Start instructions for using them in Web Console (and links to full documentation for each). A star indicates features you have access to in Web Console that you didn’t have access to in Developer Console.

Feature/Capability	Quick Start – How to Access Web Console
Quick, in-context Apex viewing/editing	Click Edit on any Apex Class, Trigger, or Scheduled Job from within the org Edit as desired, then Save
View/edit Lightning Web Component (LWC) files	Open Org Browser (cloud icon) in the left-side Activity Bar Navigate the Metadata tree, then click Retrieve Metadata Edit as desired, then Save Learn More
Run Anonymous Apex	From Command Palette (Ctrl+Shift+P on Windows or Cmd+Shift+P on macOS), run SFDX: Create Anonymous Apex Script Edit the script, then right-click in the script file -> SFDX: Execute Anonymous Apex Learn More
Generate/run SOQL queries, optionally with declarative SOQL Builder , and optimize performance by generating a query plan	From Command Palette*, run SFDX: Create Query in SOQL Builder (or Create SOQL Query) Edit the query, then select Run Query Learn More
Run Apex tests and view test results	Open Testing (beaker icon) from the left-side Activity Bar Select a test method, test class, or all Apex tests.  Run test(s) Learn More
Debug Apex with trace flags and log levels	View Logs: Command Palette* -> SFDX: Get Apex Debug Logs Trace/Log Levels Command Palette* -> SFDX: Create Trace Flag for Current User Adjust Log Levels as desired Learn More
Browse all metadata in the org , and optionally retrieve for editing/redeploy with the Org Browser	Open Org Browser (cloud icon) in left-side Activity Bar Browse metadata in the org Optionally Retrieve, Edit, Save Optionally open Explorer (files icon) in left-side Activity Bar to browse/edit/deploy retrieved metadata Learn More
Log Analysis	Coming soon via Certinia Apex Log Analyzer!

* To open Command Palette use Ctrl+Shift+P on Windows or Cmd+Shift+P on macOS.

Connected workflow example: Debugging an Apex job failure

Apex job failures are a good example of where Web Console can make an immediate difference. A developer can begin in the Apex Jobs page, where a failed or long-running Apex job is already visible. From there, they can open the related Apex class in Web Console, enable logging, rerun the scenario, inspect the execution path, jump from the stack trace to the problematic line of code, make the fix, run tests, and validate that the job now completes successfully. They can do all of that without leaving Salesforce or bouncing between disconnected tools.

This streamlined flow is more efficient because it mirrors how real troubleshooting actually happens. The work does not begin in a file tree. It begins with a problem. Web Console is designed so the IDE meets the developer at that point of failure, then stays with them through diagnosis, code change, and validation.

This is one of the clearest ways Web Console improves usability. Instead of forcing the developer to reconstruct the situation across separate tools, it keeps runtime evidence, source code, and validation steps close together, shortening the distance between “What just happened?” and “Did my fix resolve the issue?”

Production versus non-production: Web Console guardrails

Web Console is built with the realities of Salesforce development in mind. In production orgs, Apex editing is read-only, letting developers inspect and understand code safely without any risk to live orgs. In sandboxes and other non-production environments, developers can make inline edits and save changes as part of a faster path-to-fix workflow.

That balance is important. A modern experience should make developers faster, but not by weakening platform guardrails. Web Console keeps the guardrails intact while still streamlining inspection, debugging, and validation.

How to launch Web Console

Web Console is now enabled by default for users with admin permissions. Getting started with Web Console requires no local command-line setup or extension installation. Once it is enabled, you can simply launch it directly from the Setup (gear) menu within your Salesforce org or refer to the official guide on How to launch Web Console. Global access can be disabled or enabled through Setup -> Development -> Web Console.

What about Developer Console?

While we believe that Web Console will provide you with the functionality that you need and an improved experience, if you still prefer to use Developer Console you can easily re-enable it through Setup -> Development -> Web Console, then toggle Enable Developer Console. 

If you or your team find yourselves needing to revert to the legacy Developer Console, we would love to know why! Please share your feedback so we can ensure Web Console continues to satisfy all your development needs.

Conclusion

We’re excited to bring Web Console to general availability, providing a quick, easy, and streamlined experience for your everyday development needs. Whether it’s making a quick edit to an Apex class, modifying an LWC component, testing and debugging your code, querying data in your org, running an Apex script, or just browsing your org’s metadata, Web Console makes it easy. 

And it’s only a click away: try Web Console today at Setup Menu (gear icon) -> Web Console!

Resources

• Web Console documentation
• Feedback/Issues repository on GitHub
• AMA: Oct 28, 2026 at 9 a.m. PT

About the author

Karen Fidelak is a Sr. Director Product Management at Salesforce, focused on bringing robust developer tooling and experiences to our developer community. She leads product teams responsible for our IDEs, VS Code extensions, CLI, Agentforce Vibes, DevOps Center, DX Inspector, and Code Analyzer. You can follow her on LinkedIn.

The post Announcing General Availability: Web Console – Your Modern In-Browser IDE appeared first on Salesforce Developers Blog.