If you followed along with my previous post, Agentforce Voice for Agent Script: Voice-Enabling Best Practices, you added the voice blocks to a script and tuned its instructions for the ear. This post picks up where that one stopped. It’s for developers who have a voice-ready Agent Script agent and want it to answer real calls. You’ll need an org with the full Agentforce Voice setup, which a free Developer Edition org doesn’t include. 

In this post, you’ll look at what your org needs first and how a call reaches your agent. Then you’ll set up the number and routing, and check a call after you hang up.

What does my org need before a call can reach the agent?

You’ll need everything from the previous post: an org with Agentforce Voice turned on, and an Agent Script agent with the language, connection telephony, and modality voice blocks. Phone calls add two more needs: a phone number and an agent user.

You’ll do most of the setup with the Salesforce CLI, from the Salesforce DX project that holds your agent. If you don’t have one yet, create a project in VS Code with the Salesforce Extensions. Then, in the project’s terminal, log in and make the org your default. Replace <your-domain> with your org’s My Domain:

sf org login web --alias voice-org --set-default --instance-url https://<your-domain>.my.salesforce.com

The commands in this post then leave out --target-org. The checks are SOQL (Salesforce Object Query Language) queries, which you run with sf data query.

A way to get a phone number

Check for this before you start, not halfway through setup. Some orgs have an entitlement that includes a number and inbound voice credits. Query for those two:

sf data query -q "SELECT MasterLabel, AmountUsed, CurrentAmountAllowed FROM TenantUsageEntitlement WHERE Setting IN ('setting/force.com/orgValue.CountOfTenDLCNumbers', 'setting/force.com/orgValue.InboundVoiceCredits')"

You want two rows, “Count of Ten-Digit Long Code Numbers” and “Inbound Voice Credits”, each with a CurrentAmountAllowed above AmountUsed. A blank or a null AmountUsed means none are used yet. If the query returns no rows, talk to your Salesforce account team about adding numbers before you go on.

An agent user

A phone agent must be an Agentforce Service Agent. It runs as its own agent user, not as whoever is logged in, because a caller isn’t logged in to anything. That user has the Einstein Agent User profile, and each one takes an Einstein Agent User license. Make sure you have one available with the following command. UsedLicenses should be lower than TotalLicenses:

sf data query -q "SELECT UserLicense.Name, UserLicense.TotalLicenses, UserLicense.UsedLicenses FROM Profile WHERE Name = 'Einstein Agent User'"

Then create the user with the following command. It prints the new user’s username:

sf org create agent-user

Licenses are limited, so reuse an agent user across rebuilds instead of making a new one each time.

In your Agent Script, set the agent type to AgentforceServiceAgent, and put the new user’s username in access.default_agent_user. It’s the user’s Salesforce username, which looks like an email address but often isn’t one you can email.

config:
   developer_name: "VoiceAgent"
   agent_label: "Voice Agent"
   agent_type: "AgentforceServiceAgent"

access:
   default_agent_user: "agent.user.xxxxx@example.com"

How does a phone call reach an Agent Script agent?

Three pieces of setup sit between a caller and your script. A call reaches a phone number. A voice channel ties that number to an Omni-Channel flow. The flow routes the call to your agent.

Each piece has one job. The number is the address callers dial. The flow decides who answers. Today, that’s always your agent, but a flow is also where you’d add business hours or more routing rules later. The channel connects the number to the flow, and it’s the switch that turns calls on and off.

Salesforce creates a VoiceCall record for every call. That record travels through the whole chain: the flow receives its ID, and so does your agent. It’s also how you’ll check the call afterwards.

How do I set up the phone number and Omni-Channel routing flow?

The number and the channel live under Agentforce Voice Setup → Voice Channels with Agents, and the flow lives in Flow Builder. Do these in order, because each step needs the one before it.

1. Activate your agent. The routing flow can only point at an active agent. If yours isn’t active, it won’t show up when you pick where calls go. You can do this from Agentforce Builder → Select your Agent → Commit → Activate.
2. Request a number. Click New Number. A wizard opens in a new window. Pick a country, a number type, and a number. Once you’re done, the number shows as Requested, then Live. It can take a few minutes. Use Refresh Status on the Phone Number tab to check.
3. Build the routing flow. It’s a small Omni-Channel flow with one element, which you’ll build in the following section.
4. Create and activate the channel. The channel, which you’ll set up in the section after that, ties the number to the flow.

Build the routing flow

You will need an Omni-Channel flow. A few details decide whether calls reach your agent:

• Name the input variable exactly recordId. Salesforce passes the VoiceCall ID into the flow through that name. Make it a Text variable that’s available for input, or the flow never receives the call.
• Keep it to one Route Work element. You need to route a single record (the recordId variable) through a Phone service channel to the Agentforce Service Agent you previously activated.
• Set a voice queue as the fallback. It’s where a call lands if the agent can’t take it, so it must be a queue that supports the VoiceCall object. List your voice queues with the following command:

sf data query -q "SELECT Queue.Name, QueueId FROM QueueSobject WHERE SobjectType = 'VoiceCall'"

• Activate the flow, and note its API name. You’ll use the API name to check the flow with a query.

You can also confirm the flow is active from the Salesforce CLI. Replace Voice_Agent_Routing with your flow’s API name:

sf data query -q "SELECT ApiName, IsActive FROM FlowDefinitionView WHERE ApiName = 'Voice_Agent_Routing'"

Create and activate the channel

The channel ties your number to your flow. Getting a number doesn’t create one, so back in Agentforce Voice Setup → Voice Channels with Agents, create a New Channel where you select the Phone Number you previously created and the Omni-Channel flow you just created.

This creates a PSTN Voice channel. PSTN stands for public switched telephone network: the regular phone network.

A new channel is created inactive, and calls won’t reach your agent until you activate it. The channel list doesn’t have a toggle. The Activate button is on the channel’s own page. If your first test call goes nowhere, check this first.

Once it’s active, the channel shows a checkmark in the Active column of the Voice Channels with Agents list:

To check the channel from the Salesforce CLI instead, run the following command. IsActive should be true:

sf data query -q "SELECT DeveloperName, IsActive FROM MessagingChannel WHERE MessageType = 'PstnVoice'"

How do I check a call after I hang up?

To check a call, query its VoiceCall and AgentWork records. A live call doesn’t save a transcript, so these records are how you confirm what happened. First, call the phone number you set up in Agentforce Voice Setup. You should reach your agent.

Don’t worry if the first ring takes a while. Some of that time is spent before the call reaches Salesforce. In testing, Salesforce accepted the call around five seconds after it arrived.

After you hang up, start with the call itself:

sf data query -q "SELECT Id, FromPhoneNumber, CallAcceptDateTime, CallEndDateTime, CallDurationInSeconds, VendorType FROM VoiceCall ORDER BY CreatedDate DESC LIMIT 1"

Check that VendorType is VirtualVoiceAgent, and that FromPhoneNumber is the phone you called from. Then check the routing with the call’s ID:

sf data query -q "SELECT Status, ServiceChannel.DeveloperName, AcceptDateTime FROM AgentWork WHERE WorkItemId = '<VoiceCall Id>'"

The work item should be on sfdc_phone, the developer name of the built-in Phone service channel.

Conclusion

Answering real phone calls doesn’t mean rewriting your Agent Script agent. The work is setup: an agent user, a number, a one-element Omni-Channel flow, and a PSTN Voice channel. Check each call through its VoiceCall and AgentWork records, because a live call doesn’t save a transcript.

With those pieces in place, the agent you voice-enabled in my previous post answers when someone calls. The VoiceCall record also holds the caller’s number, which your agent’s actions can use. That’s a topic for a later post.

Have questions? Ask on the Trailblazer Community or reach out to @SalesforceDevs.

Resources

• Agentforce Voice for Agent Script: Voice-Enabling Best Practices
• Agentforce Voice
• Agent Script (Agentforce Developer Guide)
• Create a Salesforce DX Project in VS Code
• Salesforce CLI Command Reference
• Omni-Channel Flows (Salesforce Help)
• Agent Platform Tracing: Debug Agentforce with Trace Trees, SOQL, and Slack
• Agent Script Recipes (GitHub)

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.

The post Agentforce Voice for Agent Script: Route Real Phone Calls to Your Agent appeared first on Salesforce Developers Blog.

Two enhancements remove the need for those workarounds. The Keep Manual Shares when Transferring Records setting is available now. Custom row causes, also called Apex sharing reasons, are rolling out for standard objects in the Metadata API and will reach all orgs by the end of October. In this post, we’ll look at Keep Manual Shares on Record Transfer and Custom Row Causes for Standard Objects.

Keep manual shares on record transfer

Availability: Available now.

In Sharing Settings, turn on Keep Manual Shares when Transferring Records. Manual shares then survive ownership changes, and you can remove any workarounds you built for this.

Custom row causes for standard objects

Availability: Rolling out now; all orgs will have it by the end of October.

Apex managed sharing requires an Apex sharing reason. Salesforce stores it in the RowCause field of each share record; we call it a custom row cause in this post. You can now define one on a standard object the same way you do on a custom object. For details, see Sharing a Record Using Apex.

The following example defines an On-Call Expert sharing reason on Case, using the Metadata API:

<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
    <sharingReasons>
        <fullName>On_Call_Expert__c</fullName>
        <label>On-Call Expert</label>
    </sharingReasons>
</CustomObject>

Deploy it with a package.xml that lists Case.On_Call_Expert__c as a SharingReason member.

Then you can use it in Apex:

CaseShare share = new CaseShare();
share.CaseId = caseId;
share.UserOrGroupId = userId;
share.CaseAccessLevel = 'Edit';
share.RowCause = Schema.CaseShare.RowCause.On_Call_Expert__c;
insert share;

You can also assign a custom row cause in Flow.

A custom row cause keeps your Apex shares separate from users’ manual shares, and Salesforce doesn’t delete them when the owner changes. In the share table, admins can see why each user has access. Because each reason is separate, you can update or delete the shares for one reason without touching the others. Unlike the Keep Manual Shares setting, a custom row cause doesn’t change how users’ manual shares behave. In November, you’ll be able to manage custom row causes in AIforce and Setup with Agentforce.

Conclusion

Winter ’27 gives you two ways to keep shares when a record’s owner changes.

• If you don’t create shares in code, turn on Keep Manual Shares when Transferring Records. It’s one org-wide setting.
• If code, a Flow, or an integration creates shares on standard objects, switch to a custom row cause. Your shares survive owner changes, stay separate from users’ manual shares, and show why each user has access.

You may need only one of them. Start by reviewing the code that creates CaseShare, AccountShare, or other standard share records.

Resources

• Understanding Apex Managed Sharing
• Protecting Force.com Custom Sharing Code (2013)
• Salesforce Data Security Model — Explained Visually (2017)
• IdeaExchange: Allow Custom RowCause values for Standard Objects

About the author

Larry Tung is the Product Manager for the Sharing team, where he’s working on the next generation of user access features and protecting sensitive data. When Larry isn’t working, he enjoys playing sports and board games with his kids and reading.

Peder Rice is a software engineer on the Sharing team, where he works on record access at scale. He enjoys traveling with his kids in search of hidden corners the guidebooks miss.

The post Protect Apex Shares: Custom Row Causes on Standard Objects appeared first on Salesforce Developers Blog.

Claude Code now supports mods: small plugins that run inside Claude Code and can draw directly in its interface. In this post, you’ll build sf-headless-band, a mod that shows your Salesforce default org above the prompt, including its type and, for a scratch org, how many days it has left. It also adds a line for each Salesforce MCP server, with the org it reaches. Production always appears in red, so you can’t miss it.

The full source for this mod is on GitHub. Clone it to follow along, or create the files as you go.

What is a Claude Code mod?

A mod is a Claude Code plugin that can use JavaScript or TypeScript event handlers, called hooks. Claude Code calls a hook when something happens: a session starts, a turn completes, a tool is about to run, or a part of the interface is about to be drawn. A hook can watch the event, change it, or take it over.

That’s what makes mods different from settings hooks, skills, and MCP servers, which work from outside Claude Code. A mod runs inside it, so it can draw its own interface: a pane, a toast, a status line, or a band above the prompt, where your org information belongs.

The Claude Code docs cover the rest in depth: start with the Mods Overview, then Create a Mod and Draw in the Interface.

What you’ll build

The sf-headless-band mod:

• Finds your default org the way the Salesforce CLI does: by checking an environment variable (SF_TARGET_ORG) first, then the project’s config, and finally the global config
• Shows the org’s alias and My Domain, its type on a colored pill (scratch, sandbox, Developer Edition, or production), and, for a scratch org, the days until it expires
• Adds a line for each Salesforce MCP server: for the Salesforce DX MCP Server, the orgs its --orgs flag allows; for a Hosted MCP Server, the org its calls reach
• Shows or hides the band with /sf-headless-band and remembers your choice
• Refreshes when you change folders, after each Claude turn, and within three seconds of a config change, so sf config set target-org in another terminal shows up on its own

When you’re done, the plugin folder looks like this:

sf-headless-band/
├── .claude-plugin/
│   └── plugin.json      # the plugin manifest
├── hooks/
│   ├── hooks.json       # points to your code
│   ├── salesforce.ts    # reads the Salesforce CLI's files
│   ├── org.ts           # finds the default org
│   ├── mcp.ts           # finds the Salesforce MCP servers
│   └── register.tsx     # draws the band
├── tests/
│   ├── org.test.ts
│   ├── mcp.test.ts
│   └── band.test.ts
└── types/
    └── index.d.ts       # declares the mod's state

Prerequisites

• Claude Code v2.1.287 or later, in the terminal or the Code tab of the Claude Desktop app
• The Salesforce CLI with at least one authorized org, or a Salesforce MCP server added to Claude Code
• A Salesforce DX project to try it in

Step 1: Create the plugin

A mod is a plugin with a manifest, a hooks.json that points to your code, and the code itself. Create the folders:

mkdir -p sf-headless-band/.claude-plugin sf-headless-band/hooks sf-headless-band/types

Save the manifest as sf-headless-band/.claude-plugin/plugin.json. The types field points to the file where you’ll declare the mod’s state in the next step:

{
  "name": "sf-headless-band",
  "version": "0.1.0",
  "description": "Shows the Salesforce default org, its type, and scratch org expiry above the prompt",
  "author": { "name": "Your Name" },
  "types": "./types/index.d.ts"
}

Name your entry point in sf-headless-band/hooks/hooks.json. Claude Code loads TypeScript and JSX directly, so there’s no build step:

{ 
  "modules": ["./register.tsx"] 
}

Step 2: Declare the mod’s state

The mod keeps what it finds in Claude Code’s reactive state, $.state. When a value changes, the band redraws on its own, and the values survive the mod reloading.

Declare them in sf-headless-band/types/index.d.ts, under your plugin’s name. Here’s the org’s part; the MCP servers’ types are in the full file on GitHub:

export type OrgType = 'production' | 'developer' | 'sandbox' | 'scratch' | 'unknown'

export type OrgInfo = {
  /** The alias when the target org is one, else the username. */
  name: string
  username: string
  type: OrgType
  /** Its My Domain host, from the CLI's auth file. */
  host?: string
  /** Days until a scratch org expires; undefined for any other type. */
  daysLeft?: number
}

declare module 'claude-code' {
  interface PluginState {
    'sf-headless-band': {
      org: OrgInfo | null
      mcp: McpOrg[]   // the Salesforce Hosted MCP Servers
      dx: DxMcp[]     // the Salesforce DX MCP Servers
      domains: Record<string, { host: string; type: OrgType }>
      hidden: boolean // kept in $.store across sessions
    }
  }
}

Step 3: Find the default org

You could run sf org display and parse the output, but it takes a second or two each time: far too slow for something that redraws above your prompt.

Instead, the mod reads the same small files the Salesforce CLI reads:

Outside a Salesforce DX project, the global default still applies, as it does for the CLI. Some older auth files don’t have the isScratch and isSandbox flags, so the mod falls back to the instance URL: .scratch. and .sandbox. in the My Domain give the type away, and so does a Developer Edition’s -dev-ed.

Here’s the heart of that logic. It returns the same type you declared in Step 2, under the name SfOrgType, and DEVELOPER_URL matches a Developer Edition’s My Domain. As a catch-all, an org that matches nothing counts as production, so if the mod guesses wrong, it errs on the side of caution.

export const authType = (auth: any): SfOrgType => {
  if (auth === undefined) return 'unknown'
  const url: string = auth.instanceUrl ?? ''
  if (auth.isScratch === true || url.includes('.scratch.')) return 'scratch'
  if (auth.isSandbox === true || url.includes('.sandbox.')) return 'sandbox'
  if (DEVELOPER_URL.test(url)) return 'developer'
  return 'production'
}

Copy hooks/salesforce.ts, hooks/org.ts, and hooks/mcp.ts from GitHub. They take a file-reading function as an argument instead of calling the mods API, so tests can pass in fake file contents rather than reading real Salesforce CLI files.

Note: The files the mod reads are Salesforce CLI internals, not a public API, so a future CLI release could change them. The auth files also hold access tokens. The mod reads only the type, My Domain, and expiry fields and never displays or sends anything else, but it’s a good reminder that a mod runs with your permissions. Install mods only from people you trust, and run claude plugin validate on any mod before you install it.

Step 4: Draw the band

Now for the hooks. Copy hooks/register.tsx from GitHub. In the order they appear in the code:

• session.start finds the orgs and servers, watches the CLI’s config files every three seconds, and registers /sf-headless-band
• tool.call watches each MCP call: a hosted server doesn’t say which org it reaches, so the mod finds the org’s My Domain in the call’s request or result, and remembers it
• command.run shows or hides the band
• classic.SessionStart finds them again after /clear, /resume, and /branch, which reset $.state
• classic.CwdChanged finds them again when you change folders
• turn.complete finds them again after each Claude turn, in case Claude ran sf config set for you
• ui.render draws the band

Here’s the ui.render hook. To keep it short, it shows only the CLI line and leaves out the MCP server lines:

on('ui.render', { component: 'AbovePrompt' }, async ($, e, next) => {
  const info = await read($, org)
  if (e.props.hasSurvey || (await read($, hidden)) || info === null) {
    return next(e)
  }

  const { Box, Text } = $.ui.resolve(e)

  // The org type on a solid pill: red production, yellow sandbox, green scratch
  const pill = (type: OrgType) => (
    <Text backgroundColor={ORG_TYPE_COLOR[type]} color="inverseText">{` ${ORG_TYPE_LABEL[type]} `}</Text>
  )

  // sf › cli › alias › my-domain › [ type ]
  const line = (
    <Box flexDirection="row">
      <Text dimColor>sf › cli › </Text>
      <Text bold>{info.name}</Text>
      {info.host ? <Text dimColor> › {domainName(info.host)}</Text> : null}
      {/* › expires in N days, for scratch orgs */}
      <Text dimColor> › </Text>
      {pill(info.type)}
    </Box>
  )

  // The band is shared: keep what the mods after this one draw there
  const theirs = await next(e)
  return theirs ? (
    <Box flexDirection="column">
      {line}
      {theirs}
    </Box>
  ) : (
    line
  )
})

A few details in this code are worth copying into your own mods:

The hook picks its render site with a matcher. Claude Code fires ui.render for every part of the interface it draws. The { component: 'AbovePrompt' } filter narrows the hook to the band above the prompt. When there’s no org to show, or the band is hidden, the hook returns next(e) and draws nothing.
The band is shared. Every mod draws in the same band, so a mod that returns only its own tree hides everyone else’s. Putting the result of await next(e) under your line keeps theirs.
The colors are theme keys. success, warning, error, and inactive follow the light or dark theme, so the band looks right in both.
It doesn’t guess a hosted server’s org. A hosted server’s line has no org type until a call has shown its org, and tool.call runs the call with await next(e) before it looks.

Step 5: Try it

Check the mod first. claude plugin validate lists every event the mod handles and every call it makes, without running it:

claude plugin validate ~/path/to/sf-headless-band

Then open a Salesforce DX project, start Claude Code with the plugin folder, and turn the band on:

cd ~/projects/my-sfdx-project
claude --plugin-dir ~/path/to/sf-headless-band

Type /sf-headless-band on. The band appears above the prompt, with your default org, its My Domain, its type, and, for a scratch org, the days until it expires:

Now try each case:

Switch orgs. Run sf config set target-org <another-alias>. Within three seconds, the band shows the new org. A sandbox gets a yellow pill:

Point at production. Set the target org to a production org. Its pill is red:

Ask Claude for data through a Hosted MCP Server. After the first call, its line shows the org it reached.

The repo also has tests for the org lookup, the MCP servers, and the band. They run against a mock Claude Code, so you don’t need a real org. Run claude plugin test from the plugin folder. Test a Mod explains how they work.

Step 6: Load it in every session

--plugin-dir loads the mod for one session. To load it in every session, add the folder to CLAUDE_CODE_PLUGIN_DIRS in the env block of ~/.claude/settings.json. To share it with your team, add it to a plugin marketplace, and everyone can install it with /plugin install.

Tip: You don’t have to write every change by hand. Start Claude Code with the plugin folder and ask for a change, such as a different color for Developer Edition orgs. Claude Code’s built-in plugin-authoring skill knows how mods work, and the mod reloads after each turn that changes it.

Conclusion

You built a mod that keeps your Salesforce context in view: which org you’re on, what kind it is, how long a scratch org has left, and which orgs your MCP servers reach. Along the way, you saw the core ideas behind every mod: hooks that respond to events, one that wraps a tool call, and a band drawn with ui.render.

The band is only a starting point. You could build a mod that asks before Claude runs sf project deploy start against production, shows a pane listing your scratch orgs and their expiry, or adds a / command that opens your default org in a browser.

Resources

• Video: Salesforce Mods Overview 
• GitHub: sf-headless-band
• Documentation: Mods Overview
• Documentation: Draw in the Interface
• Documentation: Salesforce CLI Setup Guide
• Documentation: Salesforce DX Developer Guide

About the author

Dave Norris is a Developer Advocate at Salesforce. He’s passionate about making technical subjects broadly accessible to a diverse audience. Dave has been with Salesforce for over a decade, has over 40 Salesforce and MuleSoft certifications, and became a Salesforce Certified Technical Architect in 2013.

The post Building a Claude Code Mod for Salesforce appeared first on Salesforce Developers Blog.

We introduced Salesforce Multi-Framework in open beta with React support, then made React apps production-ready in our first generally available (GA) release. With the Winter ’27 release, we’re expanding the ways that developers, admins, and partners can build and deliver Multi-Framework experiences with support for new frameworks, new distribution channels, and new capabilities. 

What’s new in Salesforce Multi-Framework

Here are the highlights for Winter ’27:

• Angular is GA: Build, vibe code, preview, deploy, and run production Angular apps natively on Salesforce. Angular joins React as the second generally available UI framework for Multi-Framework.
• Microfrontend is GA: Embed React and Angular experiences in Lightning Experience, Experience Cloud, the Salesforce mobile app, and Mobile Publisher apps.
• Managed packages: Package, distribute, install, and upgrade non-site (internal, employee-facing) Multi-Framework apps as managed packages.
• Localization and internationalization support: Create experiences for users across languages and regions with locale-aware formatting and localized labels.
• Multi-factor authentication (MFA) support: Build more secure applications that work with Salesforce MFA requirements.
• Multi-Framework Insights is Beta: Review industry-standard performance and key usage insights for Multi-Framework apps.

Together, these Winter ’27 updates make Multi-Framework a more complete platform for building, embedding, distributing, and operating modern Salesforce experiences. Teams can choose React or Angular, surface apps across Salesforce with Microfrontend, distribute non-site apps through managed packages, meet enterprise requirements with localization and MFA, and monitor performance and usage with Multi-Framework Insights (Beta).

Let’s look at each capability in more detail.

Build native Angular apps on Salesforce

Angular joins React as a generally available framework for Salesforce Multi-Framework. Developers can bring their Angular skills, libraries, component systems, and existing development workflows to Salesforce while building on trusted platform services.

Multi-Framework provides three Angular templates:

• angularinternalapp for employee-facing apps opened from the Salesforce App Launcher
• angularexternalapp for customer- and partner-facing apps delivered through Experience Cloud
• angularbasic for a minimal starting point

The internal and external templates include the metadata and platform integration needed for their target audiences. 

Developers can get started from the Agentforce Vibes welcome page or generate a project from the command line. To scaffold an employee-facing Angular app with the Salesforce CLI, run:

sf template generate project --name account-pulse --template angularinternalapp

The generated project uses familiar Angular tooling. Develop and test locally with the Angular CLI, build with your existing npm workflow, and deploy with the same Salesforce DX commands that you use for the rest of your project.

When deployed, the app becomes a UIBundle metadata type. Internal apps run on the dedicated salesforce.app domain, where browser-native origin boundaries isolate each app from the Lightning runtime and other apps. Users still get seamless Salesforce sign-on, while the platform continues to enforce object-level security, field-level security, sharing rules, and validation rules on supported data requests and saves.

The framework-agnostic Data SDK provides Angular apps with the same GraphQL operations and platform capabilities as React apps. Choosing Angular doesn’t change the app’s Salesforce security model or require a separate authentication layer.

New Angular samples in the Multi-Framework Recipes repository demonstrate common platform integration patterns.

Embed apps across Salesforce with Microfrontend

Microfrontend is now generally available. You can embed externally hosted apps built with any frameworks across:

• Lightning Experience
• Experience Cloud
• Salesforce mobile app
• Mobile Publisher

You don’t have to rebuild an existing app in Lightning Web Components (LWC) to surface it within a Salesforce experience. The lightning-ui-embedding base component hosts the app in a secure, sandboxed iframe and provides a two-way communication channel between the embedded app and its surrounding Salesforce page.

This channel makes the embedded experience feel like part of the host page. An LWC can pass properties to the app, and the app can send events back to the LWC. Teams can combine a rich React or Angular workflow with native Salesforce components while maintaining a clear security boundary between them.

For example, an LWC can pass a selected industry into an embedded Angular account dashboard. When a user selects an account in the Angular app, the app can send the record ID back to the LWC, which then renders the account with native Salesforce components.

Pass data from the host page to the embedded app

Set the props attribute on lightning-ui-embedding. When a host value changes, Salesforce sends the updated properties to the app.

<template>
    <lightning-radio-group
        label="Filter the embedded app"
        type="button"
        options={industryOptions}
        value={industry}
        onchange={handleIndustryChange}>
    </lightning-radio-group>

    <lightning-ui-embedding
        lwc:ref="embedding"
        src={appUrl}
        props={embedProps}
        width="100%"
        height="560">
    </lightning-ui-embedding>
</template>

Inside the React or Angular app, use the View SDK to read the initial state and subscribe to changes.

import { getViewSDK } from '@salesforce/platform-sdk';

const view = await getViewSDK();
const ui = view?.getUiState?.();

if (ui) {
    applyFilters(ui.state.props);
    ui.subscribe((next) => applyFilters(next.props));
}

Send events from the embedded app to the host page

The same channel works in the other direction. Dispatch a CustomEvent through the View SDK, and Salesforce forwards it to the host component.

view?.dispatchEvent?.(
    new CustomEvent('accountpulse.accountselected', {
        detail: {
            recordId: account.id,
            name: account.name
        }
    })
);

The host LWC can use the event details to update native components, navigate to a record, or coordinate with other elements on the page.

With Microfrontend, teams can continue using LWC where deep platform composition is the priority, use React or Angular for self-contained application experiences, and connect them when a page needs both.

Distribute apps with managed packages

Partners can now package, distribute, install, and upgrade non-site Multi-Framework apps with managed packages.

A package can include the Multi-Framework app and the supporting Salesforce metadata that makes up the complete solution, such as its UIBundle, Custom Application metadata, permission sets, Apex, custom objects, and other dependencies.

This support is important because a Multi-Framework app is rarely just frontend code. It often depends on a schema, permissions, server-side logic, and configuration. Partners can version and distribute the complete application as one installable, upgradeable unit instead of coordinating separate deployment paths for the UI and its Salesforce dependencies.

Managed packages provide the namespace and lifecycle controls that ISVs need to distribute protected solutions. Customers can install and upgrade the application through the standard package lifecycle, and partners can make their Multi-Framework solutions available through AgentExchange.

In Winter ’27, managed packaging support applies to non-site apps. Site-based Multi-Framework apps aren’t supported in managed packages.

Localize apps for users across languages and regions

Multi-Framework apps can now use Salesforce internationalization context instead of maintaining separate regional preferences in the frontend.

The @salesforce/platform-sdk/i18n module retrieves the running user’s context and creates locale-aware formatters for dates, times, numbers, percentages, and currencies. Here’s an example that formats revenue using the user’s Salesforce locale and currency:

import { createDataSDK } from '@salesforce/platform-sdk';
import {
    createI18nFormatters,
    fetchI18nContext
} from '@salesforce/platform-sdk/i18n';

const sdk = await createDataSDK();
const context = await fetchI18nContext(sdk);
const format = createI18nFormatters(context);

const annualRevenue = format.formatCurrency(5080000, {
    maximumFractionDigits: 0
});

The Data SDK also includes a labels extension for retrieving custom labels by namespace and locale. This keeps translatable UI copy separate from application code and lets packaged apps resolve the correct namespaced labels at runtime.

Localization is more than translating strings. A currency value, date, time, or decimal can be interpreted differently across locales even when the underlying data is the same. By using the context already maintained by Salesforce, an app can present that information consistently with the rest of the platform.

Support enterprise authentication with MFA

Multi-Framework apps now support Salesforce multi-factor authentication, helping organizations apply their enterprise authentication requirements consistently to modern frontend experiences.

Developers don’t need to build a separate MFA flow into the application. Authentication remains managed by Salesforce, and the Multi-Framework app participates in the organization’s existing identity and access policies.

Combined with the salesforce.app security boundary and server-side enforcement of object-level security, field-level security, and sharing rules, MFA support makes Multi-Framework apps ready for a broader range of enterprise use cases.

Understand app performance and usage with Multi-Framework Insights (Beta)

Multi-Framework Insights gives teams industry-standard performance metrics and key usage insights for Multi-Framework apps.

From Setup, click Multi-Framework Insights (Beta) in Scale Center and generate an insights report. The dashboard surfaces performance and usage metrics and trends so teams can identify optimization opportunities for their most-viewed apps.

Multi-Framework Insights closes an important operational gap: developers can go beyond successfully deploying an app and begin understanding how it performs for real users. Because this feature is Beta, review its current availability and limitations before relying on it for production monitoring workflows.

Choose how you want to build Multi-Framework apps

Multi-Framework supports developers, admins, and business users with three different ways to create modern Salesforce experiences.

These options provide different entry points into the same broader platform: code-first development with Agentforce Vibes, prompt-first app creation with Builder Central, and description-based page generation with Quick Pages.

Agentforce Vibes: GA, now with Angular support

Agentforce Vibes is the Salesforce vibe coding environment for developers, available through a VS Code extension and web IDE. It helps teams plan, write, test, preview, and deploy apps and agents.

Agentforce Vibes now supports Angular in addition to React. Developers can start an Angular Multi-Framework app directly from the welcome page, describe what they want to build, preview the result, and deploy it to Salesforce.

Winter ’27 also improves agent-assisted development workflows. Expanded evaluations validate more generated React and Angular code, while new branding and Salesforce CMS skills help coding agents find brand guidance and search, update, and publish managed content.

Because a Multi-Framework app remains a standard Salesforce DX project with an npm-based build, teams can also use tools such as Claude Code and other AI coding assistants as part of their workflow.

Builder Central: Beta

Builder Central is the Salesforce natural-language-based app builder. Start with an idea, then create and refine the application through conversation before deploying it in your org.

Builder Central gives admins a guided way to build Multi-Framework experiences without beginning in a traditional code editor. It generates the application and its Salesforce configuration while letting you iterate with natural-language prompts.

Quick Pages: Beta

Quick Pages enables business users to describe the page they need in plain language and create an interactive page with multiple tabs, dynamic charts, and data tables, built on live Salesforce data. There is no application project to start and no changes to Salesforce metadata. 

Quick Pages runs inside Salesforce and builds Multi-Framework apps, and every page respects the field- and object-level security of the person viewing it, so people see only the data they already have access to. Admins decide who can create and view pages, and everything stays inside your org’s security boundary.

What’s next

We want to keep making the Salesforce Platform easier to build on and more flexible, so teams can choose the frameworks and tools that work best for them.

Next, we’re working on Vue as the next supported UI framework, new agentic experiences enabled by Multi-Framework, and support for Government Cloud. We’ll share more as these capabilities become available.

We’re excited to see what you build. Try the new capabilities, explore the recipes, and share your feedback with the Salesforce Developers community.

Resources

• Salesforce Multi-Framework documentation
• Winter ’27 Release Note
• Multi-Framework React recipes
• Multi-Framework Angular recipes
• Multi-Framework Microfrontend recipes
• The Salesforce Developer’s Guide to the Winter ’27 Release

About the Authors

Alice Oh is a Director of Product at Salesforce building foundational products that enable flexible and extensible ways to create, vibe code, and surface apps across the Salesforce ecosystem. In her free time, she bikes around the Bay Area in search of the flakiest croissants. Follow and connect with her on LinkedIn.

Charles Watkins is a self-taught software developer and Lead Developer Advocate at Salesforce. He spends his time blogging, crafting code samples, and finding new places to hike in the Pacific Northwest. You can follow him on LinkedIn.

The post What’s New in Salesforce Multi-Framework: Angular Is Now GA appeared first on Salesforce Developers Blog.

As of the September 2026 release of B2C Commerce (release 26.9), you don’t need a third-party bot-management entitlement to fight back. eCDN, the Cloudflare-based CDN built into B2C Commerce, sits in front of every storefront request. This release adds four new detection fields you can write firewall and rate-limiting rules against, plus a managed-transform header you can read at your origin to warn the shopper directly.

This post covers: 

• The detection fields eCDN now exposes 
• The firewall-rule and rate-limiting-rule syntax to act on them
• A working example in SFRA (B2C Commerce’s Storefront Reference Architecture) that turns the edge signal into a shopper-facing “reset your password” prompt 
• How to monitor what the detection is catching

Prerequisites

Salesforce must enable the Leaked-Credential-Check managed transform on your zone or zones. This is a Cloudflare-side toggle, so no redeploy is required on your part. Custom rules and rate limit rules can be created at any time with the detection fields below. Contact Salesforce (through a support case) to enable the managed transform for your zone.

The detection fields

Four fields are available in your eCDN firewall and rate-limiting rule expressions as of release 26.9:

1. cf.waf.credential_check.password_leaked
2. cf.waf.credential_check.username_leaked
3. cf.waf.credential_check.username_and_password_leaked
4. cf.waf.credential_check.username_password_similar

They evaluate on the SFRA storefront login endpoints (Account-Login) and the SLAS login endpoint. SLAS submits credentials via HTTP Basic auth, which the detection engine decodes, so headless and PWA Kit implementations are covered too. If you run a custom login controller, contact Salesforce; we’ll work with you to make sure that endpoint is protected too.

Challenge leaked credentials with a security rule

Managed Challenge is an action you can select when creating a Custom rule. It is an adaptive security check that Cloudflare presents when a request matches a rule. It tries to determine whether the requester is a legitimate human/browser or an automated/malicious client without always showing a traditional CAPTCHA. You can challenge login attempts that use a leaked password. From the custom-rules examples:

# Expression
(http.request.uri.path contains "/Account-Login" and cf.waf.credential_check.password_leaked)
# Action
managed_challenge
# Note: SLAS cannot solve a challenge, consider block or rate limiting.

Throttle credential stuffing with a rate-limiting rule

To throttle credential stuffing without penalizing legitimate search crawlers, split the rule expression (what to count) from the counting expression (what increments the counter). From Allow verified search crawlers and detect leaked credentials:

# Rule expression — count login POSTs, excluding verified bots
(http.request.uri.path contains "/Account-Login" and http.request.method eq "POST" and not cf.client.bot)
# Counting expression — only increment when credentials are leaked
(cf.waf.credential_check.username_and_password_leaked)

The not cf.client.bot clause in the rule expression excludes requests identified as verified search crawlers, so legitimate bots aren’t throttled alongside credential-stuffing attackers.

Warn the shopper in SFRA

A plain block is the wrong tool here: a reused breached password isn’t proof of an attacker; it’s often the legitimate shopper who needs a nudge to rotate a password. When the Exposed-Credential-Check managed transform is on, eCDN adds a header to the login request before it reaches your storefront server. The shopper’s browser never sees it. It’s a request-side header, readable only server-side, on the same request that carries the login submission.

Header value → Meaning:

• 1 → Previously leaked username and password
• 2 → Previously leaked username
• 3 → Similar combination of previously leaked username and password
• 4 → Previously leaked password

In SFRA, req.httpHeaders is a case-insensitive map of the incoming request headers, available in every controller; no new middleware is needed. Here’s what’s new in Account.js’s server.post('Login', ...), added so the warning is attached only when authentication succeeds:

var URLUtils = require('dw/web/URLUtils'); // add to the existing require block

   // Exposed-Credential-Check is added by Cloudflare to the request it forwards to
   // the origin; it is never sent by the shopper's browser.
   var exposedCredentialCheckMessages = {
       1: Resource.msg('warning.message.exposedcredentialcheck.usernamepassword', 'login', null),
       2: Resource.msg('warning.message.exposedcredentialcheck.username', 'login', null),
       3: Resource.msg('warning.message.exposedcredentialcheck.similar', 'login', null),
       4: Resource.msg('warning.message.exposedcredentialcheck.password', 'login', null)
   };
   var exposedCredentialCheckHeader = req.httpHeaders.get('exposed-credential-check');

   // ...inside the existing successful-login branch, before res.json(loginResponse):
   if (exposedCredentialCheckMessages[exposedCredentialCheckHeader]) {
       loginResponse.exposedCredentialWarning = {
           message: exposedCredentialCheckMessages[exposedCredentialCheckHeader],
           resetPasswordUrl: URLUtils.url('Account-EditPassword').toString()
       };
   }

Why only on a successful login? Two reasons:

1. You act only once you know it’s the real shopper. A correct password is the proof point that it’s safe to say “these credentials are known-breached elsewhere — please rotate them.”
2. No oracle for attackers. If the same flag were echoed on a failed login, a credential-stuffing attacker could learn which guessed username/password combinations are breach-flagged, independent of whether the guess was correct. Restricting to successful logins closes that side channel.

If the header is absent or not 1–4, exposedCredentialWarning is simply omitted and the response is identical to today’s behavior.

For the resource-bundle messages, modal template, client-side handler, and build step, see the full SFRA walkthrough gist.

Monitor it

Before you tighten actions, check how much of your login traffic the detection flags. Use Security Analytics in Business Manager to filter on the credential-check detection and confirm your rule fires as expected.

Need to export the raw logs instead? eCDN Logpush can batch and ship your firewall logs to S3, Splunk, Datadog, and more.

Demo video

Watch leaked-credential detection in action: https://youtu.be/vr3n6XLgEtU

Extend the learning: full SFRA walkthrough

The controller change above is the core of the integration. For the rest of the origin-side code, including the resource-bundle messages, modal template, client-side handler, and build step, see the full SFRA walkthrough gist.

Conclusion

Release 26.9 raises the floor on credential-stuffing defense for every B2C Commerce customer, with no new entitlement required: detection fields you can act on at the edge, and a managed-transform header you can turn into a shopper-facing safeguard in a few lines of SFRA. Use this as your baseline, then see the Bot Management Developer Guide for how to layer in the rest of a defense-in-depth bot-mitigation program.

Resources

• Bot Management Developer Guide
• Bot Mitigation Best Practices for Flash Sales
• SLAS Best Practices
• Create custom rules (with examples)
• Rate-limiting rules — allow verified crawlers & detect leaked credentials
• eCDN Logpush
• Leaked Credentials release notes
• Full SFRA walkthrough (sample code gist)

About the Author

Raghu Venkatraman, Director, Product Management — Raghu Venkatraman is a Product Management Director at Salesforce, where he drives product and bot mitigation strategy and innovation for B2C Commerce. With extensive experience in enterprise software and a passion for building user-centric solutions, Raghu focuses on delivering products that empower organizations to work more efficiently and effectively. He brings deep expertise in product leadership and cross-functional collaboration to help customers maximize their Salesforce investments. Follow him on LinkedIn

The post Stop Credential Stuffing with B2C Commerce eCDN appeared first on Salesforce Developers Blog.

What are Salesforce Microfrontends?

Salesforce Microfrontends let you bring independently developed web applications and widgets into Lightning while keeping a clear boundary between Salesforce and the embedded application.

At a high level, the architecture has three parts:

Lightning host → UI Embedding → embedded web application

The host is a custom Lightning Web Component that renders the lightning-ui-embedding base component. It owns the Salesforce context, retrieves the platform data the embedded application needs, and determines what information to share with it.

The guest is the web application or widget being embedded. It can receive context and UI state from its Lightning host and send custom events back through the UI Embedding channel.

The guest runs inside a sandboxed iframe, providing an isolation boundary between the two applications. UI Embedding provides the managed communication layer that connects them.

This means, for example, that an Account page can use native LWC for record details, actions, and navigation while displaying an embedded React application for a specialized experience.

To the user, these experiences come together within Lightning. To developers, they remain independently developed applications connected through a Salesforce-supported integration layer.

More than embedding a web page

Unlike a plain iframe, a Microfrontend can exchange context, data, UI state, and events with its Lightning host through UI Embedding.

Consider a simple ScoreAccount web application. The application displays an Account’s current rating and lets the user select Hot, Warm, or Cold. When the Account page loads, the Lightning host retrieves the Salesforce record information and provides the relevant state to ScoreAccount. The embedded application renders the current rating.

If the user selects a different rating, ScoreAccount sends an event back to the host. The Lightning Web Component handles that event and updates the Salesforce record.

Conceptually, the interaction looks like this:

Salesforce → record context, data, and UI state → Microfrontend

Microfrontend → events and user interactions → Salesforce

Neither application needs to know how the other is implemented. UI Embedding provides the contract between them.

Understand the security boundary

The isolation between Salesforce and the embedded application is an important part of the Microfrontends architecture.

The embedded application runs inside a sandboxed iframe rather than directly inside the Lightning page. This creates a browser-enforced boundary between the two application environments.

For an externally hosted application, its origin must also be configured appropriately in Salesforce so the browser is permitted to load it. The host then controls the information shared with the guest through the UI Embedding channel.

The embedded application remains responsible for its own application architecture and any authentication or data access required outside the information explicitly provided by its Lightning host.

This model allows the applications to communicate without collapsing them into the same runtime or tightly coupling their implementations.

For the latest security configuration and supported options, refer to the UI Embedding setup documentation.

Build the ScoreAccount Microfrontend

Let’s make the architecture concrete.

The ScoreAccount application displays an Account’s current rating and lets the user change it to Hot, Warm, or Cold.

Bringing the application into Lightning involves four main pieces:

1. Allow the application’s origin in your Salesforce security configuration.
2. Connect the guest application to the Salesforce UI Embedding channel.
3. Create a host LWC using lightning-ui-embedding.
4. Deploy the web application and Salesforce host through their respective deployment workflows.

The interesting part is how the guest and host communicate.

Connect the guest application

The guest application connects to its Lightning host through the Salesforce Platform SDK.

It can retrieve UI state supplied by the host, subscribe to future changes, and dispatch events when users interact with the application.

Here’s the ScoreAccount example:

// Get SDK instance
import { getViewSDK } from "@salesforce/platform-sdk";

const RATINGS = ["Hot", "Warm", "Cold"];

export default function ScoreAccount() {
  const [connected, setConnected] = useState(false);
  const [props, setProps] = useState({});

  // Data in: read the props the host pushed, and stay subscribed.
  useEffect(() => {
    let unsubscribe;
    let cancelled = false;

    getViewSDK().then(
      (sdk) => {
        if (cancelled) return;
        const ui = sdk.getUiState();
        if (!ui) return; // no host state → stay disconnected
        setConnected(true);
        setProps(ui.state.props ?? {});
        unsubscribe = ui.subscribe((next) => setProps(next.props ?? {}));
      },
      () => {}, // SDK never resolved → stay disconnected
    );

    return () => {
      cancelled = true;
      unsubscribe?.();
    };
  }, []);

  // Data out: send the chosen rating back to the host.
  async function score(rating) {
    const sdk = await getViewSDK();
    sdk.dispatchEvent(
      new CustomEvent("score", { detail: { rating }, bubbles: true }),
    );
  }

  return (
    <Card connected={connected} name={props.name} rating={props.rating}>
      <RatingPicker
        ratings={RATINGS}
        active={connected ? props.rating : null}
        disabled={!connected}
        onScore={score}
      />
    </Card>
  );
}

There are two important flows here.

Data comes in. ScoreAccount reads the UI state provided by its Lightning host and subscribes to changes. If Salesforce provides an updated state, the embedded experience can react to it.

Events go out. When the user selects a rating, ScoreAccount dispatches a score event containing the selected value.

The example uses React, but externally hosted Microfrontends aren’t tied to a specific frontend framework. You can use React, Angular, Vue, or other standards-based web technologies supported by the embedding model.

Create the Lightning host

Now let’s look at the Salesforce side.

A host Lightning Web Component renders ScoreAccount using the lightning-ui-embedding base component.

The markup is small:

<!-- scoreAccountEmbedding.html -->
<template>
  <lightning-ui-embedding
    sandbox="allow-forms allow-modals allow-popups allow-popups-to-escape-sandbox"
    shell-title="Account Score Widget"
    src={computedSrc}
    props={account}
    onscore={handleScore}
  ></lightning-ui-embedding>
</template>

Each part has a clear responsibility.

src identifies the guest application. props contains the information Salesforce sends to it. sandbox controls the standard browser iframe capabilities granted to the guest. And onscore lets the host respond to the custom event sent by ScoreAccount.

The JavaScript connects this experience to Salesforce data:

// scoreAccountEmbedding.js
import { LightningElement, api, wire } from "lwc";
import { getRecord, getFieldValue, updateRecord } from "lightning/uiRecordApi";
import RATING from "@salesforce/schema/Account.Rating";

const FIELDS = [RATING];

export default class ScoreAccountEmbedding extends LightningElement {
  @api baseUrl = "http://localhost:5173"; // App origin
  @api recordId;

  @wire(getRecord, { recordId: "$recordId", fields: FIELDS })
  record;

  get computedSrc() {
    const url = new URL(this.baseUrl);
    url.pathname = "/embedding/score-account";
    return url.toString();
  }

  // Send updated Salesforce state to the guest.
  get account() {
    return {
      recordId: this.recordId,
      rating: getFieldValue(this.record?.data, RATING)
    };
  }

  // Handle the rating event from the guest.
  async handleScore(evt) {
    const { rating } = evt.detail ?? {};
    if (!this.recordId) return;

    await updateRecord({
      fields: {
        Id: this.recordId,
        Rating: rating
      }
    });
  }
}

Now the complete interaction becomes clear:

1. The Account page loads and the host retrieves the current rating from Salesforce.
2. The host passes the Account context and rating into ScoreAccount.
3. ScoreAccount renders that state for the user.
4. The user selects Hot.
5. ScoreAccount dispatches the score event back to its Lightning host.
6. The host receives the event and updates the Salesforce record.
7. When the Salesforce data changes, the host provides the updated state back to the embedded application.

The Lightning host understands Salesforce. The guest understands its application. UI Embedding connects them.

For detailed state and event patterns, see Exchange Data Between the Page and an Embedded App.

Bring existing web applications into Lightning

The ScoreAccount example is intentionally small, but the architecture applies to much larger applications.

Many organizations already have web applications with their own frameworks, component libraries, engineering teams, deployment pipelines, and release schedules. Rebuilding those experiences simply to make them available in Salesforce may not always make sense.

With Microfrontends, the application can remain externally hosted while participating in a Lightning experience. The application continues to own its frontend framework, application logic, hosting, and release lifecycle. Salesforce provides the embedding boundary and the communication model needed to connect it with Lightning.

That could mean bringing an existing analytics experience into an Account workspace, embedding an internal search application, or surfacing a specialized workflow maintained by another engineering team.

Microfrontends allow existing web investments to participate in Salesforce without requiring the application and Lightning host to become the same application.

Microfrontends and Multi-Framework

Microfrontends are also part of a broader evolution in how modern frontend applications can work with Salesforce.

Microfrontends with UI Embedding focus on bringing web applications into Salesforce experiences.

For externally hosted applications, your application can remain on its existing infrastructure and retain its development and deployment model.

Salesforce Multi-Framework expands the development model further by enabling applications built with supported open-source frontend frameworks to be developed and deployed on Salesforce.

These applications can be packaged as UI bundles, a Salesforce metadata type that contains the application and the information Salesforce needs to build and run it.

The two models are complementary:

Framework support for Salesforce-hosted UI bundles may evolve across releases. Refer to the current framework support documentation for the latest supported frameworks.

LWC and Microfrontends work together

Microfrontends don’t replace Lightning Web Components. They expand the Salesforce frontend ecosystem around them.

LWC remains the native component model for building Salesforce experiences and working deeply with Salesforce platform capabilities.

Microfrontends add another architectural option when an experience already exists outside Salesforce or needs to retain its own frontend technology, application boundary, and development lifecycle.

That means a single Lightning experience can combine native LWC for record information, Salesforce actions, and platform workflows with an embedded web application for a specialized experience.

Different engineering teams can also maintain those experiences independently.

The team responsible for the Microfrontend can own its framework, components, and release process. The Salesforce team can own the Lightning experience and control the context shared across the application boundary.

The result isn’t LWC versus Microfrontends. It’s an architecture where each can do what it does best.

Where Microfrontends fit

Microfrontends are particularly useful when you’re bringing an established web experience into Lightning and want to preserve its existing technology and development lifecycle.

For example, an organization may already have a specialized React analytics application maintained by a dedicated engineering team. Embedding that experience can preserve the team’s existing framework, component library, and release process while making the application available to Salesforce users.

Native LWC remains a natural fit for experiences designed specifically around Salesforce platform capabilities and native Lightning development.

The key architectural question isn’t simply which frontend framework you prefer. It’s where the application boundary belongs.

If an experience should remain an independently developed web application, Microfrontends provide a supported way to connect that boundary to Lightning.

If you’re building a native Salesforce component that depends deeply on Salesforce platform behavior, LWC continues to provide the native development model. And if you’re building a supported modern framework application directly on Salesforce, Multi-Framework and UI bundles extend the set of development options further.

Together, these models give teams more flexibility in how they design modern Salesforce applications.

Try Salesforce Microfrontends

The easiest way to understand the model is to see the host and guest working together.

The UI Embedding recipes provide working patterns for embedding applications, exchanging state, sending events, managing sizing, and integrating an embedded application with Lightning.

For implementation details, configuration, security requirements, and the latest supported capabilities, use the Salesforce Developer documentation as the source of truth.

The core mental model is simple:

• Embed your web application in Lightning using lightning-ui-embedding.

• Pass the context and data it needs through the managed embedding channel.

• Handle events sent back by the embedded application.

Everything else builds on that foundation.

Conclusion

Lightning Web Components have long provided Salesforce developers with a powerful native way to build user experiences.

Salesforce Microfrontends expand that story.

With UI Embedding, teams can bring modern web applications into Lightning while allowing those applications to retain their frameworks, development models, and application boundaries.

The Lightning host provides the Salesforce context. The external application provides its specialized application experience. Microfrontends securely connect the two.

And with Salesforce Multi-Framework, that story expands further by enabling supported modern framework applications to be built and hosted on Salesforce.

For developers, this creates a broader frontend development model:

Build natively with LWC. Bring existing web applications into Lightning with Microfrontends. Build supported modern framework applications on Salesforce with Multi-Framework.

Resources

• Get started with Salesforce Microfrontends and UI Embedding
• Explore framework support
• Exchange data between Salesforce and an embedded application
• Style an embedded application
• Explore UI Embedding Recipes
• Embed an internally hosted UI Bundle
• Learn more about Salesforce Multi-Framework
• Explore Multi-Framework Recipes on GitHub

About the author

Sangeeta Patnaik is a Senior Product Manager at Salesforce, building products across platform security, developer productivity, and modern application experiences. She is passionate about AI, security, and making complex technology simpler to build, safer to use, and easier to connect.

The post Salesforce Microfrontends: Embed Web Apps in Lightning appeared first on Salesforce Developers Blog.

But data and actions are only half of the story. When an agent replies with a wall of text, users lose the rich, interactive experience they’re used to inside Salesforce. The Headless Experience Layer (HXL) closes that gap. HXL is the part of the Headless Toolkit that brings interactive experiences to any agent: you define a widget once in declarative JSON, and it renders natively in Agentforce and in any Model Context Protocol (MCP) client that supports MCP Apps. No more rebuilding the same experience for every channel.

In this post, you’ll learn the core concepts, how HXL works, and where it fits in AIforce. We’ll then walk through a real widget from the Pronto sample app, following it from the Apex action to the MCP server.

Understanding the Headless Experience Layer

HXL is a centralized engine built on one principle: write once, render anywhere. Today, most agent actions return a plain-text sentence. With HXL, the same action returns a branded, interactive card that looks and behaves consistently, whether your user is in Agentforce, Slack, or Claude.

Because you build the widget once and reuse it on every supported interface, you don’t maintain a separate UI for each one. This saves development time and keeps the experience consistent. A widget isn’t a Lightning Web Component (LWC) or a React app. It’s a declarative tree of components that each surface renders natively.

Core platform benefits

• Your existing security model. A widget only displays what your action returns. When the action enforces sharing and field-level security, every surface shows each user only what they’re allowed to see.
• One source of truth. The same Apex action and the same widget definition serve every channel. There’s no second copy to keep in sync.
• Less integration code. Custom Lightning Types describe your data shape, so you don’t need custom API bridges between your org and each UI surface.

HXL Essentials: Components, Widgets, and Custom Lightning Types

The HXL architecture relies on three core concepts:

• Components: The foundational building blocks of HXL. Components are reusable UI primitives that can be composed to build different experiences. Each component is surface-aware and knows how to render across supported HXL surfaces.
• Widgets: Composed UI experiences built by combining multiple components to address a specific use case. Widgets define the final UI structure and behavior delivered to the user.
• Custom Lightning Types (CLTs): The bridge between data and UI. A CLT describes the shape of your data. Its renderer tells the platform which widget draws that data and how the fields map onto the widget’s attributes.

Where the widget’s data comes from

A widget doesn’t fetch data on its own. The data arrives through the Custom Lightning Type (CLT), which defines the structure your data must follow. Whatever source you use, its output has to match the CLT structure so its properties can bind to the widget attributes. In this post, the data source is an Apex invocable action, following the pattern used in the HXL docs and the Pronto sample app.

How HXL works

You write the Apex action once and the widget once. Only the wiring between them changes per channel.

What you can build in the beta

In the HXL beta, you can:

• Build widgets as JSON in your Salesforce DX project, or vibe code them with an AI agent using the Salesforce Skills library. 
• Learn the components and preview layouts in the HXL Playground.
• Render widgets in Agentforce and preview them in Agentforce Builder. See how to render a widget in Agentforce.
• Render widgets in MCP clients that support the MCP Apps standard, such as Claude and ChatGPT.
• Make widgets interactive with two client actions, sendMessage and openLink.

Example: a Pronto customer reviews widget

To keep things concrete, we’ll use Pronto, our fictional food-delivery sample app. Pronto ships an Employee_Assistant agent with a Get Customer Reviews action. Ask the agent, “Show me the reviews for The Green Fork,” and it will render a review card instead of a paragraph of text.

The card shows a header with the average rating, followed by one entry per review with the customer’s name, the order date, the star rating, and the comment. It’s built from four pieces:

1. An Apex invocable action that returns the review data.
2. A widget that defines the card’s layout.
3. A Custom Lightning Type that binds the action’s output to the widget.
4. An agent action output (or an MCP tool) that tells the surface to render that type.

How the HXL files map in a Salesforce DX project

Here’s how the four pieces map to files in the Pronto repo. The rest of this post walks through them in this order.

Start with the Apex action

Everything starts with the data. GetCustomerReviewsAction is a global Apex class with an @InvocableMethod. It returns a success flag, a message, and one structured reviews object. That object’s shape is what the widget and CLT bind to. Here’s the Apex class, trimmed to its contract:

global with sharing class GetCustomerReviewsAction {
  @InvocableMethod(label='Get Customer Reviews'
    description='Retrieves customer reviews for a specific storefront')
  global static List<Output> getCustomerReviews(List<Input> inputs) { /* ... */ }

  global class Output {
    @InvocableVariable(label='Success') public Boolean isSuccess;
    @InvocableVariable(label='Message') public String message;
    @InvocableVariable(label='Reviews') public ReviewWrapper reviews;
  }

  global class ReviewWrapper {
    @InvocableVariable public Integer reviewCount;
    @InvocableVariable public Decimal averageRating;
    @InvocableVariable public List<ReviewItemWrapper> items;
  }

  global class ReviewItemWrapper {
    @InvocableVariable public String customerName;
    @InvocableVariable public Decimal rating;
    @InvocableVariable public Date orderDate;
    @InvocableVariable public String comments;
  }
}

Note: The Apex class computers averageRating and reviewCount itself, but you can now use Salesforce Formulas to compute values in the widget itself.

Define the widget: layout, contract, and registration

A widget lives in a UiWidgetBundle under uiWidgets/<widgetName>/. The bundle holds up to three files, each with one job:

• customerReviews.uiwidget-meta.xml registers the bundle and sets widgetType to JSON.
• customerReviews.json is the composition file. It’s the layout, built from tile/* blocks.
• schema.json is optional. It declares the type of each attribute, so tools can validate your bindings before you deploy.

Every composition starts with a lightning__agentforceWidget root and a tile/widget tree. Values that change per record are {!$attrs.<name>} placeholders. To repeat a component for each item in a list, you add a forEach meta property and name the loop variable with forItem. Here’s the core of Pronto’s reviews widget, trimmed for brevity:

{
  "type": "lightning__agentforceWidget",
  "contentBody": {
    "widgetBody": {
      "definition": "tile/widget",
      "children": [
        {
          "definition": "tile/column",
          "attributes": { "gap": "lg" },
          "children": [
            {
              "definition": "tile/text",
              "attributes": {
                "text": "Average: {!$attrs.averageRating}/5 ({!$attrs.reviewCount} reviews)",
                "variant": "body",
                "color": "muted"
              }
            },
            {
              "definition": "tile/column",
              "attributes": { "gap": "md" },
              "meta": { "forEach": "{!$attrs.items}", "forItem": "$review" },
              "children": [
                {
                  "definition": "tile/text",
                  "attributes": { "text": "{!$review.customerName}", "variant": "h4", "weight": "semibold" }
                },
                {
                  "definition": "tile/text",
                  "attributes": { "text": "{!$review.rating}/5", "variant": "body", "weight": "semibold" }
                },
                {
                  "definition": "tile/text",
                  "attributes": { "text": "{!$review.comments}", "variant": "body", "color": "muted" }
                }
              ]
            }
          ]
        }
      ]
    }
  }
}

Inside the loop, $review is the current item. You reach each field with {!$review.<field>}. There’s no JavaScript in a widget, so the layout only places and styles values.

The schema is the widget’s contract. It names each attribute and gives it a lightning:type.
Notice that items is a list whose items point at an Apex class you just saw:

{
  "title": "Customer Reviews Widget",
  "type": "object",
  "properties": {
    "attributes": {
      "lightning:type": "lightning__objectType",
      "properties": {
        "reviewCount":   { "lightning:type": "lightning__numberType" },
        "averageRating": { "lightning:type": "lightning__numberType" },
        "items": {
          "lightning:type": "lightning__listType",
          "items": {
            "lightning:type": "@apexClassType/c__GetCustomerReviewsAction$ReviewItemWrapper"
          }
        }
      }
    }
  }
}

Preview widgets in the HXL Playground

The HXL Playground is a browser-based learning tool for HXL. It isn’t part of the build or deploy flow, so you don’t need it to ship a widget. It’s simply the fastest way to learn the components and try out a layout.

The Playground has three areas. The Components area documents each component and its attributes. The Widgets area lets you compose components and preview the result on several surfaces. Tutorials walk you from a single text block to a full widget.

To try Pronto’s reviews card, create a widget and paste the composition from customerReviews.json into the Structure tab. Then add sample values for averageRating, reviewCount, and items in the Data tab. The preview updates as you type, so you can fix the layout before you copy it back into your project. Previews can differ from the live experience, so always test on each target surface.

Bind data to UI with a Custom Lightning Type

A Custom Lightning Type (CLT) connects your action’s output to a widget. A widget is a shell until data flows in. For Agentforce, the CLT is typed directly to the Apex class that the action returns. Pronto’s customerReviewsOutput type points at the action’s ReviewWrapper inner class:

{
  "title": "Customer Reviews Output",
  "description": "Customer reviews and rating summary returned by GetCustomerReviewsAction, rendered as a widget",
  "lightning:type": "@apexClassType/c__GetCustomerReviewsAction$ReviewWrapper"
}

The CLT’s renderer.json points at the widget and binds each widget attribute to an output field:

{
  "renderer": {
    "componentOverrides": {
      "$": {
        "definition": "@widget/c/customerReviews",
        "attributes": {
          "reviewCount":   "{!$attrs.reviewCount}",
          "averageRating": "{!$attrs.averageRating}",
          "items":         "{!$attrs.items}"
        }
      }
    }
  }
}

Read each binding from right to left. The output field on the right feeds the widget attribute on the left. Two details matter here. The "$" key means “the whole type,” and the @widget/ prefix tells the platform to resolve a UiWidgetBundle.

Render the widget in Agentforce

The agent needs to know that this output should render. In Pronto’s Agent Script, the action’s reviews output names the CLT and marks itself displayable:

reviews: object
    label: "Reviews"
    complex_data_type_name: "c__customerReviewsOutput"
    filter_from_agent: False
    is_displayable: True

With is_displayable: True, the agent can show the output in the conversation. Agentforce then resolves the CLT, follows its renderer to the widget, and draws the card. Keep filter_from_agent: False so the output also stays in the agent’s context.

The model still decides when to show the card. In our testing, it usually renders on the first question in a fresh conversation. Follow-up questions in the same conversation sometimes come back as text. To make rendering more consistent, name the action explicitly in your subagent’s instructions. Pronto’s Employee_Assistant does exactly that, referencing the action by name: Call {!@actions.getCustomerReviews} to retrieve customer reviews for a storefront.

Render the same widget through MCP

To render the same widget through MCP, you add two nested Custom Lightning Types, and only the outer one carries the renderer. This is where “render anywhere” pays off. Pronto exposes Get Customer Reviews as a tool on its ProntoEmployeeServer MCP server. HXL widgets follow the MCP Apps standard, so any MCP client that supports MCP Apps, such as Claude and ChatGPT, can render the same card.

MCP needs a different CLT shape, though. An MCP tool call wraps the action output in an envelope with actionName, isSuccess, and outputValues. So you add two nested types. The inner type, customerReviewsResponse, mirrors the Apex Output class. The outer type, customerReviews, mirrors the envelope. Only the outer type has a renderer, and its paths read two levels deep:

{
  "renderer": {
    "componentOverrides": {
      "$": {
        "definition": "@widget/c/customerReviews",
        "attributes": {
          "reviewCount":   "{!$attrs.outputValues.reviews.reviewCount}",
          "averageRating": "{!$attrs.outputValues.reviews.averageRating}",
          "items":         "{!$attrs.outputValues.reviews.items}"
        }
      }
    }
  }
}

The widget and the attribute names on the left are identical. Only the paths on the right change. In the MCP server definition, an entry publishes the outer type as a UI resource. The tool then points at that resource by name:

<tools>
    <apiDefinition>
        <apiIdentifier>aa:apex-GetCustomerReviewsAction</apiIdentifier>
        <apiSource>API_CATALOG</apiSource>
        <operation>GetCustomerReviewsAction</operation>
    </apiDefinition>
    <uiResource>customerReviews</uiResource>
    <readOnly>true</readOnly>
    <toolName>getCustomerReviews</toolName>
    <toolTitle>Get Customer Reviews</toolTitle>
</tools>
<resources>
    <resourceName>customerReviews</resourceName>
    <resourceUri>ui://widget/lightningType/c__customerReviews</resourceUri>
    <resourceTitle>Customer Reviews</resourceTitle>
</resources>

Every client that calls getCustomerReviews follows the resource back to the same @widget/c/customerReviews definition. After you deploy, activate the server in Setup under API Catalog > MCP Servers. Then connect your MCP client through an External Client App. The HXL MCP channels guide covers the client setup in detail.

How to get started

First, enable the beta. In Setup, search for Headless Experience Layer Settings under Feature Settings. Turn on Headless Experience Layer (Beta) and accept the beta terms. Your project should use API version 67.0 or later.

Next, explore a working example. Clone the Pronto sample app, install it in your org, and ask the Employee_Assistant for a storefront’s reviews. Then open the customerReviews widget and its two CLT shapes to see how the pieces fit.

When you’re ready to build your own widget, let an AI agent do the heavy lifting. The open-source Salesforce Skills library is optimized for Agentforce Vibes and works with other AI coding tools. Its HXL skills can plan the Apex display fields, the widget, and the Lightning Type from a single prompt. They can also update your Agent Script and generate the nested MCP types.

To try the whole flow hands-on, take the Give Agents UI with the Headless Experience Layer workshop. It builds a Pronto storefront profile card and renders it in both Agentforce and an MCP client.

Conclusion

HXL makes one hard thing easy: shipping consistent, interactive UI to every agent surface your users touch. You build a widget once and map your data with a Custom Lightning Type. The same card then renders inside Agentforce and across MCP clients, backed by the security your action already enforces. That means less UI code, no drift between channels, and faster delivery.

The fastest way to see it is to install Pronto and watch its review card render. Have questions or something to show? Bring them to the Trailblazer Community, or share what you build with us on LinkedIn.

Resources

• Headless Experience Layer: Get Started
• Build Rich UI with HXL
• HXL Playground
• Salesforce CLI
• Trailblazer Community
• Use HXL Widgets on MCP | Build Rich UI | Headless Experience Layer Developer Guide (Beta)
• Use Agentforce Vibes to Build Widgets | Headless Experience Layer Developer Guide (Beta)
• GitHub – forcedotcom/sf-skills: Salesforce’s curated collection of agent skills for building applications. Optimized for Agentforce Vibes, compatible with all AI tools.
• Give Agents UI with the Headless Experience Layer (HXL)

About the author

Akshata Sawant is a Lead Developer Advocate at Salesforce and co-author of a book titled “MuleSoft for Salesforce Developers,” published by Packt Publication. For a more in-depth look at Akshata’s accomplishments, visit her LinkedIn profile. 

Monika Singh is a Senior Product Manager at Salesforce, focused on Headless Experience Layer (HXL). She has a background in AI/ML product management and is passionate about building intelligent, personalized digital experiences. For more details, visit her LinkedIn profile.

The post Building Interactive UI with Headless Experience Layer appeared first on Salesforce Developers Blog.

Batch data transforms

Data 360’s native batch data transform feature allows for data preparation over DLOs and DMOs, including through operations like joins, filters, and aggregates. You can use the Transform Builder UI to create batch transforms on the platform. The Batch Data Transforms in Data 360 Trailhead module is a great starting point.

Code Extension 

Code Extension is a Data 360 feature that runs custom PySpark logic against DLOs and DMOs inside an isolated Spark compute environment. It powers multiple pipelines, including search-index chunking and batch transform logic, the use case that this post covers.

If you are not familiar with the basics of Code Extension, you can check out the following resources before going deeper into this blog:

• Blog: Extend Data 360 with the Power of Code.
• YouTube: Extend Data 360 with Code Extension.
• Trailhead: Code Extension in Data 360 Module.

Under the hood: the development workflow for Code Extension batch data transform scripts

With Code Extensions, you author a PySpark script that drives the same batch transform pipeline as the one used by native batch transforms. A batch transform Code Extension script runs under strict isolation, using the datacustomcode SDK‘s Client() for reading and writing to DLOs or DMOs.

Here’s a high-level overview of what happens on your (the developer’s) machine and what happens in Data 360:

On the developer machine, a Python virtual environment is used for local execution involving the SDK, your custom PySpark script, and its dependencies. To run the extension locally, you use the following Salesforce Command Line Interface (SF CLI) for Code Extension command: sf data-code-extension script run. The command executes a Spark job on your computer, which reads DLOs or DMOs using the Connect API (by default, the first 1000 rows), and writes only to console output. This is where you’ll iterate until the logic works as intended.

The next step is to deploy to your org. To do so, use the SF CLI command: sf data-code-extension script deploy. The command zips up the project using Docker and uploads it via the Connect API into a Data 360 Transform and Code Extension pair.

When running the transform (now or on a schedule), Data 360 manages the Spark job, which executes your PySpark script to read from and write to DLOs or DMOs.

We recently published Run Complex Data Transformations in Data 360 with Code Extension, which gives you more information about the basics. Below, we build on that introduction and walk through three more examples: rolling up an account hierarchy, exploding a JSON event stream, and scoring leads with a bundled scikit-learn model.

Example 1: Iterative rollup of an account hierarchy

The use case: Roll up each account’s total-tree Annual Recurring Revenue (ARR), including its own plus every descendant’s, at any depth, into Account_Rollup__dll.

The solution: With the Account__dll records having various descendant depths, we can use a loop and keep joining the frontier one hop deeper until nothing new comes back.

from pyspark.sql.functions import col, sum as _sum, coalesce, lit

from datacustomcode.client import Client
from datacustomcode.io.writer.base import WriteMode


def main():
    client = Client()

    accounts = (
        client.read_dlo("Account__dll")
        .select("id__c", "parent_id__c", "arr__c")
        .persist()
    )

    descendants = accounts.select(
        col("id__c").alias("root_id"),
        col("id__c").alias("descendant_id"),
    ).persist()

    frontier = descendants
    while True:
        next_hop = (
            frontier.alias("f")
            .join(
                accounts.alias("a"),
                col("a.parent_id__c") == col("f.descendant_id"),
                "inner",
            )
            .select(
                col("f.root_id").alias("root_id"),
                col("a.id__c").alias("descendant_id"),
            )
        )
        if next_hop.isEmpty():
            break
        descendants = descendants.union(next_hop).persist()
        frontier = next_hop

    totals = (
        descendants.alias("d")
        .join(
            accounts.alias("a"),
            col("d.descendant_id") == col("a.id__c"),
            "left",
        )
        .select(col("d.root_id"), col("a.arr__c"))
        .groupBy("root_id")
        .agg(coalesce(_sum("arr__c"), lit(0)).alias("tree_arr__c"))
        .withColumnRenamed("root_id", "id__c")
    )

    client.write_to_dlo("Account_Rollup__dll", totals, WriteMode.OVERWRITE)


if __name__ == "__main__":
    main()

The convergence check, stop, accumulate loop is plain Python driving DataFrames. NOTE: This convergence check assumes an acyclic hierarchy. If parent_id__c can form a cycle, add a max-depth counter to break the loop so a bad record can’t hang the Spark job indefinitely.

The results written to Account_Rollup__dll are as expected for this sample dataset:

You can find this entire example, including the sample data used, in the SDK’s docs/examples/script/account_rollup directory.

Example 2: Flatten a batched event stream from a JSON-array column

The use case: Analytics SDKs commonly deliver events batched by session. One row per session is stored in a raw landing DLO, with each session’s events packed into a single JSON-array column. Downstream analysis use cases, such as funnel analysis, cohort segmentation, or identity-graph inputs, need one row per event.

The solution: The parse-and-explode logic is worth pulling out of the entrypoint into a reusable helper. With Code Extensions, this can be done by putting files or modules in the payload/py-files/ directory, which needs to have this exact name.

# payload/py-files/events.py
from pyspark.sql.functions import col, explode_outer, from_json, to_timestamp
from pyspark.sql.types import (
    ArrayType, StringType, StructField, StructType,
)


EVENT_SCHEMA = StructType([
    StructField("event_id", StringType(), True),
    StructField("event_type", StringType(), True),
    StructField("ts", StringType(), True),
    StructField("path", StringType(), True),
    StructField("value", StringType(), True),
])
EVENT_ARRAY_SCHEMA = ArrayType(EVENT_SCHEMA, True)

# One row per event, carrying its parent session + user.
def parse_events(df, session_col, user_col, events_col):
    field = next(f for f in df.schema.fields if f.name == events_col)
    events = (
        col(events_col)
        if isinstance(field.dataType, ArrayType)
        else from_json(col(events_col).cast("string"), EVENT_ARRAY_SCHEMA)
    )
    return df.select(
        col(session_col),
        col(user_col),
        explode_outer(events).alias("evt"),
    ).select(
        col("evt.event_id").alias("event_id__c"),
        col(session_col),
        col(user_col),
        col("evt.event_type").alias("event_type__c"),
        to_timestamp(col("evt.ts")).alias("event_ts__c"),
        col("evt.path").alias("path__c"),
        col("evt.value").alias("value__c"),
    )

The entrypoint is now thinner: read, explode, filter, write.

# payload/entrypoint.py
from pyspark.sql.functions import col

from datacustomcode.client import Client
from datacustomcode.io.writer.base import WriteMode
from events import parse_events


def main():
    client = Client()

    sessions = client.read_dlo("User_Sessions__dll").select(
        "session_id__c", "user_id__c", "events__c"
    )
    exploded = parse_events(sessions, "session_id__c", "user_id__c", "events__c")

    output = exploded.filter(col("event_id__c").isNotNull())

    client.write_to_dlo("User_Events__dll", output, WriteMode.OVERWRITE)


if __name__ == "__main__":
    main()

The results written to User_Events__dll are as expected for the sample dataset:

You can find this entire example, including the sample data used, in the SDK’s docs/examples/script/json_explode directory.

Example 3: Score leads with a bundled scikit-learn model

The use case: The data scientist on your team trained a small scikit-learn classifier over categorical lead features (for example, industry, employee band, region, and source) and handed you the serialized artifact. You want a score on every lead as part of the nightly pipeline.

The solution: Similar to the py-files directory from the last example, you can ship other file types in the files directory. You can also ship external dependencies in Code Extensions by using the requirements.txt file, which in this example brings in scikit-learn, joblib, and pandas. Bundle the model as payload/files/lead_scorer.zip (a zip around lead_scorer.joblib — the joblib carries the sklearn pipeline plus feature schema and value domain). The training script is a plain scikit-learn Pipeline fit, run locally before deploying the Code Extension for any model adjustments.

The PySpark entrypoint can joblib.load the model, enumerate every combination of its categorical inputs, score that small grid with predict_proba, and left-join the grid against the leads DLO.

import itertools
import tempfile
import zipfile
from pathlib import Path

import joblib
import pandas as pd
from pyspark.sql import Row
from pyspark.sql.functions import coalesce, col, lit

from datacustomcode.client import Client
from datacustomcode.io.writer.base import WriteMode


UNKNOWN = "__unknown__"
MODEL_ARCHIVE = "lead_scorer.zip"
MODEL_MEMBER = "lead_scorer.joblib"

OUTPUT_COLUMNS = [
    "id__c", "first_name__c", "last_name__c", "industry__c",
    "employee_band__c", "region__c", "source__c", "score__c",
]


def load_bundled_model(client):
    archive_path = client.find_file_path(MODEL_ARCHIVE)
    extract_dir = Path(tempfile.mkdtemp(prefix="lead_scorer_"))
    with zipfile.ZipFile(archive_path) as zf:
        zf.extract(MODEL_MEMBER, path=extract_dir)
    return joblib.load(extract_dir / MODEL_MEMBER)


def build_score_grid(spark, bundle):
    pipeline = bundle["pipeline"]
    feature_cols = bundle["feature_cols"]
    domain = bundle["feature_domain"]

    combos = list(itertools.product(*(domain[c] for c in feature_cols)))
    grid_pd = pd.DataFrame(combos, columns=feature_cols)
    grid_pd["score__c"] = pipeline.predict_proba(grid_pd)[:, 1]

    rows = [
        Row(**{c: r[c] for c in feature_cols}, score__c=float(r["score__c"]))
        for r in grid_pd.to_dict(orient="records")
    ]
    return spark.createDataFrame(rows), feature_cols


def main():
    client = Client()

    leads = client.read_dlo("Lead__dll")
    spark = leads.sparkSession

    bundle = load_bundled_model(client)
    grid, feature_cols = build_score_grid(spark, bundle)

    normalized = leads
    for c in feature_cols:
        normalized = normalized.withColumn(c, coalesce(col(c), lit(UNKNOWN)))

    scored = (
        normalized.alias("l")
        .join(grid.alias("g"), feature_cols, "left")
        .withColumn("score__c", coalesce(col("score__c"), lit(0.0)))
    )

    client.write_to_dlo(
        "Lead_Scored__dll", scored.select(*OUTPUT_COLUMNS), WriteMode.OVERWRITE
    )


if __name__ == "__main__":
    main()

The grid is small, just a few thousand rows, so Spark’s planner auto-broadcasts it and every lead gets its score from a plain equi-join. This approach works well when features are naturally categorical or already banded (industry, region, tier, or segment). Same pattern for churn, propensity, and product-affinity: any model whose inputs are categorical or bucketable. coalesce to __unknown__ keeps the join total as new industries or sources appear.

The results written to Lead_Scored__dll are as expected for the sample dataset:

Because Lead_Scored__dll is a first-class Data 360 object, once mapped into a DMO, an Agentforce agent like Coworker can query it directly: “Who are my top 10 hottest leads this week?”

You can find this entire example, including the sample data used, in the SDK’s docs/examples/script/lead_scoring directory.

Limits and other considerations

Code Extension jobs run under managed Spark with fixed memory, timeout, and dependency-size limits documented in the Considerations When Writing Code Extensions guide. Because local runs sample only the first 1000 rows (by default) via the Connect API, data-scale problems, such as partition skew on a deep account tree or an out-of-memory issue on a large explode, only surface on the deployed run, so test at full scale after deploy. The documented limitations will evolve over time based on the roadmap, which you can influence by reaching out to your account executive and discussing feature requests.

Conclusion

Code Extension is the right tool for the job when Python is the right language: imperative control flow, an existing library you want to reuse, a serialized model, a helper module worth unit-testing on its own. Code Extension for batch data transform is GA. What use cases does this unblock for you and your team? 

More Resources

• Python SDK: forcedotcom/datacloud-customcode-python-sdk · PyPI
• Salesforce CLI plugin: salesforcecli/plugin-data-code-extension
• Developer guide: Data 360 Code Extension
• Help: Batch Data Transforms Overview

About the author

Mark DeLaVergne is a Principal Software Engineer at Salesforce working on Code Extension in Data 360.  With 19 years in software engineering and architecture, he currently leads Code Extension and partners on wider Data 360 design.  You can find him on LinkedIn.

The post Advanced Code Extension PySpark Examples for Batch Data Transforms appeared first on Salesforce Developers Blog.

This post covers the key updates for developers. We start with AIforce and the Headless Toolkit, including Salesforce Multi-Framework, MCP, Salesforce CLI, and API updates. Then we cover Lightning Web Components (LWC), Apex, Agentforce, Data 360, and platform developer tools.

AIforce and Headless Toolkit

AIforce brings the full power of Salesforce to any interface. You build the capability once, and it shows up directly inside your users’ agents, apps, and workflows.

Under the hood, this runs on a headless architecture. Every major Salesforce capability is available as an API, a Model Context Protocol (MCP) tool, or a CLI command. Any authenticated caller can use it, whether that’s an app, a human, or an AI agent. The Headless Toolkit is the biggest developer theme of the Winter ’27 release. It brings AI Skills, the Headless Experience Layer (HXL), Multi-Framework apps, MCP tools, and CLI and API enhancements. Let’s dive into the main developer features.

Salesforce Development plugin for Claude Code

The Salesforce Development plugin teaches Claude Code how to build Salesforce apps and agents. It detects your Salesforce DX project and gives Claude Code Salesforce-specific skills and org context through pre-configured Salesforce-hosted MCP servers. Install the plugin from the Claude Plugin Marketplace, or run this command in Claude Code.

/plugin install salesforce-development@claude-plugins-official

Using Codex, Cursor, or another coding agent? The plugin’s skills come from the open-source Salesforce skills library, which works with any agent that supports AI Skills. Install it with one command.

npx skills add forcedotcom/sf-skills

Explore what’s inside the plugin

The core plugin ships skills that cover the everyday Salesforce development lifecycle. They generate Apex, custom objects and fields, permission sets, Flows, reports, and Lightning pages. They also write and run Apex tests, analyze debug logs, run SOQL queries, configure sharing, scan code with Code Analyzer, and validate and deploy metadata.

The plugin also connects Claude Code to MCP servers for Salesforce API and metadata guidance. A bundled Apex and SOQL language server gives the agent the same code intelligence your IDE uses.

Go beyond the core plugin with specialized plugins

New in Winter ’27, the plugin knows when a task needs more than its core skills. Describe your task, and it recommends a specialized plugin from the Salesforce catalog. The catalog includes specialized plugins such as:

• dx-org-lifecycle: Manage Dev Hubs, scratch orgs, sandbox refreshes, trial orgs, and managed package post-install setup.
• dx-devops: Run DevOps Center pipelines and work items, and configure their automated tests.
• agentforce-adlc: Author, test, and deploy Agentforce agents.
• experience-lwc and experience-react: Build Lightning web components and React apps.
• integration: Set up Named Credentials, callouts, OAuth apps, and Change Data Capture.

To search the catalog yourself, add the plugins keyword and a description of your task.

/salesforce-development:discover plugins <description of your task>

Prefer fewer suggestions? Run /salesforce-development:plugin-recommendations to set how readily the plugin recommends plugins, from off to high.

Salesforce Multi-Framework

Salesforce Multi-Framework lets you build web apps with frontend frameworks you already know, like Angular or React, and run them on the Salesforce Platform. Your app gets Salesforce data, security, and governance without a separate hosting stack. Winter ’27 adds Angular alongsideReact, a richer Data SDK, a way to embed your app in Lightning pages using microfrontends, and 2GP packaging. 

Additionally, we’ve updated the Multi-Framework Recipes sample repository with new Angular and microfrontend code samples to help you get started.

Build Multi-Framework apps with Angular

Angular joins React as a supported framework. Bring your existing Angular skills, libraries, and apps to the platform. Scaffold an app from the angularinternalapp template for employee-facing apps, or the angularexternalapp template for customer and partner apps or angularbasic for a barebones template. Angularinternalapp and angularexternalapp templates come pre-wired with platform integration.

sf template generate project --name account-pulse --template angularinternalapp

Your app is a UIBundle metadata type. You build it with the standard Angular CLI and deploy it with the same Salesforce DX commands you use for the rest of your project.

Reuse data logic with Data SDK extensions

The Data SDK works with any framework and enforces object-level security, field-level security, and sharing rules on every request. In Winter ’27, you can package your own data logic as an extension. Write the extension once with defineDataExtension, and call it through a typed sdk.ext.<name> namespace in every bundle that needs it.

Here’s an extension that returns the top accounts by annual revenue, using the GraphQL API in User Interface API (UI API).

import { defineDataExtension, gql } from '@salesforce/platform-sdk';
interface TopAccountsQuery {
    uiapi: {
        query: {
            Account: {
                edges: {
                    node: {
                        Id: string;
                        Name: { value: string | null } | null;
                        AnnualRevenue: { value: number | null } | null;
                    };
                }[];
            };
        };
    };
}

const TOP_ACCOUNTS = gql`
    query TopAccounts($first: Int) {
        uiapi {
            query {
                Account(first: $first, orderBy: { AnnualRevenue: { order: DESC, nulls: LAST } }) {
                    edges {
                        node {
                            Id
                            Name @optional { value }
                            AnnualRevenue @optional { value }
                        }
                    }
                }
            }
        }
    }
`;
export const pulseExtension = defineDataExtension({
    name: 'pulse',
    setup: (sdk) => ({
        async topAccounts(first = 5) {
            if (!sdk.graphql) {
                throw new Error('GraphQL is not available on this surface');
            }
            const result = await sdk.graphql.query<TopAccountsQuery, { first: number }>({
                query: TOP_ACCOUNTS,
                variables: { first }
            });
            return (result.data?.uiapi.query.Account.edges ?? []).map(({ node }) => ({
                id: node.Id,
                name: node.Name?.value,
                annualRevenue: node.AnnualRevenue?.value
            }));
        }
    })
});

Attach the extension when you create the SDK, then call it like any other SDK method.

import { createDataSDK } from '@salesforce/platform-sdk';
import { pulseExtension } from './pulse-extension';

const sdk = await createDataSDK({ extensions: [pulseExtension] });
const accounts = await sdk.ext.pulse.topAccounts(5);

The Data SDK also picks up these additions:

• Labels extension: Retrieve custom labels by namespace and locale.
• Minimum API version: Set a minimum Salesforce API version on an extension so that it attaches only where its data exists.
• Per-request headers: Pass a headers option on an individual GraphQL query or mutation. Headers are part of the cache key, so requests with different headers don’t share cached responses.

Localize your app and talk to the host page

Use the new @salesforce/platform-sdk/i18n module to match dates, numbers, and currency to each user’s Salesforce locale. Call getCurrentApp() to read the running app’s namespace, name, and qualified name.

import { createDataSDK, getCurrentApp, getViewSDK } from '@salesforce/platform-sdk';
import { createI18nFormatters, fetchI18nContext } from '@salesforce/platform-sdk/i18n';

const sdk = await createDataSDK();

// Format currency with the running user's locale and currency
const ctx = await fetchI18nContext(sdk);
const fmt = createI18nFormatters(ctx);
const total = fmt.formatCurrency(5080000, { maximumFractionDigits: 0 });

// Read the running app's identity, for example c__w27AccountPulse
const app = await getCurrentApp();
console.log(app.identity?.qualifiedName);

Embed your app in Lightning pages as a microfrontend (Beta)

You don’t have to rebuild your app in LWC to show it on a Lightning page. Write a thin Lightning web component that renders the lightning-ui-embedding base component and points it at your deployed app’s URL. Salesforce hosts your app in a secure, sandboxed iframe and gives it a two-way channel to the surrounding page.

That channel is what makes a microfrontend feel native. The host component can pass data down to your app, and your app can send events back up. In our example below, an industry filter in the LWC filters the Angular app’s account list, and clicking an account in the Angular app shows that record in native Salesforce components.

Pass data from the host LWC to your app

Set the props attribute on lightning-ui-embedding. When a value changes, Salesforce pushes the new props to your app.

<template>
    <lightning-radio-group
        label="Filter the embedded app"
        type="button"
        options={industryOptions}
        value={industry}
        onchange={handleIndustryChange}>
    </lightning-radio-group>
    <lightning-ui-embedding
        lwc:ref="embedding"
        src={appUrl}
        props={embedProps}
        width="100%"
        height="560">
    </lightning-ui-embedding>
</template>

In your app, read the props with getUiState() from the view SDK, and subscribe to get every change.

const view = await getViewSDK();
const ui = view?.getUiState?.<PulseUiState>();
if (ui) {
    this.industry.set(ui.state.props.industry ?? '');
    ui.subscribe((next) => this.industry.set(next.props.industry ?? ''));
}

Send events from your app to the host LWC

Dispatch a CustomEvent through the view SDK. Salesforce forwards it to the host page.

select(account: PulseAccount): void {
    this.view?.dispatchEvent?.(
        new CustomEvent('pulse.accountselected', {
            detail: { recordId: account.id, name: account.name }
        })
    );
}

The event arrives on the lightning-ui-embedding element with the same type and detail. Embedding event names contain a dot, so you can’t bind them in the template. Add the listener once in renderedCallback instead.

import { LightningElement, api } from 'lwc';
export default class MicrofrontendHost extends LightningElement {
    @api appUrl; // deployed app URL on the salesforce.app domain
    industry = '';
    selected;
    listening = false;

    get embedProps() {
        return { industry: this.industry };
    }
    renderedCallback() {
        const embedding = this.refs.embedding;
        if (embedding && !this.listening) {
            this.listening = true;
            embedding.addEventListener('pulse.accountselected', (event) => {
                this.selected = event.detail; // { recordId, name }
            });
        }
    }
    handleIndustryChange(event) {
        this.industry = event.detail.value;
    }
}

The host then renders selected.recordId with lightning-record-view-form, so the details panel is plain Salesforce UI. Here’s the same page after a user picks Retail in the LWC filter and selects an account in the Angular app.

Embedding supports internal, employee-facing apps built with React or Angular and served from the salesforce.app domain. You can add the host component to Lightning pages and Experience Cloud site pages.

Package, manage, and monitor your apps

• Package with 2GP: Distribute Multi-Framework apps with second-generation packaging (2GP). Use unlocked packages for apps you want to keep editable, or managed packages to distribute locked, namespaced internal apps through AppExchange.
• Manage apps in App Manager: From Setup, open App Manager and select New App | New Multi-Framework App. Choose Builder Central to build from a natural language description, or Agentforce Vibes to work directly with code.
• Analyze performance in Scale Center (Beta): From Setup, open Multi-Framework Insights (Beta) and click Generate Insight Report. The dashboard shows key metrics for up to ten apps with the most page views over the last seven days.

Headless Experience Layer (Beta)

The Headless Experience Layer (HXL) lets you define a rich UI once, as a widget, and render it natively in Agentforce, Claude, and Slackbot. To show how it works, I built a snow report widget for an Agentforce agent. Four pieces of metadata connect the agent’s Apex action to the UI, and each piece refers to the next by name.

First, the agent’s action calls the Apex invocable method and types its output with a custom Lightning type, c__w27SnowReport.

Get_Snow_Report:
   description: "Returns today's snow report for a resort"
   inputs:
      resort: string
         is_required: True
   outputs:
      report: object
         complex_data_type_name: "c__w27SnowReport"
         is_displayable: True
   target: "apex://W27_SnowReportService"

The Lightning type is a LightningTypeBundle with two files. Its schema.json binds the type to the Report Apex class that the action returns.

{
  "title": "Snow Report",
  "lightning:type": "@apexClassType/c__W27_SnowReportService$Report"
}

Its renderer.json points to the w27SnowReport widget and maps each field of the Apex class to a widget attribute.

{
  "renderer": {
    "componentOverrides": {
      "$": {
        "definition": "@widget/c/w27SnowReport",
        "attributes": {
          "resort": "{!$attrs.resort}",
          "conditions": "{!$attrs.conditions}",
          "newSnowCm": "{!$attrs.newSnowCm}",
          "baseDepthCm": "{!$attrs.baseDepthCm}",
          "liftsOpen": "{!$attrs.liftsOpen}",
          "liftsTotal": "{!$attrs.liftsTotal}"
        }
      }
    }
  }
}

The w27SnowReport widget itself is a UiWidgetBundle. Its composition file lays out HXL components and binds them to those attributes. Here’s an excerpt: the header, the lifts progress bar, and a button that sends a follow-up message to the agent.

{ "definition": "tile/text", "attributes": { "text": "{!$attrs.resort}", "variant": "h2" } },
{ "definition": "tile/badge", "attributes": { "label": "{!$attrs.conditions}", "variant": "success" } },
{ "definition": "tile/progress",
  "attributes": { "label": "Lifts open", "value": "{!$attrs.liftsOpen}", "max": "{!$attrs.liftsTotal}", "size": "md" } },
{ "definition": "tile/button",
  "attributes": {
    "label": "Show lift hours",
    "actions": { "click": [
      { "definition": "action/sendMessage", "attributes": { "content": "What are the lift hours today?" } }
    ] }
  } }

Here’s the result in the Agentforce Builder preview. The action returns structured data, and the agent shows it as an interactive card instead of plain text.

To try it, turn on Headless Experience Layer Settings in Setup, and deploy the widget and the Lightning type with sf project deploy start. To use the same widget in Claude or Slackbot, add the action as a tool on a custom MCP server. You can also explore components in the HXL Playground.

Salesforce MCP updates

Model Context Protocol (MCP) now works in both directions on Salesforce, through Salesforce Hosted MCP Servers and Agentforce. Your Agentforce agents can call MCP tools, and external AI clients can call your agents as MCP tools. Here’s what’s new.

Expose your Agentforce agents as MCP tools

Make an Agentforce agent available to any MCP client, such as Claude, ChatGPT, or Cursor, by adding it as a tool on a custom MCP server. The external client sends a request, and your agent handles it with its own instructions, actions, and knowledge sources. Every call runs as the authenticated user, so sharing rules, field-level security, and Einstein Trust Layer policies still apply.

To expose an agent:

1. In Setup, go to Integration > Salesforce MCP Servers and open your custom server.
2. Add a tool, and select Agentforce Agent as the backing type.
3. Choose the agent, then give the tool a name and a description.
4. Publish the server.

The agent’s required inputs become the tool’s parameter schema. Only agents built with the new Agent Script Builder can be exposed, so upgrade legacy agents first. 

Tip: External models choose tools based only on the name and description. Make each tool task-specific. For example, one sales agent can back a “Schedule Customer Meeting” tool and a “Forecast Deal” tool instead of a single generic “Sales Agent” tool. Update the description whenever the agent’s instructions change.

Add MCP server tools to your Agentforce agents

Going the other way, you can now add AgentExchange MCP server tools to an agent directly in Agentforce Builder. The Actions modal lists MCP server tools next to standard agent actions. Use the MCP Server Tools filter to find them quickly.

Two related updates make the right server easier to find and manage:

• Agentforce Registry: Each MCP server on AgentExchange has its own card that shows its tools and the solutions it belongs to. From Setup, open Agentforce Registry, select Registered MCP Servers, and click New+ to open AgentExchange and browse server cards.
• API Catalog: Activate Salesforce hosted MCP servers for Agentforce and supported external MCP clients, and register external MCP servers, including MuleSoft.

Automate Marketing Cloud Engagement with 40 new MCP tools

The Marketing Cloud Engagement MCP server adds 40 tools, so your AI agent can handle more day-to-day operations in natural language. New tools create and run Automation Studio activities, manage campaigns and Content Builder folders, upsert bulk data, query data extensions, erase contacts, and retrieve email tracking events.

Salesforce CLI updates

Salesforce CLI ships every week, so a lot has landed since Summer ’26. Here are five updates worth acting on now.

Move off the temporary secrets workaround

Commands such as org display and org list --json no longer print access tokens, SFDX auth URLs, or passwords. The SF_TEMP_SHOW_SECRETS=true workaround that restores the old output goes away on October 28, 2026. When a script needs a secret, ask for it explicitly.

sf org auth show-access-token --target-org my-org
sf org auth show-sfdx-auth-url --target-org my-org
sf org auth show-user-password --target-org my-org

Check your CI jobs now. A script that reads accessToken from org display --json gets [REDACTED] instead of a token, and the failure shows up later as a 401 error.

Scaffold async Apex with built-in best practices

New Batchable and Queueable values for the --template flag generate async Apex that follows platform best practices.

sf template generate apex class --name ProcessAccounts --template Batchable
sf template generate apex class --name SendEmail --template Queueable

The Batchable template uses a typed scope, an inline SOQL query, and Database.RaisesPlatformEvents. The Queueable template attaches a Finalizer, so your post-job logic runs even after an unhandled exception.

public with sharing class SendEmail implements Queueable, Finalizer {

    public void execute(QueueableContext context) {
        System.attachFinalizer(this);
        // TODO: implement job logic here
    }

    public void execute(FinalizerContext context) {
        if (context.getResult() == ParentJobResult.UNHANDLED_EXCEPTION) {
           // handle failure
        }
    }
}

Control Apex debug logs from the command line

Set the debug log level when you run anonymous Apex. Use --debug-level for a predefined level, or --category-level for per-category control.

sf apex run --file test.apex --debug-level DETAIL
sf apex run --file test.apex --category-level Apex_code=FINEST --category-level Db=FINE

New apex trace commands to create, list, and delete trace flags are coming next in the release candidate.

Set up scratch orgs for realistic testing

Assign a role to a new scratch org user with roleDeveloperName in the user definition file.

{
  "Username": "w27.presenter@winter27demos.example",
  "LastName": "Presenter",
  "Email": "w27.presenter@winter27demos.example",
  "profileName": "Standard User",
  "roleDeveloperName": "W27_Demo_Presenter"
}

To let Apex tests send email to unverified domains, enable enableSubstituteFromAddress in your scratch org definition file.

{
  "settings": {
    "emailAuthorizationSettings": {
      "enableSubstituteFromAddress": true
    }
  }
}

Skip the source-tracking scan on large projects

When your org is already in sync with your project, such as an org pre-seeded with your metadata, set SF_SOURCE_TRACKING_ASSUME_SYNCED to skip the local scan before deploys and retrieves. On very large projects, this can save some time.

export SF_SOURCE_TRACKING_ASSUME_SYNCED=true
sf project deploy start --target-org my-org

Tip: Use it with extra care. If the org isn’t really in sync, it drifts further out of sync.

Also new: the api request rest and api request graphql commands are generally available, and Salesforce CLI now requires Node.js 22 or later. See the Salesforce CLI release notes for every command and flag.

Salesforce Platform API updates

Winter ’27 ships API version 68.0. Two changes need action from integration owners now, and two make everyday API work easier.

Assign Use Any API Auth before December 1, 2026

Beginning December 1, 2026, every user who authenticates with SOAP API login() needs the Use Any API Auth user permission. This applies to all orgs. Users without it get an error. Test the change in advance with the release update in Setup.

This is a step toward the bigger change. SOAP login() in API versions 31.0 through 64.0 retires in Summer ’27. Move those integrations to OAuth with external client apps.

Plan for the retirement of API versions 31.0 through 40.0

SOAP API, REST API, and Bulk API versions 31.0 through 40.0 are being retired. For REST, this covers every URI under /services/data/vXX.X/.

• Summer ’27 (deprecation): These versions stop getting security updates and bug fixes.
• Summer ’28 (retirement): Calls to these versions fail.

Search your integrations, scripts, and middleware for hard-coded versions in this range, and move them to a current version.

Use latest instead of a numbered REST API version

Replace the version segment in a REST API URI with latest. Salesforce routes the request to the most recent version that your org supports. To see which version latest resolves to, call the List Available REST API Versions resource.

sf api request rest "/services/data/latest/sobjects/Account" --target-org my-org

In our Winter ’27 org, latest resolved to v68.0. Use it for scripts and internal tools. Keep a pinned version for production integrations that depend on a specific contract.

Monitor composite API requests with EventLogFile

Query the EventLogFile object for the new CompositeApi and CompositeApiSubrequest event types. You get details for each composite and composite graph request, and for each subrequest. That helps when a composite call succeeds overall but one subrequest fails.

SELECT EventType, LogDate, LogFileLength
FROM EventLogFile
WHERE EventType IN ('CompositeApi', 'CompositeApiSubrequest')
ORDER BY LogDate DESC

LWC updates

Winter ’27 brings two Lightning Web Components (LWC) features to general availability and fills a few gaps for state managers and console apps. Upgrade your components to LWC API version 68.0 to pick up the latest behavior. According to the release notes, version 68.0 has no version-specific changes, so it’s an easy upgrade.

Write logic in templates with complex template expressions (GA)

You no longer need a getter just to join strings, count items, or pick a CSS class. Write a subset of JavaScript directly in the template with template expressions. Template expressions require API version 66.0 or later.

<template>
    <p>{`Hello, ${firstName} ${lastName}!`}</p>
    <p>{isLoggedIn ? 'Welcome back!' : 'Please log in'}</p>
    <p>Theme: {user?.profile?.settings?.theme ?? 'default'}</p>
    <p>In-stock: {items.filter(item => item.qty > 0).length} of {items.length}</p>
    <ul>
        <template for:each={items} for:item="item">
            <li key={item.name} class="{item.qty > 0 ? 'slds-text-color_success' : 'slds-text-color_error'}">
                {item.name} ({item.qty})
            </li>
        </template>
    </ul>
</template>

Keep these rules in mind:

• Quote attribute expressions: The compiler requires double quotes around an expression in an attribute value, as in class="{...}".
• Keep expressions simple: You can’t use this, new, or function declarations in an expression.
• Iterate over expressions: for:each accepts a quoted expression that returns an array, such as for:each="{items.filter(item => item.qty > 0)}". Each item still needs a unique key.

Use third-party web components with lwc:external (GA)

Use an existing third-party web component library in LWC without rewriting it or wrapping it in an iframe. Load the library, then add lwc:external to the custom element so it renders as a native web component.

Our example uses w27-rating-stars, a plain, framework-free custom element packaged as an IIFE and uploaded as a static resource named w27RatingStars. It knows nothing about LWC. It reads value and max attributes and fires a standard rate event. In your LWC, load the static resource and render the element with lwc:external.

<template>
    <template lwc:if={libraryLoaded}>
        <w27-rating-stars lwc:external value={rating} max="5" lwc:spread={starProps} onrate={handleRate}>
        </w27-rating-stars>
    </template>
</template>

import { LightningElement } from 'lwc';
import { loadScript } from 'lightning/platformResourceLoader';
import RATING_STARS from '@salesforce/resourceUrl/w27RatingStars';

export default class ExternalComponent extends LightningElement {
    rating = 4;
    starProps = { 'data-qa': 'product-rating' };
    libraryLoaded = false;

    async connectedCallback() {
        await loadScript(this, RATING_STARS);
        this.libraryLoaded = true;
    }

    handleRate(event) {
        this.rating = event.detail.value;
    }
}

Note: Third-party web components require Lightning Web Security. Load libraries as IIFE or UMD bundles, because loadScript doesn’t support ES modules. On an lwc:external element, LWC passes values as attributes by default and sets properties only when the custom element defines them.

Here’s the w27-rating-stars component rendered inside a Lightning web component.

Refresh state manager data with refresh()

Some state managers serve data without a single record ID, such as related list records. You can now call refresh() on these managers to pull fresh data after an update. You don’t need to reload the page or create a new manager. Ensure the current status is loaded before calling it. The status remains loaded during execution, and the returned promise resolves once data populates with the latest results.

import { LightningElement, api } from 'lwc';
import relatedListRecords from 'lightning/stateManagerRelatedListRecords';

export default class OpportunityList extends LightningElement {
    @api recordId;
    related = relatedListRecords({
        parentRecordId: undefined,
        relatedListId: 'Opportunities',
        fields: ['Opportunity.Name']
    });

    connectedCallback() {
        this.related.value.setParentRecordId(this.recordId); // load the Account's Opportunities
    }

    async handleRefresh() {
        const sm = this.related.value;
        if (sm.status === 'loaded') {
            await sm.refresh(); // rejects if the status isn't loaded
        }
    }
}

Note: status, data, and refresh() live on related.value, not on related.

Apex updates

Winter ’27 gives Apex more room to work and better ways to test and inspect your code. Here are the highlights, with examples.

Handle larger payloads with higher heap limits

The Apex heap limit increases from 6 MB to 10 MB for synchronous transactions and from 12 MB to 25 MB for asynchronous transactions. The new limits are turned on automatically. Deploying from a Winter ’27 sandbox to a Summer ’26 production org? In the sandbox, open Apex Settings in Setup and select Enforce the Summer ’26 Apex heap limit until production upgrades.

Test real callouts with Apex integration tests (Developer Preview)

Unit tests can’t make real callouts, so a mock can hide a broken named credential or payload. Integration tests let you call the real service from a scratch org. They aren’t available in production orgs or sandboxes, and they don’t count toward code coverage. Turn on the ApexIntegrationTests feature in your scratch org definition file, then annotate the class and its test methods with @IntegrationTest.

@IntegrationTest
public with sharing class W27_ExternalServiceIntegrationTest {
    @BeforeClass
    static void setup() {
        insert as user new Account(Name = 'W27 PaymentTestAccount');
    }
    @IntegrationTest
    static void testExternalServiceCallout() {
        Account a = [SELECT Id FROM Account WHERE Name = 'W27 PaymentTestAccount' WITH USER_MODE LIMIT 1];
        HttpRequest req = new HttpRequest();
        req.setEndpoint('callout:W27_Echo/get?status=verified&account=' + a.Id);
        req.setMethod('GET');
        HttpResponse res = new Http().send(req);
        Assert.areEqual(200, res.getStatusCode());
        Assert.isTrue(res.getBody().contains('verified'));
    }
    @TearDown
    static void tearDown() {
        delete [SELECT Id FROM Account WHERE Name = 'W27 PaymentTestAccount'];
    }
}

Integration tests don’t roll back data, so clean up in @TearDown. It runs after each test method, so with several methods, delete only per-method data there. Only one integration test class can run per org at a time, and runs are asynchronous only. Run them with sf apex run test, without --synchronous. If you register Test.setMock(), the mock still wins.

Compare two fields in SOQL with FORMULA() (Beta)

Compare fields directly in a WHERE clause with FORMULA() instead of creating a formula field just for a query. FORMULA() requires API version 68.0 and isn’t available in production orgs.

List<Opportunity> openBalances = Database.query(
    'SELECT Name, Amount_To_Pay__c, Amount_Paid__c FROM Opportunity ' +
    'WHERE FORMULA(\'Amount_To_Pay__c - Amount_Paid__c\') > 0 ' +
    'WITH USER_MODE ORDER BY Name'
);

Prevent field name collisions in managed package queries

If a subscriber creates a field with the same API name as a field in your managed package, dynamic SOQL in your package can resolve the wrong field. Build a Database.QueryOptions object with withExplicitNamespace(true), and bind it with a SET OPTIONS clause. For details, see Prevent Field Name Collisions in Managed SOQL Queries.

Database.QueryOptions options = Database.QueryOptions.builder()
    .withExplicitNamespace(true)
    .build();
List<SObject> rows = Database.queryWithBinds(
    'SELECT Id, Name FROM Opportunity WHERE Name LIKE :prefix LIMIT 5 SET OPTIONS :options',
    new Map<String, Object>{ 'prefix' => 'W27%', 'options' => options },
    AccessLevel.USER_MODE
);

Note: Put SET OPTIONS after the other clauses, including WHERE, ORDER BY, LIMIT, and OFFSET. Only FOR UPDATE can follow it.

Look up Apex types with the Apex Symbol API (Beta)

The Apex Symbol API is a Tooling API resource that returns the same type information the Apex compiler uses, for built-in, custom, packaged, and dynamic types. Use it to power code completion or to ground a coding agent before it writes Apex. Set category to builtin, database, or dynamic, and narrow the results with namespace and name. The API handles one request per org at a time.

sf api request rest "/services/data/v68.0/tooling/symbols?category=builtin&namespace=Database&name=QueryOptionsBuilder" --target-org my-org

Page through Data 360 objects with Apex cursors (Beta)

Apex cursors now work with Data 360 Data Model Objects (DMOs). Fetch any slice of a large result set, forward or backward, without Batch Apex. In one of my orgs with Data 360, the same pattern pages through more than 1.4 million rows successfully.

Database.Cursor cursor = Database.getCursor(
    'SELECT device_id__c, event_ts__c, power_draw_w__c FROM Radiant_Reading__dlm ORDER BY event_ts__c DESC'
);
Integer total = cursor.getNumRecords();
List<SObject> lastPage = cursor.fetch(Math.max(total - 50, 0), 50); // jump straight to the end

DMO queries can consume Data Services credits from your Data 360 subscription. Track usage with Limits.getDataCloudCursors() and Limits.getDataCloudCursorRows(). Cursors expire 24 hours after you create them.

More Apex updates

• Test Discovery API: Filter results with the testLevel parameter, such as RunLocalTests. In API version 68.0, testLevel replaces showAllMethods.
• Recompile only invalid Apex: In Setup, use Compile only invalid classes or Compile only invalid triggers instead of recompiling the whole org. To get the errors programmatically, call the Tooling API apexCompileResults resource.
• Old API version warnings: The compiler now warns about classes and triggers saved at API versions 9.0 through 19.0, which will be retired. Move them to API version 20.0 or later.
• Elastic limits for Batch Apex (Beta): Elastic limits now cover Batch jobs, in addition to Queueable jobs and future methods. Jobs keep running above the rolling 24-hour async limit, and you can test this in non-production orgs.

Agentforce monthly updates

Agentforce ships updates every month, and the August and September updates arrive with Winter ’27. This round gives Agent Script a lot of new language features. It also makes multi-agent solutions generally available and simplifies how you move agents between orgs.

Write more expressive agents with new Agent Script language features

Agent Script now handles more logic without an extra action or a prompt workaround.

• New expression functions: lower(), upper(), to_json(), from_json(), and json_path(obj, path, default).
  
• else if chains: Branch on more than two conditions. Nested if statements and elif still aren’t supported.
• New system variables: @system_variables.current_connection and @system_variables.current_modality tell your agent where and how it’s talking to the user.
• Deterministic escalation: A top-level escalate statement hands the conversation to a human when a condition is met. The example below uses each of these features.

before_reasoning:
   set @variables.tier = upper(@variables.tier_input)
   set @variables.first_sku = json_path(from_json(@variables.order_json), "$.items[0].sku", "none")
   if @variables.score >= 90:
      set @variables.band = "high"
   else if @variables.score >= 70:
      set @variables.band = "medium"
   else:
      set @variables.band = "low"
reasoning:
   instructions: ->
      | Recent tags: {!@variables.recent_tags[0:2]}. You're on {!@system_variables.current_modality}.
after_reasoning:
   if @variables.needs_human:
      escalate

Format action output per connection

Tell your agent exactly how to format an action’s output on each connection. Add a when @connection.<name> block to the action, and pick a response format with render. The new built-in json format sends the action’s structured output directly to the client. Add show_and_return: True to send the response and end the turn.

connection messaging:
   label: "Messaging"
subagent menu:
   reasoning:
      actions:
         get_menu: @actions.Get_Menu_For_Restaurant
            with restaurant=...
            when @connection.messaging
               render: @response_formats.json
                  show_and_return: True

The compiler checks that each format belongs to its connection. After we published the agent, the rule appeared as a messaging render rule that returns JSON and ends the turn. To shape replies with natural language instead, add connection instructions to the Messaging, Service Email, or Marketing Email connection.

Accept file uploads in agent conversations

Service and Employee agents can now accept screenshots, receipts, and PDFs on Enhanced Chat v1, Enhanced Chat v2, and Lightning Experience. Your agent can read the file, attach it to a record, or use it as context. This feature is rolling out starting the week of September 21, 2026.

Turn it on in the agent’s config block. The mode can be auto (the default), managed, disabled, or error. In managed mode, uploaded files land in @system_variables.uploaded_files, so your script decides what to do with them.

config:
   developer_name: "W27_Channels_Lab"
   file_upload:
      mode: "managed"
   runtime:
      streaming: True

The new runtime block shown here also lets you set runtime behavior, such as streaming and citations, per agent.

Delegate to specialist agents with Multi-Agent Orchestration (GA)

Multi-Agent Orchestration is generally available. Connect an orchestrator agent to specialized agents in your org, and let each agent do what it does best. Declare the specialist as a connected_subagent, then hand off to it like any other subagent.

start_agent concierge:
   reasoning:
      instructions: ->
         | Answer resort questions yourself. Hand off menu questions to the menu specialist.
      actions:
         ask_menu_specialist: @utils.transition to @connected_subagent.Menu_Specialist
            description: "Hand off restaurant menu and food questions"

connected_subagent Menu_Specialist:
   target: "agent://W27_Menu_Specialist"
   description: "Answers questions about restaurant menus"
   delegate_escalation: True

In our test example, a menu question moved from the concierge to the specialist, which called its Apex action and answered. A question about ski lift hours stayed with the concierge.

Deploy agents between orgs with simplified metadata types

Starting in API version 68.0, an agent is described by two metadata types: AiAgentDefinition and AiAgentDefinitionVersion. You no longer list every planner, plugin, Apex class, flow, and prompt template by hand. Retrieve a version with its dependencies in one command.

sf project retrieve start --metadata "AiAgentDefinitionVersion:W27_Channels_Lab#1" --root-type-with-dependencies AiAgentDefinitionVersion

In our org, this returned the agent definition, the version, its Agent Script authoring bundle, and the Apex class behind its action. Both orgs must be on API version 68.0. Until production upgrades, keep using the previous metadata types to deploy from a Winter ’27 sandbox.

Also new: Compare and merge agent versions in Agentforce Builder, and the Agentforce platform is now turned on by default. Gemini 2.5 Pro, Flash, and Flash-Lite requests are rerouted to newer Gemini models on October 20, 2026, so test your prompts now.

To see the latest Agent Script grammar, linter, and compiler, explore the open-source Agent Script repository.

Data 360 monthly updates

Data 360 ships updates as often as monthly, and changes included in Winter ’27 are generally listed under October 2026 in the release notes. Here are two key updates for developers.

Measure RAG retriever quality with advanced retriever metrics

Retrievers find the content that grounds retrieval-augmented generation (RAG). To measure one, test it in the Retriever Playground in Advanced Mode with a question and a reference answer. Data 360 now returns a context precision score. Context precision measures how well the retriever ranks relevant chunks above irrelevant ones. A higher score means the relevant chunks are at the top. The metrics panel also shows the retrieval response time and the retrieved chunks.

To track retriever quality from code, query the AI Retriever Quality Metric DMO (ssot__AiRetrieverQualityMetric__dlm). Each row holds the context precision, answer relevancy, and faithfulness scores for a retriever request, along with the user utterance and the IDs of the retrieved context. This query averages the scores for each retriever over the last seven days.

List<AggregateResult> scores = [
    SELECT ssot__RetrieverApiName__c retriever,
           AVG(ssot__ContextPrecisionScoreNumber__c) contextPrecision,
           AVG(ssot__AnswerRelevancyScoreNumber__c) answerRelevancy,
           AVG(ssot__FaithfulnessRelevancyScoreNumber__c) faithfulness,
           COUNT(Id) samples
    FROM ssot__AiRetrieverQualityMetric__dlm
    WHERE ssot__MetricCreatedTimestamp__c = LAST_N_DAYS:7
    GROUP BY ssot__RetrieverApiName__c
];

Compare these averages before and after you change chunking, the search index, or the model, so you know which change moved the score. Testing retrievers consumes credits. For details, see Billing Considerations for Testing Retrievers.

Transform zero-copy data with Python code extensions

Code extension runs your custom Python batch transforms in Data 360. Winter ’27 extends them to zero-copy data: a data lake object (DLO) backed by a zero-copy connector, or a data model object (DMO) mapped from that DLO. The connector reads the data in place on the external platform, so you skip the ingestion step and the cost of storing a copy. Your script needs no special configuration. It runs the same way on federated data as on ingested data.

Write the script with the Code Extension plugin for Salesforce CLI (Beta). The SDK hands you a PySpark DataFrame. This script reads a DMO, averages signal strength for each device, and writes the result to another DMO.

from pyspark.sql.functions import avg, count, round

from datacustomcode.client import Client
from datacustomcode.io.writer.base import WriteMode


def main():
    client = Client()

    readings = client.read_dmo("Radiant_Reading__dlm")

    signal_by_device = readings.groupBy("device_id__c").agg(
        round(avg("signal_dbm__c"), 1).alias("avg_signal_dbm__c"),
        count("*").alias("reading_count__c"),
    )

    client.write_to_dmo(
        "Radiant_Device_Signal__dlm", signal_by_device, write_mode=WriteMode.OVERWRITE
    )


if __name__ == "__main__":
    main()

Create the package, run scan to fill in the read and write permissions in config.json, and then run the script locally against your org.

sf plugins install @salesforce/plugin-data-code-extension
sf data-code-extension script init --package-dir ./radiant-script
sf data-code-extension script scan --entrypoint ./radiant-script/payload/entrypoint.py
sf data-code-extension script run --entrypoint ./radiant-script/payload/entrypoint.py --target-org my-org

A local run reads a sample of rows through the Query API and prints the output DataFrame instead of writing it, so you can test against real data safely. When the output looks right, zip and deploy the package with sf data-code-extension script deploy, and then run it from a batch data transform.

Platform development tool updates

Winter ’27 brings a new in-browser IDE, Apex performance scans from your coding agent, and region-aware routing for Agentforce Vibes.Here’s what’s new.

Write and run code in the browser with Web Console (GA)

Web Console is a browser-based IDE built on VS Code for Web and built into Salesforce, so there’s nothing to install. Open it from the Setup menu by selecting Web Console, or click Edit on an Apex class or trigger in Setup.

In Web Console, you can:

• Edit code: Edit and save Apex, and view and edit Lightning web components with Org Browser.
• Run Apex and SOQL: Run anonymous Apex scripts, and build queries with SOQL Builder and see their query plans.
• Test and debug: Run Apex tests from the Testing panel, create a trace flag, and get debug logs.
• Work with metadata: Browse, retrieve, and deploy your org’s metadata.

Apex is read-only in production orgs, so make your edits in a sandbox or other non-production org. Running queries requires the Use Any API Client user permission. See supported editions for availability.

In Winter ’27, Developer Console doesn’t appear in the Setup menu by default. To bring it back, from Setup, enter Development in the Quick Find box, select Web Console, and set Enable Developer Console to Active. If you switch back, share your reasons in the Web Console feedback repository.

Scan Apex for performance antipatterns with ApexGuru

Ask your coding agent to check Apex for performance issues with the scan_apex_class_for_antipatterns tool from ApexGuru in the Salesforce DX MCP Server. The tool works in Agentforce Vibes, Claude Code, Cursor, and other MCP clients. Turn it on with the scale-products toolset.

{
  "servers": {
    "Salesforce DX": {
      "command": "npx",
      "args": ["-y", "@salesforce/mcp", "--orgs", "DEFAULT_TARGET_ORG", "--toolsets", "scale-products"]
    }
  }
}

ApexGuru also finds exact and near-duplicate Apex code, ranked by how many characters you can remove. From Setup, open Scale Center, go to Scale Insights, and click ApexGuru Insights to review the Code Duplicates recommendations. ApexGuru runs in production and Full Copy sandbox orgs, and it’s included at no extra cost for Unlimited Edition, Signature Success Plan, and Scale Test customers.

Keep Agentforce Vibes requests in your org’s region

Route Agentforce Vibes AI requests to the model endpoint closest to your Salesforce org, instead of to the United States by default. When geo-aware routing is on, the model picker shows only the models available in your org’s region. To turn it on, from Setup, enter Agentforce Vibes Extension in the Quick Find box, and turn on Enable Geo-Aware Routing for this Org. Data 360 must be turned on first.

Scratch orgs don’t inherit this setting, so add it to your scratch org definition file.

{
  "settings": {
    "agentforceForDevelopersSettings": {
      "agentforceForDevelopersGeoAwareOptIn": true
    }
  }
}

By default, a request falls back to the United States when no model is available in your region. To return an error instead, in Einstein Setup, turn on Enable In-Region Model Request Only. This setting doesn’t yet apply to Anthropic and Gemini models.

Conclusion

Winter ’27 is the release that makes Salesforce truly headless. Every major capability, including data, automation, grounding, and agents, is now reachable from a CLI, an API, your IDE, or an autonomous AI agent, with security enforced by default. With the Headless Experience Layer, the UI you build once rendered in Lightning Experience, ChatGPT, Claude, and Slackbot.

The best way to get ready is to spin up a sandbox, scratch org or a Developer edition org and try these features before they reach production. Have questions, or want to share what you’re building? Join the conversation in the Salesforce Developers Trailblazer Community, or connect with us on the Salesforce Developers channels.

More Winter ’27 learning resources

• Read the official release notes
• Join the Salesforce Developers Trailblazer Community group to connect with the global developer community
• Join the Release Readiness Trailblazers Community group to get early access to release information and discuss changes with other developers

About the author

Mohith Shrivastava is a Principal Developer Advocate at Salesforce with 15 years of experience building enterprise-scale products on the Salesforce Platform. Mohith is currently among the lead contributors on Salesforce Stack Exchange, a developer forum where Salesforce Developers can ask questions and share knowledge. You can follow him on LinkedIn.

The post The Salesforce Developer’s Guide to the Winter ’27 Release appeared first on Salesforce Developers Blog.

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/04_architecturalPatterns/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.