The feature is based on the OpenTelemetry standard and stores all span data directly in Data 360, making it queryable alongside the rest of your org’s data with a single toggle flip.

How to enable Agent Platform Tracing

Enabling Agent Platform Tracing takes about two minutes:

1. Toggle it on in Setup. Navigate to Setup → Agent Platform Tracing and flip the toggle to enabled. This starts writing span data to Data 360 for every Agentforce action execution in your org.
2. Verify Data 360 is provisioned. Agent Platform Tracing stores spans in data model objects (DMOs), so your org needs Data 360 provisioned and active. If you’re already using Agentforce, this is likely already in place.
3. Check permissions. Users querying trace data need the Data Cloud Data Access permission set, plus read access to the ssot__TelemetryTraceSpan__dlm and related DMOs.
4. Wait for data. Spans begin populating within minutes of the first Agentforce action execution after enablement. There’s no backfill of historical data.

Once enabled, trace data is queryable via SOQL against the Data 360 DMOs described in the sections below.

How Agent Platform Tracing builds a trace tree

The core concept of Agent Platform Tracing is straightforward: each instrumented service that is called when an Agentforce action executes generates a telemetry record called a span, and every span records its parent’s ID. That parent-child chain lets you reconstruct the execution sequence as a hierarchical tree, from the root interaction down through the instrumented downstream calls.

Here’s what that looks like in practice. The following trace shows an agent action executing a flow that results in an error:

[OK] run.interaction (96afcfefaa6fbfe9) — 2,430ms
└── [OK] run.llmstep (9939b8bc33d12bfa) — 167ms
    └── [OK] run.topic.FlowAgentforce__FlowBuilderAutomationsTopic — 3ms
        └── [OK] run.llmstep (b3595456464fbe93) — 1,341ms
            └── [ERROR] run.action.Get_Account_179SB000000v31B — 481ms
                ├── [OK] run.invokeActions.FLOW — 274ms [InvocableAction]
                │   └── [OK] run.Get_Account.1 — 266ms [Flow]
                │       Attributes: flow.api.name=Get_Account, flow.api.version=1,
                │                   flow.execution.api.version=Spring '26,    
   |                    flow.type=AutolnchNoTrig
                │       └── [OK] run.createrecord.account — 42ms [Flow]
                │           Attributes: db.collection.name=Account, db.rows_affected=0,
                │                       db.operation.name=query
                └── [OK] run.llmstep (b4e5194e749ede24) — 884ms

A few key things to call out here: the ssot__DurationNumber__c field (e.g. 2,430ms) tells you how long each step took, and ssot__StatusCode__c (Status is always either OK or ERROR) tells you exactly where a chain broke.

Note that the flow ran successfully — run.Get_Account.1 returned OK — but the parent action still errored. The reason is in the span attributes: db.rows_affected=0 tells you the Account query returned nothing. Despite the operation being named run.createrecord, the db.operation.name=query attribute reveals it was actually performing a lookup, not a write, and that lookup came back empty. The action expected a result and didn’t get one. Execution continued anyway with a fallback run.llmstep, which is why the overall interaction didn’t terminate immediately.

Without the span attributes, you’d see a failed action and have no idea whether the flow ran, whether it touched the database, or what it found there.

Comparing Agentforce session tracing and Agent Platform Tracing

Agent Platform Tracing stores spans into Data Lake Object (DLOs) which get mapped into Data Model Object (DMOs) using the single source of truth (ssot) prefix. Before going further, it’s worth understanding how Agentforce sSession Tracing and Agent Platform Tracing differ.

Agentforce Session Tracing — centered on ssot__AiAgentInteraction__dlm — is instrumented at the planner level and captures the conversational flow: what the user said, which subagent handled the request, and what the agent returned. Agent Platform Tracing, via ssot__TelemetryTraceSpan__dlm, is instrumented at the service level and captures the back-end execution state that powered that response. The span DMO is self-referential by design: ssot__TelemetryParentSpanId__c maps back to ssot__Id__c, enabling tree traversal from any node in either direction. Furthermore, because both DMOs share the exact same underlying Trace ID, you can join ssot__TelemetryTraceId__c directly to ssot__TelemetryTrace__c. This enables you to connect Agentforce session tracing to the specific back-end code execution provided by Agent Platform Tracing.

Querying trace data with SOQL

With SOQL, you can query these DMOs directly via the API to extract exactly the diagnostics you need. A good starting point is profiling performance by operation type, which quickly surfaces any parts of your agent execution that are consistently slow:

SELECT ssot__OperationName__c,
       AVG(ssot__DurationNumber__c) AvgDuration,
       MAX(ssot__DurationNumber__c) MaxDuration,
       COUNT(Id) SpanCount
FROM ssot__TelemetryTraceSpan__dlm
WHERE ssot__StartDateTime__c > 2026-01-01T00:00:00Z
GROUP BY ssot__OperationName__c
LIMIT 20

Or we can query for all recent spans that have errors:

SELECT ssot__Id__c, ssot__OperationName__c, ssot__TelemetryTrace__c,
       ssot__StartDateTime__c, ssot__DurationNumber__c, ssot__StatusCode__c
FROM ssot__TelemetryTraceSpan__dlm
WHERE ssot__StatusCode__c = 'ERROR'
ORDER BY ssot__StartDateTime__c DESC
LIMIT 20

Or count errors across operation types:

SELECT ssot__OperationName__c, COUNT(Id) SpanCount
FROM ssot__TelemetryTraceSpan__dlm
WHERE ssot__StatusCode__c = 'ERROR'
GROUP BY ssot__OperationName__c
LIMIT 20

Once we find a span we want to investigate, we can query for all related spans via ssot__TelemetryTrace__c:

SELECT ssot__Id__c, ssot__OperationName__c, ssot__TelemetryParentSpanId__c,
       ssot__ServiceName__c, ssot__StatusCode__c, ssot__DurationNumber__c,
       ssot__StartDateTime__c, ssot__EndDateTime__c,
       ssot__TelemetrySpanAttributeText__c
FROM ssot__TelemetryTraceSpan__dlm
WHERE ssot__TelemetryTrace__c = 'YOUR_TRACE_ID'
ORDER BY ssot__StartDateTime__c ASC

We can then reconstruct the tree client-side by matching each span’s ssot__TelemetryParentSpanId__c to another span’s ssot__Id__c, treating null or 0000000000000000 as the root.

Query Agent Platform Tracing data from Slack with Slackbot

Because this data lives in Data 360, you can easily query the data to observe Agentforce. One effective pattern is wiring instructions into a Slack canvas, feeding it to Slackbot, and using it as the natural language interface for our trace data. This makes it easy for anyone to digest the trace information, as long as Slackbot is set up to query the information correctly. Whether you’re responding to a user complaint or proactively checking for errors, the workflow is the same: ask the bot, get the trace tree, pinpoint the issue, and discuss a fix, without ever leaving Slack. No log spelunking, no guesswork. Just a conversation with Slackbot to find the root cause and come up with a potential solution.

The approach I take when providing instructions to Slackbot is simple: I provide the schemas, sample queries, join patterns, and main use cases. You can find some of the instructions I use in my  Agent Platform Tracing Slackbot Instructions GitHub repo. 

You’ll need to make sure that your Slack is connected to an org that has Agent Platform Tracing enabled. Once you do, just add the instructions for Slackbot into a canvas and either add the canvas as a tab for Slackbot or paste it into the chat at the beginning of your conversation.

Here’s a typical Slackbot exchange:

You:  Why did interaction b9e8f7b4 take 4 seconds?

Slackbot:  I queried all spans for trace b9e8f7b4. The interaction
           took 2,690ms total. Here's the breakdown:

           run.interaction           2,690ms  OK
           └─ run.llmstep              139ms  OK
              └─ run.topic               3ms  OK
                 └─ run.llmstep        838ms  OK
                    └─ run.action      327ms  OK
                       └─ run.llmstep 1,011ms  OK   ← slowest span

           The bottleneck is the final run.llmstep span (1,011ms),
           which accounts for 38% of total duration.

Once you have Slackbot set up with Agent Platform Tracing, you can ask things like:

• Why did this agent interaction take 4 seconds?
• Which subagent is responsible for the most errors this week?
• What are the most common errors for a given operation type? 
• What’s the root cause of this issue that a user is asking about? 

Joining Agentforce Session Tracing and Agent Platform Tracing data

With the right instructions, Slackbot can query and join both Agentforce Session Tracing and Agent Platform Tracing data together. Joining them provides a full trace tree for end-to-end observability of Agentforce. With both features, we have complete visibility of agent activity and issues in a couple of minutes.

Use this when you want to correlate a user’s conversational context (Agentforce Session Tracing) with the back-end execution details (Agent Platform Tracing). This is an optional advanced use case; both features work independently.

How the join works

Because ssot__TelemetryTraceId__c on ssot__AiAgentInteraction__dlm matches ssot__TelemetryTrace__c on ssot__TelemetryTraceSpan__dlm, they can be used for a direct join. This means you can fetch all spans for an interaction in a single query.

Full joined hierarchy

Session (ssot__AiAgentSession__dlm)
└── Interaction (ssot__AiAgentInteraction__dlm)
    └── Step (ssot__AiAgentInteractionStep__dlm)
        └── Span (ssot__TelemetryTraceSpan__dlm)
            └── Span (ssot__TelemetryTraceSpan__dlm)
                └── ...

Query pattern: Get all spans for a known interaction

SELECT ssot__Id__c, ssot__OperationName__c, ssot__TelemetryParentSpanId__c,
       ssot__StartDateTime__c, ssot__DurationNumber__c, ssot__StatusCode__c
FROM ssot__TelemetryTraceSpan__dlm
WHERE ssot__TelemetryTrace__c = 'TELEMETRY_TRACE_ID_FROM_INTERACTION'
ORDER BY ssot__StartDateTime__c ASC

Getting started

Generative AI adds complexity to modern stacks that traditional logging wasn’t designed to observe, and the cost of those blind spots compounds the longer they take to find. Agent Platform Tracing removes the blind spots. And, when you combine it with Slackbot, it is far easier to observe, troubleshoot, and fix Agentforce issues in production so your agents can get back to work without issues. Check out the Agent Platform Tracing Slackbot Instructions GitHub repo for working Slackbot instructions that you can copy-and-paste into a canvas to get started, and the Agent Platform Tracing documentation for setup instructions and the full data model reference.

Trevor Scott is a Senior Manager of Product Management at Salesforce, focused on enabling customers with security and telemetry data to help developers and admins ship more confidently.

The post Agent Platform Tracing: Debug Agentforce with Trace Trees, SOQL, and Slack appeared first on Salesforce Developers Blog.

This post covers how the new MCP server works, how to install it locally, and how your feedback will help us shape the future of the tool.

Solving the context window challenge

Data 360 has a massive API surface. Exposing every endpoint directly as a tool quickly overwhelms a large language model’s (LLM) context window. To solve this, our engineering team implemented a novel approach inspired by Cloudflare’s research on MCP server tool management at scale. Instead of registering the approximately 200 REST API operations individually, this MCP server consolidates them behind three facade tools:

• search: Discovers tools by intent, keyword, or family.
• payload_examples: Fetches working JSON payloads so the LLM understands how to structure complex requests.
• execute: Runs the specific underlying tool by name and passes the correct parameters.

When an LLM wants to perform a task, it uses a typical workflow: it searches for the right capability, fetches a payload example to understand the required data structure, and then executes the operation. This approach saves context window space and improves the accuracy of the AI’s actions while remaining flexible enough to support the ever-growing headless capabilities of Data 360 far into the future.

What the Data 360 MCP server includes

Under the hood, the three facade tools give your AI client access to hundreds of REST API operations organized into tool families. These tools connect directly to most of the general availability (GA) APIs on Data 360.

Getting started: installation and authentication

During this Developer Preview, the MCP server is designed for local execution and is not yet multitenant. This means each running instance connects a single user to a single Salesforce org.

To run the server, you need Java 17 or later, Maven 3.9 or later, and a Salesforce org with Data 360 enabled. You can use an Agentforce Developer Edition org or a Data 360-enabled Trailhead playground if you want to test it in an isolated environment. The server communicates via stdio, so it will work with any MCP client that supports this transport layer. Once your org is ready, follow the instructions in the README to connect your agent and start building.

The GitHub repo contains an installer script that helps set up dependencies and configure common MCP clients for use with the server.

Help us shape the general availability release

The new Data 360 MCP Server enables you to connect powerful LLMs to your Salesforce data without hitting context window limits. By using a novel facade tool architecture, we’ve made roughly 200 API operations easily accessible for agents and coding assistants. 

The Developer Preview is a critical step before we integrate this architecture directly into the Salesforce platform for general availability. By releasing it as open-source now, we aim to speed up platform integration and gather direct feedback from developers. Install the server today, test it with your local tools, and share your feedback on GitHub to help us prepare for the GA release. 

When the Data 360 MCP server becomes generally available, we’ll offer it as a Salesforce Hosted MCP Server alongside other product integration MCP servers. In the meantime, our entire Data 360 team will be testing it internally alongside you to build and refine a collection of Data 360 agent skills; stay tuned for more news on those!

About the authors

Alba Rivas works as a Principal Developer Advocate at Salesforce. You can follow her on Linkedin.

Chris Peterson is a Senior Director of Product Management at Salesforce, currently working on Data 360 Headless.

The post Introducing the Data 360 MCP Server (Developer Preview) appeared first on Salesforce Developers Blog.

We introduced the newest version of the GraphQL wire adapter (lightning/graphql) in Spring ‘26. Now we’re introducing support for using GraphQL beyond just querying in LWC, adding the ability to easily create, update, and delete records via the GraphQL Mutations API.

Executing GraphQL mutations in LWC with executeMutation

In LWC, interacting with the Salesforce GraphQL API for mutations is achieved via the executeMutation function from the lightning/graphql module.
The executeMutation function allows you to execute one or more data changes. The function accepts an object parameter with the same three properties as the GraphQL wire: query, variables, and operationName. For example, to update an Account’s name:

import { gql, executeMutation } from 'lightning/graphql';

const updateRecord = gql(`
            mutation UpdateAccount($input: AccountUpdateInput!) {
                uiapi {
                    AccountUpdate(input: $input) {
                        success
                    }
                }
            }
`);

 await executeMutation({
            query: updateRecord,
            variables: {
                input: {
                    Id: '001xx000003GYiCAAW',
                    Account: {
                        Name: 'Acme[Updated]',
                    },
                },
            },
        });

The executeMutation function supports dynamic query creation, just like the updated GraphQL support provided by lightning/graphql, so you can build these mutation inputs dynamically with JavaScript.

Data consistency considerations

Lightning Data Service keeps Salesforce record data consistent across UIAPI and GraphQL. With GraphQL mutations, this mostly works seamlessly, but we do have a few tips for getting the best results: 

• Newly created records will not appear in existing GraphQL query results until the query is refreshed, depending on its filter criteria and cache state. This applies to create and update mutations that affect records included in a query result set. 
• Updated record fields may be propagated to subscribed Lightning Data Service wire adapters when their cached data overlaps. It may not be necessary to refresh in all scenarios.
• Deleted records will properly be removed from Lightning Data Service wire results. Refreshes are not required for delete operations.

See it in action: The LWC recipes showcase

To help you get started immediately, we have added dedicated examples to the LWC Recipes GitHub repository.

The new graphqlMutation components demonstrate how to use executeMutation to handle create, update, and delete operations through GraphQL. By exploring the source code for the graphqlMutation components, you can see practical implementations of data mutation, success handling, and error display via toast events.

You can clone the LWC Recipes repository to your local machine and deploy the app to your Salesforce org to test this new functionality.

GraphQL Mutations fully unlock bulk updates and tree saves for Lightning Web Components (LWC) without custom Apex. You can now not only view your Salesforce data efficiently but also modify it seamlessly, bringing richer, data-driven applications to life. This capability significantly streamlines the development of complex UIs that require simultaneous creation, update, or deletion of multiple related records. The integration of GraphQL Mutations marks a major step toward empowering LWC developers with a more modern and powerful way to manage data transactions on the Salesforce platform.

Developer Resources

Ready to start mutating your data? Here are the resources you need to dive in:

• Developer Documentation: lightning/graphql
• GitHub repository: LWC Recipes – Find the new graphqlMutation components and other examples.
• API Developer Guide: GraphQL API – Details on the mutation schema and structure.
• Postman Collection: Salesforce Platform APIs/GraphQL – Helpful for testing mutation structure.
• Best Practices Guide: GraphQL Wire Adapter Best Practices – Maximize your GraphQL potential.

About the Authors

Stephen Carraway is a Lead Member of Technical Staff at Salesforce from the Lightning Data Service team. When he’s not building client data libraries, he’s busy woodworking, gardening, and 3D printing. 

Ben Sklar is a Director of Product Management at Salesforce responsible for UI API, the Salesforce GraphQL API, the Lightning Data Service, and AI Developer Kit. Ben is a major fan of GraphQL, but when not using GraphQL, you can find him playing ultimate frisbee or skiing during the winter. Follow him on LinkedIn.

The post GraphQL Mutations Now Available in LWC: Create, Update, and Delete Records appeared first on Salesforce Developers Blog.

This is where developers get a front-row view of the latest AI innovations, product launches, and breakthrough ideas. You’ll gain the skills to build smarter apps and agents, while connecting with a global community shaping the future of Salesforce development.

Each year, we invite the Salesforce Developer community to take the stage. Whether you’re a first-time Dreamforce speaker or a seasoned pro, this is your opportunity to share your expertise, best practices, and real-world insights with thousands of the highly engaged developers and technical leaders. 

The Dreamforce 2026 Call for Participation is now officially open. If you have a great idea for a session, be sure to follow the guidelines outlined below and complete the submission process by 5 p.m. PT on May 27, 2026.

Why submit a Dreamforce proposal?

Presenting at Dreamforce is about inspiring others, sharing your knowledge and expertise, and helping to build a strong and collaborative community of Salesforce professionals. The developer track is seeking compelling, high-quality session proposals that educate by showcasing expertise through technical deep dives, real-world implementations, and innovative solutions that help attendees learn new skills and drive business outcomes. 

Explore topics for your session

The strongest proposals tell a clear, compelling story: the challenge you faced, the solution you built, and what you learned along the way. To craft a standout submission, consider highlighting one or more of the following:

• Technical deep dives that showcase your expertise – whether it’s a specific feature, a solution you’ve built, or a topic you’re passionate about, grounded in real experience
• The latest Salesforce innovations, including hands-on experience with new or upcoming features
• Pilot or beta experiences that offer early insights into what’s next
• Solutions built with Salesforce technologies such as Agentforce, Data 360, Apex, Lightning Web Components, Model Context Protocol (MCP), vibe coding, and more

Cross-cloud use cases that span multiple Salesforce products – for example, integrations between core Platform and Slack

Choose a session format

For inclusion into the Developer track, you can choose from the following session formats:

• Breakout Sessions (40 minutes): These sessions are held in dedicated rooms with larger audience capacity, giving presenters ample time to deep dive into their topic and take live questions. We recommend 32 minutes for presentation delivery and 5-7 minutes for questions and discussion. Up to three presenters may deliver a breakout.
• Theater Sessions (20 minutes): Fast, focused, and built for impact. Conducted on the show floor in open theaters without formal Q&A, with presenters encouraged to continue the conversation with attendees after their session. Maximum of two presenters.

Submit your proposal 

Submitting a Dreamforce session proposal is a straightforward process. Here are some guidelines for filling out the submission form:

• Review the Call for Participation form before starting. Every detail you include helps the technical review team evaluate your session’s potential. We’re looking for clear storytelling, real-world relevance, and actionable takeaways, so be sure to outline the challenge, your solution, and the technical insights your audience will walk away with.
• Craft an authentic and meaningful title and abstract.
  • Title (60 characters max): Make it very clear to attendees what they’ll learn. Tip: Start with a verb and include the name of the product or technology. Example: “Using Parallel Subscriptions to Help with Your Agents”
  • Abstract (200 characters max): Dive deeper into what your session will cover. Accuracy and clarity are more important than creative writing. Be careful with AI-generated content, which can feel inauthentic and impersonal.
• Make sure you can attend Dreamforce 2026 if your session is accepted. Note that we do not provide travel or accommodation for presenters.

Access speaker support and resources

If your session is accepted, you’ll receive an email confirmation by the end of June 2026, and you and any co-presenters will be asked to confirm your participation via our Content Portal. All presenters receive a complimentary speaker pass to Dreamforce 2026. If you’ve already purchased a pass, you’ll receive instructions on how to request a refund or transfer it to someone else.

We’ll guide you through the session preparation process, which includes coaching you to prepare your content, reviewing your presentation slides, and rehearsing your session. 

Not accepted? Don’t be discouraged. The process is competitive and reflects session balance, audience needs, and event themes, not the quality of your idea. Consider sharing your expertise at Trailblazer Community conferences or Trailblazer Community group meetups.

Important dates to remember

• April 29, 2026: Call for Participation opens
• May 27, 2026, 5 p.m. PT: Submission deadline
• End of June 2026: Proposal status notifications sent
• September 15–17, 2026: Dreamforce 2026, San Francisco

Begin your submission now

Submit your proposal by Wednesday, May 27, 2026 at 5 p.m. PT. We look forward to seeing your ideas.

About the author

Christie Fidura is responsible for Global Developer Programs at Salesforce. You can follow her on BlueSky or LinkedIn.

The post The Dreamforce 2026 Call for Participation Is Now Open appeared first on Salesforce Developers Blog.

This is where the enterprise interface is heading; the AI revolution is here. Today, Salesforce hosted MCP servers are generally available — and they’re the infrastructure that enables that for your organization.

What started as a pilot last spring and beta last October — connecting AI assistants to Salesforce logic and assets through the Model Context Protocol (MCP) — is now a production-ready capability for every Enterprise Edition org and above. Any MCP-compatible client can securely connect to Salesforce with enterprise-grade authentication, governance, and admin control built in.

A hosted MCP server is a Salesforce-managed endpoint that exposes your org’s logic and assets — data, flows, Apex actions, queries, and more — to any AI client that speaks MCP. Salesforce handles hosting, authentication, and permission enforcement automatically. Whether your users live in Slack, Claude, ChatGPT, or something else entirely, MCP means they can work with Salesforce without switching contexts. All the major AI platforms and workplace communication solutions are building on MCP as the standard way to connect AI agents to enterprise systems. We now have an open standard for the industry to converge upon, and Salesforce is enthusiastically embracing the shift.

What’s in the GA

If you read the beta announcement, you saw the vision. For the GA, we’re highlighting the following:

• Fully managed infrastructure. Salesforce hosts and scales your MCP servers, just as it does for the REST APIs you already use. No servers to provision, no uptime to manage. Enable a server in Setup and you’re live.
• Platform security built in. Your existing permissions automatically apply — CRUD, FLS, sharing rules, and all the other controls you’ve already mastered. Every transaction runs as the authenticated user, without anonymous service accounts or a new security model to learn. OAuth and PKCE control access.
• Robust, extensible feature set. Use prebuilt standard servers for the Agentforce 360 Platform, Tableau Next, Data 360 SQL, and more — or configure custom servers that expose your flows, Apex actions, and Named Query APIs.
• Prompt templates. Craft prebuilt starting points for common tasks like account reviews or deal analysis in natural language to guide AI toward useful outputs grounded in your org’s data.

And soon, you’ll be able to open up even more possibilities by invoking Agentforce agents via MCP.

Real-world use cases and impact

We received great customer feedback during the pilot and beta periods regarding use cases for the MCP server:

Sales reps who never leave their AI assistant. A rep preparing for a quarterly business review asks their chatbot to pull the account history, open opportunities, recent case activity, and stakeholder map — all from Salesforce, all in one conversation. No tab-switching, SOQL, or reports to build. The CRM data comes to them.

Cross-system intelligence. A financial services company connects their AI assistant to Salesforce alongside their ERP system. The assistant reconciles quarterly revenue by comparing closed-won opportunities against general ledger entries, all with production data and enterprise-grade security.

Custom tools for domain-specific workflows. ISV partners can build custom MCP tools backed by Apex invocable actions, Apex REST, and more. This gives our mutual customers’ AI assistants the ability to interact with their industry-specific data model through natural language, without the end user needing to understand the underlying schema.

Human at the wheel

In the beta announcement, we characterized MCP as a universal translator between AI agents and your business data. Though that’s accurate, it undersells the importance of enabling secure access to data and actions under human control.

Every MCP transaction runs with the authenticated user’s identity, permissions, and accountability. If the agent updates a record, that person’s name appears in the audit trail. If their permissions don’t allow an operation, the agent can’t do it either. The human is in the driver’s seat.

Steve Jobs called the personal computer “a bicycle for the mind” — a tool that amplified human capability beyond what was possible working by hand. With MCP and today’s AI assistants, we’ve moved past the bicycle. If personal computers were human-powered, now we’ve attached an engine, but the human is still at the wheel. A sales rep preparing for a meeting doesn’t log into Salesforce, navigate to the account, click through related records, and build a briefing by hand. They ask their AI assistant — in whatever tool they’re already working in — and get a comprehensive account review grounded in live customer data.

The pace of business increases every day, and MCP helps your team keep up.

Safety comes faster this time

It took more than 50 years for seat belt mandates in automobiles. In AI, safety controls are evolving in months, not decades.

MCP itself is a safety mechanism. Structured tool calls replace unstructured API access. The server defines exactly which operations are available; there’s no way for an AI assistant to call an API that hasn’t been explicitly exposed. A new OAuth scope provides access to MCP, but not our existing REST APIs. Salesforce adds further layers: the platform’s decades-proven permission model, full audit trails, and the secure-by-default posture requiring MCP servers to be specifically enabled.

Salesforce has always had strong access controls, but that’s not true of every enterprise system. A new category of products is emerging to help manage this on an enterprise-wide basis: MCP gateways — similar to API gateways, but purpose-built for the protocol. Products like MuleSoft AI Gateway provide centralized governance across all your MCP servers, not just Salesforce. Enterprises deploying MCP across multiple vendors will want to explore MCP gateways for centralized access control.

Getting started

The setup takes less than 30 minutes. Here’s the shortest path:

1. Enable a server in Setup → API Catalog → MCP Servers
2. Create an External Client App with mcp_api and refresh_token scopes
3. Connect your client — Postman for testing, then Claude, ChatGPT, or similar for everyday use

Documentation is grouped into three layers to match the needs of various roles:

• Salesforce Help — Admin setup and configuration
• Developer Docs — Technical reference, client setup, and troubleshooting
• Community Wiki — Patterns, tips, and the rationale behind our design decisions

If you’re not sure where to begin, try the platform/sobject-reads server in a sandbox. It’s read-only, risk-free, and immediately useful. When you’re ready for more, you can choose or build the exact tool set your organization needs.

A new chapter

When we launched the beta, we imagined a world where every department could access CRM data through natural language. This year at TDX I presented on how our hosted MCP server brings this to life for Salesforce customers. You can now watch this TDX session on Salesforce+: Master Agentic Integration with Salesforce MCP Servers

CRM is a capability, not a destination. We’re just getting started.

About the author

Ross Belmont is a Senior Director of Product Management focused on integrations, with more than 15 years of experience in the Salesforce ecosystem.

The post Salesforce Hosted MCP Servers Are Now Generally Available appeared first on Salesforce Developers Blog.

Today, we’re announcing two tools that change this. B2C Developer Tooling is an open-source project that|includes a command-line interface (CLI) and a software development kit (SDK) for the entire B2C platform. On-demand sandbox cloning is a new platform capability that lets you create exact replicas of existing sandboxes in minutes. This post covers what the tooling includes, how sandbox cloning works, and how you can get started today.

B2C Developer Tooling: A single CLI for the entire platform

B2C Developer Tooling is an open-source, Apache 2.0–licensed, Salesforce-supported set of packages purpose-built for B2C Commerce developers and admins. We publish three Node.js packages: the CLI (@salesforce/b2c-cli), a reusable SDK (@salesforce/b2c-tooling-sdk), and agent skills for AI-assisted development.

The CLI is built on oclif — the same framework behind the Salesforce sf CLI and Heroku CLI — and provides 200+ commands across 20+ topic areas. That includes code deployment, sandbox management, Managed Runtime, embedded CDN (eCDN) configuration, Shopper Login and API Access Service (SLAS), Custom Salesforce Commerce API (SCAPI) endpoints, Account Manager administration, and more. Whether you’re pushing cartridges with b2c code deploy, tailing Managed Runtime (MRT) logs, or configuring Web Application Firewall (WAF) rules on your eCDN zone — we’ve consolidated it into one tool.

The source code lives on GitHub at the B2C Developer Tooling repository.

Built for the modern platform

We built the tooling SCAPI-first, using Salesforce Commerce APIs wherever available and falling back to the Open Commerce API (OCAPI) only where needed. Authentication is zero-config for most commands — a built-in public OAuth client and browser-based login flow means you can start working without creating API credentials.

For continuous integration (CI) and automation, the CLI is backwards-compatible with sfcc-ci conventions and environment variables, so you can adopt it alongside your existing setup. If you use sfcc-ci, consider updating your CI/continuous delivery (CD) systems to stay up-to-date with the latest platform changes and deprecations. Structured logging with automatic redaction of secrets keeps your pipelines clean and your credentials safe.

Developer velocity

We designed the CLI to keep you moving. Generate new cartridges, controllers, hooks, custom APIs, job steps, and Page Designer components from built-in scaffolds with b2c scaffold generate. Pull instance logs directly from the command line with b2c logs get — and filter by type, level, or time range without navigating WebDAV. For MRT storefronts, b2c mrt tail-logs streams environment logs in real time.

Official GitHub Actions

We provide official GitHub Actions for automating B2C Commerce operations in your CI/CD pipelines. High-level composite actions cover the most common workflows — code deployment, data import, MRT deployment, and job execution — while a raw command passthrough handles everything else. The actions manage CLI installation, credential configuration, and caching automatically. These are fully transparent composite actions defined in YAML, with no compiled JavaScript. See the CI/CD guide for details.

Spotlight: On-Demand Sandbox Cloning

Starting with the 26.3 release, we’re introducing On-Demand Sandbox Cloning — the ability to create exact replicas of existing sandboxes with the same data, configurations, and application code. This is a platform-level capability available through the Control Center UI and the B2C CLI from day one.

Why this matters: environment setup that previously took hours of manual configuration can now be completed in minutes. Need a fresh environment for testing a release? Clone your staging sandbox. Want to reproduce a production issue safely? Clone the relevant environment and investigate in isolation. Each clone is fully independent, so changes in one never affect the other.

Key benefits:

• ~75% faster environment setup, based on internal testing comparing traditional import/export (data import, code deployment, site configuration) to a single clone command 
• Exact replicas — data, site configuration, and code version all carry over
• Fully isolated — each clone is an independent sandbox with its own lifecycle

All of this leads to faster, less error-prone test and development cycles.

When using the cloning feature, you’ll likely still need to update certain environment-specific configurations. Site preferences, aliases, hybrid SLAS configuration settings, and any instances of the tenant identifier of the environment are not automatically updated and should be set with a post-clone data import.

Cloning with the CLI

The CLI provides full support for creating and managing clones:

# Create a clone and wait for it to complete
b2c sandbox clone create zzzv-123 --wait

# List all clones for a sandbox
b2c sandbox clone list zzzv-123

# Get detailed status of a specific clone
b2c sandbox clone get zzzv-123 aaaa-002-1642780893121

You can optionally specify a --target-profile (medium, large, xlarge, xxlarge) and --ttl to control the clone’s resource size and lifetime. The source sandbox is automatically stopped during cloning to ensure data integrity.

Teach your coding agent B2C Commerce

B2C Developer Tooling includes two sets of agent skills designed for AI coding agents:

• b2c-cli — 16 skills covering CLI operations like code deployment, sandbox management, MRT, and eCDN configuration. These teach your coding agent how to use the CLI on your behalf.
• b2c — 18 skills teaching B2C development patterns including controllers, hooks, Custom APIs, Page Designer components, forms, and more. These give your coding agent deep knowledge of B2C-specific architecture and best practices — not just CLI syntax.

The skills work with Claude Code, Cursor, GitHub Copilot, VS Code, Windsurf, and any tool that supports the agent skills format. Install them from the Agent Skills marketplace, through the Skills CLI, or by running b2c setup skills.

The CLI also includes a safety mode that prevents accidental destructive operations, which is particularly important when exposing the CLI as a tool to coding agents. You can set the safety level to NO_DELETE, NO_UPDATE, or READ_ONLY to control what operations are allowed.

Model Context Protocol (MCP) Server

For deeper integration, we also ship an MCP server (@salesforce/b2c-dx-mcp) that gives coding agents direct access to platform tools. It includes tools for managing cartridges, working with MRT environments, and scaffolding Custom SCAPI endpoints. It also supports building storefront-next components with Figma-to-component generation, Page Designer decorators, and site theming. Connect it to any MCP-compatible coding agent for a richer development experience.

Extend with plugins and build with the SDK

The CLI supports an oclif-based plugin system for adding custom commands, and exposes hook points for integrating with external credential stores, modifying API requests, and customizing deployment workflows. Community plugins already exist for IntelliJ configuration, Keychain credential storage, and more.

For custom integrations, the SDK (@salesforce/b2c-tooling-sdk) exposes all core functions as a reusable Node.js library — build your own tools on top of the same APIs that the CLI uses. The CLI also supports shell autocomplete for bash, zsh, fish, and PowerShell.

Conclusion

Between a unified CLI covering the full B2C platform and the ability to clone sandboxes in minutes, we’re making it significantly easier for you to develop, test, and ship on Commerce Cloud. Install the CLI today with npm, try cloning a sandbox, and let us know what you think. Your feedback directly shapes what we build next.

Node.js 22 or later is required. To install agent skills for your coding agent, run b2c setup skills. We welcome feedback and contributions through GitHub Issues.

Resources

• B2C Developer Tooling documentation
• B2C Developer Tooling on GitHub
• Agent Skills guide
• CI/CD with GitHub Actions
• sfcc-ci migration guide

About the author

Charles Lavery is a Principal Member of Technical Staff at Salesforce specializing in developer tooling and APIs.

The post Introducing the B2C Commerce CLI and On-Demand Sandbox Cloning appeared first on Salesforce Developers Blog.

• Agentforce Vibes Developer Guide: Build a React App with Salesforce Multi-Framework (Beta)

注意: 2026年4月時点ではまだ Beta 版です。

この記事では、Developer Edition で作成したスクラッチ組織を使い、内部ユーザーが利用する想定のシンプルなアプリを作成する手順を紹介します。スクラッチ組織の作成方法については、かこのブログ記事「Developer Edition + スクラッチ組織で、複数の開発・検証組織を手にいれる」をご参照ください。ログインして表示言語を日本語化した状態から進めていきます。

事前準備

まずは VS Code で新規に「Standard」で作成したプロジェクトを用意します。

React External App や React Internal App もあるのですが、結構作り込まれたテンプレートが展開されます。構造を理解することがやや大変なので、今回はシンプルなテンプレートからの作成を紹介します。

このあと、スクラッチ組織を作成、もしくは既存のスクラッチ組織に接続します。組織にログインして機能有効化を行ってください。

• 設定 > アプリケーション > Salesforce Multi-Framework を使用した React 開発 (ベータ)
• 「Enable Beta」ボタンを押す

この機能はオフにできませんので、必ず Developer Edition や Sandbox などで試すようにしてください。

このあとはローカルの VS Code での操作を進めます。Standard で作成したプロジェクトで、スクラッチ組織に接続した状態にしておきます。

ステップ1: テンプレートを展開

まずターミナルを開き、次のコマンドを実行します。

sf template generate ui-bundle -n myreactapp -d "./force-app/main/default/uiBundles" -t reactbasic

force-app/main/default/myreactapp ディレクトリに必要なファイルが展開されます。

このディレクトリに移動して、install と run dev を実行します。

# ディレクトリに移動
cd force-app/main/default/uiBundles/myreactapp

# 必要なライブラリをインストール
npm install

# ローカルで実行
npm run dev

ブラウザを開いて、表示された URL にアクセスしてみます。次のように表示されたら成功です。

ターミナルで Ctrl + C でローカルのサーバーを止めておきます。

ステップ2: ビルドとデプロイ

2026年4月25日時点ですが、graphqlClient.ts でエラーを検出しています。当該ファイルの13行目を次のように修正します。

修正前: const response = await data.graphql?.<TData, TVariables>(query, variables);
修正後: const response = await data.graphql?.<TData, TVariables>({query, variables});

それではビルドを行います。同じフォルダで次のコマンドを実行します。

npm run build

エラーが出なければ成功です。

それでは組織にデプロイしてみましょう。次のコマンドを実行します。(スクラッチ組織の場合のコマンドです)

sf project deploy start

Status が Succeeded で完了すれば成功です。

ステップ3: 動作確認

それでは組織にデプロイされた React アプリを見てみましょう。

• アプリケーションランチャー > Myreactapp

先ほどのローカルテストと同じように表示されれば成功です。

ステップ4: 取引先のデータを表示できるように修正

pages ディレクトリの下に「Accounts.tsx」ファイルを作成します。(Agentforce Vibes に作ってもらいましたので、切り詰めればもっとシンプルにできるかもしれません。)

import { useEffect, useState } from 'react';
import { executeGraphQL } from '@/api/graphqlClient';
import {
  Table,
  TableBody,
  TableCell,
  TableHead,
  TableHeader,
  TableRow,
} from '@/components/ui/table';
import { Skeleton } from '@/components/ui/skeleton';
import { Alert, AlertDescription, AlertTitle } from '@/components/ui/alert';

interface AccountNode {
  Id: string;
  Name: { value: string };
  Website: { value: string | null };
}

interface AccountsData {
  uiapi: {
    query: {
      Account: {
        edges: Array<{
          node: AccountNode;
        }>;
      };
    };
  };
}

const ACCOUNTS_QUERY = `query GetAccounts {
  uiapi {
    query {
      Account {
        edges {
          node {
            Id
            Name {
              value
            }
            Website {
              value
            }
          }
        }
      }
    }
  }
}`;

export default function Accounts() {
const [accounts, setAccounts] = useState<AccountNode[]>([]);
const [loading, setLoading] = useState(true);
const [error, setError] = useState<string | null>(null);

  useEffect(() => {
const fetchAccounts = async () => {
try {
        setLoading(true);
        setError(null);
const data = await executeGraphQL<AccountsData, undefined>(ACCOUNTS_QUERY);
const accountNodes = data.uiapi.query.Account.edges.map(edge => edge.node);
        setAccounts(accountNodes);
      } catch (err) {
        setError(err instanceof Error ? err.message : 'Failed to fetch accounts');
        console.error('Error fetching accounts:', err);
      } finally {
        setLoading(false);
      }
    };
    fetchAccounts();
  }, []);

if (loading) {
return (
      <div className="max-w-7xl mx-auto px-4 sm:px-6 lg:px-8 py-12">
        <h1 className="text-3xl font-bold text-gray-900 mb-6">取引先一覧</h1>
        <div className="space-y-2">
          <Skeleton className="h-12 w-full" />
          <Skeleton className="h-12 w-full" />
          <Skeleton className="h-12 w-full" />
          <Skeleton className="h-12 w-full" />
          <Skeleton className="h-12 w-full" />
        </div>
      </div>
    );
  }

if (error) {
return (
      <div className="max-w-7xl mx-auto px-4 sm:px-6 lg:px-8 py-12">
        <h1 className="text-3xl font-bold text-gray-900 mb-6">取引先一覧</h1>
        <Alert variant="destructive">
          <AlertTitle>エラー</AlertTitle>
          <AlertDescription>{error}</AlertDescription>
        </Alert>
      </div>
    );
  }

return (
    <div className="max-w-7xl mx-auto px-4 sm:px-6 lg:px-8 py-12">
      <div className="mb-6">
        <h1 className="text-3xl font-bold text-gray-900">取引先一覧</h1>
                  全{accounts.length}件の取引先が登録されています
      </div>
      {accounts.length === 0 ? (
        <Alert>
          <AlertTitle>取引先がありません</AlertTitle>
          <AlertDescription>
            現在、登録されている取引先はありません。
          </AlertDescription>
        </Alert>
      ) : (
        <div className="border rounded-lg overflow-hidden">
          <Table>
            <TableHeader>
              <TableRow>
                <TableHead className="font-semibold">ID</TableHead>
                <TableHead className="font-semibold">取引先名</TableHead>
                <TableHead className="font-semibold">ウェブサイト</TableHead>
              </TableRow>
            </TableHeader>
            <TableBody>
              {accounts.map(account => (
                <TableRow key={account.Id}>
                  <TableCell className="font-mono text-sm">
                    {account.Id}
                  </TableCell>
                  <TableCell className="font-medium">
                    {account.Name.value}
                  </TableCell>
                  <TableCell>
                    {account.Website.value ? (
                      <a
                         href={account.Website.value}
                         target="_blank" rel="noopener noreferrer"
className="text-blue-600 hover:underline">
                        {account.Website.value}
                      </a>
                    ) : ('—')}
                  </TableCell>
                </TableRow>
              ))}
            </TableBody>
          </Table>
        </div>
      )}
    </div>
  );
}

routes.tsx ファイルを次の内容に置き換えます。

import type { RouteObject } from 'react-router';
import AppLayout from '@/appLayout';
import Home from './pages/Home';
import Accounts from './pages/Accounts';
import NotFound from './pages/NotFound';

export const routes: RouteObject[] = [
  {
    path: '/',
    element: <AppLayout />,
    children: [
      {
        index: true,
        element: <Home />,
        handle: { showInNavigation: true, label: 'Home' },
      },
      {
        path: 'accounts',
        element: <Accounts />,
        handle: { showInNavigation: true, label: '取引先' },
      },
      {
        path: '*',
        element: <NotFound />,
      },
    ],
  },
];

ステップ5: 再ビルドとデプロイ

ファイルの修正が完了したら、再度ビルドを行い組織にデプロイします。

# ビルドの実行
npm run build

# デプロイの実行
sf project deploy start

# もしソースファイルエラーやコンフリクトが発生した場合(コマンドを実行するディレクトリによって --source-dir の引数は要調整)
sf project deploy start --source-dir . --ignore-conflicts

Status が Succeeded で完了すれば成功です。

ステップ6: 動作確認

スクラッチ組織の場合、取引先にはデータが何もないのでいくつか作成しておきます。

再度 Myreactapp を表示します。画面右上のメニューアイコンを押すと「取引先」選択肢が出現し、選択すると取引先の一覧が表示されれば成功です。

おわりに

今までは Lightnign Experience & Lightning Web Components と Visualforce に頼っていた Web ブラウザへの UI 提供ですが、React にも対応したことで、そのデータの表現力が格段に向上しました。いわゆる社内向けの UI はもちろん、Experience Cloud での社外向けサイトでの利用も可能です。正式リリースまで今しばらくお待ちください。

今回はすべて手動での作業手順でご紹介しましたが、もちろんバイブコーディングで開発を進めていくこともできます。Agentforce Vibes はもちろん、その他のコーディング支援ツールでも利用できるようにスキルを公開していたりしますので、ぜひご活用ください。

• Github: Agentforce Vibes Library

SFDX プロジェクトの新規作成を行う際に、React Internal App を選ぶとより作り込まれたテンプレートが展開されます。Agentforce で作成したエージェントとのチャットも行える UI も組み込まれています。こちらもぜひ試してみてください。

参考資料

• Agentforce Vibes Developer Guide: Build a React App with Salesforce Multi-Framework (Beta)
• Github: Agentforce Vibes Library
• Agentforce Vibes React (Open Beta): Quick Look
• Github: Multiframework Recipes

The post Salesforce Mult-Framework を使用した React による UI 開発 appeared first on Salesforce Developers Blog.

Historically, tools for addressing this challenge have relied on top-down analysis — scanning Apex metadata to find suspicious patterns. Today, we are unveiling a bottom-up revolution: Database Insights in Scale Center.

The “runtime reality” gap

Traditional performance analysis tools suffer from a runtime reality gap. They look at your code repository and say, “This query uses an indexed field; it’s fine.” But enterprise-grade applications live and breathe dynamic SOQL, where the query isn’t fully built until the moment a user clicks a button.

Static scanners are blind to the bind variable values — the actual data passed into your filters at runtime. Without knowing these values, it is impossible to distinguish between a selective success and a table-scan terror:

• Selective success: Your query uses an index to jump straight to the 10 records you need out of millions. It’s fast, efficient, and keeps your org snappy.
• Table-scan terror: This occurs when the database engine cannot use an index and is forced to look at every single record in a table to find a match.

Architect’s tip: Think of a table scan like trying to find a specific quote in a 500-page book by reading every single word from page one, rather than using the index at the back to jump to the right page. When your table grows to millions of rows, these scans cause CPU timeouts and slow down the entire platform for your users.

Navigate to Database Insights from Setup >> Scale Center >> Database Insights.

Engineering the bottom-up approach

Database Insights turns the traditional model on its head. You don’t guess which queries are slow; you start where the performance impact is actually felt: the database. This is a three-step process.

1. Identifying the heavy lifters

Instead of analyzing every line of code, with the bottom-up approach you identify the specific queries driving resource consumption during your most critical business windows. Think of it like a database administrator using standard system views (similar to open-source equivalents like pg_stat_statements). You isolate the queries that dominated CPU usage during your org’s peak performance hour, helping you identify the specific code causing the most friction.

2. Intelligence-driven reconstruction

A raw database execution looks very different from the Apex you wrote. Our platform uses a sophisticated mapping engine to bridge the gap between runtime database activity and your source code:

• Context discovery: The system automatically filters out system overhead to focus exclusively on your custom logic.
• Traceability: The system correlates database activity back to its origin — whether that’s a specific Apex class, Flow, or report.
• Bind-value awareness: It captures the actual bind variable values passed to the database. Knowing a query failed because of a NULL filter can be the difference between a guess and a guaranteed fix.

3. Execution-plan analysis 

Once the query has been reconstructed by the mapping engine, it is analyzed by the Database Insights optimization engine. By evaluating the actual database execution plan — the same way an expert uses an EXPLAIN command — we generate surgical recommendations based on that execution plan for the query.

Case study: The dynamic predicate problem

Consider a common pattern: a utility class that fetches records based on dynamic filters. 

public static List simpleBindingSoqlQuery(Map<String, Object> bindParams) {
    String queryString =
        'SELECT Id, Name ' +
        'FROM Account ' +
        'WHERE name = :name';
    return Database.queryWithBinds(
        queryString,
        bindParams,
        AccessLevel.USER_MODE
    );
}

String accountName = 'Acme Inc.';
Map<String, Object> nameBind = new Map<String, Object>{'name' => accountName};
List accounts = simpleBindingSoqlQuery(nameBind);
System.debug(accounts);

A static scanner inspects the Apex code and reports that the query passes all checks — it uses bind variables, is sanitized, and shows no obvious flaws. In reality, during peak traffic, Scale Center identifies this method as a top CPU consumer because the runtime data exposes issues that static analysis cannot see.

Example: The non-selective null

A UI component accidentally passes a null value into the filter. The reconstructed SOQL becomes:

SELECT Id, Name FROM Account WHERE name = null

Since NULL values are rarely indexed effectively in large datasets, the engine scans millions of rows in a full table scan. Scale Center flags this as a high-CPU query, notes that the filter ‘Name’ is receiving null values, and provides the recommendation: add a null-check in the Apex controller before execution to prevent NULL values from reaching the query.

Example: The polymorphic date bloat

A report generation tool builds a query with a wide date range. The reconstructed SOQL is:

SELECT Id FROM Case WHERE CreatedDate = LAST_N_DAYS:365 AND Status = 'Closed'

In this case, the database performs an index skip scan. The combination of a broad date range and a low-cardinality status field forces the database engine to examine far more rows than necessary. Scale Center identifies this high CPU usage and recommends narrowing the date range to 30 days or including the Status field in a composite index to improve selectivity.

Comparing static analysis and Database Insights

The following table shows how a traditional static Apex parser differs from Database Insights across visibility, complexity, performance, and context.

How to use Database Insights results

When you open Database Insights, don’t focus only on the SOQL string. Look at both the “SOQL” and the “Recommendation” columns to identify the actual queries and suggestions for how to improve them.

A game changer for architects and developers

If you are managing a large-scale implementation, Database Insights in Scale Center provides unique capabilities that are not available through static analysis alone.

First, it enables impact-based prioritization. You aren’t investigating and fixing 100 “maybe” slow queries. You are fixing the top 15 queries that actually consumed the most CPU during your busiest hour last week. Second, it supports infrastructure stability. By optimizing these expensive, suboptimal SQL queries, you aren’t just helping your users; you are also protecting the pod’s availability and reducing the risk of concurrent request limit exceptions.

Database Insights is not just another dashboard. It is a bridge between the database optimizer and the Apex developer. By analyzing how queries are executed and providing targeted recommendations and providing a library of fixes, we are moving from passive monitoring to actionable, data-driven recommendations.

About the author

Anand Vardhan is a Product Owner for the Scalability Products Team, helping customers develop scalable solutions on the Customer 360 platform. Anand designs features for Scale Center and Scale Test products. His background includes performance and scale engineering, server-side optimization, Lightning, application design, caching, and managing large data volumes. Follow Anand on LinkedIn.

The post Beyond Static Analysis: How Scale Center’s New Database Insights Thinks Like a DBA appeared first on Salesforce Developers Blog.

「商談が終わったら、すぐに活動内容を入力してください」

営業現場でよく聞くこの一言が、いかに現場の負担になっているか。

移動中、次のアポの準備中、それでも入力しなければならない。結果として記録が後回しになり、CRMのデータ品質が下がり、マネージャーは実態が見えなくなる···そんな悪循環は、多くの営業組織が抱える慢性的な課題です。

この記事では、Salesforce の 画面フロー機能とPrompt TemplateのStructured Output(構造化出力)機能を組み合わせて、この課題をどのように解決できるかを、実際の実装例をもとに解説します。

動画:利用イメージ

音声入力ーAIによる項目振り分け

この機能を使った利用例がこちらです。モバイルに音声で話すだけで、AIが重要情報を自動抽出し情報を更新します。本例ではテストオブジェクトというカスタムオブジェクトを対象としていますが、どのオブジェクトに対しても転用可能です。

何をする機能なのか

やっていることはシンプルです。

ここでは、レコードページから画面を起動する例をご紹介します。

1. 営業担当者がレコードページのボタンを押す
2. 「ここに音声入力してください」というテキストエリアが表示される
3. 担当者は商談の内容を自由に話すか、テキストで入力する
4. 「次へ」を押すとAIが内容を解析し、案件の各項目を自動で更新する

従来であれば「課題は何か」「予算はどれくらいか」「ステージはどこまで進んだか」を個別に入力する必要がありました。このフローでは、商談後のメモを自由形式で入力するだけで、AIがそれらを自動的に仕分けして書き込みます。

プロンプトについて

プロンプト全文と応答構造

本例ではテストオブジェクトを対象としていますが、このプロンプトは商談オブジェクトに更新する想定のプロンプトです。

プロンプト全文

【Role】
活動報告の音声文字起こしを最小修正で正規化(内部のみ)し、以下を出力せよ(コードフェンス禁止)。

【抽出用マーカー規約(厳守)】
- Key: opp.stage / opp.pain / opp.start / opp.event / opp.budget / opp.req

【Inputs】
- raw_transcript: {!$Input:input}

【商談更新用(値のみ・ラベル無し・推定抽出強化)】
- すべての opp.* は、タグ内にプレーンテキストの値のみを簡潔に1行250文字以内で出力。
- 禁止:Markdown記法(太字・リストなど)、ラベル("金額:"など)、カッコ装飾、信頼度スコア、引用符、改行。
- 抽出基準(重要):
  - 「確定」していなくても、会話の中で登場した見込み値、概算、候補、提案内容があれば積極的に抽出すること。
  - わずかでも関連する言及があれば値を入れ、「本MTGでは更新候補無し」としないこと。
- 整形ルール:改行は半角スペースへ変換。連続空白は1つへ短縮。
- 完全除外条件:会話全体を通して、そのトピックに関する言及が一切なかった場合のみ、「本MTGでは更新候補無し」を出力。

[各項目の抽出指針]
- opp.stage: 商談の現在の到達点と顧客の温度感を要約した説明文。単なるフェーズ名(例:「提案」)ではなく、「担当者は前向きだが部長決裁待ち」「機能要件は合意したが予算で難航中」のように具体的な状況を記述すること。
- opp.pain: 顧客が漏らした悩み、不満、現状の課題(推測含む)。簡潔に1文で記載。
- opp.start: 開始時期、導入時期、納期の目安(「来春」「4月頃」等のテキストも可)。簡潔に1文で記載。
- opp.event: 今後のマイルストーン、コンペリングイベント(幹部プレゼン、定例会、PoC開始など)。簡潔に1文で記載。
- opp.budget: 金額、予算感、価格帯、コストに関する言及(「100万くらい」「予算確保済み」など幅のある表現もそのまま抽出)。簡潔に1文で記載。
- opp.req: 機能要件、要望、導入条件、制約事項。簡潔に1文で記載。

プロンプトの設計ポイント

【1. 使用モデル:Gemini 2.5 Flash】

今回はGemini 2.5 Flashを使用しています。速度とコストのバランスが良く、日本語の音声文字起こし処理に適したモデルです。

【2. 出力形式:JSON構造化出力+セクションマーカー方式】

プロンプト自体はシンプルなテキスト指示ですが、SalesforceのStructured Output(構造化出力)機能によって、AIの回答はJSON形式で返されます。フロー側では structuredResponse.budget のようにドット記法で各項目に直接アクセスできるため、追加のパース処理は一切不要です。

【3. 「確定情報でなくても積極的に抽出する」という指示】

通常のデータ抽出では「確実な情報のみ抽出」という指示が多いですが、このプロンプトは逆のアプローチを取っています。商談では「100万くらい」「来春かな」という曖昧な言及も重要な営業情報であるため、「わずかでも言及があれば値を入れる」と明示しています。

【4. 空欄上書きリスクを防ぐ「完全除外条件」】

「一切言及がなかった場合のみ『本MTGでは更新候補無し』」と書くことで、フロー側の制御でこのキーワードが格納されている場合は更新しないように制御することができます。この制御を入れることで、既存のCRMデータが空欄で上書きされてしまうリスクを防ぐことができます。(今回のフローではこの制御分岐は入れていません)

【5. ステージは「状態の文章」で記録する】

opp.stage(案件ステージ)に対して、単に「提案中」「交渉中」ではなく「担当者は前向きだが部長決裁待ち」のような状況説明文を要求しています。マネージャーがリスト画面を一覧したときに、クリックせずに状況が把握できるCRMを実現するための設計です。

出力形式:JSON応答構造について

ここで、応答形式をJSON、応答構造から「新しいLightning種類」を選択し出力構造を作成します。

名称を指定します

次に、出力先項目を指定します。ここの項目変数名はプロンプト側と整合性が取れる形にする必要があります。(ただし、厳密に完全一致させなくても大丈夫です)

また、この説明欄を入力することで、より精度高く抽出することが可能になります。プロンプト側でしっかりと定義している場合には記載していなくても問題ありません。

補足:JSON応答構造を利用する場合の注意事項

カスタム Lightning 種類で項目のデータ型が Date, DateTime, Time だった場合は、フローから値にアクセスしても取得できない問題があります。(2026/3/6 確認時点)

現状回避策として Lightning 種類では String にしておき、フローの数式項目を使って変換します。

フローの構造

技術的には、以下の4ステップで構成されています。

STEP 1:レコードの取得

対象レコードのIDをもとに、現在の商談情報を取得します。

STEP 2:音声入力画面

ユーザーに向けて「ここに音声入力してください」というテキストエリアを表示します。フロー種類は Screen Flow(画面フロー)であるため、Lightning ページ上でそのままウィジェットとして起動できます。

STEP 3:AIによる解析

ここが核心部分です。Flow の generatePromptResponse アクションを通じて、Prompt Template(プロンプトテンプレート)を呼び出します。

入力として先ほどのテキストエリアの内容を渡すと、AIが以下の6項目を JSON 形式で返します。

• budget 予算情報
• event コンペリングイベント
• pain 顧客課題
• stage 案件ステージの進捗
• req 要求仕様・要件
• start 導入時期・タイミング

これは Salesforce の Structured Output(構造化出力)機能を活用したものです。

AIに対して「この形式のJSONで回答せよ」と指定することで、後続の処理でそのまま各フィールドに書き込めるようになります。

STEP 4:レコードの更新

STEP 3 で得たJSONの各値を、対応するレコードの項目にそれぞれ書き込んで完了です。

補足:

「本MTGでは更新候補無し」の場合には更新しない制御を入れる場合には、このように決定要素による条件分岐を入れることによって実現可能です。

なぜ Structured Output(構造化出力) が重要なのか

従来のAI活用では、AIの回答はテキストとして返ってくるため、「その中から必要な情報を抜き出す」という後処理が必要でした。正規表現や文字列解析を駆使しても、AIの回答のゆらぎに対応しきれないケースがありました。

Structured Output を使うと、AIは最初から指定した構造のJSONで回答します。フローから見れば structuredResponse.budget のように、オブジェクトのプロパティとして値を参照できるため、追加の解析処理が不要になります。

この仕組みにより、「AIの出力をそのままSalesforceの項目に書き込む」という処理が、コードを一行も書かずにノーコードで実現できます。

現場への展開イメージ

このデモ実装ではテスト用カスタムオブジェクトを対象としていますが、実運用では Opportunity(商談)や Event(行動)オブジェクトへの応用が考えられます。

たとえば:

• 商談終了後:担当者が車の中で商談メモを音声入力 → Opportunity の StageName、予算、顧客課題などが自動更新
• 訪問報告:活動内容をフリーテキストで記録 → 「競合情報」「顧客要望」「次のアクション」が自動でカテゴリ分けされて記録
• マネージャーレビュー: AI が整理した項目をもとに状況をレポートで一目で確認、週次レビューの準備時間を削減

まとめ

Salesforce Flow の generatePromptResponse アクションと Prompt Template の Structured Output を組み合わせることで、「自由なテキスト入力 → 構造化されたCRMデータ」という変換が、驚くほどシンプルな構成で実現できます。

• ノーコード:Apexを書かずにFlowとテンプレートだけで構築可能
• 構造化出力:AIの回答を最初からJSONで受け取るためパース処理不要
• 現場への展開:Lightningページにボタン一つで組み込めるScreen Flow形式

「営業がCRMを入力しない問題」は、ツールの問題ではなく入力コストの問題です。入力コストをAIで限りなくゼロに近づけることが、データ品質と現場定着の鍵になります。

※ 本記事は Salesforce の実装例をもとに作成しています。ご紹介した機能はお客様の環境に応じて Agentforce 関連のライセンスや設定が必要な場合があります。

The post 話しかけるだけで商談情報を自動更新 Salesforce Flow × Structured Output（構造化出力） の実装例 appeared first on Salesforce Developers Blog.

Why use complex expressions?

Until now, LWC templates only supported simple property binding. If you wanted to combine a first and last name, you had to create a getter in your JavaScript class. While this keeps logic separate, it often leads to “boilerplate” code — extra lines of code that don’t do much but pass data around.

With complex template expressions, you have the power to handle simple UI logic where it belongs: in the template. This makes your components easier to read and faster to build.

Getting started with the syntax

To use this feature, your component must use API version 66.0 or higher in its js-meta.xml file. Once enabled, you can start using a subset of JavaScript directly in your HTML. See this guide on component API versioning for more information.

Logical and arithmetic operators

You can now perform math or logical checks right in the tag. For example, if you want to show a special badge only when an item count is high, you can do it like this:

 
<template> 
<template><div key="{item.id}"> 
<span class="”{index" 0="" first-item="" :="" item="">{index + 1}. {item.label}</span> 
</div><p> 
</p></template> 
</template>

Using expressions in attributes

One of the most powerful ways to use this feature is inside HTML attributes. You can dynamically change classes or titles without needing extra variables in your JavaScript file.

However, there is one very important rule to consider: complex template expressions in attributes must be surrounded by double quotes. If you forget the quotes, the LWC compiler will throw an error. By using quotes, you ensure that the template stays compliant with standard HTML rules.

 
<template><div class="{isActive ? 'brand-border' : 'neutral-border'}"> User Profile </div><p>
<button title="{item.name + ' - ' + item.status}"> View Details </button> 
</p></template> 

Staying HTML compliant

Because LWC templates are still HTML files, some JavaScript characters can confuse the browser. For example, the less than symbol ( < ) looks like the start of a new HTML tag if used in plain text. To stay safe, follow these tips:

• Use Greater Than: Instead of {age < 18}, use {18 > age}.
• Stick to Double Quotes: Always wrap attribute expressions in "{...}".

LWC complex template expression limitations and restrictions

To keep your components fast, we’ve limited what you can do in a template. You cannot use the new keyword, you cannot create full function declarations, and you cannot use assignment operators like = or ++. Think of template expressions as read-only logic meant for displaying data.

For a full set of valid and invalid expressions, see these examples.

Conclusion

Complex template expressions are a huge win for developer productivity. By reducing the need for additional getters and functions in your JavaScript files, we’re making LWC feel more modern and intuitive. Remember, this is currently an experimental feature. We encourage you to try it out in your Spring ’26 sandbox environments and share your feedback with us!

Resources

• Learn more about how to work with complex template expressions in the LWC Developer Guide.
• Review the Spring ’26 Release Notes for full details on API version 66.0.
• Practice your skills by completing the Build Lightning Web Components project on Trailhead.
• Brush-up on component API versioning

About the Author

John Hefferman is a Software Engineer at Salesforce. John enjoys helping developers build faster and more efficiently on the Salesforce Platform.

The post Simplify Your LWC Development with Complex Template Expressions appeared first on Salesforce Developers Blog.