This is all made possible with Salesforce Hosted MCP Servers connected to Slackbot, your AI teammate built right into Slack. It’s the engagement layer where your teams, your AI agents, and everything you’ve built across the Salesforce ecosystem work together in one place.

In this post, we’ll explore why Slack is the best conversational interface for Salesforce, how Salesforce Hosted MCP Servers work within it, how to connect them with Slackbot, and what becomes possible when the Salesforce Platform meets the work operating system where your organization runs.

Slack: The engagement layer for the agentic enterprise

Slack is the work OS: a shared surface where the people, agents, and data that power your organization come together to move work forward. Through natively-built-in Salesforce Platform features and connected MCP servers, it’s where the full Salesforce ecosystem — Agentforce 360, Data 360, Tableau — becomes accessible through natural conversation, right where teams are already collaborating.

The screenshot below shows a Salesforce records list and Tableau insights inside of Slack’s desktop app, and the related conversation between a user and Slackbot on the Slack mobile app.

At the center of that experience is Slackbot: a single AI interface to every conversation, file, channel, and app across your organization. What Slackbot surfaces can be shared, discussed, and acted on by the whole team. And because Slackbot can synthesize your data with the conversations plus your connected tools, it can take the context that builds as you work with your team in Slack and bring it back into your records simply as a natural byproduct of work.

That’s what makes Slack uniquely powerful. And because your full business context is now available via MCP to the Slackbot MCP client, tools that once worked in parallel can finally work together, all through a single conversation.

Salesforce Hosted MCP Servers: A quick refresher

Model Context Protocol (MCP) is an open standard that lets AI agents interact with external tools and data sources from various vendors. Salesforce Hosted MCP Servers are our generally available implementation of this standard, giving any MCP-compatible client secure, governed access to run queries, modify records, and execute actions directly from their Salesforce org, without requiring a separate login or custom integration code.

Salesforce has shipped a set of standard hosted MCP servers out of the box: Salesforce servers, Tableau, and Data 360. Beyond the standard servers, developers can expose their own org’s capabilities by building custom MCP servers with tools — Apex actions, Lightning Flows, Apex REST endpoints, APIs from the API Catalog, Prompt Builder templates, and Agentforce agents — without writing new integration code.

For a deeper dive on Salesforce Hosted MCP Servers themselves, check out the Salesforce Hosted MCP Servers documentation.

Configuring Slack to work with Salesforce Hosted MCP Servers

Setting up Slackbot to work with Salesforce Hosted MCP Servers is simple; no URLs to copy, no OAuth configurations to wire up manually, no custom code required. The entire setup lives in the Slack Admin UI and takes just a few steps.

Prerequisites

Before getting started, you’ll need:

• A paid Slack plan (Business+, Enterprise Select, Enterprise Grid, or Enterprise+) with access to Slackbot and Salesforce
• At least one Salesforce org already connected to Slack
• Workspace Owner/Admin or Org Owner/Admin access
• Salesforce Administrator access to the connected org
• One or more active Salesforce Hosted MCP servers

If you haven’t connected Salesforce to Slack yet, follow the steps in the Connect Salesforce and Slack help article first. Once that connection is in place, user authentication is handled automatically. Slackbot uses your existing Slack-Salesforce account mapping, so members don’t need a separate login.

Note: Don’t have a Slack workspace yet? Creating one is simple: follow these steps to get started.

Step 1: Open MCP server settings

The path to MCP server configuration depends on your plan:

For Business+ and Enterprise Select:

Admin → Workspace settings → Salesforce → Salesforce MCP Servers

For Enterprise Grid and Enterprise+:

Organization name → Tools & settings → Organization settings → Salesforce → MCP Servers

Step 2: Add a Salesforce Hosted MCP Server

1. Click Add MCP Server
2. Choose the server you want to add from the list of active Salesforce Hosted MCP Servers (e.g., SObject All, Data 360, custom servers)
   
3. Click Add, then review the tools the server exposes
4. Click Next

If you’re on Enterprise Grid or Enterprise+, you’ll also select which workspaces the server will be available in before proceeding.

Step 3: Configure access

1. Choose who in your organization can use this MCP server via Slackbot:
   • Everyone: All members with access to Slackbot
   • Specific people and group: Fine-grained control by team or individual
   • No one: Install now, enable access later
     
2. Click Connect to finish.

The MCP server is now active and Slackbot can use it on behalf of anyone with access.

How Salesforce permissions apply to Slackbot MCP calls

Salesforce MCP servers in Slackbot are permission-aware by design. Every action Slackbot takes respects the standard Salesforce security model: field-level security, object permissions, and sharing rules are enforced per user, per request. Users only see and act on what they’re allowed to in Salesforce. Slack admins can adjust access, update permissions, or remove a server entirely from the Slack organization admin UI at any time.

Security is also handled at the Slack user level with prompts to prevent accidental use of MCP tools. The screenshot below shows Slackbot prompting the user to confirm if it can use the CreateAccountSyncMeetingTask custom MCP tool.

Slackbot and Salesforce Hosted MCP Servers in action

Once your MCP servers are configured, every member of your team authenticated across Slack and Salesforce gains natural language access to your Salesforce org based on their permissions — directly in the place where they’re already working. Here’s what that can look like in practice. We’ll use Northern Trail Outfitters (a fictitious outdoors gear vendor) for the following examples.

Triggering a custom business process

A Northern Trail Outfitters sales rep has a call in an hour with one of their customers, Alpine Trekkers. Instead of opening Salesforce, navigating to the Account page, cross-referencing the opportunities and cases to prepare for the call, they just ask Slackbot:

“Run a health check on the Alpine Trekkers account”

Slackbot uses a tool from the standard SObject All MCP server to identify the account based on its name. It then calls the custom health check flow tool. The flow retrieves additional data from related cases, opportunities and activities to calculate a health score thanks to precise business rules.

The health check indicates that the account is at risk because of an unresolved critical support case.

Prepping for a sales call

Once the sales rep reviews the Alpine Trekkers’ account health, they ask Slackbot to help plan for the customer meeting. Slackbot uses another custom tool to identify the meeting stakeholders (thanks to the Salesforce contacts related to the account) and logs the right information to prepare for the meeting. In the screenshot below, Slackbot calls a custom MCP tool that creates a task to set up an account sync meeting.

Pipeline analysis with live Tableau data

Thanks to Slackbot’s help with the preparation, the customer meeting goes well and their concerns are addressed. The Alpine Trekkers account is no longer at risk.

The Northern Trail Outfitters sales manager wants a current read on Q2 pipeline health. Rather than pulling up a Tableau dashboard separately, they ask directly Slackbot:

“What does Tableau show for Q2 pipeline conversion rates by region?”

With the Tableau MCP server connected, Slackbot queries the semantic layer — respecting row-level security — and returns a trusted, governed answer with visualizations, grounded in actual business metrics. The sales rep can share those insights with the team and hit the ground running, and the conversation about what to do happens right there, next to the data.

Conclusion

This concludes our tour of how to connect Slackbot to Salesforce Hosted MCP servers. You saw why Slack is the engagement layer for the agentic enterprise and how Salesforce Hosted MCP servers let you run your business with agents thanks to Headless 360. We took a look at how to configure Slackbot to work with Salesforce Hosted MCP servers and saw practical examples of its benefits.

It’s now your turn to connect Slackbot to your Salesforce org. Start with the Connect Slackbot to Salesforce with MCP help article for the full setup guide.

Resources

• Documentation: Connect Salesforce and Slack
• Documentation: Connect Slackbot to Salesforce with MCP
• Documentation: Salesforce Hosted MCP Servers

About the authors

Ashley Mao is a Senior Product Marketing Manager at Salesforce, where she leads product launches across Salesforce and Slack. She enjoys exploring what it means to work alongside agents as teammates, and what’s possible when data and dialogue come together.

Philippe Ozil is a Principal Developer Advocate at Salesforce, where he focuses on the Salesforce Platform. He writes technical content and speaks frequently at conferences. He is a full-stack developer and enjoys working with APIs, DevOps, robotics, and VR projects. Follow him on X, LinkedIn, and Bluesky, and check out his GitHub projects.

The post Connect Slack to Salesforce with Hosted MCP Servers appeared first on Salesforce Developers Blog.

Today, we’re taking the next big step on that journey. The Salesforce Headless 360 MCP Server is now available in Beta starting in early July. It builds on the hosted MCP servers that we made generally available in April, and it’s one surface that brings Salesforce to your MCP clients.

In this blog post, we’ll walk you through what’s new and how to get started with the Headless 360 MCP Server (Beta).

Use only four tools, not four thousand

When we were designing the Headless 360 Server, we needed to come up with a way to bring the thousands of features that Salesforce has built to MCP clients. If we exposed each feature as a distinct MCP tool, a model would have to reason over thousands of tool descriptions and pick the right one. The risk there is that the model would burn a huge amount of context, tokens, and time before it could take action. It’s also a scale problem that gets harder as we add more features and more APIs in the future. 

So, the Headless 360 Server takes a different shape. It presents an agent with four tools, not thousands. Behind these tools we’ve put a continuously growing library of skills. The agent’s surface stays small and stable, and the action surface scales independently.

Explore the new tools: Discover, Describe, Dispatch, and Dispatch Read Only

The four tools in our Headless 360 Server map to how an agent moves through a request.

• Discover: Takes the agent’s interpretation of what you asked for and runs a semantic search across a vector index of every API and skill we’ve generated. It returns a ranked set of candidates, so agents spend less time and call fewer MCP tools trying to find what they need.
• Describe: Pulls back the technical contract for a skill with APIs, parameters, dependencies, and the ordered steps. This tool helps an agent verify that the Discover tool is serving helpful results and details the steps an agent needs to take.
• Dispatch: Invokes the chosen skill. It routes to the right endpoint and enforces the user access guards before anything runs.
• Dispatch Read Only: Runs read-only dispatch actions

You could ask your agent to “Plan an integration that sends events to AWS when Account records change.” Your agent can propose and build an integration, saving you the time you’d otherwise spend clicking through three Setup screens to configure Change Data Capture, a named credential, and the event relay.

In this example, an MCP client will start by using the Discover tool to find the relevant skills for Change Data Capture, Named Credentials, and Event Relay. 

Once it’s found them, it’ll use the Describe tool to inspect the API calls it needs to make and the order in which they need to happen. In order to create an event relay, the agent needs to start by creating a named credential. 

Finally, once the agent knows what API calls need to be made, it executes those calls with the Dispatch tool. Of course, this same pattern extends beyond the work developers and admins do to the work that business users take on across Salesforce’s products.

Guardrails for MCP clients

Agents are powerful, and it’s worth talking about the guardrails that are in place today to make sure your MCP clients keep out of trouble. This matters for business users on the Headless 360 MCP Server, and it matters more for admins and developers. Every Salesforce Hosted MCP transaction runs as the authenticated user, scoped through an external client app with the mcp_api scope. CRUD, FLS, sharing rules, profile permissions, and permission sets all apply. If you can’t do it in Salesforce, your agent can’t do it through the MCP server. The audit trail attributes actions to you.

On top of the gating Salesforce that enforces, most MCP clients also allow you to set tool-level restrictions. If you want to verify the actions that your agent will take on your behalf, you can set your tool-level permissions to have the agent ask for your approval each time it runs a tool. This matters most for admins and developers, who carry wide-ranging permissions in their orgs and should be careful about the changes they and their agents take. As always, follow the best practice of making configuration changes in sandboxes and developer orgs before you take them to production.

Up-skilling agents with thousands of new skills

We’re launching this Beta with roughly 100 skills that will sit behind our MCP server. We’re also creating thousands of new skills that sit behind the Headless 360 MCP Server. 

At launch, the majority of these skills will be focused on Setup operations for admins, extending the kind of capabilities in Agentforce for Setup to headless MCP clients. During the Beta, the Headless 360 MCP Server will grow to encompass cloud-specific skills that represent the breadth of what business users can do with Salesforce, too. 

A few of the high-traffic tasks that your agent can handle in July include:

• Managing users: Create, deactivate, freeze and unfreeze, reset or set passwords, assign permission sets and permission set licenses, this includes the full surface that a builder reaches for on the User detail page
• Managing Apex triggers: Read, write, and deploy Apex triggers
• Building event-driven integrations: Define platform events, manage Change Data Capture, and manage event relays
• Creating named credentials: Designate auth mechanisms, endpoints, and certificate handling

Unsurprisingly, there’s a lot of AI being used to generate the skills that back our Headless 360 MCP Server. As part of this project, we created an internal tool called the Headless 360 Factory that scans Salesforce Setup, identifies features that are missing API access, and then generates APIs and skills that agents can use via our MCP server. Feature teams across Salesforce are reviewing these skills now and bringing their own to make sure that all of Salesforce is represented in one MCP server.

Join the Beta

To join the Beta, go to Salesforce Setup, find the Salesforce Hosted MCP Servers section, look for Headless 360 in the list, and click Activate. We also want your feedback on this server.  Post questions, issues, and comments in our github repo for Salesforce Hosted MCP Servers.

Resources

• Salesforce Hosted MCP Servers Developer Guide
• Salesforce Hosted MCP Servers GA Announcement
• Salesforce Hosted MCP Servers Github Repo

About the author

Tyson Read is a Senior Director of Product Management at Salesforce. He works on MCP and event-driven integrations.

The post Announcing the Headless 360 MCP Server Beta appeared first on Salesforce Developers Blog.

Starting July 2026, we’re introducing a single, unified reference page for the core Connect REST API and other related API families, including Agentforce, Chatter, Chatter Feeds, CMS, Commerce, Experience Cloud, Files and Folders, and Personalization. 

In this post, we’ll walk through what’s new, the benefits you’ll notice right away, and a few things that work differently than before.

The old way: Disconnected pages

In the previous documentation, the left navigation was a long tree of links, and you chose your API version from a dropdown at the top. Understanding one endpoint required you to assemble the picture from several disconnected pages. And for many people, that meant lots of open browser tabs.

Request and response bodies were documented on standalone pages, separate from the resources that actually used them.

The new Connect REST API reference: One page, three columns

The new API reference brings everything together on a single page with a three-column layout. The left column lists only resources. The center column shows the selected resource. The right column shows request and response examples. Many elements are clickable, so you can expand and collapse details. You can drill down exactly as far as you need into complex objects without ever losing your spot.

Key improvements

We rebuilt the reference around the way developers actually work. Here’s what stands out:

• Everything in context: The request you send and the response you get back now sit right beside the resource that uses them.
• Extensive examples: The right-hand column shows request and response examples for the operation you’re viewing.
• Searchability: You can use the search box in the left nav to filter down the number of endpoints. You can also use your browser’s Find command to locate any piece of text in the whole API reference and highlight every match at once.

Built on OpenAPI

The reference now follows the OpenAPI Specification (OAS), the industry standard for describing REST APIs. Beyond cleaner, more consistent structure, the move to OAS lets us improve the accuracy of the reference itself. And because it’s a standard spec, you can download it directly and use it with AI agents or code generation workflows. Each API family’s reference includes a Download button for grabbing its OpenAPI specification.

Versions throughout

We’ve also retired the per-version snapshots and the version dropdown. In their place is a single, evergreen reference that’s always current. Version information now lives in-line, throughout the page. For each resource and object, you’ll see an Available in note, so that you no longer have to pick a version up front just to find out when something shipped.

What works differently

A redesign this big changes a few habits. Here’s what to know about the new experience.

To copy a full endpoint path, click it. Click any operation’s path and a popup appears with the complete request URL, ready to copy and paste.

Field types can include a pattern. Some fields show a regular-expression pattern that describes the values they accept. For example, you might see ^(00T|00U)\w*. Reading it left to right: ^ means the value starts here, (00T|00U) means it begins with either 00T or 00U, and \w* means any letters, numbers, or underscores follow. In plain terms, that’s a Salesforce ID that must start with the key prefix 00T or 00U.

You can’t deep-link to a request or response body anymore. Because request and response bodies are no longer separate pages, you can’t link directly to one. Link to the operation instead, and the body appears right there alongside it.

Navigation. To choose a new API family, click All Reference or the Reference tab.

Conclusion

The new Connect REST API Developer Guide lets you discover the details faster with less context switching. Try it out and let us know what would make it even more helpful by clicking the Share your feedback button at the bottom of the page.

Resources

• Connect REST API Developer Guide
• The OpenAPI Specification

About the authors

Richard Sexton is a Technical Writer at Salesforce specializing in developer docs. Follow him on LinkedIn.

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

The post Introducing a New Connect REST API Experience appeared first on Salesforce Developers Blog.

The good news is that there’s now a better way to troubleshoot such scenarios with Deployment Insights. This new feature in Scale Center automates post-release validation by unifying release events with platform metrics to deterministically isolate performance regressions from ambient traffic noise. 

In this blog post, we’ll walk you through how this telemetry engine functions and how to integrate it into your deployment runbooks to proactively catch stability issues before they impact your SLAs.

The post-deployment blind spot

Upon initiating a metadata deployment within a high-scale environment, conventional observability frameworks often struggle to address three critical architectural challenges:

• Fragmented telemetry correlation: Validating systemic health demands intensive manual effort to bridge siloed metrics, where end user EPT, application server cycles, and Apex resource exhaustion signals remain isolated across disparate logs.
• The deterministic baseline challenge: Quantifying release-driven degradation requires comparing post-deployment performance against an equivalent peak-load window. Identifying a historical interval that precisely mirrors current traffic volume and utilization patterns is historically tedious and prone to error.
• Latent architectural regressions: Inefficiencies, such as a non-selective query embedded in new trigger logic, frequently escape detection in staging. These silent performance shifts only surface as critical bottlenecks when production traffic reaches peak utilization.

Deployment Insights eliminates this operational blind spot by unifying release events with Scale Center’s automated telemetry engine, delivering deterministic comparisons to identify exactly how code modifications impact environment stability.

Navigation and interpretation of the Deployment Insight Report

To generate a Deployment Insights Report, follow the steps below.

1. Navigate to the Setup Menu in Scale Center.
2. Go to the Deployment Insights section.
3. Select a specific deployment.
4. Click the Generate Insights Report button to view the report for that deployment.

Once generated, the report moves from high-level operational signals down to granular, actionable component details.

Delta analysis and top-line telemetry

The top of the report delivers an automated delta summary, highlighting immediate efficiency shifts. Instead of looking at raw numbers, it provides percentage-based variances for foundational enterprise metrics. Sections include:

• Change in Errors Before and After Deployment 
  • This section provides visualization for the anomaly in the errors related to Rowlock timeouts, such as concurrent errors, connection pool errors, or callouts, that may have started to increase or decrease post deployment

• Change in Performance Before and After Deployment 
  • Average SOAP and REST API Request Time: This metric provides degradation in the performance of the REST API and SOAP API-based requests getting invoked from external integration syncs
  • App CPU vs. DB CPU Per Request: This metric instantly reveals if your application custom code has started to use more application server cycles (e.g., massive loops, inefficient JSON parsing) or stalling on database execution (e.g., non-selective queries post deployment
  • User Experience (EPT): This metric surfaces the overall experience from the response time of UI-based requests that matters most to the end user experience

Each section provides self-explanatory takeaways for interpretation. The goal here is to provide a unified view of the data, so it’s easier to quickly identify whether or not a release deployment has actually created an issue in the first place.

Specialized diagnostic deep-dives

The Deployment Insights Report doesn’t stop at highlighting whether or not there was a problem, but it also identifies where the problem started post deployment and what actions can be taken up by the users to remediate those errors. 

Beneath the top-line metrics are four dedicated tabs built for rapid, targeted triage: Errors, User Experience, API Performance, and Infrastructure Performance.

To identify a regression in any of the metrics shown, click on the checkbox Display numerical change from before to after deployment present in each of the tabular data.

Here is the tabular representation of each of these sections and the data that it provides for remediation. For each section, it clearly outlines the recommended fix on the entry point.

Under the hood: The telemetry engine architecture

Lets now understand the details of how we built the Deployment Insights Telemetry system.

The system doesn’t just display linear historical trends; it builds a deterministic comparison model. The platform operates on an asynchronous pipeline that balances the Scale Center UI with backend system-level services to compute performance deltas without adding any runtime overhead to your production instance.

Here is how the system orchestrates this process behind the scenes:

Deployment Telemetry Processing Flow

Behind the scenes, the telemetry engine orchestrates a coordinated, four-step lifecycle to deliver deterministic performance insights:

1. Deployment Identification: The engine catalogs metadata and managed-package events from a 25-day rolling window, establishing a comprehensive chronology of environment modifications.
2. Sliding Window Calculation: Upon report initiation, a backend heuristic scrutinizes historical load patterns. It performs a four-day retrospective to establish a pre-deployment peak hour baseline, aligning it against a verified post-deployment peak traffic hour derived from up to a three-day forward-looking analysis.
3. Telemetry Aggregation & Normalization: The system harvests high-fidelity metrics from across the infrastructure layers, specifically isolating fluctuations in app CPU, database execution, EPT, and platform concurrency limits.
4. Signal Isolation: By correlating synchronized high-utilization windows, the engine filters out ambient traffic noise to spotlight architectural regressions driven solely by code changes.

Architect’s tip: The Peak Hour Principle

Modern enterprise architectures are notoriously complex, generating vast oceans of telemetry. Effective validation requires analyzing performance during high-stakes business windows, where peak system load intersects with critical server-side behaviors. To address this, the engine intelligently identifies these specific peak hours, automating performance comparisons across high-utilization intervals to distinguish genuine production regressions from an optimized baseline.

System requirements, considerations, and noise isolation

To get the most out of Deployment Insights, architects must keep a few system behaviors and boundary conditions in mind:

• Supported deployment types: The engine can track metadata changes across all standard delivery mechanisms, whether your pipeline pushes changes programmatically (via the Salesforce CLI or direct Metadata API calls), promotes work items through DevOps Center, uses native change sets, or installs unlocked packages. 
• Minimum traffic thresholds: Because the engine relies on the Peak Hour Principle, the target organization must maintain a baseline of active production traffic. In ultra-low volume orgs’ full copy sandboxes with sporadic usage, the sliding window heuristic may struggle to isolate clear peak-hour baselines.
• Isolating environmental noise: If multiple decoupled teams deploy changes within the same deployment window, or if a seasonal traffic surge (like a scheduled marketing blast) occurs simultaneously, results can become ambiguous. In these scenarios, use the Infrastructure tab to isolate the specific entry points. If the DB CPU spike correlates to a specific Apex class modified in your deployment payload, it is a code regression. If the spike is uniformly distributed across unchanged legacy APIs, the shift is likely environmental noise.

Post-deployment runbook best practices

To shift your release cycle from reactive firefighting to automated validation, incorporate Deployment Insights directly into your production deployment runbooks using this checklist:

1. Establish a mandatory release gate: Add a Deployment Insights review as a standard checklist item for your deployment team, treating post-release performance validation with the same severity as your automated test runs.
2. Enforce the 24-Hour stabilization window: Do not generate the report immediately after a deployment finishes. Allow the production environment to run for 24 hours, so the telemetry engine can capture a true, representative peak-load business window.
3. Analyze percentage-based deltas: Generate the report and scan for color-coded deltas. Focus on any core metric (App CPU, DB CPU, or EPT) that exhibits a regression greater than 15% from the pre-deployment baseline.
4. Bypass manual log triage: If a regression is flagged, skip manually writing Event Log File queries. Use the report’s integrated diagnostic deep-links to pivot directly into a specialized investigation view (such as a Concurrent Apex Investigation), which will automatically load with the exact peak-hour timestamps pre-populated.

About the author

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

Ravi Raina is Director Product Management at Salesforce working on the Scalability Products portfolio.

The post Identify and Fix Performance Regressions Using Deployment Insights in Scale Center appeared first on Salesforce Developers Blog.

What if you could skip all of that and just describe what you want? In this post, we’ll walk through how the new Mobile Skills can accelerate your mobile app development, from initial project setup all the way through building real features and functionality.

Getting past the mobile learning curve

Most Salesforce Developers are comfortable with business logic. What trips them up is everything around it, including OAuth handshakes, SDK version mismatches, Xcode build settings, and Gradle configurations. Native mobile development involves significant infrastructure overhead that has nothing to do with the app’s actual purpose, and it can take days just to get a project into a state where real work can begin.

Mobile Skills take that entire bootstrapping phase off your plate. They generate a clean, modern project structure with authentication and SDK integration already wired up, so your first task is building a feature, not fighting a toolchain.

Built for developers who live in IDEs, not GUIs

Mobile Skills output standard source files organized the way a professional iOS or Android project should be. You get a real Xcode workspace or Android Studio project that you can read, refactor, and push to Git. The code is yours from the moment it’s generated.

Skills: How agents go from generic to useful

An Agent Skill is a packaged, reusable capability that an AI agent can invoke. Think of it as a well-documented function your AI assistant knows how to call, except instead of returning a string, it can scaffold a project, generate code, configure SDKs, or run commands on your behalf.

Each skill ships with:

• A clear contract — what it does, what inputs it expects, what it produces
• Domain knowledge — the patterns, APIs, and conventions for the task
• Executable instructions — so the agent can actually do the work, not just talk about it

Skills are how you turn a general-purpose AI into a domain expert. A generic LLM might know that the Salesforce Mobile SDK exists. A skill knows the right project template, the right dependencies, and exactly which boilerplate to generate for your org’s auth flow.

Introducing Mobile Skills

Mobile Skills give your AI agent everything it needs to build production-quality native mobile apps using Salesforce Mobile SDK, the same SDK that powers Salesforce mobile apps.

Here’s what the Mobile Skills are capable of today:

• Create a Mobile SDK app from scratch

Describe the app you want, for example “Build me a native iOS app for field reps with offline access to Accounts and Contacts”, and Mobile Skills scaffold a fresh Mobile SDK project, configured for your org, ready to run.

• Add Mobile SDK to an existing app

Already have an iOS or Android app? Mobile Skills can integrate Mobile SDK into your existing codebase without forcing you to start over. They handle dependencies, configuration, and the integration patterns that often trip people up.

• SmartStore sync

Configure encrypted, on-device storage with a single prompt. Mobile Skills know the soup definitions, indexing strategies, and query patterns that work, so there’s no more digging through docs to figure out what IndexSpec to use.

• Mobile sync

Set up bidirectional sync between your app and your org with the right sync targets, sync down/up policies, and conflict resolution, and do it all declaratively, from a prompt.

• Offline-first behavior

Tell your agent “this app needs to work offline” and Mobile Skills wire up the right combination of SmartStore + MobileSync, sets up appropriate cache policies, and handles the edge cases (for example, network transitions, failed syncs, and dirty records) that can take weeks to get right by hand.

• Authentication and login

Basic auth, OAuth flows, and login screens are all generated correctly the first time, following the secure patterns Salesforce recommends.

• Biometric authentication

Add Face ID, Touch ID, or Android biometrics to your app with a single instruction.  Mobile Skills handles the platform differences, the fallback flows, and the security best practices.

• Agentforce chat panel integration

Drop a fully-wired Agentforce chat experience into your mobile app. Your end users get an intelligent, contextual agent inside their app, configured to talk to your org, and you don’t have to read a single integration guide.

Getting started with Mobile Skills

Mobile Skills are part of forcedotcom/sf-skills, the open-source collection of Salesforce Agent Skills for platform development. The repository is public: you can browse it, fork it, contribute to it, and pull skills into whatever agentic tool you’re already using. Think of it as a growing catalog of things AI agents should know how to do on Salesforce.

Works wherever you work

Skills in this repository follow the open Agent Skills specification, which means they aren’t locked to a single tool. Mobile Skills work across surfaces, whether that’s Agentforce Vibes (available out of the box), Claude Code, Cursor, OpenCode, Codex, or any other agent that supports the spec. To install in a code agent, just run:
npx skills add https://github.com/forcedotcom/sf-skills --skill mobile-apps-create

How it works under the hood

/mobile-apps-create is the primary entry point — a lightweight orchestrator that lives in sf-skills. When you describe what you want to build (for example, “I need a Salesforce mobile app with offline sync”), the orchestrator determines which SDK family and platform you’re targeting, then routes your request to the appropriate individual skill that handles the actual work.

A real example

It starts with a single sentence. In Agentforce Vibes, describe the app that you want to build. In this example, I’m building an iOS app to manage a store inventory and sync the data back to Salesforce. 

Agentforce Vibes picks up the intent, activates Mobile Skills under the hood — handling Mobile SDK authentication, SmartStore for offline data, and MobileSync for bidirectional Salesforce sync — and starts generating the full app.

Within moments, the app is built and running in the iOS simulator. The first thing you see is the standard Salesforce OAuth login screen, secure, familiar, and fully functional. Mobile SDK handles the entire authentication flow, including token management, refresh, and session persistence. No custom auth code required.

After login, the app lands on a home screen with a clean product inventory dashboard. Counts, categories, and visual summaries are all pulled live from the Salesforce org. This isn’t a mockup; it’s real data flowing through MobileSync’s soup-to-cloud sync pipeline, displayed in a native SwiftUI interface.

Tapping into the Products tab reveals the full inventory list, with each item editable. You can add a new product, update a quantity, or change a description; every modification syncs back to Salesforce automatically. Even if the device goes offline, SmartStore caches changes locally and MobileSync pushes them upstream when connectivity returns.

But why stop at inventory management? Back in the Agentforce Vibes prompt, I went ahead and asked the agent to embed an Agentforce chat panel. Just like that, the app now includes a native Agentforce conversational interface right inside the app. The Agentforce SDK handles the agent connection, conversation threading, and action orchestration, all wired up from a single prompt.

Store Managers can use the Agentforce chat to ask questions like “Which products are low in stock?” or ask it to refill stock without ever leaving the app. It’s not just an app anymore; it’s an AI-powered mobile experience, built in minutes.

What’s Next

The Mobile Skills you see today are the foundation. We’re actively expanding the library to cover more SDK capabilities, more frameworks, and richer end-to-end app generation flows. If you’re building mobile apps on Salesforce, this is the moment to plug AI into your workflow, not as a typing assistant, but as a companion engineer who already knows the platform.

Your feedback matters! Try Mobile Skills, share your feedback, and tell us what to build next.

Resources:

• Explore sf-skills on GitHub
• Get Started with Agentforce
• Mobile SDK Developer Guide
• Mobile SDK GitHub repository

About the author

Shalini Jain is a Director of Product Management at Salesforce, where her primary focus lies in shaping the Mobile Platform Experience for developers through AI-driven innovation. Her current initiatives are heavily invested in enhancing developer productivity by bringing agentic AI capabilities directly into the mobile development workflow, as evidenced by the tools highlighted throughout this blog post. Furthermore, she is spearheading new features in Mobile SDK to further streamline and optimize how developers build, test, and ship mobile apps, with the ultimate goal of delivering a truly seamless and intuitive experience for all Salesforce mobile developers.

The post Build Native Mobile Apps Within Minutes Using Agent Skills appeared first on Salesforce Developers Blog.

Defining state in LWC with defineState

A state manager is a dedicated JavaScript module that encapsulates a related set of data (the “state”) and the actions that operate on it. You create one with the defineState function from @lwc/state, passing a setup function. The setup function’s first argument is an object of building blocks: atom, computed, and setAtom. defineState returns a factory; any arguments you pass when you call it flow through to your setup function after that object, so you can parameterize each instance:

• An atom is a reactive “atomic” value, which is essentially a wrapper around a piece of data that LWC can use to make components and other state managers reactive to changes in that data.
• A computed is a lazily-evaluated derivation that recalculates only when its dependencies change.
• setAtom is used whenever you need to modify state.

import { defineState } from '@lwc/state';

export const createCounter = defineState(({ atom, computed, setAtom }, initialCount = 0) => {
    const count = atom(initialCount);
    const doubled = computed([count], (countValue) => countValue * 2);


    const increment = () => setAtom(count, count.value + 1);


    return { count, doubled, increment };
});

Any component that references count or doubled in a reactive context is automatically re-rendered after increment runs. Computed values recompute lazily and only when their inputs change, and multiple setAtom calls in the same tick are batched into a single notification cycle, so you get reactivity without the re-render churn.

Sharing state across a component tree with fromContext

State managers go beyond a single component. You can create an instance at the top of a component tree and consume it in a descendant component below using fromContext, with no prop drilling, no event handling, and no pub/sub plumbing:

Example code for the top-level component that instantiates the state manager:

import createShopStateManager from 'c/shopState';

export default class App extends LightningElement {
    shopState = createShopStateManager();
}

Example of a descendant component that reads the same instance via LWC context:

import { LightningElement } from 'lwc';
import { fromContext } from '@lwc/state';
import createShopStateManager from 'x/shopState';

export default class Cart extends LightningElement {
    shopState = fromContext(createShopStateManager);

    get cartTotal() {
        return `$${this.shopState.value.cartTotal.toFixed(2)}`;
    }
}

Built-in state managers for Salesforce data

Salesforce ships a collection of state managers in the lightning namespace that expose Salesforce data and metadata through the Lightning Data Service. Each one presents a uniform shape:

status

• “unconfigured": The state manager doesn’t have sufficient configuration information to proceed
• “loading": The state manager is in the process of obtaining data
• “loaded": The state manager has loaded data and set the data property
• “error": There was an error loading the data. The error property contains additional information

data

When the state manager status property is “loaded", the data property is in a valid state, and can be used by consumers of the state manager. The form and structure of data depend on the specific state manager.

error

When the state manager status property is “error", the error property is in a valid state, and contains details of the specific error. If there’s a configuration error with the state manager itself, for example, missing or invalid parameters used in the factory function, error is usually a simple string. If the error is with the request or response, error can be a FetchResponse. However, error handling is complex. See Handle Errors in Lightning Data Service for a thorough explanation.

Available state managers expose record, objectInfo, layout, and related list data. Because state managers can be nested and wired together with computed, you can build sophisticated, fully reactive data waterfalls, for example: fetch a record to discover its record type, then fetch the matching layout, then fetch the full record using the layout’s fields.

Example of a component that consumes a lightning/stateManagerRecord:

import { LightningElement, api } from 'lwc';
import { getFieldValue } from 'lightning/uiRecordApi';
import createRecordStateManager from 'lightning/stateManagerRecord';
import ACCOUNT_NAME_FIELD from '@salesforce/schema/Account.Name';
import ACCOUNT_INDUSTRY_FIELD from '@salesforce/schema/Account.Industry';

export default class AccountCard extends LightningElement {
    _recordId;

    // The built-in state manager instance. Config takes the schema field refs;
    // recordId is supplied later via the @api setter.
    state = createRecordStateManager({
        fields: [ACCOUNT_NAME_FIELD, ACCOUNT_INDUSTRY_FIELD]
    });

    @api
    set recordId(id) {
        this._recordId = id;
        // Updaters live on the frozen outer shape, so go through .value.
        this.state.value.setRecordId(id);
    }
    get recordId() {
        return this._recordId;
    }

    get displayLabel() {
        const { status, data } = this.state.value;
        if (status !== 'loaded') return 'Loading…';
        const name = getFieldValue(data, ACCOUNT_NAME_FIELD) ?? 'Unknown';
        const industry = getFieldValue(data, ACCOUNT_INDUSTRY_FIELD) ?? '';
        return industry ? `${name} — ${industry}` : name;
    }
}

See state managers in action

State managers bring a modern, reactive data-flow pattern to LWC that scales from a single component to a full application. Because state managers are plain JavaScript modules with no DOM dependency, you can unit-test them with Jest without mounting a component. You can reuse the same state module across multiple component trees. And because consumers read values from the state manager’s public shape rather than reaching into its internals, you can refactor how state is stored without updating every consumer. Additionally, with the built-in UI API state managers, you get that same shape for Salesforce data out of the box. Note: state managers are available in Lightning Experience, but not yet supported in Experience Cloud.

To help you get started, we’ve published two complete examples in the forcedotcom/state-management GitHub repository:

• simple-store: A standalone shopping-cart application (demoed at TDX in March 2026) that shows how multiple components can read and mutate the same state manager entirely through context, with no properties or events. You can run it live on StackBlitz.
• platform-state-managers: A Salesforce DX project that builds a layout-driven record detail panel using the record and layout state managers. The source is heavily commented, and is the best place to learn the basics.

More resources

Ready to start managing your state? Here are additional resources you need to dive in:

• Developer Documentation: Manage State Across LWC Components
• GitHub repository (forcedotcom/state-management): Find the platform-state-managers and simple-store examples.
• Live playground (Simple Store on StackBlitz): Explore a full state-manager app in your browser.

About the Authors

Mike Burr is a Principal Member of Technical Staff at Salesforce from the Lightning Data Service team. When he’s not building client data libraries, he’s busy tweaking his home automation and listening to audiobooks.

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

The post LWC State Managers: Share Reactive State Across Components appeared first on Salesforce Developers Blog.

Whether you’re a developer building MCP servers or an admin managing them, understanding the security model helps you control who can access what, when, and how. In this post, we’ll cover authentication, authorization, permission controls, and logging best practices for Salesforce Hosted MCP Servers.

Understanding the Salesforce Hosted MCP Server security model

The Salesforce MCP security model has three layers:

1. Authentication: Verifies who’s making the request
2. Authorization: Determines what they’re allowed to do
3. Permission controls: Enforce granular access at the object and field level when working with the primitives (tools, prompts and resources) exposed by the server

And, in addition to these security layers, logging tracks all activity for audit and compliance.

The first two layers are directly linked to the MCP standard and the third (permission controls) is specific to the Salesforce Platform. Each security layer builds on the previous one. You can’t authorize someone until you know who they are. You can’t enforce permissions without authorization rules.

Understanding how these layers and logging work together helps you build a defense-in-depth strategy. Let’s look at each layer in detail.

Authentication: Verifying identity

Authentication is the first line of defense. It answers the question: “Who are you?”

Authentication and authorization are technically defined as optional for MCP implementations as per the MCP specification, but we will assume for the rest of this post that it’s mandatory in an enterprise context given that without proper security, unauthorized users could access sensitive data or trigger unwanted operations.

MCP specifies OAuth 2.0 as its authentication and authorization mechanism. It supports only a subset of OAuth 2.0 — not every authorization flow or grant type is available. Popular clients like Claude and ChatGPT support fewer flows than Salesforce does.

While MCP is fairly recent, OAuth 2.0 has been around for more than a decade and the Salesforce Platform has a number of mechanisms to integrate with OAuth, whether it acts as a client or a server. This means that, as a Salesforce Developer, you do not have to implement OAuth security. Instead, you control it declaratively through an external client app (ECA).

We strongly recommend creating a dedicated ECA per MCP client (one for Claude, one for ChatGPT, one for Cursor, etc.) rather than sharing a single ECA across multiple clients. This helps with controlling access and auditing the client’s activity.

When it comes to Salesforce Hosted MCP Servers, we only support the authorization code flow through the ECA. This means that users have to authenticate with Salesforce when connecting to the MCP server. Their individual Salesforce user account is tied to the MCP session.

Notes:

• There’s no option to specify a service account with a principal user, such as an integration user, to be used across all sessions. This is an anti-pattern that customers should avoid.
• At this time, there’s no plan to allow machine-to-machine flows. The human remains in the loop to connect to the org and grant access to the MCP tools.

By default, any user from your org can connect to your ECA and access the MCP servers. However, you can specify authorization rules to control the access.

Authorization: Controlling access

Authorization tells you what the user can do. Once a user is authenticated, Salesforce evaluates their permissions to determine which resource they can access.

There are a number of mechanisms that you can put in place to control authorization.

Authorize access with OAuth scopes

The first level of authorization to access specific resources is handled by OAuth scopes when configuring an ECA.

The new “Access Salesforce hosted MCP servers (mcp_api)” scope grants access to Salesforce Hosted MCP Servers. We’ve released this scope to avoid exposing the “Manage user data via APIs (api)” scope that grants full access to the Platform APIs (REST, Tooling, Metadata, etc.).

As a general rule, it’s preferable to only expose a limited set of “safe” operations to agents via MCP rather than to allow full API access.

Restrict access to pre-authorized users

With the default ECA configuration, all users from your org can authenticate and access the MCP servers. You can restrict access to specific pre-authorized users by configuring an app policy. This lets you select users with specific profiles or permission sets.

For example, this configuration only allow users with the “MCP Client User” permission set to connect to the ECA:

Enforce IP restrictions

In addition to restricting the use of the ECA to specific users, you can apply IP restrictions by only specifying IP ranges to connect. These restrictions are enabled in the default ECA configuration under App Authorization.

You can specify trusted IP ranges for all users in the Network Access setup menu or for specific user profiles.

Shorten refresh token lifetime

Once a user logs in with the ECA, they acquire an access token that is passed to all subsequent MCP operations. The token must be refreshed after its lifetime expires.

The default token lasts for a year, but you can control the duration of the token lifetime and reduce it in production. You can do this to limit the risk of token theft and reuse for malicious intents. To control the token lifetime, go in the ECA configuration and look for Refresh Token Policy under App Authorization. Our documentation includes recommendations on how to improve security in this area.

Revoke access

Should you need to revoke tokens for your ECA before they expire, go to Setup, search for OAuth Usage, select your ECA, and revoke individual tokens or run a bulk revoke operation.

Activate MCP servers

By default, all MCP servers are inactive. Only activate the ones that you intend to expose to agents.

For example, here we’ve only activated a custom server and two standard servers:

Annotate MCP tools

While not strictly a security measure, it’s a best practice to annotate MCP tools that you expose to provide hints about their behavior. Doing so lets agents know how they should use the tools. For example, should the agent ask the user for confirmation when running potentially destructive operations, such as deleting a record, or whether a tool can safely be run multiple times.

Note: Support for MCP tool annotations is optional on the client side and these may not be enforced by all agents.

Permission controls: Granular access management

You cannot restrict access to a specific MCP server through the ECA configuration, but you control access to the tools that compose those servers.

MCP tools run with the same permissions as the user who authenticated with the ECA. This means that our core security model applies at all levels:

• Object-level access (CRUD permissions)
• Field-level security (FLS) restrictions
• Record sharing rules

It’s also possible to implement custom tools with Agentforce, Apex, or Flow to address unique security requirements. If you choose this path, always follow security best practices.

Be sure to work with permission sets to protect sensitive operations and follow the principle of least privilege. Grant only the permissions that users need to do their jobs. Review permissions regularly and remove access that’s no longer required.

Also, test permissions before deploying to production. For example, run Apex tests and Flow tests on your MCP tools with the runAs method to simulate the behavior of users with different access levels.

Logging: Tracking access

Logging creates an audit trail of who accessed what and when. This is essential for security monitoring, compliance, and troubleshooting.

All actions that are performed by the MCP tools are attributed to the user that connected to the ECA in audit trails. Salesforce automatically logs MCP server activity using Event Monitoring.

To access the logs, navigate to Setup and search for Event Log File Browser. Filter Event Type on “API Total Usage”. You can identify MCP traffic by filtering the event log CSV files for rows where the API_CLIENT_CATEGORY column matches SALESFORCE_HOSTED_MCP. You’ll see the users that called the MCP tools and the affected objects (entities) among other details.

Review logs regularly. Look for errors thanks to STATUS_CODE or unexpected access patterns with USER_NAME or CLIENT_IP. These can indicate security issues or misconfigured permissions.

Conclusion

In this post, we’ve reviewed how to secure Salesforce Hosted MCP Servers, and we’ve covered all of the components that form this layered security architecture, including:

• Authentication verifies identity
• Authorization controls what tools users can access
• Permission controls enforce granular data access
• Logging creates an audit trail for compliance and security monitoring

It’s now up to you to implement these security best practices and protect your data while shipping powerful MCP tools that agents can use.

Resources

• Documentation: Salesforce Hosted MCP Servers
• Documentation: Manage MCP Servers in API Catalog
• Documentation: External Client Apps
• Documentation: Permission Sets
• GitHub: Community Wiki

About the author

Philippe Ozil is a Principal Developer Advocate at Salesforce, where he focuses on the Salesforce Platform. He writes technical content and speaks frequently at conferences. He is a full-stack developer and enjoys working with APIs, DevOps, robotics, and VR projects. Follow him on X, LinkedIn, and Bluesky, and check out his GitHub projects.

The post How to Secure Salesforce Hosted MCP Servers appeared first on Salesforce Developers Blog.

Whether adapting to regulatory shifts or launching new products, account teams can use BRP to implement fresh metrics in minutes, surfacing real-time, actionable insights for every client relationship manager. In addition, BRP supports organizational agility by shifting logic ownership from engineering tickets to a simpler admin configuration. Clear extension points enable developers to customize BRP further using Flow, Apex, or Lightning web components.

In this blog post, we’ll walk through the BRP architecture and the core data model. We’ll then demonstrate how admins can configure BRP , and how business users can set up and use the system. Finally, we’ll explore how to extend BRP using Apex business logic and document generation.

What Business Relationship Plan is (and why it matters)

Business Relationship Plan is the layer in Agentforce Financial Services that sits on top of the AccountPlan object in Salesforce. It gives organizations a structure for plan records, objectives, measures, and tasks, and it allows them to extend this model with Flow, Apex, and UI components.

At a high level, BRP connects:

• Plan: Account-level strategy record
• Objectives: Prioritized outcomes with owners
• Measures: Key performance indicators (KPIs) and targets
• Action Plan: Action items tied to objectives
• Visibility: Progress tracking across accounts

When we enable Einstein features, we can also add interaction summaries for better context before meetings.

Account Plans vs. BRP: What to use when

While Account Plans serve standard, linear management needs, Business Relationship Plan delivers a highly extensible architecture specifically engineered for sophisticated, multi-outcome strategies and deep platform integration.

Business Relationship Plan architecture at a glance

The architecture of Business Relationship Plan spans four layers: Data (Plan, Objective, Measure records), Experience (Lightning pages and Flexcards), Orchestration (Flow, Apex, Omniscript), and Insight (Einstein summaries and analytics). 

1.   Data layer: Plan, Objective, Measure, and Task records with standard and custom fields
2.   Experience layer: Lightning pages, Flexcards, and Strategic Tracker components
3.   Orchestration layer: Flow, Omniscript, and Apex automation
4.   Insight layer: Einstein summaries and dashboard analytics

The diagram below shows how data flows between BRP’s four layers and their components: the Data layer with sObjects, the Experience layer with Lightning components, the Orchestration layer with Flow and Apex, and the Insight layer with Einstein and dashboards.

BRP data model: Core objects and relationships

Business Relationship Plan offers a technical structure for Account Plan records, objectives, measures, and action plans, connecting client account goals directly to Financial Deal, Opportunities, Cases, and Contacts within the Salesforce data model.

Core objects

While each of the Account Plan entities contains numerous fields, we’ll focus here on the fundamental fields that are essential across all entities to help you understand the core data structure.

AccountPlan: The root planning object.

• Standard fields: Name, AccountId, Status, StartDate, EndDate
• Key relationships: Account (lookup), Owner (lookup)

AccountPlanObjectiveCategory: Categories for classifying objectives.

• Standard fields: Name, Description, StartDate, EndDate, IsActive

AccountPlanObjective: Strategic goals within a plan.

• Standard fields: Name, AccountPlanId, Priority, Status, Owner, StartDate, EndDate, Description
• Key relationships: AccountPlan (master-detail), Owner (lookup), AccountPlanObjCategory (lookup)

AccountPlanObjectiveMeasure: Quantifiable KPIs tracking objective progress.

• Standard fields: Name, AccountPlanObjectiveId, ValueType, TargetValue, CurrentValue
• Key relationships: AccountPlanObjective (master-detail), AccountPlanObjMeasCalcDef (lookup)

AccountPlanObjectiveMeasureRela: Links measures to related records.

• Standard fields: Name, AccountPlanObjectiveMeasureId, ReferenceRecordId
• Key relationships: AccountPlanObjectiveMeasure (master-detail), ReferenceRecord (multi-lookup to Opportunity, Financial Deal, Case, Contact, Campaign, etc.)

ActionPlan: Structured task-based execution plans.

• Standard fields: Name, ActionPlanType, StartDate, EndDate
• Key relationships: Target (multi-lookup)

ActionPlanItem: Individual tasks within an action plan.

• Standard fields: Name, ActionPlanId, IsRequired, DisplayOrder, DependencyStatus
• Key relationships: ActionPlan (master-detail), ActionPlanItem (multi-lookup)

Task: Action items tied to objectives.

• Standard fields: Subject, Status, Priority, Due Date, Assigned To
• Key relationships: What (lookup to Objective)

Sample SOQL query

The query below retrieves active plans with nested objectives and measures, which is useful for building custom dashboards.

SELECT Id, Name, Account.Name, Status, StartDate, EndDate,                                                                                                                                                                                                                                                                                                                                                                                
      (SELECT Id, Name, Priority, Status, Owner.Name,
          (SELECT Id, Name, TargetValue, CurrentValue                                                                                                                                                                                                                                                                                                                                                         
           FROM AccountPlanObjectiveMeasures)                                                                                                                                                                                                                                                                                                                                                                                               
       FROM AccountPlanObjectives                                                                                                                                                                                                                                                                                                                                                                                                           
       ORDER BY Priority, CreatedDate)                                                                                                                                                                                                                                                                                                                                                                                                      
  FROM AccountPlan                                                                                                                                                                                                                                                                                                                                                                                                                          
  WHERE Status = 'Active'                                                                                                                                                                                                                                                                                                                                                                                                                   
    AND Account.Industry = 'Banking'                                                                                                                                                                                                                                                                                                                                                                                                        
  ORDER BY StartDate DESC                                                                                                                                                                                                                                                                                                                                                                                                                   
  LIMIT 100

Calculation definitions in Business Relationship Plan

A Calculation Definition is a core configuration record in BRP that defines the logic for platform-led aggregations. It establishes a technical framework with three fundamental pillars:

• Target object: Identify the specific record type for data aggregation
• Target field: Specify the numeric or currency value to be rolled up
• Rollup type: Define the mathematical operation (Sum, Count, Min, or Max)

Furthermore, users can implement conditional logic to filter the underlying data set, ensuring that only qualifying records contribute to the final metric. Once this setup is complete, client relationship managers can leverage these definitions across multiple Account Plan measures without writing a single line of code.

Summary of roles

This collaborative framework ensures that while admins govern the formula, the platform manages the data, and users focus on results. That is the power of Calculation Definitions.

Let’s now take a look at the steps an admin would take to set up calculation definitions in Agentforce Financial Services. Once set up, we’ll then look at how a business user would use the system.

The admin experience: Configuring the engine

The initial setup phase creates a reusable asset for the entire organization. Once published, these definitions become standard options for all team members during measure creation. 

As an admin, you would follow these steps to configure BRP.

Step 1: Access configuration

Navigate to Setup -> Sales Account Plans and you will see the calculation definition section. You will see both out-of-the-box (OOTB) logic and custom configurations tailored to your specific business requirements.

Step 2: Define the data parameters

Click on New Calculation Definition and populate the following essential fields:

• Identity: Assign a Name and unique API Name for the definition
• Context: Provide a clear description, so end users understand what the metric represents
• Source: Select the Target Object (e.g., Financial Deal) and the corresponding Target Field
• Logic: Choose the Rollup Type; the platform automatically infers the data type from your field selection

Step 3: Implement conditional filters

Admins can apply up to five conditions to refine the calculation scope. For example, you might exclude records where the status is “Inactive” or filter by specific transaction thresholds to ensure metric accuracy.

Step 4: Lifecycle Management

New definitions begin in Draft mode for review. Transitioning to Active status locks the core configuration to prevent unintended changes to live metrics, ensuring consistency across quarterly planning cycles.

The business user experience: Operationalizing strategy

Once activated, these technical definitions are handed off to client relationship managers to drive daily business outcomes.

Business users would follow these steps:

Step 1: Establish the plan hierarchy

Users begin by creating an Account Plan and defining high-level Objectives, such as increasing portfolio retention or growing fee income.

Step 2: Link measures to logic

For each Objective, the user adds a measure. They define the name and target value, then select the appropriate calculation definition from the dropdown to assign the aggregation logic.

Step 3: Associate records 

The user manually associates relevant records (e.g., Financial Deals) using the AccountPlanObjectiveMeasureRela records. This flexible mapping allows single records to contribute to multiple plans without limit.

Step 4: Automate orchestration

The platform executes a nightly scheduled job that processes these associations, applies admin-defined conditions, and updates the Current Value field automatically, ensuring that fresh data is available every morning.

Architecting for performance: The daily cadence

Agentforce Financial Services utilizes a batch approach for these calculations to maintain optimal system performance. This design ensures that today’s updates to deals or record associations are consistently reflected in the next day’s planning metrics without creating unnecessary overhead.

Workflow example: Tracking Q3 deal revenue

Consider a scenario where a financial advisor tracks transaction revenue for a high-net-worth client.

Phase 1: Admin configuration

1. Admin creates an “Active Deal Transaction Value” definition targeting the Financial Deal object.
2. Logic is set to Sum the transaction field with a filter for active status.

Phase 2: Execution

1. Monday: The advisor sets up the Account Plan and links eight deals to a new measure.
2. Tuesday: The system reflects a $1.45M current value automatically.
3. Quarter-End: As new deals close and are associated, the platform tracks the revenue growth until the $2M goal is surpassed.

Extend Business Relationship Plan with Apex

For complex business logic, developers can use Apex to extend BRP functionality. This allows you to implement sophisticated patterns beyond Flow capabilities, such as a nightly scheduled job that computes weighted health scores (on a 0–100 scale) for objectives by analyzing progress from baseline to target. Such automation can programmatically refresh status labels like On Track, At Risk, or Off Track, while utilizing batchable Apex to maintain performance for large-scale deployments exceeding 2,000 records.

Prerequisites

Before implementing Apex extensions for BRP, ensure that your org meets these requirements:

• Salesforce Edition: Enterprise Edition or higher
• Financial Services Cloud license: Active FSC license
• Agentforce Financial Services: Enabled in org settings
• Permission sets: AccountPlan object permissions (Read, Create, Edit) assigned to users
• Omnistudio runtime: Enabled for Flexcards and Omniscript functionality
• Custom field access: Ability to create custom fields on AccountPlanObjective and AccountPlanObjectiveMeasure objects

The following example shows how to customize BRP to track objective health scores.

Example: Calculate objective health score

To prepare your organization for the Apex calculation, create these custom fields:

• On AccountPlanObjectiveMeasure:
  • BaselineValue__c (Text, 255): Stores the starting value for progress calculation
  • Weight__c (Number, 5,2): Defines the relative importance (weight) of the measure in the objective’s health score
• On AccountPlanObjective:
  • HealthScore__c (Number, 5,2): Stores the calculated weighted health score (0–100)
  • Status picklist update: To use the determineHealthStatus method, add the values On Track, At Risk, and Off Track to the AccountPlanObjective.Status picklist
• Crucial Data Note: Ensure that the ValueType field (Number, Currency, or Percent) is set on AccountPlanObjectiveMeasure records before TargetValue and CurrentValue can be persisted.

/**
 * Computes a weighted health score per Account Plan Objective from its measures,
 * then sets HealthScore__c and a text Status from score bands.
 */
public class BRPObjectiveHealthCalculator {

    /**
     * Loads objectives (and related measures), aggregates progress by weight,
     * and updates objectives that have at least one valid weighted measure.
     *
     * @param setOfObjectiveIds Ids of AccountPlanObjective records to recalculate; no-op if null/empty.
     */
    public static void calculateHealthScores(Set setOfObjectiveIds) {
        if (setOfObjectiveIds == null || setOfObjectiveIds.isEmpty()) {
            return;
        }

        // Child subquery: FROM clause must be the child relationship API name + __r (verify in object manager).
        List objectives = [
            SELECT Id, Name, HealthScore__c, Status,
                   (SELECT Id,
                           BaselineValue__c,
                           TargetValue,
                           CurrentValue,
                           Weight__c
                    FROM AccountPlanObjectiveMeasures)
            FROM AccountPlanObjective
            WHERE Id IN :setOfObjectiveIds
        ];

        // Only objectives we actually change are DML’d to avoid unnecessary updates/triggers.
        List objectivesToUpdate = new List();

        for (AccountPlanObjective obj : objectives) {
            // Running totals for weighted average of per-measure progress (0–100 each).
            Decimal weightedScore = 0;
            Decimal totalWeight = 0;

            for (AccountPlanObjectiveMeasure measure : obj.AccountPlanObjectiveMeasures) {
                if (isValidMeasure(measure)) {
                    Decimal progress = calculateProgress(measure);
                    // Null weight defaults to 1 so the measure still counts equally if unspecified.
                    Decimal weight = measure.Weight__c != null ? measure.Weight__c : 1;

                    weightedScore += progress * weight;
                    totalWeight += weight;
                }
            }

            // Skip update when no valid measures contributed weight (avoids divide-by-zero and blank scores).
            if (totalWeight > 0) {
                // Weighted average progress, expressed on a 0–100 scale for storage/display.
                obj.HealthScore__c = (weightedScore / totalWeight);
                obj.Status = determineHealthStatus(obj.HealthScore__c);
                objectivesToUpdate.add(obj);
            }
        }

        if (!objectivesToUpdate.isEmpty()) {
            update objectivesToUpdate;
        }
    }

    /**
     * A measure is included only when baseline, target, and current are all present,
     * so progress and comparisons are well-defined.
     */
    private static Boolean isValidMeasure(AccountPlanObjectiveMeasure measure) {
        return measure.BaselineValue__c != null
            && measure.TargetValue != null
            && measure.CurrentValue != null;
    }

    /**
     * Linear progress from baseline toward target, as a percentage (0–100).
     * Values are coerced with Decimal.valueOf in case the fields are numeric types other than Decimal.
     */
    private static Decimal calculateProgress(AccountPlanObjectiveMeasure measure) {
        Decimal baseline = Decimal.valueOf(measure.BaselineValue__c);
        Decimal target = Decimal.valueOf(measure.TargetValue);
        Decimal current = Decimal.valueOf(measure.CurrentValue);

        // Degenerate case: no movement defined; treat as fully achieved to avoid division by zero.
        if (target == baseline) {
            return 100;
        }

        // Raw % along the line from baseline to target; can exceed 0–100 before clamping.
        Decimal progress = ((current - baseline) / (target - baseline)) * 100;
        // Clamp so a single outlier measure cannot push the aggregate beyond 0–100 contribution.
        return Math.min(Math.max(progress, 0), 100);
    }

    /**
     * Maps stored score to a simple status label for reporting/UI.
     */
    private static String determineHealthStatus(Decimal score) {
        if (score >= 80) {
            return 'On Track';
        }
        if (score >= 60) {
            return 'At Risk';
        }
        return 'Off Track';
    }
}

Usage: Call this class from a scheduled Apex job to recalculate health scores nightly.

public class BRPHealthScoreScheduler implements Schedulable {
    public void execute(SchedulableContext ctx) {
       Set objectiveIds = new Set();
      
       for (AccountPlanObjective obj : [
           SELECT Id
           FROM AccountPlanObjective
           WHERE Status = 'In Progress'
           AND AccountPlan.Status = 'Active'
       ]) {
           objectiveIds.add(obj.Id);
       }
      
       if (!objectiveIds.isEmpty()) {
           BRPObjectiveHealthCalculator.calculateHealthScores(objectiveIds);
       }
    }
}

Schedule with: System.schedule('BRP Health Score Calculator', '0 0 2 * * ?', new BRPHealthScoreScheduler());.

Note: For orgs with more than 2,000 active objectives, refactor this into a Database.Batchable class with a batch size of 200. The calculateHealthScores method already accepts a Set<Id>, so the batchable execute() method can pass each batch directly.

global class ObjectiveHealthScoreBatch implements Database.Batchable {

    global Database.QueryLocator start(Database.BatchableContext bc) {
        return Database.getQueryLocator(
            'SELECT Id FROM AccountPlanObjective'
        );
    }

    global void execute(Database.BatchableContext bc, List scope) {
        Set objectiveIds = new Map<Id, SObject>(scope).keySet();
        calculateHealthScores(objectiveIds); // already accepts Set
    }

    global void finish(Database.BatchableContext bc) {
        // optional: send notification, log results
    }
}

Extend Business Relationship Plan with Document Generation

Salesforce Document Generation enables organizations to automatically create Word documents and PowerPoint presentations from Account Plan data. By placing the Summary Documents component on the Account Plan record page, developers can allow users to generate documents on-demand from pre-built templates with merge fields and conditional logic. Generated documents pull live data (objectives, measures, activities, related records) and are stored in Salesforce, where they can be:

• Exported: Download as native .docx/.pptx formats or convert to PDF
• Shared: Email as attachments or share via public/private links
• Printed: Download and print for client meetings or internal reviews
• Archived: Store for compliance and audit trails
  

This simple extension adds a lot of value and can be used for executive summaries, quarterly business reviews, and stakeholder presentations.

Best practices for developers

• Review existing OOTB capabilities first: Before building custom components, check available features like Flexcard Selector, Objectives Component, Action Plans, and Summary Documents for complete out-of-the-box functionality to avoid duplicate development
• Keep objective definitions specific and time-bound: Use validation rules to enforce date ranges and clear naming conventions
• Limit KPIs to meaningful indicators: Avoid measure proliferation; focus on three to five key measures per objective
• Build automation for repetitive tasks: Use Flow for measure reminders and status updates

Conclusion

When essential account data is static and siloed, annual account planning becomes more challenging and can easily fail.Business Relationship Plan gives financial services organizations a technical and operational model that they can run every week. With the right data model, UI, and automation, account teams can track goals in real time, act faster, and be more productive.

For developers, BRP provides a solid foundation with clear extension points. Whether you’re building Flow automation, Apex business logic, or custom LWC components, the platform supports continuous planning workflows that replace static annual planning cycles.

Resources

• Business Relationship Plan Overview
• Enable Business Relationship Plan
• Business Relationship Plan Setup Guide
• Add FlexCard Component
• Configure the Pre-Built Account Plan Lightning Page 
• Configure Fields Specific to BRP
• Manage User Access for BRP 
• Sales Account Plans Overview
• Account Plans Setup
• Strategic Tracker with Sales Action Plans 
• Einstein Summaries for BRP
• Salesforce Developers sample apps on GitHub

About the author

Vignesh Damodharan is a Lead Member of Technical Staff with Agentforce Financial Services, where he leads Salesforce engineering teams building enterprise products on the Salesforce Platform. Follow him on LinkedIn.

The post Build Continuous Planning Systems in Agentforce Financial Services appeared first on Salesforce Developers Blog.

Many Salesforce Developers want a repeatable, design-first lifecycle for agent development. The Headless 360 approach pairs a coding agent like Claude Code, Codex, or Agentforce Vibes with Agent Skills, so you can design, build, deploy, test, and debug from a single plain-language conversation. You stay the designer; the coding agent does the development. 

In this post, we’ll look at how to set up Salesforce Agent Skills, scaffold a project and connect an org, design before you build, generate your metadata, validate and test, and debug with traces. Everything we’ll discuss here works today through the open-source Salesforce Skills Library and the Salesforce CLI.

Teach your coding agent Salesforce with Agent Skills

Agent Skills are how your coding assistant learns Salesforce. A skill is a small bundle of instructions and commands that teaches the assistant a specific task, such as building an Apex class or a Lightning web component (LWC), building a flow, or developing Agentforce agents. Without skills, the assistant guesses. With them, it runs the right steps and necessary CLI commands or MCP tools and follows conventions.

You should install these skills either globally or within your project directory for any coding agents besides Agentforce Vibes, as the latter includes them by default. The Salesforce Skills Library ships dozens of skills covering Apex, LWC, Agentforce, Data 360, and metadata deployment. 

Three skills drive the agent lifecycle specifically:

• developing-agentforce: Design, build, deploy, debug (see docs)
• testing-agentforce: Test specs and batch runs (see docs)
• observing-agentforce: Inspect production traces from Data 360 (see docs)

Once installed, in most coding agents you should be able to type ‘/’ in your assistant to browse them. You’ll see a skill load by name as the assistant works, for example, developing-agentforce activates the moment you ask for an agent scaffold.

You’ll also need a few common tools on your machine first: Node.js and the Salesforce CLI. And here’s the best part — if something is missing, use your assistant to get help. And if the assistant has permissions, it can also install these for you.

To install Salesforce Agent Skills, run the below command from your terminal or ask your assistant to run the below command.

npx skills add forcedotcom/sf-skills

After executing the command, you will navigate through a few quick configuration choices. First, you’ll pick the specific skills from the library to equip your assistant. Then, designate your preferred coding agent and decide if these instructions should be available across all your projects or just for the current local directory.

Scaffold the project and connect your org

Every Salesforce project starts with a scaffold — a folder holding all your metadata as files. This is the same project structure you already pull into an integrated development environment (IDE) like VS Code. Your assistant works against those local files, then deploys them to an org.

Here’s the shift that matters. You no longer memorize CLI flags or look up command syntax. You describe what you want in plain language, and the coding agent runs the right Salesforce CLI command for you. The CLI does the actual work — the agent just knows which command to call and translates your words into it.

For example, scaffolding a project used to mean typing the exact command and its flags:

sf project generate --name agent-script-demo

Now, you simply describe the goal in plain language, and the agent runs that command for you:

“Create a Salesforce project scaffold named agent-script-demo”

Keep each project in its own folder, so the agent only touches what it should. From there, the same pattern repeats for every step. For example, when you ask it to set up your org, the agent checks the current default and sets your scratch org or sandbox as the default for this project using the commands below.

sf config get target-org --json
sf config set target-org agent-build --json

You can also ask the coding agent to open your default org, and the coding agent will use the command below to open it.

sf org open

A best practice is to build in scratch orgs or sandboxes and never give your agent access to the production environment. Also, never paste secrets like passwords into a prompt. A handy workflow is to run a second terminal without the assistant. That way you can copy, edit, and run sensitive commands yourself. 

Design before you build

This is the most important habit in the whole lifecycle. If you let an agent build on its own, it may produce something you have to throw away. So, slow down and design first.

Two things make this easy. First, switch your assistant into plan mode (in Claude Code, press Shift+Tab to cycle to “plan mode”). In plan mode, the assistant proposes a plan instead of changing files. Second, ask the assistant to interview you before it builds. A prompt like this works well:

“Before you build anything, interview me to design this agent. Ask one question at a time and recommend a sensible default for each. Treat the design as a decision tree: when my answer opens new choices, follow that branch and keep asking until it’s fully resolved, then move to the next branch. Cover the data model, actions, permissions, and agent structure. Don’t stop or start building until every decision needed to build the agent is made.”

That single instruction turns the assistant into a design partner. It walks down every branch of the decision tree — following each answer to the sub-decisions it raises — and only stops once nothing is left to decide. Nothing gets built on a guess. For our example, an employee To-Do Manager agent, it walked through real architectural choices:

• Where should to-dos live: in a custom object, or the standard Task object?
• Which fields and status values does the agent need?
• Should the agent run as the logged-in user?
• Use one sub-agent with three flow actions, or a hub-and-spoke model with a sub-agent per task?
• Should the backing logic be Salesforce Flows or Apex?

Note that the above is an example prompt, and based on your organization’s best practices, you can build an agent skill of your own to help you design this, so you do not have to repeat this prompt.

The Claude Code coding assistant interviews the developer one question at a time, recommending a default for each design decision.

Visualizing your agent as a graph is helpful. Each sub-agent acts as a node representing a specific domain: a single, focused job with its own dedicated instructions and actions. A router node at the top orchestrates these sub-agents based on the conversation. Designing the agent means defining these nodes and providing clear instructions and tools to ensure that the agent achieves the user’s goals.

So, the rule of thumb is about domains, not difficulty. Keep a single sub-agent when the whole job lives in one domain, for example, frequently asked questions (FAQ) or a status lookup. Reach for multiple sub-agents in a hub-and-spoke shape when the work spans distinct domains that each deserve their own instructions, actions, or security gate. Most agents land at one to five domain sub-agents. You make these calls, not your coding agent. That’s the point — you end up more confident because you designed the graph.

The AI-generated info graphic below conveys these ideas.

Generate, deploy, and let the agent fix and retry

Once the plan is approved, the assistant builds everything: the custom object and fields, the flows, and the agent definition file written in Agent Script (the declarative format that specifies your agent’s sub-agents, routing logic, instructions, and action bindings). The output is an authoring bundle: the deployable package containing the agent’s complete definition as local metadata files. You can watch it happen live in VS Code as files appear.

Be sure to scope the work explicitly in your plan. A common choice is “build, deploy, and validate” before you publish. You can also add reminders that the assistant might otherwise skip, for instance, “make sure the new object has the right permissions; create a permission set.” Field-level security (FLS) and create-read-update-delete (CRUD) permissions matter, so call them out.

The standout behavior is an automated fix-and-retry loop. When a deploy fails, the assistant reads the compiler or deploy error, traces it to the offending metadata, applies a fix, and redeploys, repeating that cycle until the deploy succeeds. It’s the same edit-compile-debug loop you’d run by hand, just driven by the agent. If you want to go faster, you can fan out the work, so parallel agents build several flows at once instead of one after another. When you go for parallel work, make sure you understand dependencies and group them, so they can execute without stepping on each other.

You drive this in plain language: “Build a single sub-agent To-Do Manager using Salesforce Flows, build, deploy, and validate it, and create a permission set for the new object”. Behind that prompt, the developing-agentforce skill runs a precise sequence. It first generates the authoring bundle (the agent scaffold), then validates that Agent Script compiles with a local check, deploys the backing flows or Apex the actions reference, and finally deploys the authoring bundle itself. Knowing the sequence helps you follow along and step in when needed.

sf agent generate authoring-bundle --json --no-spec --name "To-Do Manager" --api-name To_Do_Manager
sf agent validate authoring-bundle --json --api-name To_Do_Manager
sf project deploy start --json --metadata Flow
sf project deploy start --json --metadata AiAuthoringBundle:To_Do_Manager

Notice two best practices baked into the skill. Every command leads with --json to make the output machine-readable, and every deploy names its metadata explicitly. A bare sf project deploy start ships everything that changed, and scoping each deploy keeps agent metadata from going out by accident.

Validate, then test in two modes

When the build finishes, the assistant validates the agent’s behavior paths automatically, checking far more paths than you’d test by hand. Validation is required before the agent can be published, so it’s built into the flow.

Still, don’t skip your own testing. Automated validation is a safety net, not a substitute for judgment. This is where the testing-agentforce skill comes in. It gives you two modes: quick smoke tests while you iterate, and a saved batch suite for regression testing and continuous integration. Use the first to move fast, and the second to keep the agent honest as it grows.

Quick smoke tests with preview sessions

The quick mode is a live preview session. You start a session, send a real utterance, and end the session when you’re done — each preview sends a trace you can read afterward. Note that --authoring-bundle must appear on all three subcommands.

sf agent preview start --json --authoring-bundle To_Do_Manager

sf agent preview send --json --authoring-bundle To_Do_Manager --session-id SESSION_ID --utterance "Create a to-do to write a blog"\

sf agent preview end --json --authoring-bundle To_Do_Manager --session-id SESSION_ID

Batch regression testing with test specs

For repeatable testing, you describe the cases you care about and the skill writes a test spec. The spec is a YAML file that lists each utterance alongside what should happen. Three assertions matter per case:

• expectedTopic: The sub-agent that the conversation should route to
• expectedActions: The actions that should fire
• expectedOutcome: A plain-language description of the right result

That last one is graded by a large language model (LLM) acting as a judge, so it reads the response the way a person would. It’s the most reliable assertion, so include it on every case.

name: To_Do_Manager_Tests
subjectType: AGENT
subjectName: To_Do_Manager
testCases:
  - utterance: "Create a to-do to write a blog"
    expectedTopic: To_Do_Management
    expectedActions:
      - Create_To_Do
    expectedOutcome: "A new to-do titled 'write a blog' is created and confirmed to the user."

You then create the test definition from that spec and run it as a batch, waiting for the results.

sf agent test create --json --spec specs/To_Do_Manager-testSpec.yaml --api-name To_Do_Manager_Tests --force-overwrite

sf agent test run --json --api-name To_Do_Manager_Tests --wait 10

When a case fails, the skill diagnoses it straight from the trace — a sub agent that didn’t match, an action that never fired, or an ungrounded response. It then applies a targeted fix and retries for a few iterations before asking for your help. You can also run the live preview in the new Agent Builder for an admin-friendly view, or use the Agentforce DX panel in VS Code to start a test session.

Note: We are enhancing the automated testing experience to support multi-turn conversation, injection of state variables, and verify action validations. Keep an eye on the release notes.

Publish and activate your agent

When it works, publish and activate the agent. Publishing turns the deployed bundle into a runnable agent version as Inactive; activating turns it on so users and tests can reach it. You can publish now and activate later if you prefer. Below are commands that the agent runs for publish and activation.

sf agent publish authoring-bundle --json --api-name To_Do_Manager
sf agent activate --json --api-name To_Do_Manager

And if you forgot a piece of metadata, just ask the agent to build it for you. The whole point is that you describe the gap and the assistant fills it. Maintain a repeatable history by committing your Agent Script and associated metadata to a source control system like Git. This practice ensures you can revert to a known functional version whenever necessary, keeping your development environment stable and secure.

Debug with traces, not guesswork

The agent trace is the primary debugging signal for Agentforce agents. It’s a JSON file generated after each conversation turn that shows which sub-agent handled the request, what the LLM received, and which actions fired. Agents rarely come out perfect on the first try, so you’ll keep tweaking them. You’ll work with traces in two places, and they look slightly different in each.

Local traces during development

While you build, the traces are local. After each preview send, the runtime writes one JSON file per conversation turn. Each trace shows the full execution path: which sub-agent handled the turn, what variables were set, what the LLM saw, and which actions it called. You’ll find these files in your project.

.sfdx/agents/To_Do_Manager/sessions//traces/.json

These local traces are instant and complete, but they only cover your own preview sessions. The fix loop is simple: open the trace, paste it back into your assistant, and explain what you expected versus what happened. In the Agent DX panel, you can grab the same trace with one click. The trace is detailed enough that the assistant usually pinpoints and fixes the issue — you can even ask it to “self-test using the trace and fix it.” This resolves the large majority of problems before the agent ever ships.

Production traces with the observing-agentforce skill

Once real users are on the agent, you need a different lens. That’s the job of the observing-agentforce skill. Instead of one local file, it queries the Session Trace Data Model (STDM) — the production session data that Agentforce stores in Data 360 — so you can see how the agent behaves across real conversations at volume.

The skill follows a three-step loop: observe, reproduce, improve. It queries production sessions to surface the failures that matter — sub-agent misroutes, action errors, low adherence, slow actions, and abandoned sessions. It then reproduces a suspect case in a local preview to confirm the root cause, and only then edits the agent to fix it. You ask in plain language, “find the worst-performing sessions from the last day and tell me why”, and the skill runs the queries and reads the results for you.

For either kind of trace, a visualizer helps when the routing itself is hard to follow. The agent is a graph: a router hands each conversation to a sub-agent, which builds variables and prompts, sends them to the LLM, and calls tools until it has an answer. A tool like AgentLens lets you walk that graph step by step, seeing each sub-agent handoff, the tools sent to the LLM, and the response that ends the flow.

Note: for agent observability at scale for production agents, it is recommended to set up dashboards and metrics using Agent Observability

Extend the lifecycle with custom agent skills

Adopt this lifecycle and your day-to-day changes. You stop clicking through Salesforce setup for routine work and start describing outcomes instead. When something isn’t right, the fix almost always lives in one of four places: your prompt, your context, the tools you built, or the skills you installed.

That last one is the real unlock. When a skill produces metadata you don’t like, improve the skill and contribute it back. Your fixes compound for everyone, and the assistant gets better at Salesforce over time. Pairing that with a design-first interview keeps you in control — you slow down just enough to learn and to own the design.

The agentic development lifecycle: Recap

The agentic development lifecycle gives you a faster, more reliable way to build Agentforce agents. Install Agent Skills from the Salesforce Skills Library so your assistant knows Salesforce, scaffold and connect your project, then design before you build with plan mode and a design-first interview. Let the assistant generate the metadata and fix-and-retry failed deployments, validate and test the result, and debug with traces when something’s off. You move quicker and stay the designer the entire time.

Want to go deeper or share what you’ve built? Join the conversation in the Salesforce Developers Trailblazer Community.

Resources

• Agentforce Developer Center
• Salesforce Skills Library on GitHub (forcedotcom/sf-skills)
• Agentforce DX Visual Studio Code extension

About the author

Mohith Shrivastava is a Principal Developer Advocate at Salesforce with 15 years of experience building enterprise-scale products on the Agentforce 360 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 Master the Agentic Development Lifecycle for Agentforce appeared first on Salesforce Developers Blog.

Of course, managed package triggers are a black box. We don’t own them, and we can’t touch them. But our custom triggers? That’s our house, and we get to set the rules. The answer isn’t more triggers. It’s one, done right.

That’s where Agentforce Vibes becomes your best pair programmer. It reads through your triggers, tells you exactly what each one is doing, spots the landmines, and helps you consolidate everything into a clean, scalable pattern iejggcbhdbklunjvfhejciflcuchnvrn the way it should have been built from the start. What would typically take days of manual code review and architectural planning gets done in a fraction of the time, so your team can focus on what actually matters building great solutions.

In my org, I had multiple triggers firing on the Opportunity object, each one written at a different point in time, by different developers, for different reasons. In this post, I’ll walk you through the approach I used to bring all of that chaos under one roof, into a single, clean trigger while intentionally leaving any managed package triggers untouched.

The workflows, skills, prompts, and steps you’ll see throughout this post are based on my own org, and your org will certainly look different. Your trigger count, logic complexity, and dependency map are uniquely yours. That’s completely normal, and honestly, that’s the point.

From concept to practice: Skills and workflows

What makes this approach powerful is that you can turn it into a reusable skill or workflow — a framework that you can run on any object, share across your team, or plug into other agents. The principles are universal; the execution is yours to shape.

Skills: Your on-demand code analyst

Think of a skill as a specialist you can call on instantly. Point it at your triggers and it surfaces what actually matters: recursion traps, SOQL inside loops, conflicting field assignments, or gaps in test coverage. Analysis that used to take hours of careful reading? It now takes minutes.

Workflows: Safe, repeatable refactoring at scale

A workflow takes that analysis and turns it into a structured, sequenced process: audit first, then refactor what needs fixing, then generate the consolidated trigger, handler, and tests in the right order. No steps skipped, no code merged before it’s ready. Just a clean, predictable path from messy to maintainable.

From chaos to a single, clean trigger

Below is the a generic workflow that I implemented to take multiple Apex triggers on a single object and consolidate them into one clean, maintainable handler.

This workflow works on any standard or custom object as it contains no hardcoded object names. You can run it multiple times on different objects. You’ll get the same process and the same quality of analysis without the need for reconfiguration.

Let’s take a look at the workflow steps in more detail.

Step 0: Project setup

Before you get started, there are a few things you’ll need in place.

This walkthrough assumes that you’re working in VS Code with the Salesforce Extension Pack installed, your org is authenticated via the Salesforce CLI, and the Salesforce DX MCP Server is enabled in Agentforce Vibes. If you’re already set up, feel free to skip ahead. Otherwise, each link above will get you there quickly.

I’ve published a base version of the skills and workflows for trigger consolidation on GitHub. Think of it as your ready-to-run starting point: fork it, adapt it to your org’s objects and conventions, and make it your own.

Now, let’s install the skills and workflows. Head over to this README for setup instructions, it walks you through copying the .a4drules/ directory into your Salesforce DX project root.

This copies three files into your project: apex-trigger-risk-scan.md, pex-trigger-consolidation-analysis.md, and trigger-consolidation.md.

your-sfdx-project/
├─ .a4drules/
│   ├─ skills/
│   │   └─ apex-trigger-risk-scan.md                  ← single trigger analysis skill
│   │      └─ apex-trigger-consolidation-analysis.md  ← cross trigger analysis skill
│   └─ workflows/
│       └─ trigger-consolidation.md    ← trigger consolidation workflow

That’s the entire install — no restart or configuration required. Agentforce Vibes picks up the new skills and workflow immediately.

Step 1: Workflow start

1. Click the Agentforce Vibes icon in the VS Code Activity Bar to open the chat panel.
2. Type the following command to start the trigger consolidation workflow.

   /trigger-consolidation
   

3. The workflow kicks off by asking which object to work on.

   Which Salesforce object do you want to consolidate triggers for?
   (e.g. Opportunity, Case, Account, Invoice__c)
   

4. Type an object name like Opportunity and press Enter.

Step 2: Metadata retrieval

The workflow uses the Salesforce CLI to query your org’s metadata to retrieve Apex triggers and the related helper classes.

You can watch it work in the chat panel with an output similar to this:

Running: sf data query --query "SELECT Name, ... FROM ApexTrigger
WHERE TableEnumOrId = 'Opportunity' AND Status = 'Active'"

## Summary of what was retrieved:
**Triggers (9 total, 5 readable):**
1. **OpportunityBefore** (x2) - Body hidden (managed package / org-installed, unreadable)
2. **OpportunityAfter** - Body hidden (unreadable)
3. **OpportunityTrigger** - Body hidden (unreadable)
4. **OppDeleteTrigger** - before delete — readable
5. **OppCreateTrigger** - before insert, after insert — readable
6. **OpportunityNotifyTrigger** - after insert, after update — readable
7. **OppStageTrigger** - before update — readable
8. **OpportunityUpdateTrigger** - before update, after update — readable
The dependent classes are all accessible: OpportunityUtils, OpportunityHelper, and NotificationService. No test classes exist for this trigger suite. Let me load the apex-trigger-analysis skill to conduct the risk assessment.

Step 3: Trigger analysis

With the source in hand, the workflow loads the two trigger analysis skills and runs every trigger through all risk dimensions.

Per-trigger scan: apex-trigger-risk-scan skill (seven dimensions)

Cross-trigger analysis: apex-trigger-consolidation-analysis skills (eight dimensions)

You’ll see findings stream into the panel in real time.

Score Meaning
1–3      Low — safe to consolidate with minimal prep
4–6      Medium — refactor required before merge
7–9      High — urgent action recommended
10       Critical — production incident likely without immediate action
Overall risk score: 7/10

Step 4: Plan creation

Here’s the part that matters: the workflow does not generate a single line of code yet.
Instead, it writes a detailed plan file to docs/trigger-audit-plan.md and pauses.

Audit complete. I've written the full plan to docs/trigger-audit-plan.md.
Overall risk score: 7/10
Please review the findings and edit anything before I generate
the consolidated scaffold.
When you're ready, reply YES to proceed. Reply NO to stop here.

Step 5: Plan review

Open the plan file in VS Code. It contains:

• Trigger inventory: Every trigger, its events, line count, risk score, and top finding
• Risk register: Every finding with severity, plain-English description, and recommendation
• Dependency graph: Which triggers share which helper classes, as a plain-text diagram
• Logic merge map: Exactly which logic from which trigger goes into each consolidated context, with conflicts flagged explicitly
• Best practices compliance: Where current triggers violate Apex standards and what the consolidated code will fix

This file is yours to edit. You can change the instructions, add team notes, remove a trigger from the plan, etc. When you’re ready to proceed, the workflow reads your edited version before it writes any code. What you see in the plan is what gets built.

When the plan looks right, go back to the Agentforce Vibes chat panel and type:

YES

Step 6: Plan execution

The workflow reads your (possibly edited) plan and generates consolidated files directly into your Salesforce DX project.

For instance, this is what you could see when consolidating an opportunity trigger:

✓ force-app/main/default/triggers/OpportunityTrigger.trigger        (28 lines)
✓ force-app/main/default/classes/OpportunityTriggerHandler.cls      (74 lines)
✓ force-app/main/default/classes/OpportunityTriggerHelper.cls       (32 lines)
✓ force-app/main/default/classes/OpportunityTriggerTest.cls         (58 lines)

Consolidation complete. Search for // CONFLICT and // ASYNC REQUIRED
comments — these are the only places that need manual review.

In this example, these four files are generated:

• OpportunityTrigger.trigger: This is a single trigger covering only the events that existed across the originals. No business logic in the body, everything delegates to the handler.
• OpportunityTriggerHandler.cls: One method per trigger context has a static Boolean recursion guard at the top, and every method is annotated with its consolidated source triggers. Logic is merged in the correct sequence per the Logic Merge Map you reviewed.
• OpportunityTriggerHelper.cls: This is the actual business logic, fully ported from the original triggers. All SOQL is bulkified outside loops, and duplicate logic from multiple triggers appears exactly once.
• OpportunityTriggerTest.cls: Test methods for single insert, bulk insert (200 records), update, bulk update, and delete are each traceable back to the source trigger.

Step 7: Manual review

Once the workflow terminates, the last manual task is to review the comments that were left during the execution. There are two types of comments that you should address:

• // CONFLICT: Where two triggers set the same field to different values. You decide which wins
• // ASYNC REQUIRED: Where a sync callout needs to move to @future or Queueable before deploying

Finally, the trigger jungle is a solved problem. Once a trigger is optimized, you can leverage prompts to deactivate the old trigger and, once tested and validated, promote the new implementation to a higher environment.

Considerations

• Before you adapt this framework, make it yours. The workflow and skill are starting points, not scripts. Your org’s complexity, naming conventions, and business logic are unique to everything generated here, so edit the audit plan before you commit to it.
• Spend real time in plan mode before generating any code. Open docs/trigger-audit-plan.md, work through the phases, flag the conflicts you already know about, and align the merge order with your team’s plan. The more thinking you do upfront, the cleaner the output.
• Treat generated code as a recommendation, not a final answer. Always review and validate before you deploy. These are smart suggestions, not certified production-ready commits.
• Fix High severity issues before you consolidate anything. If the audit surfaces recursion risks, SOQL or DML in loops, or field conflicts, stop and resolve those first. Merging broken logic into a single trigger doesn’t fix it and just makes it harder to debug later.
• Version control everything. This includes triggers, handler classes, service classes, audit files, test classes — all of it. If it gets generated or modified, it belongs in source control.
• Always test in a sandbox first and never run directly against production. The workflow connects to whichever org you’re authenticated to, so before running /trigger-consolidation, verify that sf org list shows a sandbox or scratch org as your default. Consolidating triggers in production without testing is how outages happen.
• Run one object at a time, but think about the whole org. This isn’t a one-and-done fix. Once Opportunity is clean, move to Case, then Account, then your custom objects. The phased approach is intentional: each consolidation builds confidence for the next.

Conclusion

Trigger sprawl is common and costly, and with the right approach, it’s completely solvable.

Ready to clean up your org? Start with your simplest triggers, follow the steps in this guide, build confidence, then tackle the high-traffic objects. Run the Agentforce Vibes analysis skill and let the audit canvas show you exactly what you’re dealing with. One trigger, one handler, zero surprises.

Resources

Agentforce Vibes

• Developer Guide: Agentforce Vibes Overview
• Developer Guide: Agentforce Vibes Quick Start
• Install: Salesforce Extension Pack for VS Code
• Documentation: Agentforce Vibes MCP Server 
• Developer Guide: Skills in Agentforce Vibes
• Developer Guide: Workflows in Agentforce Vibes

Salesforce CLI

• Setup Guide: Salesforce CLI 
• Command Reference: SF Project Retrieve
• Command Reference: SF Data Query 

Apex Trigger Best Practices

• Developer Guide: Apex Triggers 
• Developer Guide: Apex Best Practices
• Trailhead: Apex Trigger Badge

Metadata & Deployment

• Developer Guide: Metadata API 
• Reference: Package.xml Manifest
• Developer Guide: Custom Metadata Types 

About the author

Lakshmi Anusha Myneni is a Principal Technical Architect at Salesforce with 15 years of experience in the financial services industry. She partners closely with customers during the most critical stages of their journey, translating complex business challenges into compelling, technically sound Salesforce solutions.

The post Analyze and Consolidate Apex Triggers via Agentforce Vibes appeared first on Salesforce Developers Blog.