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

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

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

事前準備

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

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

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

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

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

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

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

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

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

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

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

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

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

# ローカルで実行
npm run dev

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

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

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

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

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

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

npm run build

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

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

sf project deploy start

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

ステップ3: 動作確認

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# ビルドの実行
npm run build

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

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

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

ステップ6: 動作確認

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

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

おわりに

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

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

• Github: Agentforce Vibes Library

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

参考資料

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

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

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

The “runtime reality” gap

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

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

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

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

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

Engineering the bottom-up approach

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

1. Identifying the heavy lifters

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

2. Intelligence-driven reconstruction

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

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

3. Execution-plan analysis 

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

Case study: The dynamic predicate problem

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

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

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

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

Example: The non-selective null

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

SELECT Id, Name FROM Account WHERE name = null

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

Example: The polymorphic date bloat

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

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

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

Comparing static analysis and Database Insights

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

How to use Database Insights results

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

A game changer for architects and developers

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

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

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

About the author

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

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

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

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

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

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

動画:利用イメージ

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

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

何をする機能なのか

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

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

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

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

プロンプトについて

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

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

プロンプト全文

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

名称を指定します

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

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

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

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

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

フローの構造

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

STEP 1:レコードの取得

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

STEP 2:音声入力画面

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

STEP 3:AIによる解析

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

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

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

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

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

STEP 4:レコードの更新

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

補足:

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

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

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

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

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

現場への展開イメージ

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

たとえば:

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

まとめ

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

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

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

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

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

Why use complex expressions?

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

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

Getting started with the syntax

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

Logical and arithmetic operators

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

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

Using expressions in attributes

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

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

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

Staying HTML compliant

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

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

LWC complex template expression limitations and restrictions

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

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

Conclusion

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

Resources

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

About the Author

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

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

Salesforce Hosted MCP Server は、AIエージェントが Salesforce データと自動化機能に安全かつ管理された方法でアクセスできるプラットフォームを提供します。Claude、ChatGPT、Cursor などの MCP に対応するクライアントから、Salesforce に接続できるようになります。

この記事では、Hosted MCP Server の初期セットアップ方法について、外部クライアントアプリケーションの作成から MCP Server の有効化、そしてクライアントからの試行までを順に解説します。

免責事項: この記事は 2026年4月16日時点の情報で作成しています。その後の更新や機能追加により画面や操作ステップが変更になっている場合もあります。あらかじめご了承ください。

参考

• Salesforce Hosted MCP Servers

設定の流れ

1. 外部クライアントアプリケーションを作成
2. 使いたい MCP Server を有効化
3. クライアント側での設定追加・有効化

今回は Developer Edition & システム管理者での操作で解説します。

外部クライアントアプリケーションを作成

まずは、MCP クライアントからのアクセスを Salesforce で認証・認可できるように外部クライアントアプリケーションを作成します。

• 設定 -> アプリケーション -> 外部クライアントアプリケーション -> 外部クライアントアプリケーションマネージャー
• 「新規外部クライアントアプリケーション」ボタンを押す

必要情報を入力します。

• 外部クライアントアプリケーション名:
  • (任意の名前)
• API 参照名:
  • (任意の名前)
• 取引先責任者メール:
  • (管理者のメールアドレス)

そのまま少し画面を下げます。

• OAuth を有効化:
  • チェックを入れる
• コールバック URL:
  •  使用するクライアントアプリに応じて適切なものを設定
  • 画像例では localhost にしているが、Claude Desktop で使う場合は「https://claude.ai/api/mcp/auth_callback」にするなど
  • 参考: Steps to Create an External Client App
• OAuth 範囲:
  •  次の二つを選択
    • いつでも要求を実行(refresh_token, offline_access)
    • Salesforce でホストされている MCP サーバーにアクセス (mcp_api)

そのまま少し画面を下げます。

• セキュリティ: 次の二つのみを選択
  • サポートされる認証フローに Proof Key for Code Exchange (PKCE) 拡張を要求
  • 指名ユーザーの JSON Web トークン (JWT) ベースのアクセストークンを発行
• 「作成」ボタンを押す

• 「設定」タブに切り替え

そのまま画面を少し下げます。

• OAuth 設定のアコーディオンを開く
• 「コンシューマー鍵と秘密」ボタンを押す

• メールで送られてくる確認コードを入力

• コンシューマー鍵をコピーしておく

以上で外部クライアントアプリケーションの作成は完了です。

使いたい MCP サーバーを有効化

提供する機能によってサーバーが分かれています。ここでは「sobject-reads」を有効化して使用できるようにします。

• 設定 -> インテグレーション -> API カタログ -> MCP サーバー
• 一覧から「sobject-reads」の名前のリンクを押す

• 画面右上「有効化」ボタンを押す

サーバー状態が「稼働中」に変われば有効化が完了です。また、ツールタブから、実際にこの MCP サーバーが提供しているツール(機能)の一覧を確認できます。

以上で MCP サーバーの有効化は完了です。

ちなみにこの機能で面白いところは、カスタムの MCP サーバーを作成し、フローや Apex をツールとして登録、クライアントとなる生成 AI アプリやエージェントから自然言語で呼び出せるようになる点です。もちろん、皆さんが作ったフローや Apex も対象で、ノーコードでクライアントから呼び出せるようにすることができます。

クライアント側での設定追加・有効化

ここでは Claude Desktop アプリでの設定を例に見てみましょう。

注意: ここからは他社プロダクトになります。画面表示や操作パスは予告なく変更になる場合がありますので、必ずお使いになるプロダクトの最新情報をご確認ください。

• カスタマイズ -> コネクタ -> 「+(追加ボタン)」 -> 「カスタムコネクタを追加」を押す

必要事項を入力します。

• コネクタ名は任意のもので良い
• URL は Salesforce の設定画面にある MCP サーバーの Server URL を指定
• 詳細設定を開き、OAuth のクライアント ID のみを設定

• 「連携/連携させる」ボタンを押す。

• ブラウザが開くので連携で使うユーザーを選ぶ

• 内容を確認し「許可」ボタンを押す

次のような画面になれば成功です。

• 「デスクトップアプリを開く」ボタンを押す

ツールの一覧が見えてくれば接続も無事できています。

以上でクライアント側の設定は完了です。クライアントによって設定の仕方が異なりますので、それぞれの設定の仕方をご確認ください。

動作検証

それでは動作検証をしてみましょう。先ほど設定した Claude Desktop で会話してみます。

• 「こんにちは！Salesforce にアクセスして、取引先の一覧を見せて」

次のように回答が返ってくれば成功です。

違う聞き方もしてみましょう。

おわりに

この記事では、Salesforce Hosted MCP Server の初期セットアップから使い始めるまでの流れについて解説しました。

これまで、生成 AI アプリ・エージェントなどから Salesforce のデータにアクセスするためには、独自の API アクセスラッパーのようなものを構築する必要がありましたが、Hosted MCP Server を使えば、一度設定するだけで複数の MCP 対応クライアントから Salesforce にアクセスできるようになります。フィールドレベルセキュリティや共有ルールも尊重されるため、安全に AI エージェントを活用できます。

ぜひ、Developer Edition で Hosted MCP Server を試してみてください。AI エージェントと Salesforce の連携により、新しい可能性が広がります！

The post Salesforce Hosted MCP Server 使い始め appeared first on Salesforce Developers Blog.

株式会社アストロ・エンタープライズ(架空の会社名)では、各プロジェクトの経費管理を Salesforce 上で行っています。通常、プロジェクト予算は厳格に管理されており、予算残高がマイナスになるような経費の支出はシステムでブロックする必要があります。 しかし、現場からは「災害時や緊急トラブル対応時には、承認を待たずに予算超過してでも経費を計上したい」という強い要望が出ています。

あなたはシステム管理者兼開発者として、この「原則禁止、ただし緊急時は例外」という柔軟かつ堅牢なロジックと、現場が使いやすい操作画面をゼロの状態から構築しなければなりません。

更新履歴

1. 2026/4/22: ロジックの実装手段について、当初の記載に縛られず、Salesforce の標準提供 & 基盤上で動作するものであれば良いように修正
2. 2026/4/21: カスタムオブジェクトへの項目作成で、項目の説明は実装時には入力不要である旨を追記

実装要件

以下のコンポーネント作成から画面カスタマイズ、ロジック実装までのすべての工程を録画に含めてください。

1. カスタムオブジェクトと項目の作成

※記載以外のオブジェクトや項目を作っても構いませんが、加点はされません。「録画提出の手順と完了定義」のステップ3 動作検証（証明操作）が記述通り完了すれば良し、とします。

2. 画面カスタマイズ（UI/UX）

• プロジェクトのレコード詳細画面:
  • 関連リストとして「経費」オブジェクトが表示されるように設定してください。
  • 関連リストには「経費名」「金額」「緊急フラグ」の各項目が表示されている必要があります。
  • 重要: プロジェクトのレコード詳細と関連リストは、タブの切り替えではなく、同一ページ内に同時に表示されるように配置してください。

3. 予算超過の制御ロジック（基本ルール）

• 目的: 通常時、プロジェクトの「予算残高」が 0 未満（マイナス）になるような保存を禁止する。
• エラーメッセージ: 「予算が不足しています。経費を計上できません。」
• 実装手段: 数式、入力規則、フロー、または Apex トリガーなど Salesforce が標準で提供し基盤上で動作する機能を単独、もしくは必要に応じて組み合わせて実装。

4. 自動減算ロジックの実装

• 内容: 経費レコードが作成された際、親プロジェクトの「予算残高」から経費の「金額」を差し引く。
• 実装手段: 数式、入力規則、フロー、または Apex トリガーなど Salesforce が標準で提供し基盤上で動作する機能を単独、もしくは必要に応じて組み合わせて実装。今回はバルク更新を考慮せず画面操作での1件 & 新規作成のみが対象で良い。

5. 緊急承認ロジック（例外要件）

• 目的: 現場の緊急事態に柔軟に対応するため、特定の条件下で基本ルールをスキップさせる。
• 要件: 経費レコードの「緊急フラグ」が ON の場合は、要件3で定義した「予算超過の制限」を無視し、予算残高がマイナスになっても正常に保存を完了させること。

録画提出の手順と完了定義

以下の操作手順をすべて含む、開始から完了までは無編集の 1 本の画面操作録画を作成してください。

操作にあたっては禁止事項があります。(ブラウザのオートコンプリート禁止、事前に用意したコードのコピー&ペースト禁止など)

詳しくはイベント概要&予選参加ガイド「操作にあたっての制約」を参照してください。

ステップ 1：開始確認

1. 設定のホームを表示させた状態から録画を開始する。
   • Trailhead Playground で新規に取得した直後の状態
   • 事前設定は表示言語が日本語以外の場合は日本語に変えることのみを可とする

※「設定のホーム」画面であれば表示内容に差異があっても良いです。

ステップ 2：環境構築（実装操作）

1. オブジェクト作成: 指定された 2 つのオブジェクトと項目を作成する。
2. 画面カスタマイズ: プロジェクトのレコードページを編集し、関連リストを配置する。
3. ロジック実装: 「予算減算」「超過制御」「緊急例外」の各ロジックを実装・有効化する。

ステップ 3：動作検証（証明操作）

1. テストデータの準備:
   • 「プロジェクト」レコードを作成し、プロジェクト名: プロジェクト1、予算残高: 100,000 と入力して保存する。
2. 通常時のブロック確認（要件3の証明）:
   • 関連リストから「経費」を新規作成する。
   • 経費名: 経費1、金額: 150,000、緊急フラグ: OFF で保存を試み、エラーメッセージが表示されることを示す。
3. 緊急時の許可確認（要件5の証明）:
   • 同じ入力画面のまま、緊急フラグ: ON に変更して保存し、成功することを示す。
4. 最終結果の確認（要件2・4の証明）:
   • 親の「プロジェクト」レコード詳細画面で、予算残高が -50,000 になり、かつ関連リストに経費が表示されていること、レコードの項目として経費名、金額、緊急フラグが表示されていることを示す。

ステップ 4：終了確認

1. ステップ3-4操作完了時の画面で、録画を終了する。

※アプリケーションがセールスである必要はありません。

お問い合わせ

実装要件や録画方法について不明点や質問がありましたらイベント概要&予選参加ガイドをご確認の上、コミュニケーション用の Slack ワークスペースの指定のチャンネルでお尋ねください。

Happy Hacking!

The post Lightning MiniHack Live 予選実装要件: 予算超過を打破せよ！緊急承認ロジックの実装 appeared first on Salesforce Developers Blog.

Why this matters to developers

Most teams treat performance analysis as a late-stage activity. Code gets written, reviewed, tested, and deployed, and only then do the costly problems show up: SOQL in loops, unbounded queries, expensive schema lookups, or queries that fetch more data than the code actually uses. By that point, fixing those issues often means rework, delay, and production cleanup.

ApexGuru changes that sequence. In the Agentic DX MCP workflow, performance analysis can happen in the same loop as writing code, reviewing code, and preparing changes for deployment. That means developers can catch issues before they become runtime incidents or technical debt. This is especially useful because ApexGuru is not just a generic static check. In Salesforce DX MCP Server, the scale-products toolset includes the GA tool scan_apex_class_for_antipatterns, which analyzes Apex classes for performance antipatterns and then returns detections grouped by severity along with fix guidance. When connected to an org where ApexGuru is enabled, the severity assessment can also reflect runtime-informed context rather than static structure alone.

From Code Analyzer to Salesforce DX MCP Server

The shift-left journey of ApexGuru did not start with MCP. It had already begun moving into the developer workflow through its integration with Code Analyzer, where developers could authorize an ApexGuru-enabled org and scan a selected Apex class directly from the editor for performance issues. Unlike Code Analyzer, however, ApexGuru itself is available only in Production and Full Copy Sandbox orgs for Unlimited, Enterprise, Professional, and Signature Editions.

ApexGuru Insights in Code Analyzer can still be surfaced in earlier-stage environments when ApexGuru has already been activated in Production or Full Copy Sandbox orgs. In practice, this allows developers to view ApexGuru Insights through Code Analyzer in Developer Sandbox, Partial Copy Sandbox, and Scratch Orgs where the Developer Hub is backed by a Production or Full Copy org. That brought ApexGuru from an app experience into an IDE-assisted workflow and extended performance analysis further left in the development lifecycle.

Salesforce DX MCP Server builds on that foundation. ApexGuru first established a runtime-aware, specialized AI approach to detecting Apex performance antipatterns, then moved closer to the developer workflow through Code Analyzer integration in Visual Studio Code (VS Code). With DX MCP, ApexGuru takes the next step by expanding into broader MCP-based and agentic workflows across clients such as Agentforce Vibes, Claude Code, Cursor, Cline, and other MCP-compatible developer environments. Code Analyzer brought ApexGuru into the IDE, while Salesforce DX MCP Server broadens its reach and makes ApexGuru available as part of a more flexible, agent-driven development experience.

What ApexGuru adds to Salesforce DX MCP Server

ApexGuru is especially useful in Salesforce DX MCP Server because it brings performance analysis into the same workflow where developers are already writing and reviewing code. A class can compile, pass tests, and still carry avoidable CPU cost, query inefficiency, or scalability risk. ApexGuru helps surface those issues earlier, before they turn into runtime incidents or costly cleanup later.

With Salesforce DX MCP Server, the flow becomes much simpler. You write code, ask your MCP client to scan the class, review the antipatterns and severity, and apply the recommended fixes before you commit or deploy. Performance is no longer a separate destination. It becomes part of the development loop.

Designing performance guidance for agentic workflows

To truly empower an AI agent to act as a performance engineer, we had to move beyond simple API wrappers and design for context exchange. That is, we had to design for a workflow that combines local code context with org-side runtime context. The core challenge in bringing ApexGuru to agentic IDEs was bridging two completely different environments: the developer’s local machine (where the unsaved code lives) and the Salesforce org (where the runtime telemetry lives).

To solve this, we mapped ApexGuru to the MCP as an executable tool within the Salesforce DX MCP Server. The Salesforce DX MCP Server runs locally, so it can inspect the developer’s file directly while also using Salesforce CLI authentication to access org-side runtime context.

When an agent invokes the scan_apex_class_for_antipatterns tool, the invocation requires specific parameters: the className and the absolute apexFilePath. Behind the scenes, the tool does not rely on simple regular expressions; it utilizes Abstract Syntax Tree (AST) parsing to accurately analyze the local code’s syntax, tracking method context and loop depth.

The real magic happens when this local static analysis is combined with remote telemetry. The tool connects to your authorized org to see if the detected pattern (such as a Schema.getGlobalDescribe() call) is actually causing high CPU usage in a Production or a Full Copy Sandbox org. It then returns a JSON-structured payload to the agent containing the antipattern type, the runtime-informed severity level, the problematic code snippet, and explicit fix instructions. Because the output is structured, an MCP-compatible client can reliably summarize the finding, explain why it matters, and help display a potential fix in the editor.

To enable this agentic experience in an MCP-compatible client, simply define the Salesforce DX MCP Server in your configuration file and pass the --toolsets scale-products flag.

Much more than a static scan wrapped in chat, ApexGuru in Salesforce DX MCP Server provides a way to bring local code analysis and org-aware prioritization into the same workflow, so developers can decide what to fix first while they are still coding.

What the experience looks like in practice

ApexGuru in Salesforce DX MCP Server does more than flag a pattern; it can show you runtime-informed findings directly in the coding surface. In the following two screenshots from Agentforce Vibes, the first scan view shows the detected antipatterns, their severity, and a short explanation of why each one matters. The second, deeper view expands the issue into a more detailed explanation with telemetry-backed reasoning, expected improvement after remediation, and the likely impact on performance and stability.

Whereas a traditional code check might tell you that something is risky, ApexGuru goes further by helping answer three more useful questions: why this issue hurts, why it matters in this org, and what the likely benefit is if you fix it now. That is what makes the developer experience feel closer to performance guidance than to using a simple linter.

For example, if you are editing an Apex class that queries inside a loop or retrieves far more fields than the code actually uses, the code may still work functionally, but the pattern can become expensive as data volume grows. With ApexGuru in Salesforce DX MCP Server, you can ask your MCP client to scan the file for performance issues in your prompt; for example, “Scan the class for performance issues.”” A typical result includes a grouped antipattern type, a fix instruction, one or more detected instances, and severity for each instance.

Conclusion

Performance-first development is not just about catching issues earlier. It is about making performance review a natural part of how code gets written and refined. ApexGuru in Salesforce DX MCP Server moves performance analysis closer to the moment where developers can still act on it quickly. Instead of discovering costly bottlenecks after deployment, developers can now surface telemetry-backed findings while they are still coding, understand why those findings matter, and fix them before they become larger problems.

That is the real promise of this integration. ApexGuru is no longer limited to a separate app surface or a single IDE extension flow. It is becoming part of a broader developer workflow where performance, code quality, and remediation come together in the same loop.

Resources

• Help documentation ApexGuru
• ApexGuru in DX MCP Server: Demo video 
• ApexGuru or Scale Products MCP README
• The ApexGuru AI Engine, Explained
• Inside ApexGuru: Agentic Code Fixing
• Salesforce DX MCP Server repository and tool documentation
• Optimize Your Apex for Apps and Agentforce with ApexGuru
• Code Analyzer VS Code extension documentation

About the Authors

Mayuresh Verma is a Senior AI Product Manager at Salesforce working on the Scalability Products portfolio, including ApexGuru. Reach out to him on Linkedin.

Samarth Arora is a Member of Technical Staff at Salesforce working on ApexGuru. Reach out to him on LinkedIn.

The post Performance-First Apex Development with ApexGuru in Salesforce DX MCP Server appeared first on Salesforce Developers Blog.

If you’ve been waiting for a reason to spin up a new Developer Edition org (or dust off your existing one), this is it. Since we launched the new Developer Edition in March with Agentforce and Data 360 (formerly Data Cloud), these three additions turn it into a full AI development environment.

Agentforce Vibes IDE is now available in Developer Edition

Agentforce Vibes IDE is a browser-based, cloud-hosted Visual Studio Code (VS Code) environment that launches directly from your org’s Setup menu. Previously known as Code Builder, it gives you a fully authenticated, org-aware development environment with no local installation required.

Open Setup, click Agentforce Vibes, and within moments you’re working in a full VS Code editor with Salesforce Extensions, Salesforce CLI, and GitHub integration preconfigured. Your org’s metadata loads automatically into an SFDX project. No manual authentication, no CLI setup, no extension hunting.

From there you can develop and deploy Apex, Lightning Web Components (LWCs), and flows; run tests against your org; use the integrated terminal; and access Agentforce Vibes (the agentic coding experience) directly from the sidebar.

Agentforce Vibes with Claude Sonnet 4.5: vibe coding for Salesforce

Agentforce Vibes is the Salesforce enterprise vibe coding capability, and it’s now available in Developer Edition with Claude Sonnet 4.5 as the default model. It understands your Salesforce org’s metadata, schema, and existing code patterns. When you tell it to “create a trigger that prevents duplicate Accounts based on email,” for example, it reads your actual org structure first. No hallucinated field names.

The coding agent comes with two modes:

• Plan mode: Analyzes your org, clarifies requirements, and generates an implementation plan before writing code.
• Act mode: Creates and modifies Apex classes, LWCs, triggers, and test classes based on your natural language instructions.

Agentforce Vibes comes with predefined agent skills, and integrates with Salesforce ALM tools like Code Analyzer, and DevOps Center. It does not deploy anything unless you explicitly ask; by default, it modifies local project files you review first.

Usage limits for Developer Edition

• 110 requests per month with Claude Sonnet 4.5
• 1.5 million tokens per month
• Monthly refresh through May 31, 2026 (allocation resets each month)
• After May 31: a one-time-only allocation of 110 requests / 1.5M tokens with no further refresh

You have about two months of recurring access to experiment and build, followed by a final allocation, if you start now. Use the monthly cycles to explore broadly; use the final allocation to finish what you’ve started. If you don’t start now, you’ll only get the final allocation.

To stretch your requests, use Plan mode before switching to Act mode, be specific in your prompts (for example, say “create an Apex before-insert trigger on Lead that checks for duplicate Email values” rather than “build something for leads”), and retrieve only the metadata relevant to your current task.

Salesforce Hosted MCP Servers come to Developer Edition

Now available in Developer Edition, Salesforce Hosted MCP Servers provide a standardized way for external AI tools to connect to your Salesforce data.

MCP (Model Context Protocol) is an open standard created by Anthropic that acts as a universal interface between AI assistants and external data sources. Configure one MCP server, and any MCP-compatible client (for example Claude Desktop, Cursor, or Claude Code) can interact with your Salesforce org.

The following table shows how Hosted MCP differs from DX MCP.

Hosted MCP respects your org’s security model: object and field-level security, sharing rules, and profiles all apply.

Once connected, you can query your Salesforce data through natural language in Claude Desktop, build Agentforce agents that interact with your data via MCP, and prototype AI-driven integrations before committing to a production implementation.

How these three features work together

Agentforce Vibes IDE provides the development environment, Agentforce Vibes with Claude Sonnet 4.5 provides the AI coding partner, and Hosted MCP Servers connect external AI tools to your org’s data. Each is useful independently, but together they create a complete AI-assisted development loop.

A practical workflow:

1. Launch Agentforce Vibes IDE from Setup.
2. Use Agentforce Vibes to scaffold an Apex class and an LWC.
3. Configure a Hosted MCP Server to let Claude Desktop query the data your component displays.
4. Iterate on the component with Vibes while validating the data layer through MCP.

That’s a full AI-assisted development loop running in a free Salesforce org.

Sign up and start building

If you don’t have a Developer Edition org yet, sign up here. It’s free, doesn’t expire as long as you log in regularly, and now includes everything covered in this post.

If you already have a Developer Edition with Agentforce and Data 360, these features are gradually rolling out starting this week to existing environments. Navigate to Setup and search for “Agentforce Vibes” to get started. No additional enablement steps required.

Developer Edition resources and documentation

• Sign up for a free Developer Edition
• Agentforce Developer Center – documentation, guides, and tutorials
• Agentforce Vibes Workshop – hands-on guided workshop
• Salesforce Hosted MCP Server setup guide
• Salesforce DX MCP Server on GitHub – local MCP server with 60+ tools
• Agentforce Vibes IDE release notes

About the Author

René Winkelmeyer leads the Developer Advocacy team at Salesforce. His team focuses on Agentforce, Data 360, and the Salesforce Platform. In his spare time, you might find him still coding on GitHub. Follow René on LinkedIn.

The post New in Salesforce Developer Edition: Agentforce Vibes IDE, Claude 4.5, MCP appeared first on Salesforce Developers Blog.

Bring your hooks, your component libraries, your existing toolchain, and build on Salesforce without having to choose between your framework and your platform.

Why React on Salesforce? 

Until now, building on Salesforce meant adopting Lightning Web Components (LWC) or Aura. You got base components, declarative tools, Lightning Data Service, and UI API access, but you gave up the broader ecosystem. Open-source libraries had to be managed as static resources, and there was no way to use your own framework without losing platform features. Salesforce Multi-Framework eliminates that trade-off.

Starting today, you can bring your existing React apps, dashboards, and micro-frontends and run them natively on the Agentforce 360 Platform. Multi-Framework apps can retrieve and mutate records with GraphQL, invoke Apex methods, and use UI APIs to get user information and context, all with the same security and governance model you already know.

Build your first React app on Salesforce

Before you start, you’ll need the Salesforce CLI, Node.js v18 or later, and a scratch org or sandbox. Multi-Framework is not available in production orgs during beta.

Generate your first app

The easiest way to get started is with the new React project template in the Agentforce Vibes welcome screen. Click the React App tile and select Internal App to generate a new employee-facing React app.

Alternatively, you can generate an app using the SFDX CLI:

sf plugins install @salesforce/plugin-ui-bundle-dev

# Generate the project

sf template generate project --name my-react-project

# Switch to the project directory

cd my-react-project

# Generate the web app using the reactbasic template

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

The sf template generate ui-bundle command generates a starter React app in force-app/main/default/uiBundles. The React template comes preconfigured with:

• Salesforce Multi-Framework SDK for accessing Salesforce APIs and services
• Vite for bundling
• Vitest for testing
• shadcn/ui for components
• Tailwind CSS for styling

Running the app locally

The underlying project is just a React app, so you can run and preview it locally like any other:

# Switch to the web app folder

cd force-app/main/default/uiBundles/myreactapp

# Install the react app dependencies

npm install

# Run the project in local dev

npm run dev

Open your browser and navigate to the local app (default: localhost:5173) to see the app.

Deploying to Salesforce

When you’re ready to deploy the app to your org, build the React app and push it:

# Build the project with Vite

# This creates a /dist folder or overwrites its contents

npm run build

# Deploy the metadata file and the build to Salesforce

sf project deploy --target-org my-org

Search for “myreactapp” in the App Launcher to see the app live. You can update the app label from the app meta xml file. You now have a React-based app hosted on Salesforce with built-in authentication, security, and governance.

Access Salesforce data from React

Once your app is deployed, you’ll want to pull live data from your org. The @salesforce/sdk-data package provides hooks for querying records via GraphQL and invoking Apex methods. Here’s a React component that fetches a Contact record:

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

const QUERY = gql`
  query GetContact {
    uiapi {
      query {
        Contact(first: 1) {
          edges {
            node {
              Name { value }
              Title { value }
              Picture__c { value }
            }
          }
        }
      }
    }
  }
`;

export default function SingleRecord() {
  const [contact, setContact] = useState(null);

  useEffect(() => {
    const fetchData = async () => {
      const sdk = await createDataSDK();
      const response = await sdk.graphql(QUERY);
      
      // Navigate the UI API tree to get the first record
      const record = response.data?.uiapi?.query?.Contact?.edges[0]?.node;
      
      if (record) {
        setContact({
          name: record.Name.value,
          title: record.Title.value,
          picture: record.Picture__c.value
        });
      }
    };
    fetchData();
  }, []);

  if (!contact) return <p>Loading...</p>;

  return (
    <div style={{ border: '1px solid #ccc', padding: '1rem' }}>
      {contact.picture && (
        <img src={contact.picture} alt={contact.name} width="50" />
      )}
      <h1>{contact.name}</h1>
      <p>{contact.title}</p>
    </div>
  );
}

The createDataSDK() utility handles authentication automatically so no token management is required in the application code. You can also call Apex methods directly using the SDK’s fetch() method for server-side logic that goes beyond CRUD operations. See the Multi-Framework Beta Documentation for the full API reference.

Build React Apps with Agentforce Vibes

Agentforce Vibes 2.0 generates Multi-Framework React apps from natural language prompts. Describe the component you need to Agentforce Vibes — a dashboard showing open Opportunities by stage, for example — and Vibes produces the React code, GraphQL queries, and Salesforce metadata.

Vibes has a variety of tools to make it easy to build React apps:

• React and Apex templates to scaffold apps without starting from scratch
• Salesforce MCP server for retrieving and deploying metadata directly from the IDE
• Live Preview to see your React app update in real time as you build
• Einstein Trust Layer to ensure prompts and responses are never used to train future models

React and Lightning Web Components on Salesforce

Salesforce Multi-Framework doesn’t replace LWC; it runs alongside it. Your existing Lightning Web Components continue to work. On Lightning, React components can be embedded as micro-frontends, with the platform providing the shared data and permissions layer between them. Micro-frontend support is in developer preview. 

Choosing React does not mean leaving the platform capabilities that make Salesforce useful. We’re bringing those enterprise features to React through framework-agnostic libraries:  

• Efficient Data Management: React developers can use @salesforce/sdk-data, which provides API client methods for GraphQL and Apex that manage record querying and mutation efficiently, ensuring your app stays within API limits.
• Built-in Governance: The createDataSDK() utility handles authentication automatically, removing the need for manual token management.
• Security and Accessibility: While LWC has accessibility baked in, Multi-Framework apps can use Agentforce Vibes 2.0 templates, tools, and skills to embed enterprise-grade accessibility and security into every component.

Where they differ is in the developer experience and tooling:

Which should you choose?

Choose React when you need to share components across Salesforce and non-Salesforce surfaces, or use the broader React ecosystem. 

Choose LWC when you want declarative data access with @wire and Lightning Data Service, the base component library, and the drag-and-drop Lightning App Builder.

Beta limitations

This has been one of the most requested capabilities by the developer community, and we’re excited to finally get it into your hands. Multi-Framework is in open beta now in scratch orgs and sandboxes, and your feedback will shape where it goes from here.

A few constraints to know before you start: beta apps cannot be deployed to production orgs, Lightning App Builder drag-and-drop placement is not yet supported for React components, and some platform APIs are not available in the beta runtime. Check the Beta Documentation for the full list of known limitations.

Looking ahead, micro-frontend support for embedding React components directly into Lightning pages is in closed pilot for Spring 2027. In the meantime, we encourage you to try it out, file issues, and tell us what’s missing and what you want to see in the future.

Resources

• Demo: Introducing: Salesforce Multi-Framework
• Multi-Framework Beta Documentation — Setup guide, API reference, and known limitations
• Salesforce Multi-Framework Recipes – A collection of 20+ easy-to-digest code samples for React on the Agentforce 360 Platform
• TDX Session Recording: Building React Apps on the Agentforce 360 Platform — Live demo walkthrough. Session recording will be available after April 15 — check back here or bookmark the link.

About the Authors

Amanda Lane leads product marketing for privacy, developer tools, and Agentforce at Salesforce. Before Salesforce, she worked in finance at PwC and the KIPP Foundation. She holds an MBA in consumer analytics from Georgetown and brings a dual background in psychology and economics to product strategy.

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, Run on Salesforce: Introducing Salesforce Multi-Framework appeared first on Salesforce Developers Blog.

※本記事は2026年3月12日に米国で公開された React vs. Salesforce: How I Rebuilt My “Vibe-Coded” App on the Platformの抄訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。

私は2026年の初めにデベロッパーアドボケイトとしてSalesforceに入社しました。それまでのキャリアで、さまざまなツールの良さを発信してきましたが、研修時に告白しなければならないことがありました。実は、Salesforceがどのようなものなのか、よくわかっていなかったのです。

「SalesforceがCRMであること」と、多種多様な「クラウド製品」であること以外は知らないことだらけで、まるで未知の言語を一から学んでいるような気分でした。そこで、無駄に手を広げすぎないように、基本に立ち返ってシンプルな問いに向き合うことにしました。それは、「開発者にとってのコアプラットフォームは何か」ということです。

答えを見つけるために、何か作ってみることにしました。ただ「Hello World」と表示させるだけではなく、状態管理、UIロジック、データ永続化が必要なインタラクティブなものを。そこで作成したのが、オフィスでよくつまむ軽食をドラッグ＆ドロップでランク付けするリストです。

ただし、同じものを2つの方法で作ります。まず私が得意とするReactで構築し、次にSalesforceで、Lightning Webコンポーネント（LWC）を使って一から作り直しました。

Reactバージョンは、AIを使ってバイブコーディングで一気に作成しましたが、Salesforceバージョンは別のやり方で進めました。公式ドキュメントとTrailheadを参照して、AIにペアプログラミングの相棒になってもらいました。目標は、単に動くコードを書くことではなく、アーキテクチャーをしっかり理解することでした。

（注 – 経験豊富なSalesforce開発者の方にとっては、多分この記事に感心することや驚きは何もないと思います。ここに書いたようなエラーにも、何度も遭遇してきたことでしょう。しかし、私のようにSalesforceエコシステムにまだ馴染みがない方たちのために、Salesforceを使い始めるときに感じたことをまとめておこうと思いました）

では、マーケティング資料を読むのをやめて、実際にコードを書いてみてわかったことを紹介します。

フェーズ1：比較基準（React + Vite）

公平な実験のために、比較する基準が必要でした。そこで、20分ほどですばやくReactバージョンを作成しました。Reactのstateは理解していたので、ここで特に何かを学ぶことが目的ではありません。Salesforceエコシステムで作るときの手間や違いを正確に測るための、「対照群」を用意する必要があったのです。

実を言うと、Reactバージョンは「バイブコーディング」で作りました。LLMにランクリストのスクリーンショットを渡して、「React（Vite）とTailwind CSSを使って、この画像にあるようなオフィスの軽食をドラッグ＆ドロップでS、A、B、C、Dにランク分けして、localStorageでデータを永続化できるアプリを作成してください」と指示したのです。

できあがったアプリは、少し手を加えただけで完璧に動作しました。ベーグルをSランクに、キャンディコーン（激甘の砂糖菓子）をDランクにドラッグできました（これはDしかないでしょう。オフィスで食べようとは思えないですからね）

しかし、生成されたコードを見て、2つのことに気付きました。

1. 外部への依存 – LLMは、ドラッグ＆ドロップを実装するために、すぐにサードパーティライブラリー（dnd-kit）に頼りました。Salesforce Platformで開発する場合、どうやって実装するのだろうという疑問が浮かびました。
2. 手作業でのデータ永続化 – このアプリでランクを保存するには、ブラウザーのlocalStorageを読み書きするためだけに、40行の関数を書かなければなりませんでした。Salesforceエコシステムなら、もっと効率的に処理する方法があるだろうと思いました。そして、その考えは当たっていました。

このアプリをちゃんと「使えるもの」にする、つまり同僚と共有し、デバイス間で保存内容を維持できるようにするには、バックエンド（Node、Supabase、またはFirebase）を用意して、APIエンドポイントを書かなければなりません。

さて、ではSalesforceに移行します。

フェーズ2：比較対象 – Salesforce LWC

目標はシンプルです。まったく同じアプリをSalesforce Platformのツールだけで再作成します。外部データベースも、Nodeサーバーも使いません。使うのは自分の腕とSalesforce組織だけです。

ライブラリーか、Web標準の機能か

独自仕様だらけの悪夢のような、それともわけのわからない古めかしい言語に苦しめられるのかと、戦々恐々としましたが、ふたを開けてみると、使うのはJavaScriptでした。

Salesforceでは、Lightning Webコンポーネント（LWC）を使用します。コードは驚くほどReactに似ていると感じましたが、肝心なところがもっとシンプルでした。ドラッグ＆ドロップのロジックに、巨大なnpmパッケージが不要だったのです。私は標準のHTMLイベント（ondragstart、ondrop）を使いました。LWCは重い仮想DOMレイヤーを介さずに、そのままブラウザー上で動作するため、標準のWeb APIを使えたのです。

フェーズ3：Reactではバックエンドが必要になるが、Salesforceはバックエンドも担う

ここで、目からうろこが落ちました。Reactバージョンのアプリでは、データを「保存」するには、JSON形式をシリアライズしてブラウザーのlocalStorageに入れる処理のために、40行のコードを書かなければなりませんでした。さらに、データを永続化したい場合は、SQLを覚え、Postgresデータベースを用意し、Node APIを作成して、CORSにも対応しなければなりません。

Salesforceでは、このような手間はかかりません。カスタムオブジェクトを作成するだけですみます。

私はオブジェクトマネージャーでTier_List_Itemを作成しました。すると、すぐにセキュアでスケーラブルなリレーショナルデータベースと、自動生成されたAPIが利用可能になりました。さらに、このプロジェクトでは深く掘り下げませんでしたが、本格的なエンタープライズ向けセキュリティモデルも用意されていることに気付きました。Sランクの軽食はマネージャーのみに編集を許可するなど、細かい権限管理が必要な場合も、1週間かけて認証ミドルウェアを実装することなく、標準のUIだけで設定できます。

データをコンポーネントに取り込むために、@wireサービスを使いました。これは、データベースに直接接続し、データをリアクティブに取得する仕組みです。

Reactでの手作業の状態管理

 // Reactでは、ストレージから初期状態を読み込む処理を記述しなければならない 
const [boardState, setBoardState] = useState(loadInitialState); 

// アイテムを移動した結果を保存する処理も毎回記述しなければならない
const handleDragOver = (event) => { 
// ... 計算ロジック ... 
localStorage.setItem(STORAGE_KEY, JSON.stringify(next)); 
}; 

Salesforceでの宣言型のデータバインド

 // プラットフォームがデータを取得する
@wire(getAllItems) wiredItems; 
	
// レコードの更新をサーバーに指示するだけでよい 
handleDrop(event) { 
updateItemTier({ itemId: id, tier: newTier }); 
} 

わかったこと

• React – ライブラリーとローカルストレージの管理に時間をかけた。
• Salesforce – プラットフォームがデータベースを用意し、ブラウザーがインタラクティブな動作を提供してくれるため、ロジックの記述に時間をかけた。

変更の反映には時間がかかりましたが（ホットリロードは使えません）、データの永続化に必要な定型コードの量は大きく減りました。始める前にSalesforce Live Preview（英語）を知っていれば、プロセスをもっと速く進められたはずです。

フェーズ4：デプロイ時の確認「卵が先か、ニワトリが先か」

第2フェーズのフロントエンドを第3フェーズのバックエンドに接続する段階で、厄介なことになりました。データベースとやり取りするためにLWCとApexコントローラーを作成し、デプロイすると、ターミナルに次のように表示されたのです。

まず頭に浮かんだのは、作業のどこかでタイプミスか、何かつまらないミスをしてしまったのだろう、ということでした。スペル、ファイル名、ファイルパスなど、ありそうな間違いを一とおり調べましたが、コードに問題はありませんでした。

Reactだったら、いつものように単純にエラーをLLMに貼り付け、出てきた修正をコピーし、そのまま先へ進んでいたでしょう。しかし今回は、AIとドキュメントを使って自分の理解度を確かめることが目的だったので、立ち止まって原因を考えました。そこで、重要な違いに気付いたのです。それは、プラットフォームのコンパイルモデル。

Salesforceの正式な用語ではありませんが、これはプラットフォームがコードをどのように検証するかを理解する思考モデルとして役立ちます。Reactでは、ブラウザーだけがコードを検証します。まだ存在しないAPIを呼び出すフロントエンド関数を書いても、実行するまでは、ブラウザーは問題にしません。

Salesforceでは、サーバーがコードの正否を判断します。デプロイ時にプラットフォームがコードをコンパイルし、その有効性を確認します。その結果、私のLWCがサーバー側にまだ存在していないバックエンドメソッド（getAllItems）とやり取りしようとしていることを検出したというわけです。

先にApexクラス（バックエンド）をデプロイし、その後でLWC（フロントエンド）をデプロイする必要がありました。ミスは、構文エラーではありませんでした。ブラウザーに対してではなく、緊密に統合されたプラットフォームに対してコードを書いているということを思い出させてくれたのです。

フェーズ5：ローコード開発の威力（いわゆる「開発」）

アーキテクチャーを理解したら、データベースのほかにも、さまざまな機能を利用できることがわかりました。「軽食」が実際のデータレコードになったので、Salesforceの自動化エンジンの力をフルに使えるようになりました。

ここで、「軽食がDランクに落ちたら、Slackでチームに通知する」という複雑なビジネスロジックを加えることにしました。

Reactバージョンのアプリでは、楽しい部分はここまでで、ここからはインフラ周りの作業が始まります。webhookかcronジョブ、場合によってはZapierのサブスクリプションも必要になります。一方、Salesforceでは、1行もコードを書きませんでした。Flowを使っただけです。

Tier項目が「D」に変わったことを検知する「レコードトリガーフロー」を作成しました。軽食がDランクになると、Slackチャンネルにメッセージが送信されます。

手痛い失敗（500エラー）

とはいえ、すべてが順調に進んだわけではありません。自信がついてきた私は、2つ目の機能を追加しようとしました。軽食がSランクに入ったら、社内フィード（Chatter）に「おめでとう！」というメッセージを投稿する機能です。

設定して実行してみると、……500エラーが出ました。

ロジックに問題はなかったので、このエラーメッセージは謎でした。フローのデバッグに悪戦苦闘したあげく、AIの助けを借り、プラットフォームのドキュメントを読み返して、ようやくオブジェクトの設定にたどり着きました。

私のカスタムオブジェクトには「Feed Tracking（フィードの追跡）」という小さなチェックボックスがあったのですが、それをオンにしていませんでした。システムは、まだ存在していないフィードに投稿しようとしていたのです。

思わず突っ伏したくなりましたが、自分の考えが当たっていたこともわかりました。ローコードでも、開発の知識がいらないわけではないということを再認識させられました。ローコードであっても、開発者のように考え、プラットフォームを機能させるためにどの設定を有効にすればよいかを理解しておく必要があります。

まとめ：SalesforceはただのCRMではなく、プラットフォーム

さて、最初の3週間で、私は何を学んだのでしょうか。

「最先端のWeb開発者」と「Salesforce開発者」の違いは、思っていたよりもずっと小さいということがわかりました。JavaScriptを知っていれば、構文の大部分はすでに頭の中に入っています。

それより重要だったのは、Salesforce Platformが何をするかを理解できたことです。Salesforce Platformは、認証、データベース、ホスティング、APIといった、地味ではあっても欠かせない部分を引き受けてくれるので、開発者は重要なロジックに集中できます。ロジックが「100万ドルの案件を成約させること」であっても、「クラッカーをDランクに設定すること」であっても、使うツールは根本的には同じです。

…ちなみに、ベーグルはSランク以外はあり得ません。

一緒に学びませんか？

私もまだ初心者ですが、基礎を学ぶためにAIを相棒に「開発者初級」のTrailmixを使いました。このような軽食のランキングリスト（またはもっと役に立つもの）を作ってみたいと思った方は、以下のリソースを参考にしてみてください。

• 初級から上級までの開発者ロードマップ（Trailhead）
• Lightning Webコンポーネントガイド（英語）（開発者向けドキュメント）
• データモデリング（Trailhead）
• Salesforce Flowの基本（Trailhead）

執筆者について

Sean Keeganは、Salesforceのニューヨークオフィスに勤務するリードデベロッパーアドボケイトです。元数学教師で、複雑なテクノロジーを誰にとっても身近なものにすることに情熱を注いでいます。仕事を離れると、ゲームや観葉植物の世話、アルティメットフリスビーを楽しんでいます。ぜひX（Twitter）とLinkedInでフォローしてください。

The post React vs. Salesforce：私が「バイブ・コーディング」したアプリをプラットフォーム上に再構築した方法 appeared first on Salesforce Developers Blog.