The expertise problem

Imagine that you are using an AI coding agent to accelerate app development, or maybe you’re deep in the zone writing the configuration yourself. You prompt your agent to scaffold a new feature. But because general LLMs lack precise, version-specific knowledge of the massive Salesforce ecosystem, the agent hallucinates. It generates a complex metadata XML file based on its best understanding of Salesforce metadata and mixes up sharingModel with sharingType, guessing whether deploymentStatus is required, or fabricating non-existent values for visibility.

Suddenly, the AI advantage evaporates. You are stuck digging through a massive amount of documentation to correct its hallucinations, hunting for valid XML examples in legacy projects, or trial-and-erroring your way through failed deployment logs. An AI agent without deep, platform-specific context can quickly become a high-speed hallucination engine, and you’re the one stuck cleaning up the deployment errors.

What if your AI assistant could instantly access complete, authoritative documentation for hundreds of Salesforce metadata types right within your development workflow? That’s exactly what the Metadata API Context Skill delivers.

Introducing the Metadata API Context Skill

Salesforce Skills are specialized AI capabilities that ground Agentforce Vibes and other third-party AI development tools with deep, domain-specific knowledge. Available as sf-skills (see docs), these open-source skills are pre-loaded in Agentforce Vibes, but can be installed in any third-party AI tool. Think of them as expert consultants embedded directly into your IDE. While general AI models have broad knowledge, they often lack the precision and depth needed for complex enterprise platforms like Salesforce.

The Metadata API Context Skill, platform-metadata-api-context-get, (see docs) transforms how developers work with Salesforce metadata by providing instant access to comprehensive metadata type documentation, including field definitions, XML structures, WSDL schemas, and real-world examples.

Salesforce Metadata API is massive, which includes hundreds of metadata types ranging from familiar types like CustomObject and ApexClass to specialized types like AIApplicationConfig and ExplainabilityActionDefinition. Each type has a distinct set of strict field definitions, XML structures, namespace requirements, naming conventions, SFDX locations, and complex relationships.

Manually searching the Metadata API Developer Guide for these types can break a developer’s flow and kill productivity for both humans and agents, as finding accurate examples and identifying required fields often involves trial-and-error through failed deployments.

Real-world use case: Building a record-triggered flow

Flow metadata is one of the most complex structures in the Salesforce Metadata API. With 40+ node types, nested XML hierarchies, and intricate connector logic, even experienced developers typically build flows in the UI and reverse-engineer the generated XML, sacrificing version control clarity and code review capability. Using a real use case, let’s understand how the Metadata API Context Skill can elevate AI-based development for successful deployments in first-attempt. 

Let’s build a case-escalation flow that automatically escalates high-priority support cases and generates email alerts for it. Before you begin implementation, you want to understand the structure of Flow metadata, particularly its fields. The structured JSON resource returned as a response is divided into distinct segments like field definitions and XML structures: the fields segment for precise parameter definitions, the description section to grasp core functionality, declarative_metadata_sample_definition for ready-to-deploy XML patterns, and so on. Most developer workflows utilize one or more sections at a time. This sectional approach to data retrieval effectively reduces token overhead by 60-80% for every file processed.

You can ask your AI assistant:

“Show me the fields section for Flow metadata. I need a record-triggered flow on the Case object.” 

The skill loads just the fields section for Flow metadata, showing you all available fields with their types and descriptions. 

Furthermore, you can leverage it to help build a decision logic for the flow with a sample prompt like this:

“Generate the decision node for a record-triggered flow that evaluates whether the case qualifies for escalation (Priority = High/Critical, unassigned for 2+ hours, Enterprise/Strategic account tier). If it is a high priority case, it assigns qualifying cases to an Escalation Specialist queue.“

The skill instantly loads the declarative_metadata_sample_definition section, providing a complete, valid example with the proper XML declaration and namespace.

<decisions>
    <name>DecisionEscalationCriteria</name>
    <label>Evaluate Escalation Criteria</label>
    <locationX>176</locationX>
    <locationY>350</locationY>
    <defaultConnector>
        <targetReference>SendOwnerReminder</targetReference>
    </defaultConnector>
    <rules>
        <name>QualifiesForEscalation</name>
        <conditionLogic>1 AND 2 AND 3 AND 4</conditionLogic>
        <conditions>
            <leftValueReference>$Record.Priority</leftValueReference>
            <operator>In</operator>
            <rightValue>
                <stringValue>High</stringValue>
            </rightValue>
            <rightValue>
                <stringValue>Critical</stringValue>
            </rightValue>
        </conditions>
        <conditions>
            <leftValueReference>$Record.OwnerId</leftValueReference>
            <operator>IsNull</operator>
        </conditions>
        <!-- Additional conditions for case age and account tier -->
        <connector>
            <targetReference>AssignToQueue</targetReference>
        </connector>
    </rules>
</decisions>

Lastly, you can ask your agent to create email alerts as well for the same flow by using the following prompt:

“Add a flow section to generate email alerts using the Action Call node.”

Your AI assistant can now help you create the complete metadata file with confidence, with proper trigger configuration, decision logic, record updates, task creation, and email alerts.

These capabilities extend far beyond generating metadata from scratch. They also help you analyze and refactor existing configurations and streamline how you audit and modify legacy metadata. Imagine pulling an unfamiliar flow from your Git repository. Instead of wasting time deploying it to a sandbox to view it in Flow Builder, you can ask your AI agent directly from your IDE to explain how it works, help you modify it, and finalize changes before you ever push a deployment.

This skill gives your agent the edge it needs

The Metadata API Context Skill provides on-demand, structured access to complete metadata type documentation without leaving your development environment. Here’s what makes it powerful:

• Comprehensive coverage: Every metadata type is documented with field definitions, description, XML examples, WSDL segments for validation, file information and documentation for nested complex types.
• Intelligent token optimization: One of the skill’s most innovative features is its section-specific consumption model. The skill is designed to load only the specific sections you need, which makes it highly efficient even when working with multiple metadata types in a single conversation.
• Smart disambiguation: Using contextual keywords, the skill intelligently distinguishes between different API contexts. For example, ApexClass exists in Metadata API (for deployment), Enterprise API (for querying), and Tooling API (for debugging). The skill can accurately determine exactly which one you need.

This skill represents a shift in how we think about developer tools. Instead of treating documentation as a separate resource one context-switches to, it becomes grounded knowledge available exactly when and where a developer needs it. For teams, this translates directly to faster onboarding, fewer deployment errors, and more consistent metadata patterns across your codebase.

Best practices and performance tips

To get the most from this skill and keep token consumption low:

• Be specific: Ask for the “fields” section or “example structure” rather than generic queries.
• Load only what you need: Request specific sections (e.g., “Load fields and description from Flow”) to optimize token usage. Avoid broad prompts like “Load Salesforce Metadata Types documentation” as it causes unnecessary token overhead.
• Reference the index: If you’re not sure of the exact metadata type name, ask for a list of metadata types available in the metadata index.

Start building smarter today

The platform-metadata-api-context-get skill is available now as an open-source resource for the Salesforce Developer community in the Salesforce Skills repository. Whether you’re building custom objects, deploying complex automations, or maintaining enterprise-scale applications, this skill can transform your development workflow.

These skills are pre-loaded in Agentforce Vibes and can be installed in any third-party AI tool.

• Ensure the skill directory is in your third-party AI tool’s skills path
• The skill auto-loads when you work with metadata-related queries
• No additional configuration is required

Stop context-switching. Stop guessing at field names. Stop trial-and-error deployments. And start building with confidence, backed by comprehensive metadata documentation right at your fingertips.

Have questions or feedback about Salesforce Skills? Join the conversation in the Salesforce Developer Community or contribute to the open-source project on GitHub.

Resources

• Get started: Metadata API Context Get Skill on GitHub
• Explore more Salesforce Skills: Salesforce Skills Repository

About the author

Neha Ahlawat is a Product Management Director at Salesforce focused on Metadata API and its frameworks, source tracking, and metadata coverage.

The post Build Smarter with Metadata API Context Skills appeared first on Salesforce Developers Blog.

※本記事は2026年3月10日に米国で公開された The Future of the Salesforce Developer in the Agentic AI Eraの抄訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。

この記事のポイント

• AIは、Salesforce開発者の役割に取って代わるものではない。AIの登場によって、開発者の役割はシステム設計、品質エンジニアリング、システム横断的な思考という、より価値の高い3つの能力を発揮することに変わりつつある。
• AIを活用した開発ツールを導入すると、開発スピードはすぐには上がらず、最初はむしろ遅くなる。AI投資の意義は、単にツールを追加することではなく、ワークフローを再設計することにある。
• Salesforce開発の多くは、既存の環境に手を入れるブラウンフィールド開発で、意思決定の大半が文書化されていない、複雑なSalesforce組織を引き継ぐことになる。AIだけで、こうした組織固有の背景に対応することはできない。
• 2026年以降、Salesforce開発者のキャリアで評価される能力は、コードを速く書けることではなく、プラットフォームに関する深い知識と幅広いアーキテクチャーに関する判断力を兼ね備えていること。
• 勤め先がAIツールを導入しているかどうかにかかわらず、現在、最も重要であるスキルは、今日から身に付けていくことができる。

AI活用による開発を取り入れると、初めのうちはかえってスピードが鈍ることがあります。

これは、ツールに問題があるからでも、取り組み方が間違っているからでもありません。AIツールを導入したSalesforce開発チームに共通して見られるのが、J字型のカーブ（英語）です。AIを効果的に利用するには、タスクそのもの、つまりワークフロー、チームのプロセス、ソフトウェアの開発方法を見直す必要があります。こうした新手法では、開発を加速できるようになる前に、新たな種類のエラーが発生しがちです。

移行期の問題を解決しないまま突き進むと、よくない結果に行きつきます。質の低いコードがコードベースに大量に入り込むのではないかという懸念が生まれ、AIで本当に成果を向上できるのか、それとも開発者の生産性が向上したように見えるだけなのかという不安が広がります。

そう感じるのはもっともですが、それだけでは全体像が見えてきません。ここでは、Salesforce開発者の役割にどのような変化が起きているのかを、これまでの経緯、AIがもたらす変化、今後のキャリアパスという観点から見ていきます。

変化するSalesforce開発者の役割

Salesforceプラットフォームの歴史において、開発者の価値は明白でした。宣言型では実現できないことを実装するのが、開発者の役割だったのです。Flowだけでは不十分なとき、数式が限界に達したとき、あるいはビジネス要件が設定の範囲を越えたときには、開発者がApexを記述しました。Lightning Webコンポーネントを構築し、連携を設計し、コードでプラットフォームを拡張しました。

開発者に求められる主なスキルは、実装力でした。開発者は、要件を受け取り、実際に機能するソリューションを作成していました。その過程で、ガバナ制限、一括処理化パターン、トリガーの実行順序、マルチテナントアーキテクチャーの細かな特性に対処していました。優れた開発者は、Salesforceに関する深い知識を持っていました。プラットフォームの制約を理解しているだけでなく、その制約の中で効果的に開発する方法も熟知していました。

そうした時代が終わるわけではありませんが、流れは変わりつつあります。実装力は今も重要ですが、もう開発者の中心的な価値ではありません。開発者の価値は、システム設計、品質エンジニアリング、システム横断的な思考力へと移っています。

今起きている変化は、AIがコードを書くようになったことだけではありません。それは目に見える部分にすぎず、重要なのは、これまで見えなかった本質的な課題が浮き彫りになることです。 

AIは、Salesforce開発者に取って代わるのでしょうか？いいえ。AIが担うようになっているのは、業務の一部、とりわけ最初のコード案の生成です。Salesforce開発者の仕事全体がAIに置き換わっているわけではありません。むしろ、システム設計、品質検証、システム横断的な思考といった、今後も必要とされるスキルの需要は高まっています。開発者の役割がなくなるのではなく、再定義されているのです。

AIによって、ボトルネックが変わりました。何十年もの間、最も困難な作業は実装でした。作るべきものは明確でしたが、問題は、それをコードとして形にすることでした。今、実装には時間もコストもかかりません。Agentforce Vibes（英語）、Claude Code、Salesforce Extensions（英語）と組み合わせたCursorといったAIコーディングアシスタントを使えば、Apexクラスの生成、Lightning Webコンポーネントのひな型作成、テストスイートのドラフト、連携処理の骨組みの作成が数秒で完了します。品質にはばらつきがありますが、生成のスピードは一貫しています。

AIがコードを生成するようになって明らかになったのは、本当のボトルネックはシステム設計だったということです。何を作るのか、なぜそのように作るのか、それをシステム全体にどのように組み込むのかを理解することが課題だったのです。実装に時間がかかっていたときは、この課題は表面化していませんでした。コードの記述に費やしていた時間は、思考のための時間でもありました。コードを書きながらエッジケースを発見し、アプローチを見直し、複雑さを理解していたのです。

AIによって実装にかかる時間がほぼゼロまで短縮されると、これまで自然に確保されていた、思考のための時間がなくなります。その分、設計や分析に意識して時間をかけないと、リリースは速くなっても、理解は浅くなってしまいます。ここから問題が生じるのです。

AIはただのコード生成ツールではありません。開発者にとって、AIはこれまでにないほど強力な学習ツールです。馴染みのないコードベースについて質問し、プラットフォームの挙動をリアルタイムで調べ、設計上の判断について即座にフィードバックを得ることができます。AIによって、生産性の効率だけではなく、学習の効果も変わります。ここが重要なポイントです。学習ツールとしてのAIについては、後ほど取り上げます。

既存のSalesforce組織がAIにとって最大の課題である理由

もう1つ、AIのデモでは見落としがちな現実があります。世界のソフトウェアの大半は、ゼロから構築されるものではありません。デモでは、白紙の状態から数分で新しいアプリが構築されます。しかし、多くのSalesforce開発者が毎日向き合っているのは、既存のSalesforce組織です。こうした組織には、何百ものカスタムオブジェクトが存在します。複数のリリースにわたって構築された、自動化のレイヤーが積み重なっています。複数の管理パッケージが相互に作用していますが、誰も全体像を完全には把握していません。構築した人物が退職した後も、文書化されないまま設定に残っているビジネスロジックもあります。

これがブラウンフィールド開発です。Salesforce開発の大多数は、こうした環境で行われています。

Salesforceのエコシステムでは、数百万人の開発者が、長年にわたって進化してきたさまざまなSalesforce組織で開発に携わっています。こうした環境では、システム自体が仕様です。コード、メタデータ、属人的な知識、これまでSalesforce組織に関わったすべての人の判断の中に、仕様が蓄積されています。AIは、構造的なレイヤーの分析には長けています。しかし、その背後にある「なぜ」には到達できません。なぜそのデータモデルが選ばれたのか、特定の顧客層に対応するためにどのようなトレードオフが行われたのか、どのような制約がアーキテクチャーを形作ったのかといった理由です。そうしたコンテキストは、コードの中ではなく、人の頭の中にあるからです。

ブラウンフィールド環境でAI活用による開発を実践するためのフレームワーク

1. 構築する前に全体像を把握する。既存のSalesforce組織でAIを使ってコードを生成する前に、現在のアーキテクチャーを理解しましょう。トリガーの実行順序、自動化の依存関係、共有ルール、インテグレーションの境界を確認してください。
2. 暗黙の前提を明文化する。現在のデータモデルの背後にあるトレードオフ、特定の設計パターンが存在する理由、大規模運用でのみ表面化するガバナ制限のリスクを文書化します。
3. コンテキストを入力情報として扱う。AIツールに与えるシステムのコンテキストが多いほど、出力の質が向上します。Salesforce組織の実際のアーキテクチャーにもとづいたプロンプトなら、そのままリリースできる成果物が得られます。汎用的なプロンプトからは、作り直しが必要な成果物しか生まれません。

例 – AIアシスタントに、取引先の更新後に実行され、子レコードである取引先責任者を照会してステータス項目を同期するトリガーを生成させるとします。コードがコンパイルされ、テストをパスします。しかし、取引先にはすでに2つのトリガーが設定されています。1つはテリトリーの割り当てを再計算するトリガーで、もう1つは外部ERPにプラットフォームイベントを発行するトリガーです。3つのトリガーを合わせると、データの一括ロード時に、SOQLクエリーのガバナ制限である100回を超過します。AIは、既存のトリガー、実行順序、累積クエリー数を把握していませんでした。システムの背景情報を理解している開発者であれば、デプロイ前にこの問題に気づけたはずです。システム設計の有無が、こうした違いを生みます。

これからのSalesforce開発者にとって最も重要なスキル

以下の各セクションでは、それぞれのスキルを深く掘り下げ、実務でどのような役割を果たすのかを見ていきます。

システム設計 – これからのSalesforce開発者にとって中核となるスキル

これからのSalesforce開発者にとって最も重要な仕事は、新しいコードを書くことではありません。システムを設計し、既存のシステムを理解し、その進化の方向性を定め、AIを動かすための構造とガードレールを作ることです。

先に紹介したブラウンフィールド開発のフレームワークは、その手順を示しています。さらに難しいのは、このフレームワークを実行するには何が必要で、なぜそれがAIではできないのかを明らかにすることです。なぜトリガーは特定の順序で実行されるのか。現在のデータモデル、どのようなトレードオフによって作られたのか。負荷が高まったとき、連携はどのように動作するのか。セキュリティモデルは何を前提にしているのか。実際のガバナ制限のリスクはどこにあるのか。必要なのは、現状を文書化するだけでなく、その先を設計することです。

この仕事には、高度な技術力と創造的な判断力が必要です。AIは構造分析が得意です。コード分析からドキュメントの下書きを生成し、メタデータ全体からパターンを見つけ、依存関係のつながりを可視化できます。しかも多くの場合、人間よりも速く行えます。しかし、設計上の判断では、「なぜ」なのかを理解する必要があります。なぜそのパターンが存在するのか、なぜそのトレードオフを受け入れたのか、なぜその制約がビジネス上重要なのか。そうした判断の根拠は、コードベースではなく、人間関係や組織に蓄積された記憶の中にあります。

実務では、文書化されていない複雑なSalesforce組織を分析し、アーキテクチャーの全体像を明確に描ける開発者が、チーム全体（そこで使われるAIツールも含む）が効果的に働ける環境を作ります。その能力は、Apexを書くスピードよりもはるかに重要です。アーキテクチャーの観点から考えられる人が、チームメンバーの生産性を引き出します。コードを速く書くという仕事は、AIがすでに習得しつつあります。

Agentforceの導入に向けてSalesforce組織を準備するときも、Flowで新たな自動化を構築するときも、AIのコーディングアシスタントを開発ワークフローに取り入れるときも、この点は変わりません。どの場合でも、成果物の品質を決めるのは、システム設計にもとづく思考です。あいまいなプロンプトからは、あいまいな出力しか得られません。組織のアーキテクチャーを明確に理解していれば、リリース可能な成果物を生み出せます。

AIを活用したSalesforce開発における品質エンジニアリング

AIがコードをスピーディに生成するようになると、リスクはコードが誤っていることではありません。コードがすぐに生成され、もっともらしく見えるために、開発者が質の低いコードを受け入れてしまうことです。質の低い成果物が生まれる原因は、モデルではなく、人が確認を怠ってしまうことにあります。

開発者の日々の仕事の中心は、生成ではなく、検証へと移っています。検証とは、AIが生成したクラス、フロー、テストスイートのすべてを、編集の判断が必要なドラフトとして扱うということです。内容を厳密に確認してください。構文がコンパイルできるかだけでなく、そのアプローチが既存のアーキテクチャーに適合しているかどうかも見極める必要があります。コミットする前にリファクタリングしてください。

AIが生成したテストには、特に注意を払う必要があります。こうしたテストでは、コードが記述どおりに動作することは確認できますが、意図どおりに動作することまでは確認できません。AIにコードとテストの両方を書かせると、意義のある検証をすることなくパスしてしまうテストが生成されやすくなります。テストにも、本番用のコードと同じ水準の厳密さが求められます。

既存のSalesforce環境では、判断を誤ったときの代償が大きくなります。検証が不十分なトリガーは、一括データ処理の障害を引き起こす可能性があります。適切なガードレールが設定されていないAgentforceエージェントからは、エンドユーザーを混乱させる出力が生成されます。レコードの同時更新を想定したテストを行っていないフローは、データ整合性の問題を引き起こし、修正に数週間かかることがあります。妥協のない検証チェックポイント（テストの合格、静的解析で問題がないこと、手動確認の完了など）を設ける開発者こそが、システムの健全性を長期間維持できます。スピードが優先され、整合性がないがしろになりそうな場合に歯止めをかけることも、開発者の役目です。この役割は、AIの登場前より今の方が重要です。

これは、開発者のスキルを引き上げることにもつながります。これまで数時間かかっていたドラフトが数秒で得られるようになれば、人間の判断が最も重要となる作業、つまりアーキテクチャー上の判断やトレードオフの分析、AIの出力を採用するか否かの見極めに時間をかけられるようになります。

とはいえ、すべての開発者がアーキテクト（英語）になるということではありません。すべての開発者が、システムのコンテキストを深く捉える力を身に付けるということです。多くの場合で、開発者の役割は、実装を担うAIエージェントを監督し、リリースされる成果物に責任を負うことへと変わります。フレームワーク、コーディングパターン、コードレビュー、慎重なテスト設計は、これからも人が担う仕事です。企業のリーダー層はスピードだけを評価しがちですが、品質基準を守る開発者がいなければ、AIによって技術的負債と脆弱性が拡大することになります。

Salesforce開発者の新たな強みとなるシステム横断的な思考

開発者に深い専門性が欠かせないことに変わりはありません。AIがまだ理解していないプラットフォームの内部構造を理解している人は必要です。しかし、さらに重要なのは、深い専門性と幅広い視点を兼ね備え、自分の専門領域とシステム全体とのつながりを理解できる開発者です。

Salesforceは、アーキテクチャーを構成する要素の1つです。ApexとFlowがどのように連携するか。Flowがプラットフォームイベントとどのようにつながるか。プラットフォームイベントが外部のミドルウェアとどのようにやり取りするのか。一連の連携がエンドユーザーにどのような価値をもたらすのか。こうしたつながりを理解している開発者は、全体を見ずに1つのレイヤーだけを深く掘り下げる開発者よりも、はるかに価値の高い存在です。

構築している機能だけを見るのではなく、製品全体を把握すること。データモデルや連携の全体像、セキュリティアーキテクチャー、そしてこれらの要素を結びつけるビジネスロジックを理解すること。さらに、技術的な影響をビジネスの観点から説明し、開発が遅くなるとしても、早い段階でリスクを明らかにすることが求められます。

Salesforceのプラットフォームでは、この変化がすでに現れています。Agentforceには、コードだけでなく、AIエージェントの設計、ガードレールの設定、データアーキテクチャー、ユーザー体験を理解している開発者が必要です。リリースを重ねるたびに、クリックベースの設定とコーディングの境界はあいまいになります。SalesforceとAIサービス、データプラットフォーム、外部アプリとの接続が増えると、インテグレーションのパターンも複雑になります。これらのレイヤー全体を俯瞰し、コードを使うべき箇所を適切に判断できる開発者が、チームから頼られる存在になります。

エージェント型AI時代のSalesforce開発者へのキャリアアドバイス

この記事を読んで、この変化を重く受け止めているとしても、同じように感じている人はほかにもいます。そう感じるのは当然のことで、開発者という職業に求められるものが変わりつつあるのです。その役割は小さくなるのではなく、さらに広がるのです。

すでにワークフローでAIツールを使っている場合は、どうすればよいですか？

スピードを最優先の指標にするのはやめましょう。AIが動作するためのシステム設計、ガードレール、フレームワークを構築し、ワークフローを作り直すことに注力すべきです。これには時間がかかり、エラーも起こります。しかし、新しいパターンが定着すれば、これまで実現できなかったレベルで仕事ができるようになります。AIの出力はドラフトとして扱い、厳密に検証してください。早くリリースするように求められても、仕事の質を高める判断力を手放してはいけません。

勤め先がまだAIツールを導入していない場合は、どうすればよいですか？

取り残されるのではないかと不安になるかもしれませんが、大丈夫です。企業への導入と個人の学習は、分けて考える必要があります。企業がAIツールをいつ導入するかは個人には決められませんが、いつ学び始めるかは自分で決められます。

今すぐAIアシスタントを使って、コードベースを調べ、システム設計の思考法を実践し、ドキュメントのドラフトを生成してみましょう。チームが正式に採用しているツールに関係なく、この記事で紹介した習慣を身に付けることは可能です。システムを深く理解し、暗黙の前提を明文化し、アーキテクチャー全体を捉えるというシステム設計の作業そのものが、今行っている仕事の質を高めます。また、勤め先がAIツールを導入した際に、すばやく対応できるようにもなります。

Salesforce開発者としてのキャリアパスで、どのようなスキルが強みになりますか？

文書化されていない複雑なSalesforce組織を分析し、アーキテクチャーの全体像を明確に描くことができますか？単独では機能するAIの提案が、全体のコンテキストでは問題を引き起こす可能性を見抜くことができますか？システムの境界をまたいで、アーキテクチャー全体を考慮した判断ができますか？

AIが実装を担うようになるほど、こうした能力の価値が高まります。

Salesforce開発について学習中、あるいはSalesforce開発者としてのキャリアがまだ浅い場合は、どうすればよいですか？

今こそ、学び始めるのに最適なときです。重要性の高いスキルを身に付けるうえで、AIは最も強力なツールです。

Salesforce開発の経験が浅くても、AIを活用して馴染みのないコードベースを調べ、プラットフォーム内部の仕組みをリアルタイムで学び、システム設計上の意思決定をシミュレーションし、コードについてすぐにフィードバックを得ることができます。こうした学習方法は、2年前には存在していませんでした。今だからこそ、システム思考は以前より早く身に付けることができます。

とはいえ、表面からは見えない内部の仕組みも理解する必要はあります。外国語の学習と同じで、聞いて意味は理解できても、自分で話したり書いたりしなければ、その規則は身に付きません。AIを使えば、習得をスピードアップできます。

専門性を深める前に、まず広い視野を持ちましょう。学習した内容を記録することを習慣にしてください。Trailheadでプラットフォームの基礎をしっかり学びましょう。Salesforce認定Platformデベロッパーなどの認定資格は、基礎知識があることを証明しますが、ここで説明したスキル（システム思考、アーキテクチャー上の判断力、品質を徹底する姿勢）は、試験では測りきれない価値があります。

SalesforceコミュニティがAIへの移行を後押し

AIを活用した開発に移行するなか、エコシステムではかつてない速さで新たな知見が生まれています。しかし、その知見は、均等に行き渡っているわけではありません。AIを日常的に試している開発者がいる一方で、勤め先がまだAIの導入に乗り出していない開発者もいます。両者の差は才能ではなく、AIを実際に活用した人の率直な経験や知見に触れられる機会があるかどうかです。

今、このコミュニティの誰もができる最大の貢献は、それぞれが得た学びを共有することです。包み隠さず、正直に、取り繕うことなく共有してください。成功体験だけではなく、行き詰まりや失敗、AIによって一時的に苦労が増えた局面も共有してください。「導入して3か月間は、かえって作業が遅くなった」といった率直な経験談は、最も有益な情報の1つです。こうした情報が共有されれば、移行に伴う負担は当たり前に発生するものとわかり、他のメンバーが計画を立てやすくなります。

Trailblazer CommunityやGitHubのディスカッション、コミュニティカンファレンス（英語）、Salesforceユーザーグループ（英語）、社内チャネルで経験を共有することで、ほかの人が導入を進める助けになります。Salesforce開発者コミュニティに蓄積された率直な知見は、この移行を進めるうえで役に立つ最大の資産です。ぜひ活用し、経験を共有してください。コミュニティの重要性はますます高まっています。

これからのSalesforce開発者に求められるもの

これからは、もっと多くのSalesforce開発者が求められるようになります。必要とされるのは、システムを実装するだけでなく、設計できる開発者です。製品全体を頭の中で把握できる人です。的確な判断でAIをガイドし、スピード重視で健全性が損なわれそうなときには異議を唱え、エコシステム全体の成長につながるように学びを共有できる開発者です。

新しいツールで、可能性は大きく広がっています。重要なのは、かねてから優れたエンジニアが備えていた力、つまり判断力、文脈を捉える力、システム全体を理解しようとする姿勢なのです。

関連資料

• 開発者初級（Trailhead）
• Agentforce開発者ガイド（英語）
• Apex開発者ガイド
• Lightning Webコンポーネント開発者ガイド

執筆者について

René Winkelmeyer
開発者アドボカシーチームのリーダーとして、Agentforce、Data 360、Agentforce 360 Platformを担当。業務外でもコーディングを趣味とし、GitHubでコードを公開。LinkedInでのフォロー歓迎。

The post エージェント型AI時代におけるSalesforce開発者の未来 appeared first on Salesforce Developers Blog.

※本記事は2026年7月16日に米国で公開された Build with React on Salesforce: Multi-Framework Is Now GAの抄訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。

Salesforce Multi-Framework は、Headless 360 Platform 上で動作するフレームワーク非依存のランタイムです。Salesforce 上でネイティブに React アプリを構築し、GraphQL でレコードをクエリし、Apex を呼び出し、UI API を通じてユーザーコンテキストを読み取ることができます — 認証やトークン管理は一切不要です。Salesforce のセキュリティおよびガバナンスモデルと、React のエコシステムを、ひとつのランタイムで利用できます。

今年初めにオープンベータとしてローンチされた Salesforce Multi-Framework が、いよいよ正式リリース (GA) となりました。これは本番環境で利用可能であり、ビジネスクリティカルなワークロードでもサポートされ、Hyperforce 上で稼働する組織ではすでに有効化されていることを意味します。

Salesforce Multi-Framework GA リリースの新機能

ベータリリース以降に変更された点は次のとおりです。

• 本番組織のサポート: 本番組織、Scratch 組織、Developer Edition 組織、Sandbox にデプロイできるようになりました
• Salesforce App ドメイン: Multi-Framework の従業員向けアプリは、新しい salesforce.app ドメイン上で動作します。これは専用のオリジンであり、ブラウザーのネイティブな同一オリジンポリシーを通じて強固なセキュリティ境界を提供します
• Data SDK の更新: Data SDK が正式リリースとなり、GraphQL で Salesforce データをクエリするためのインターフェースと API が更新されました
• CustomApplication ターゲット: ベータ版の AppLauncher ターゲットは非推奨となり、従業員向けアプリでは CustomApplication が推奨されるようになりました

本番組織、Sandbox、Scratch 組織へのデプロイ

Multi-Framework は、Summer ’26 リリース以降のすべての Hyperforce 組織 — 本番組織、Sandbox、Developer Edition、Scratch — で利用可能になりました。従来の UiBundleSettings Scratch 構成設定は非推奨となりました。

お使いの組織が Salesforce Multi-Framework をサポートしているかどうかは、Salesforce の設定で React Development with Salesforce Multi-Framework(Salesforce マルチフレームワークを使用した React 開発) に移動することで確認できます。有効化されている組織では、「Salesforce App Domain」のトグルがオン(有効)になった状態で「About Salesforce Multi-Framework(Salesforce マルチフレームワークについて)」メッセージが表示されます。

新しい salesforce.app ドメイン

salesforce.app ドメインは、Multi-Framework の従業員向けアプリ専用の Web オリジンです。アプリの URL は https://<org>--<namespace>.<instance>.my.salesforce.app/app/c__<bundleName> というパターンに従います — 例: https://acme-corp-dev-ed--c.scratch.my.salesforce.app/app/c__myReactApp。各アプリはそれぞれ独自のオリジン上で動作するため、ブラウザーの同一オリジンポリシーがネイティブに分離を強制します。あるアプリが別のアプリの Cookie やストレージを読み取ることはできず、独自のサンドボックス化は不要になります。

Data SDK が GA に (破壊的な API 変更あり)

Data SDK (@salesforce/platform-sdk) は、React アプリが GraphQL で Salesforce レコードをクエリおよび更新できるようにするクライアントライブラリです。新しいパッケージ名になり、より明確な API サーフェスで提供されるようになりました。GraphQL のクエリおよびミューテーション自体に変更はありませんが、それらをラップするクライアントライブラリが変わりました。

クエリとミューテーションは、もはや単一の汎用的な graphql() メソッドを通じて処理されることはありません。読み取りには .query()、書き込みには .mutate() を呼び出すようになり、パラメーターのキーも操作の種類に対応します。

レスポンスの型付けもより厳密になりました。result.data は undefined になり得るものとしてモデル化されるようになったため、常に存在すると想定するのではなく、オプショナルチェイニング (result?.data?.uiapi) を使うことをおすすめします。

変更前 (ベータ):

import { createDataSDK, gql } from '@salesforce/sdk-data';

const sdk = await createDataSDK();
// Queries and mutations both used .graphql() with a `query` key
const result = await sdk.graphql?.<QueryResponse>({ query: MY_QUERY });
const mutationResult = await sdk.graphql?.<MutationResponse>({
  query: MY_MUTATION,
  variables: { input },
});

// result.data was assumed present
const edges = result?.data.uiapi?.query?.Account?.edges;

変更後 (GA):

import { createDataSDK, gql } from '@salesforce/platform-sdk';

const sdk = await createDataSDK();
// Reads use .query() with a `query` key
const result = await sdk.graphql?.query<QueryResponse>({ query: MY_QUERY });
// Writes use .mutate() with a `mutation` key
const mutationResult = await sdk.graphql?.mutate<MutationResponse>({
  mutation: MY_MUTATION,
  variables: { input },
});

// result.data is now potentially undefined — optional-chain through it
const edges = result?.data?.uiapi?.query?.Account?.edges;

UIBundle メタデータの変更

Multi-Framework アプリは、App Launcher から直接レンダリングされるのではなく、Custom Application メタデータを通じてプラットフォームに接続されるようになりました。.uibundle-meta.xml 内の <target> 要素にこの変更が反映されています。従業員向けアプリでは、ベータ版の AppLauncher 値は非推奨となり、CustomApplication が推奨されます。顧客向けアプリの Experience ターゲットは変更ありません。

ベータ期間中に AppLauncher を使用していた場合は、CustomApplication に更新してください。

<UIBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <masterLabel>My App</masterLabel>
    <description>A React app on Salesforce.</description>
    <isActive>true</isActive>
    <version>1</version>
    <target>CustomApplication</target>
</UIBundle>

バンドルにアクセスできるようにするには、それを参照する Custom Application も必要です。Custom Application メタデータが、UI Bundle を App Launcher に結び付けます。

<CustomApplication xmlns="http://soap.sforce.com/2006/04/metadata">
    <label>My React App</label>
    <navType>Standard</navType>
    <uiBundle>c__myReactApp</uiBundle>
    <uiType>Lightning</uiType>
    <formFactors>Large</formFactors>
</CustomApplication>

次に、権限セットを通じてアプリケーションへの表示権限を付与します。

<PermissionSet xmlns="http://soap.sforce.com/2006/04/metadata">
    <applicationVisibilities>
        <application>myReactApp</application>
        <visible>true</visible>
    </applicationVisibilities>
    <label>My React App Access</label>
    <hasActivationRequired>false</hasActivationRequired>
</PermissionSet>

ベータからの移行: 破壊的変更

ベータ版の Salesforce Multi-Framework 上で構築していた場合は、GA でデプロイする前に必ず次の 5 つの変更を行ってください。

1. インポートを @salesforce/sdk-data から @salesforce/platform-sdk に更新します。
2. graphql() の呼び出しを .query() (読み取り) と .mutate() (書き込み) に分割します。
3. result?.data にオプショナルチェイニングを使用します — undefined になり得るためです。
4. .uibundle-meta.xml 内の <target>AppLauncher</target> を <target>CustomApplication</target> に置き換え、<uiBundle> 参照を含む Custom Application メタデータファイルと、表示権限を付与する権限セットを追加します。
5. 非推奨となった UiBundleSettings Scratch 構成を削除します — もう不要です。

Multi-Framework ロードマップの今後

今後構築予定の機能は次のとおりです。

• マイクロフロントエンド: 外部でホストされている React コンポーネントを、Lightning Web コンポーネントと並べて Lightning に埋め込み、それらの間でイベントを受け渡しできるようにします
• Angular サポート: Angular を皮切りに、追加のフレームワークサポートを提供していきます
• ローカリゼーション: Translation Workbench またはメタデータを使用して、Multi-Framework コンポーネントを言語・ロケール・タイムゾーンをまたいでユーザーに適応させます
• 管理パッケージ: Multi-Framework アプリケーションを管理パッケージとして構築、テスト、配布、デプロイできるようにします
• アプリ管理: 名前、説明、URL といった基本的なアプリの詳細を App Manager から表示・管理できるようにします

これらの機能のリリースに関する更新情報やニュースについては、Salesforce Developer ブログをご確認ください。

リソース

• Introducing Salesforce Multi-Framework: 詳細なウォークスルーを含むベータ発表記事
• Multi-Framework ドキュメント: セットアップガイド、API リファレンス、ベストプラクティス
• Salesforce Multi-Framework Recipes: React on Salesforce のための 20 以上のコードサンプル

著者について

Alice Oh は Salesforce の Director of Product であり、Salesforce エコシステム全体でアプリを作成・バイブコーディング・公開するための柔軟で拡張性のある基盤製品の構築に取り組んでいます。空いた時間には、最もサクサクのクロワッサンを求めてベイエリアを自転車で走り回っています。彼女のフォローや連絡は LinkedIn からどうぞ。

Charles Watkins は独学のソフトウェア開発者であり、Salesforce の Lead Developer Advocate です。ブログの執筆、コードサンプルの作成、そしてパシフィックノースウェストで新しいハイキングスポットを探すことに時間を費やしています。彼のフォローは LinkedIn からどうぞ。

The post React で作り、Salesforce で動かす:Salesforce Multi-Framework が GA に appeared first on Salesforce Developers Blog.

Data from documentation, web searches, and CRMs necessary to ground agent responses can easily consume tens of thousands of tokens. This influx of data clogs valuable space across a multi-turn conversation, even if all of that data is not entirely relevant to your immediate task. Managing this “context tax” is one of the hardest parts of engineering production-grade agents..

MCP+ is a server-, agent-, and task-agnostic post-processing layer that wraps around your MCP clients to eliminate tool-driven context bloat. By intercepting tool outputs and extracting only the critical information that your agent actually needs, it slashes inference costs by up to 75% with zero modifications to your existing codebase. 

In this post, we’ll dive into how MCP+ works, walk through a concrete example, and show you how to get set up.

What is MCP+?

Built by Salesforce AI Research and open-sourced under Apache 2.0, MCP+ is an optimization layer for your AI workflows that is completely server, agent, and task-agnostic. Instead of flooding your agent’s context window with thousands of tokens of raw tool output, MCP+ transparently intercepts tool outputs and offloads the heavy lifting of data-sifting to high-speed, cost-effective models (like GPT-5-mini or Gemini 2.5 Flash). This helps you extract the precise data your agent needs before it ever touches your agent’s context — all configured via a simple, one-time CLI setup with zero code changes. 

MCP+ doesn’t make tool calls entirely for free. Instead, it trades a massive wall of expensive, frontier-model tokens for a tiny sliver of cheaper, lightweight model tokens.

Empirical research shows that this approach cuts token usage without significantly degrading performance. In rigorous benchmarks against token-heavy payloads in the developer ecosystem, like data from Playwright (raw HTML DOM), Yahoo Finance (structured JSON), and Google Search (Serper API payloads), MCP+ maintained comparable reasoning performance across Claude 4.0 Sonnet, GPT-5, and Gemini 3 Pro Preview models, while reducing token usage by up to 75%.

How does MCP+ know what to extract? 

The core breakthrough of MCP+ relies on a single, elegant concept: the expected_info argument.

When you run mcp-build-plus as part of its setup, it reads your existing MCP configuration file and generates a -plus version of each server. Your primary agent can now connect to this virtual proxy instead of the original server — using the same tools and the same schemas.

In the example above, the proxy_github.json generated keeps the details of the upstream MCP server to use and holds additional attributes needed.

Instead of requiring manual prompt engineering or workflow changes, MCP+ dynamically injects an expected_info parameter directly into each tool’s existing JSON input schema. When your primary agent reads its available tool definitions, it simply sees this as just another standard parameter.

Before MCP+:

// Tool Call: system_logs__fetch_log_tail
{
 "path": "/var/log/nginx/access.log",
  "line_count": 5000,
}

After MCP+:

// Tool Call: system_logs__fetch_log_tail
{
 "path": "/var/log/nginx/access.log",
  "line_count": 5000,
  "expected_info": "Look for the HTTP status code and error message associated with the failed checkout request" 
}

Because LLM agents are natively trained to follow schemas, your primary agent naturally and automatically populates this field based on its current task. Once your agent fills in expected_info, MCP+ uses it to guide what comes back. When a tool response exceeds the configured token threshold, MCP+ intercepts the raw output and routes it — along with the expected_info — to a configurable lightweight LLM. That model extracts the relevant details using two independent methods: a natural language summarisation and generated Python code that parses the raw data programmatically. Your agent receives both results in a focused, concise response instead of the full payload.

Let’s take a look at the mechanics of how this works.

MCP+ sits between your agent and the original MCP server as a transparent interception layer. The sequence diagram shows two phases:

• Tool Discovery: This happens once when your agent connects. The MCP+ wrapped client fetches the real tool schemas from the upstream server, injects an expected_info parameter into each one, and exposes them dynamically.. Your agent (Cursor, Claude Code) sees these modified schemas and naturally fills in the expected_info based on its current task.
• Tool Execution happens on every call:
  • Your agent calls a tool with its normal parameters plus expected_info. The WrappedMCPClient strips expected_info and forwards a clean request to the upstream MCP server.
  • The raw response comes back. MCP+ checks the token count against a configurable threshold.
    • Below threshold: The response passes through unchanged. Minimal added latency.
    • Above threshold: The response is routed to the PostProcessAgent, this uses a lightweight model that produces both a direct text extraction and generated Python filtering code.
  • The SafeCodeExecutor runs the generated code in a sandbox against the raw output.
  • The results: both direct extraction and code-based extraction are returned to the agent.

If post-processing fails for any reason, MCP+ falls back to the original output.

Dual post-processing strategy

Rather than relying on a single extraction method, the PostProcessAgent produces two independent results:

• Direct extraction: The lightweight LLM reads the raw output alongside the expected_info target to pull out the relevant text fragments. This is ideal for unstructured data, like conversational logs or documentation pages, but is occasionally lossy on structured data.
• Code generation: The same LLM generates Python code that programmatically filters, parses, or transforms the raw output. This handles structured formats (JSON arrays, HTML tables, nested XML) with precision that natural language extraction can miss.

This dual approach, semantic extraction and programmatic code execution, blends the best of both worlds. If either fails, MCP+ retries automatically (up to a configurable limit). Only when both methods are exhausted does the original unfiltered output pass through. Your agent never receives less information than it would without MCP+.

The SafeCodeExecutor

The code-generation method means MCP+ is executing LLM-generated Python at runtime. This could come with some risk without some guardrails in place. The SafeCodeExecutor constrains what that code can do.

• Imports like os.system, os.popen,subprocess, ctypes, pickle, and eval/exec are blocked via string-matching before the code runs to defend against obviously dangerous operations. The code receives the raw output as a data variable and writes its filtered result to result. If result is never set, the original data passes through unchanged.
  
• A 10-second execution timeout kills any long-running or recursive operations (not enforced on Windows systems). Scoped variables: the code runs in a namespace initialised with only data and result.

The sandbox ensures that even if the lightweight model generates something unexpected, the code has limited access beyond the raw output string it was given.

Intelligent activation

Not every tool response needs filtering. MCP+ uses two guardrails to protect against unnecessary latency and hallucinated expansion:

• Token threshold gate: This acts as a redundancy guard to ensure that post-processing is only triggered when there is a meaningful return on investment. A configurable token_threshold (default: 2,000 tokens) determines the minimum output size that triggers post-processing. Responses below this pass through to the agent untouched since there’s no value in routing a 200-token response through a lightweight model only to get back 180 tokens. It also avoids the risk of the post-processor misinterpreting a short, already-concise response and returning something less accurate than the original.
• Output size ceiling: This guards against hallucination. The lightweight model can sometimes elaborate on source data, add explanation, or wrap extractions in verbose formatting — producing more tokens than the original. MCP+ enforces that each extracted output stays under 50% of the original token count. If both extraction methods exceed this, the original output is returned unchanged. Your agent never receives an inflated payload as a result of post-processing.

A concrete example of MCP+ in action

Say your agent is helping you triage issues on a GitHub repository, let’s say for lwc-recipes (which includes easy-to-digest code examples for Lightning Web Components).

You ask: “How many issues in the last year have had problems with deployment on trailheadapps / agent-script-recipes”.

The agent calls the GitHub MCP server’s search_issues tool with appropriate arguments.

Arguments: {
"query": "How many issues in the last year have had issues with deployment",
"owner": "trailheadapps",
"repo": "agent-script-recipes"}, 
"expected_info": "The number of issues in the last year with deployment issues" 
}

The tool arguments do the heavy lifting, filtering to deployment-related issues across the repository. The agent used the tool call correctly: the GitHub MCP server successfully processes the request, returning a massive JSON payload containing six issues complete with full markdown bodies with steps to reproduce, empty template fields, reaction counts and avatar URLs. MCP+ optimizes this response on the fly, and because it knows that the agent only needs a count of deployment issues, it strips away the structural noise before the data ever hits your agent’s context window. 

Without MCP+: 38,693 characters of raw JSON.

{"total_count":6,"incomplete_results":false,"items":[{"id":4416618502,"number":98,
  "state":"closed","state_reason":"completed","locked":false,"title":"Unable to deploy",
  "body":"### Summary\n\nHello,\nI am trying to deploy the project on a new org without
  success.\n\n\n\n\n\n### Salesforce Org Type\n\nDeveloper Edition Org\n\n### Steps To
  Reproduce\n\n1. Connect Org\n2. Run deploy with : sf project deploy start -d force-app
  \n\n### Current Behavior\n\nFailed deploy with a lot of error\nAll of the errors are
  in the follwoing CSV file\n[errors.csv](https://github.com/user-attachments/files/
  27572897/errors.csv)\n\n### Expected Behavior\n\n_No response_\n\n### Relevant Log  ─────────────┤\n│ AiAuthoringBundle │ ActionChaining/ActionChaining │ Not available
  for deploy for this organization │ │\n│ AiAuthoringBundle │ ActionChaining/
  ActionChaining │ Not available for deploy for this organization │ │\n...
...continues for 38,693 characters with avatar URLs, event endpoints, subscription URLs, and five more issues.

With MCP+: The PostProcessAgent fires and both extraction methods return independently.

Direct extraction: 

Based on the search results, there are 6 total issues in the repository.
Of these, 4 issues are related to deployment problems:

1. Issue #98 (Closed) - "Unable to deploy" - Created 2026-05-10, deployment
   failures with AiAuthoringBundle and GenAiPromptTemplate components
2. Issue #83 (Open) - "Unable to test Custom Lightning Type Agent in Namespaced
   Scratch Orgs" - Created 2026-04-29, compilation error when deploying to
   namespaced scratch orgs
3. Issue #66 (Closed) - "Unable to Deploy the App to Org" - Created 2026-03-15,
   deployment limit error
4. Issue #41 (Closed) - "The deployment of recipes fail in latest sandbox due to
   missing default_agent_user" - Created 2026-01-09, deployment failure due to
   missing default_agent_user configuration

Additionally, Issue #58 (Open) and Issue #74 (Closed) are related to deployment/configuration concerns but are categorized as enhancements rather than pure deployment bugs.

Code-based extraction: 

{"total_issues": 6, "deployment_related_issues": 6, "issues": [
    {"number": 98, "title": "Unable to deploy", "state": "closed", "created_at": "2026-05-10T19:37:14Z", "labels": ["bug"]},
    {"number": 83, "title": "Unable to test Custom Lightning Type Agent in Namespaced Scratch Orgs", "state": "open", "created_at": "2026-04-29T12:43:58Z", "labels": ["bug"]},
    {"number": 58, "title": "Add example of Service Agent and show a DX pipeline to handle the Agent user", "state": "open", "created_at": "2026-02-20T15:24:40Z", "labels": ["enhancement"]},
    {"number": 66, "title": "Unable to Deploy the App to Org", "state": "closed", "created_at": "2026-03-15T12:01:48Z", "labels": ["bug"]},
    {"number": 74, "title": "Replace list[object] variables with specific primitive list types", "state": "closed", "created_at": "2026-04-21T17:05:58Z", "labels": ["enhancement"]},
    {"number": 41, "title": "The deployment of recipes fail in latest sandbox due to missing default_agent_user", "state": "closed", "created_at": "2026-01-09T23:20:27Z", "labels": ["bug"]}
  ]}

The agent receives ~2,588 chars instead of 38,693, which is a 93% reduction. That’s with the API already doing its job: the right query, scoped to the right GitHub repository. MCP+ strips the structural noise, leaving just what’s needed: the number of deployment issues. Across a multi-turn session, where your agent makes ten or twenty tool calls, these reductions compound into meaningful token savings and a cleaner context window for reasoning.

When should you use MCP+?

MCP+ is highly effective in scenarios where your agent workflows encounter the following patterns:

• Tool outputs regularly exceed 2,000 tokens: Search APIs and data retrieval tools routinely return massive payloads where only a small fraction is relevant to the immediate task.
• Your agent only needs specific data points from verbose responses: For example, this could be pulling a single price, a specific error code, or a date out of an entire system log or documentation page.
• You are working heavily with structured data: Payloads formatted in JSON, HTML, XML, or tables are where the code-generation method shines, delivering deterministic extraction precision.
• Token costs or context window limits are a real constraint: MCP+ prioritizes keeping your primary agent’s context window clean for actual reasoning rather than hoarding raw tool payloads.
• Your agent makes multiple tool calls per session: Even a savings of just 10-15% per turn compounds across a ten- or twenty-turn conversation. Over hundreds of active sessions, that compounding effect completely transforms the long-term economics of your production architecture.

Conversely, MCP+ will deliver minimal value or introduce unnecessary overhead in workflows that match the following patterns:

• Tool outputs are already concise: If your tools return under 2,000 tokens, the post-processing overhead exceeds the savings.
• Your agent genuinely requires the full, unedited payload: If your primary agent’s explicit task is to perform an exhaustive, line-by-line analysis, a comprehensive summary, or a direct effort to compare and contrast details across a massive text block, filtering the data beforehand can be counterproductive.
• Sub-second latency is a hard requirement: Post-processing introduces at least one additional LLM round-trip into the tool lifecycle, and applications that require instantaneous, sub-second responses should opt to pass the raw payload directly to the agent.

Getting started with MCP+

MCP+ is open source under the MCP-Universe repository. Because its built-in threshold gating automatically manages when to optimize and when to step aside, you can seamlessly wrap your entire MCP client configuration without worrying about manual performance profiling. Install it today to keep your agent’s context window clean, predictable, and focused entirely on reasoning. You just need an API key from your chosen model.

MCP+ wraps both local stdio-based servers and remote HTTP/SSE servers. For stdio servers, it intercepts the stream between your agent and the upstream process. For remote servers, including hosted endpoints like GitHub’s https://api.githubcopilot.com/mcp/, you can provide the URL directly with optional auth headers, and MCP+ will abstract away the HTTP communication seamlessly. 

Regardless of which server type you are running, deployment takes only a few minutes. To configure the proxy layer for your environment and start optimizing your live tool workflows, follow these steps:

Step 1: Install

pip install mcpuniverse

Step 2: Set your post-processing LLM key

export OPENAI_API_KEY="sk-..."
# or GEMINI_API_KEY, ANTHROPIC_API_KEY

Step 3: Build your MCP+ config

Point the CLI at your existing MCP configuration.

mcp-build-plus --mcp-config path/to/your/mcp.json

That’s it. Your existing MCP servers are now wrapped — no application code changes required. Any agent that connects will see expected_info as a parameter on every tool, and large responses will be filtered automatically with MCP servers that you specify.

The CLI also accepts fine-tuning options, such as:

TABLE HERE

For example, here’s how to wrap only your Salesforce DX MCP server using Google’s Gemini Flash 2.5 as the post-processor with a 1,000-token threshold:

mcp-build-plus --mcp-config mcp.json \
  --llm-provider gemini \
  --llm-model gemini-2.5-flash \
  --token-threshold 1000 \
  --servers salesforce-dx-mcp

The CLI creates a <server-name>-plus entry in your MCP config that runs a Python process via stdio. Your IDE connects to this virtual proxy, which mirrors all upstream tool schemas with expected_info injected and routes large responses through the post-processor. The original server entry remains untouched.

Programmatic usage of MCP+

The CLI handles most use cases, but if you need to integrate into an existing Python pipeline, you can also configure MCP+ programmatically. Here’s how to code the GitHub example above:

from mcpuniverse.extensions.mcpplus.wrapper import MCPWrapperManager, WrapperConfig
from mcpuniverse.llm import OpenAIModel

wrapper_config = WrapperConfig(
    enabled=True,
    token_threshold=2000,
    max_iterations=3
)

manager = MCPWrapperManager(
    config={
        "github": {
            "stdio": {
                "command": "./github-mcp-server",
                "args": ["stdio"]
            },
            "env": {"GITHUB_PERSONAL_ACCESS_TOKEN": os.environ["GITHUB_TOKEN"]}
        }
    },
    wrapper_config=wrapper_config
 )

llm = OpenAIModel(config={
    "model_name": "gpt-5-mini",
    "api_key": os.environ["OPENAI_API_KEY"]
})
manager.set_llm(llm)

client = await manager.build_client("github")
result = await client.execute_tool(
    tool_name="search_issues",
    arguments={
        "query": "deploy",
        "owner": "trailheadapps",
        "repo": "agent-script-recipes",
        "expected_info": "How many issues in the last year have had issues with deployment"
    }
)

Resources

• GitHub repository: MCP Universe 
• Documentation: MCP+ home page
• Documentation: Token Counting
• Documentation: Context Windows

About the authors

Prathyusha Jwalapuram is an Applied Scientist with the Salesforce AI Research team specializing in code agents. Her work focuses on pushing the boundaries of agentic research and optimizing Apex code generation. She developed MCP+ to bridge the gap between powerful tool-calling protocols and the practical constraints of token costs and context window management in production environments.

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

The post Get Started with Precision Context Management Using MCP+ appeared first on Salesforce Developers Blog.

Launched in open beta earlier this year, Salesforce Multi-Framework is now generally available. That means it’s production-ready, supported for business-critical workloads, and already enabled in orgs running on Hyperforce.

What’s new in the Salesforce Multi-Framework GA release

Here’s what has changed since the beta release:

• Production org support: You can deploy to production orgs, scratch orgs, Developer Edition orgs, and sandboxes
• Salesforce App domain: Multi-Framework employee-facing apps run on the new salesforce.app domain, a dedicated origin that provides hard security boundaries through the browser’s native Same Origin Policy
• Data SDK updates: The Data SDK is now generally available with updated interfaces and APIs for querying Salesforce data with GraphQL
• CustomApplication target: The beta’s AppLauncher target has been deprecated in favor of CustomApplication for employee-facing apps

Deploy to production, sandbox, and scratch orgs

Multi-Framework is now available on all Hyperforce orgs — production, sandbox, developer edition, and scratch — on the Summer ’26 release or later. The old UiBundleSettings scratch configuration setting has been deprecated.

You can confirm your org has Salesforce Multi-Framework support by navigating to React Development with Salesforce Multi-Framework in Salesforce Setup. Enabled orgs show an “About Salesforce Multi-Framework” message with the “Enable Salesforce App Domain” toggle on.

The new salesforce.app domain

The salesforce.app domain is a dedicated web origin for Multi-Framework employee-facing apps. Your app’s URL follows the pattern https://<org>--<namespace>.<instance>.my.salesforce.app/app/c__<bundleName> — for example, https://acme-corp-dev-ed--c.scratch.my.salesforce.app/app/c__myReactApp. Each app runs on its own origin, so the browser’s Same Origin Policy enforces isolation natively. One app can’t read another’s cookies or storage, which means there’s no need for proprietary sandboxing.

Data SDK is GA (with a breaking API change)

The Data SDK (@salesforce/platform-sdk) is a client library that lets React apps query and mutate Salesforce records with GraphQL. It now ships under a new package name and a clearer API surface. Your GraphQL queries and mutations are unchanged, but the client library that wraps them is different.

Queries and mutations are no longer funneled through a single generic graphql() method. You now call .query() for reads and .mutate() for writes, and the parameter key matches the operation type.

The response typing is also stricter: result.data is now modeled as potentially undefined, so you’ll want to optional-chain through it (result?.data?.uiapi) rather than assuming it’s always present.

Before (beta):

import { createDataSDK, gql } from '@salesforce/sdk-data';

const sdk = await createDataSDK();
// Queries and mutations both used .graphql() with a `query` key
const result = await sdk.graphql?.<QueryResponse>({ query: MY_QUERY });
const mutationResult = await sdk.graphql?.<MutationResponse>({
  query: MY_MUTATION,
  variables: { input },
});

// result.data was assumed present
const edges = result?.data.uiapi?.query?.Account?.edges;

After (GA):

import { createDataSDK, gql } from '@salesforce/platform-sdk';

const sdk = await createDataSDK();
// Reads use .query() with a `query` key
const result = await sdk.graphql?.query<QueryResponse>({ query: MY_QUERY });
// Writes use .mutate() with a `mutation` key
const mutationResult = await sdk.graphql?.mutate<MutationResponse>({
  mutation: MY_MUTATION,
  variables: { input },
});

// result.data is now potentially undefined — optional-chain through it
const edges = result?.data?.uiapi?.query?.Account?.edges;

UIBundle metadata changes

Multi-Framework apps are now wired into the platform through Custom Application metadata rather than rendering directly from the App Launcher. The <target> element in .uibundle-meta.xml reflects the change: for employee apps, the beta’s AppLauncher value has been deprecated in favor of CustomApplication. The Experience target for customer-facing apps remains unchanged.

If you used AppLauncher during beta, update it to CustomApplication.

<UIBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <masterLabel>My App</masterLabel>
    <description>A React app on Salesforce.</description>
    <isActive>true</isActive>
    <version>1</version>
    <target>CustomApplication</target>
</UIBundle>

To make the bundle accessible, you also need a Custom Application that references it. The Custom Application metadata ties your UI Bundle to the App Launcher.

<CustomApplication xmlns="http://soap.sforce.com/2006/04/metadata">
    <label>My React App</label>
    <navType>Standard</navType>
    <uiBundle>c__myReactApp</uiBundle>
    <uiType>Lightning</uiType>
    <formFactors>Large</formFactors>
</CustomApplication>

Then grant visibility to the application through a permission set.

<PermissionSet xmlns="http://soap.sforce.com/2006/04/metadata">
    <applicationVisibilities>
        <application>myReactApp</application>
        <visible>true</visible>
    </applicationVisibilities>
    <label>My React App Access</label>
    <hasActivationRequired>false</hasActivationRequired>
</PermissionSet>

Migrating from beta: The breaking changes

If you built on the beta version of Salesforce Multi-Framework, be sure to make these five changes before deploying on GA:

1. Update your import from @salesforce/sdk-data to @salesforce/platform-sdk.
2. Split graphql() calls into .query() (reads) and .mutate() (writes).
3. Optional-chain through result?.data — it can now be undefined.
4. Replace <target>AppLauncher</target> with <target>CustomApplication</target> in your .uibundle-meta.xml, and add a Custom Application metadata file with a <uiBundle> reference plus a permission set granting visibility.
5. Remove the deprecated UiBundleSettings scratch config — it’s no longer needed.

What’s next on the Multi-Framework roadmap

Here’s what we’re building next:

• Microfrontends: Embed externally hosted React components in Lightning alongside Lightning web components and pass events between them
• Angular support: We’re bringing additional framework support starting with Angular
• Localization: Adapt your Multi-Framework components to your users across languages, locales, and timezones using Translation Workbench or metadata
• Managed packages: Build, test, distribute, and deploy Multi-Framework applications as managed packages
• App management: View and manage basic app details — name, description, URL — from App Manager

Check back with the Salesforce Developer’s blog for updates and news as these features are released.

Resources

• Introducing Salesforce Multi-Framework: Beta announcement with detailed walkthrough
• Multi-Framework documentation: Setup guide, API reference, and best practices
• Salesforce Multi-Framework Recipes: 20+ code samples for React on Salesforce

About the authors

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

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

The post Build with React on Salesforce: Multi-Framework Is Now GA appeared first on Salesforce Developers Blog.

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.