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

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

実装要件

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

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

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

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

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

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

• 目的: 通常時、プロジェクトの「予算残高」が 0 未満（マイナス）になるような保存を禁止する。
• エラーメッセージ: 「予算が不足しています。経費を計上できません。」
• 実装手段: 入力規則、フロー、または Apex トリガーのいずれか、もしくは組み合わせて実装。

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

• 内容: 経費レコードが作成された際、親プロジェクトの「予算残高」から経費の「金額」を差し引く。
• 実装手段: Apex トリガー、またはフローのいずれかで実装。今回はバルク更新を考慮せず画面操作での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.

その名も「Lightning MiniHack Live」

この記事では、このエキサイティングなイベントの概要と、4月17日からスタートする予選の参加方法について詳しく解説します。

Lightning MiniHack Live とは？

提示された「実装要件」に対して、いかに素早く、正確に設定・開発を行えるかを競う、まるで e-sports のようなライブ・ハッカソンとも言えるイベントです。
予選を勝ち抜いた上位 4 名のファイナリストは、6月10日にザ・プリンス パークタワー東京で開催される「Agentforce World Tour Tokyo / TDX Tokyo」のメインステージに登壇。観衆の前でリアルタイムに構築を行い、優勝者を決定します！

予選の実装要件

• 予算超過を打破せよ！緊急承認ロジックの実装

予選の参加方法：3つのステップ

今回の予選は、「正確な構築」と「スピード」の両方が重要です。

ステップ1

まず、Agentforce World Tour Tokyo への登録を済ませておきましょう。

• イベント公式登録: Agentforce World Tour Tokyo 登録サイト

コミュニケーション用の Slack ワークスペース・チャンネルに参加をお願いします。

• ワークスペース「Japan Trailblazers」に参加
  • 初めてのアクセスの場合は次の招待リンクからこのワークスペースのメンバーとして登録
  • 招待リンク
• チャンネル「#event-lightning-minihack-live-2026」に参加
  • 公開チャンネルですので、ご自身でチャンネルへの参加をお願いします

ステップ2 (4月17日に予選の実装要件が公表された後)

「実装要件」を確認し、構築を開始します。この際、「開始から完了までのプロセスを画面録画」する必要があります。

• 録画ルール:
  • 使用する組織は Trailhead Playground
    • 一部モジュールで使用する専用の Developer Edition ではなく Trailhead 共通の Playground を使うこと
    • 必ず新規作成した直後の Trailhead Playground を使うこと
    • 事前の設定変更は、表示言語の設定を日本語にすることのみ可
  •  「設定のホーム」画面から操作を開始
    • 開始画面と完了画面の詳細については4月17日に「実装要件」を公開する時に改めてお伝え
  • 操作開始画面と完了画面の間はノーカット・編集不可。開始画面より前、完了画面より後のカットは可とする
  • 画面全体（OSの時計、タスクバー、ブラウザのURLバーを含むデスクトップ全体）を録画する
  • その他操作にあたっての制約および公式ルールを遵守

動画ファイルは、ファイル共有や動画共有のサービスをお使いいただき、応募フォームにはその動画ファイルへアクセス可能なリンクを登録ください。

ステップ3

準備ができたら、速やかに応募フォームから提出してください。

• 応募フォーム
  • https://invite.salesforce.com/lightningminihacklive
• 入力内容
  • 応募者ご本人・連絡先の情報
  • 動画に関する情報
    • 動画 URL
    • 操作開始時分
    • 操作完了時分

【重要】先着 100 名の壁！
応募フォームは先着 100 名に達した時点で自動的にクローズされます。期間内であっても、100名を超えると挑戦権がなくなりますのでご注意ください。
なお、応募は1回のみです。同一参加者から複数回の応募が認められた場合は失格とします。

操作にあたっての制約

禁止事項

• 画面表示言語の日本語への変更以外の事前設定
• ブラウザ機能または外部ツールからの自動設定またはマクロの使用
• 事前に準備したコードまたはメタデータのコピー＆ペースト
• OSやブラウザの「単語登録」、「スニペット機能」、「クリップボード履歴ツール」を使用してのコードまたはメタデータの呼び出し
• 生成 AI アプリ、AI エージェントに指示を出しての組織の設定・カスタマイズ(ただし Agentforce Vibes を除く)

許可事項

• ローカルのパソコンにインストールした Visual Studio Code、Salesforce DX、Agentforce DX、Agentforce Vibes の利用
  • ただし、事前設定は不可。新規プロジェクトの作成および組織との接続から始めること
• ベータ版機能の利用
  • ただし、組織で利用できる場合に限る

審査と本戦進出について

提出・申告された情報と動画をもとに、正確性と構築にかかった時間を厳正に審査します。

• 通知: 予選に応募された方全員に、5月11日までにメールにて結果を連絡
• 公開範囲: 本戦進出者(上位4名)のお名前のみ

本戦の概要

• 1対1での準決勝2試合および決勝1試合
• イベント運営側が用意する Developer Edition を使用
• 実装要件は本戦進出者決定後に公開

賞品・賞金

残念ながら今回はありません！本イベントは、純粋なスキル競技として開催されるものです。優勝者は「Lightning MiniHack Live 初代チャンピオン」として称えられ、Salesforce Developer Blog JP にて紹介される予定です。

おわりに

初代チャンピオンは誰か？日本中の Salesforce 開発者が注目するこのステージ。あなたのスキルが、次世代の Salesforce/Agentforce 活用を加速させるヒントになるかもしれません。
まずはコミュニケーション用の Slack ワークスペースに参加し、4月17日この記事を再度チェックして、挑戦を開始してください！

Happy Hacking!

(注: 本記事の内容は 2026年4月13日時点の公式ルールに基づいています。最新情報は必ず本記事および公式ルールをご確認ください)

• 公式ルール

The post Salesforce 開発者の腕試し！「Lightning MiniHack Live」イベント概要&予選参加ガイド appeared first on Salesforce Developers Blog.

At its core, Web Console is built around a simple idea: developers should not have to leave Salesforce to build Salesforce apps. Web Console brings the IDE into the flow of work, so you can launch from Salesforce surfaces, stay in context, and move from investigation to fix with less setup and fewer interruptions. That idea comes down to one phrase: code where you build.

What is Web Console?

As a browser-based IDE that lives directly inside Salesforce, Web Console is designed to launch from the places where developers are already working, such as Setup and other context-rich entry points. As a result, you can inspect, debug, edit, and validate without breaking your flow. Rather than opening a separate tool and manually finding the right file or log, you can start from the issue itself and work forward from there.

This is more than a new editor in a browser tab. It is a different way of working. Web Console brings together modern editing with the features and capabilities developers need in the moment, including debug logs, SOQL execution, Query Plan Inspector, Anonymous Apex, quick Apex edits, and org-aware navigation. The result is a more direct path from “something broke” to “I found it, fixed it, and validated it.”

Why Web Console feels different in practice

The value of Web Console is not just feature access. It is usability in context.

When something fails in production or a sandbox, developers are usually not starting with a neat project plan. They are responding to an event, an error, or an unexpected behavior. Legacy diagnostic tools were built for this kind of reactive investigation because they keep runtime information close at hand and minimize setup. By contrast, more project-oriented IDE workflows can be powerful for sustained development, but they often introduce more state, more panes, and more cognitive overhead for short investigative tasks.

Web Console is designed to bridge that gap. It keeps the investigation close to where the issue surfaced, while giving developers a more modern, browser-based editing and debugging experience. That means less hunting across windows, less context switching between tools, and a faster path to understanding what happened and what to do next. 

That is a big part of why this beta matters. It is not about replacing a legacy tool feature-by-feature. It is about making common developer workflows inside Salesforce faster, clearer, and more connected to the work already happening in the org.

What’s in the beta: debug logs, Anonymous Apex, SOQL, and quick edits

The beta is intentionally focused on the workflows developers and admins use most when they need to investigate and fix something quickly. These include debug log viewing, SOQL execution, Query Plan inspection, Anonymous Apex execution, and quick, in-context Apex edits. Web Console is also designed to support metadata navigation through an org-aware browser experience, so developers can stay grounded in the org while they work. 

For example, in the beta you can:

• inspect runtime behavior with a dedicated logs experience,
• execute SOQL and understand query performance with Query Plan Inspector,
• run Anonymous Apex without leaving the browser,
• open Apex from relevant Salesforce surfaces and make focused edits in context,
• navigate metadata without switching out to a separate development environment.

This is not a list of random features. It is a cohesive set of capabilities designed for the high-value moments where developers tend to lose time today: understanding a failure, tracing it to source, checking query behavior, making a targeted fix, and validating the outcome.

Connected workflow example: Debugging an Apex job failure

Apex job failures are a good example of where Web Console can make an immediate difference. A developer can begin in the Apex Jobs page, where a failed or long-running Apex job is already visible. From there, they can open the related Apex class in Web Console, enable logging, re-run the scenario, inspect the execution path, jump from the stack trace to the problematic line of code, make the fix, run tests, and validate that the job now completes successfully. They can do all of that without leaving Salesforce or bouncing between disconnected tools.

This streamlined flow is more efficient because it mirrors how real troubleshooting actually happens. The work does not begin in a file tree. It begins with a problem. Web Console is designed so the IDE meets the developer at that point of failure, then stays with them through diagnosis, code change, and validation.

This is one of the clearest ways Web Console improves usability. Instead of forcing the developer to reconstruct the situation across separate tools, it keeps runtime evidence, source code, and validation steps close together, shortening the distance between “What just happened?” and “Did my fix resolve the issue?”

Production versus non-production: Web Console guardrails

Web Console is built with the realities of Salesforce development in mind. In production orgs, Apex editing is read-only, letting developers inspect and understand code safely without any risk to live orgs. In sandboxes and other non-production environments, developers can make inline edits and save changes as part of a faster path-to-fix workflow.

That balance is important. A modern experience should make developers faster, but not by weakening platform guardrails. Web Console keeps the guardrails intact while still streamlining inspection, debugging, and validation.

How to enable Web Console (beta)

During the open beta starting April 14, 2026, Web Console will be available across Salesforce orgs and editions through admin opt-in. It will be off by default until an admin enables it from the Web Console Setup page.

To learn how to enable it in your org and get started, see the Web Console (Beta) documentation.

Why this beta is focused

The beta is intentionally scoped around a set of workflows developers will recognize immediately. It delivers value now, while laying the foundation for a broader, unified development experience over time. The near-term emphasis is on embedded workflows and the high-frequency tasks that are often a source of friction for developers today: investigating failures, tracing behavior, checking queries, making quick edits, and validating fixes.

Join us at TDX

Want to see Web Console in action? If you are attending TDX, register to join us in person to see how Web Console helps developers debug, edit, validate, and move faster — right inside Salesforce — in our session:

Build on the Salesforce Platform with Web Console
Build, edit, and validate from your browser with Web Console, the unified Salesforce web environment for Apex, metadata, and in-context editing.

• Master the core capabilities and productivity features of Web Console.
• Transition your daily development workflows from the legacy Developer Console to the modern Web Console.
• Perform metadata management and Apex development directly within the unified web interface.

Add to your TDX agenda.

About the author

Raj Sensharma is a Director of Product Management at Salesforce with over 20 years of experience delivering transformative SaaS, platform, and AI-powered solutions. He’s passionate about building AI-native products that go beyond automation to enable truly agentic experiences. Raj holds an MBA and a Master’s degree in Computer Science from the University of Central Florida. Follow him on LinkedIn.

The post Introducing Web Console (Beta): Code Where You Build on Salesforce appeared first on Salesforce Developers Blog.

Reference: Default Domain Support for B2C Commerce

For any developer, the road to launching a new feature for a high-traffic, consumer-facing web storefront can be a rocky one. Before a single line of code can be properly tested in a production-like environment, teams often face the operational burdens of manual DNS setup, custom domain registration, certificate management, and the required IT involvement that slows everything down. Setting up a new development or testing environment has traditionally been a process filled with friction, delaying innovation and extending time-to-market.

Salesforce Commerce Cloud is removing these obstacles with a powerful new capability: the Default Domain. This out-of-the-box feature provides an instantly available, eCDN-ready hostname for every instance, eliminating the setup headaches that have long frustrated developers. This post breaks down the five most impactful takeaways of this new capability.

Takeaway 1: Default Domain support for B2C Commerce

The Default Domain is far more than a simple placeholder URL; it’s an immediately eCDN-ready environment right out of the box, meaning the CDN layer and HTTPS are already configured. This is a critical distinction that transforms how development and testing can be approached.

Built-in eCDN integration enables developers to test crucial, real-world functionality in a non-production environment that accurately mimics the final production setup. Development teams can now validate PWA Kit performance, fine-tune security rules, test complex caching strategies, and conduct performance tuning early and often.

The key benefit is the ability to prevent production issues by discovering them and addressing them earlier in the development cycle. By testing in a truly production-like environment from day one, you mitigate the risk that improper domain or certificate setup will lead to outages or insecure (HTTP) traffic when you go live. For more information, see Default Domain Support for B2C Commerce.

Takeaway 2: Security is built in, not bolted on

With the Default Domain, security is a built-in feature, not an afterthought. HTTPS is automatically enabled because Salesforce manages the entire SSL/TLS certificate lifecycle. This completely eliminates any manual work for developers related to certificate provisioning, uploading, or renewal.

Production instances using a Default Domain have a “secure by default” posture. To prevent accidental public exposure, production instances are preconfigured with a “Block All” firewall rule at the eCDN layer. Development teams must explicitly add “Allow” rules for specific sites or paths they want to make accessible, ensuring nothing goes public until it’s truly ready. (Remember: rules are executed from top to bottom, so any custom “Allow” rules must be placed above the default block.)

Development and Staging instances are also protected by default, requiring user credentials for access to safeguard these lower environments from unwanted public traffic.

Takeaway 3: All of the control, none of the paperwork

Contrary to the common misconception that managed domains limit control, with the Default Domain developers have full eCDN configuration access through both the CDN API and the familiar Business Manager UI.

You retain complete control over customizing and testing the eCDN settings for your Default Domain, including:

• Web Application Firewall (WAF) rules
• Speed settings
• Routing rules
• Custom rules and Rate Limits
• Analytics
• PCI settings

This allows you to fully customize and validate your eCDN setup for a new project or feature without any risk of affecting the configuration of your production custom domains.

Takeaway 4: A complement to, not a replacement for, your custom domain

It’s crucial to understand that the Default Domain does not replace or alter the functionality of your existing custom domains (also known as vanity domains), like www.TheWidgetStorefront.com.

The two types of domains can coexist on the same instance. Your custom domain remains the preferred choice for external-facing, branded storefronts that your shoppers interact with. (While the Default Domain can be made publicly accessible if explicitly configured, it is not intended for that purpose.) The configuration of your custom domain is not affected by any changes made to the Default Domain.

The Default Domain serves a different, but equally important, purpose. Its primary use case is for internal-facing tasks – such as developer testing, load testing, and pre-production reviews – enabled by eCDN functionality in environments where setting up a custom domain is neither practical nor necessary.

Takeaway 5: More than a feature, a foundation for the future

While its immediate benefits are clear, the Default Domain is also a strategic platform enhancement that paves the way for future innovation. Specifically, Default Domain support is a critical prerequisite for enabling eCDN for on-demand sandboxes (ODS), which are planned for later this year.

This connection addresses persistent developer pain points identified through voice-of-the-customer feedback. For teams adopting composable storefronts, the lack of easy eCDN testing in sandboxes has created major friction. Limited local development support for hybrid environments has required teams to create many custom proxies, a cumbersome workaround that slows development cycles and that eCDN-enabled on-demand sandboxes would eliminate.

Conclusion

As a foundational capability, the Default Domain enables faster deployment, enhanced site security, and more streamlined composable development workflows on Commerce Cloud.

The Default Domain removes friction from the Commerce Cloud development process by eliminating the operational burden of domain and certificate management. The result is more time to focus on what you do best: building innovative features and exceptional customer experiences.

Resources

• Documentation: Default Domain Support for B2C Commerce
• Trailhead: Explore eCDN for B2C Commerce
• CDN Zones – (Applicable to Default Domains)
  • eCDN Supported Cipher Suites
  • eCDN Logpush
  • eCDN Logpush Log Fields
  • eCDN PCI 4.0 Compliance Tools
  • eCDN WAFv2
  • eCDN Custom Rules
  • eCDN Rate Limiting Rules
  • eCDN Cache Rules
• GitHub: Salesforce Commerce cloud b2c-developer-tooling
• Release Readiness Spring ’26 Highlights: Agentforce Commerce

About the author

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

Deep Shrestha is a Principal Member of Technical Staff at Salesforce, specializing in software engineering and technical architecture. With a strong background in building scalable, robust solutions, Deep brings technical depth and innovation to complex engineering challenges. His expertise spans system design, implementation, and delivering high-quality software that meets the evolving needs of enterprise customers. Follow him on LinkedIn.

The post Salesforce B2C Default Domains: Instance eCDN & SSL for Devs appeared first on Salesforce Developers Blog.

Structured Outputs moves format enforcement from your prompt to the platform. You define the shape of the response, and the platform guarantees the model returns valid, parseable JSON in that shape every time. This post walks through how to set it up and what you can build with it.

What Structured Outputs does

Structured Outputs applies system-level instructions to a prompt template that force the model to respond in a structured format, such as JSON. This is different from asking for JSON in your prompt. The response format is enforced by the platform, not by the model’s willingness to follow directions. You no longer need to specify a format in your prompt, provide example outputs, or strip Markdown fences from the response. 

You enable it by switching the prompt template’s response format from Default to JSON. Now your prompt template will always return parseable JSON for use with Flow or Apex.

Defining the response shape with Lightning types

Getting JSON back is only half the battle. If you don’t specify the response’s fields, the model will choose them for you — and there’s a good chance they’ll differ from what your automation expects, leading to an error or worse, a crash. To be useful in an automation, the response needs to include specific fields with specific data types every time. In other words, it needs a type. 

Object-based Lightning types let you define that type declaratively. Instead of specifying the fields in the prompt and writing an Apex wrapper class to model the response, you create a Lightning type with the fields you need — be they a String, Boolean, Integer, Date, or DateTime — and assign it as the prompt template’s response structure. The platform then ensures every response conforms to it.

To set one up:

1. Click New Lightning Type in the Response Structure search bar.
2. Name your type and add the fields you need.
3. Save your template.

From this point on, every invocation returns JSON with exactly those fields regardless of how the prompt or model changes. 

Using Structured Outputs in Flow

With a Lightning type assigned, your prompt template’s output fields are directly available in Flow. Add the prompt template as an Action element, and its structured response fields show up as variables you can map to record fields, use in Decision elements, or pass to subflows. 

For example, a prompt template that classifies incoming cases could return caseType, reason, and summary fields. An Update Records element can map those fields directly to the Case record as shown below. The entire automation can be done without writing a line of code.

Using Structured Outputs in Apex

In Apex, structured outputs eliminate the JSON.deserialize step entirely. Invoke the template through the Connect API, and the response will include a structuredResponse property that you can cast directly. Each Object-based Lightning type has a system-generated Apex class accessible via the LightningTypes namespace.

// Invoke the prompt template
ConnectApi.EinsteinPromptTemplateGenerationsRepresentation result =
    ConnectApi.EinsteinLlm.generateMessagesForPromptTemplate(
        templateApiName, input
    );

// Cast directly to your Lightning Type — no deserialization needed with
// LightningTypes.{Lightning Type API Name}
LightningTypes.ClassifyMessagingSessionResponse output =
    (LightningTypes.ClassifyMessagingSessionResponse)
    result.generations[0].structuredResponse;

// Use fields like any typed object
System.debug(output.issueCategory);
System.debug(output.title);
System.debug(output.summary);

The structured outputs approach skips all the boilerplate: no wrapper classes, no JSON.deserialize, and no try-catch for malformed strings and stray newlines. The platform handles the format and code handles the logic.

Limitations

Structured outputs solve the format problem but they don’t solve everything.

Field types don’t support nested objects or arrays. Object-based Lightning types support only String, Boolean, Integer, Date, and DateTime properties. If you need to extract a list (for example, line items on a receipt), you’ll need to return that data as a JSON string field and parse it in Apex yourself. This is the biggest limitation for real-world workflows, so plan your data model around it.

Picklists aren’t natively supported. You can list acceptable picklist values in the field description, but the model can still hallucinate values outside your list. Add a Flow Decision element or Apex validation to check the returned value against your expected options and fall back to a default when it doesn’t match.

Lightning type changes can silently break downstream automations. Prompt templates are versioned, but the object-based Lightning types are not. If you rename or remove a field on a Lightning type that’s already wired into a Flow or Apex class, those automations will break. Create a new Lightning type for significant changes and update your automations deliberately. Don’t edit a live type in place.

Structured doesn’t mean accurate. Structured Outputs guarantees that the response will be valid, parseable JSON in the shape you defined. It doesn’t guarantee the values are correct. Treat Structured Outputs as a mechanism for ensuring reliable formatting, not a substitute for validation logic. Add checks to catch values that don’t make sense.

Conclusion

With Structured Outputs, your prompt templates can speak the same language as the rest of Salesforce: typed, structured, and ready for automation. It’s time to delete that parsing code, simplify those flows, and start building AI workflows that just work.

Resources

Spring ’26 Release Notes | Structured Outputs
EinsteinLLMClass API documentation
Use Structured Outputs to Format Model Responses

About the author

Charles Watkins is a self-taught Developer Advocate at Salesforce and a software developer. He spends his time blogging, coding, and live streaming. You can follow him on LinkedIn.

The post Building AI Automations with Prompt Builder Structured Outputs appeared first on Salesforce Developers Blog.

動画での解説はこちらからご覧いただけます。

※この記事の内容を試すには、Agentforce が有効化された Salesforce 組織が必要です。まだ環境をお持ちでない方は、無料で取得可能な Developer Edition をご利用ください。

この記事のポイント

• Employee Agent に General CRM トピックを追加するだけで、CRM の基本検索がエージェントで可能に
• Agentforce Builder のキャンバスモードで、自然言語による取引先レコード表示
• 設定だけで完結し、コードは一切不要

1. Agentforce スタジオ と Agentforce Builder の全体像

Agentforce スタジオ とは

Agentforce スタジオ は、エージェントの作成・管理を一元的に行うためのハブです。Salesforce のアプリケーションランチャーから「Agentforce スタジオ」と検索して開くことができます。

Agentforce スタジオ には、用途に応じたエージェントのテンプレートが用意されています。

今回は Agentforce Employee Agent を使います。Employee Agent は社内ユーザー向けのエージェントで、Salesforce 内部のデータに対して自然言語で問い合わせができるようになります。

Agentforce Builder とは

Agentforce スタジオ でエージェントを選択すると、Agentforce Builder が開きます。Agentforce Builder は、エージェントの詳細な設定を行うための開発環境です。

Agentforce Builder には 2 つのビューがあります。

• キャンバス（Canvas）: ノーコードのビジュアルエディタ。Agent Script をわかりやすいブロック形式で表示し、直感的にエージェントを構成できます
• スクリプト（Script）: Agent Script のコードを直接編集できるプロコード向けビュー

今回はキャンバスを中心に操作していきます。

トピックとは

トピックは、エージェントが対応できる「業務領域」を定義するものです。1 つのエージェントに複数のトピックを追加でき、トピックごとに対応可能なアクション（検索、表示、更新など）が定義されています。

今回追加する General CRM は、Salesforce が標準で用意しているトピックで、以下のアクションがあらかじめ組み込まれています。

• 取引先の検索・表示
• 取引先責任者の検索
• 商談の検索
• リードの検索

つまり、このトピックをエージェントに追加するだけで、CRM の基本的なデータ検索がエージェントでできるようになります。

2. 事前準備

作業を始める前に、以下を確認してください。

• Salesforce 組織（Developer Edition、Sandbox、または本番環境）
• Agentforce エージェントが有効化されていること
• 取引先にサンプルデータが投入されていること（Developer Edition にはデフォルトで Edge Communications などのサンプルデータが含まれています）

※ 今回のデモでは、Developer Edition に標準で含まれている「Edge Communications」のサンプルデータを使用します。サンプルデータを削除済みの場合は、新しい Developer Edition を取得するか、手動で取引先レコードを作成してください。

3. Employee Agent に General CRM トピックを追加する

ステップ 1：Agentforce スタジオ を開く

1. Salesforce にログイン
2. アプリケーションランチャーをクリック
3. 「Agentforce スタジオ」と検索して開く
4. エージェントページが表示される

ステップ 2：Employee Agent を作成

1. エージェントページで 「新しいエージェント」 をクリック
2. Agentforce Builder が開く
3. 「Agentforce Employee Agent」 を「選択」
4. 「エージェント名」と「API 参照名」を入力し、「始めましょう」をクリック

ステップ 3：General CRM トピックを追加する

1. Agentforce Builder の左パネル（エクスプローラー）で 「トピック」 セクションを確認
2. トピックの追加オプション（「＋」ボタン）をクリック
3. 「アセットライブラリから追加」をクリック
4. 標準トピックの一覧から 「General CRM」 を選択して追加

追加後、General CRM トピックの中身を確認してみましょう。取引先の検索、取引先責任者の検索、商談の検索、リードの検索など、CRM の基本操作がアクションとしてすでに定義されているのがわかります。

ステップ 4：保存する

1. Agentforce Builder の 「保存」 ボタンをクリック

※ 作業中はこまめに保存することをおすすめします。Agentforce Builder では、保存しないまま画面を離れると変更内容が失われる場合があります。

4. キャンバスモードで自然言語テスト

設定が完了したら、Agentforce Builder のプレビュー機能を使って、エージェントの動作をテストしてみましょう。

プレビューの開き方

1. Agentforce Builder 内で 「Preview」 タブをクリック
2. チャット形式のテスト画面が表示される

自然言語でのテストシナリオ

以下の 3 つのプロンプトを順に試してみましょう。特定の取引先の中身を段階的に深掘りしていく流れで、自然言語検索の実力を確認できます。

今回は、Developer Edition にデフォルトで含まれているサンプルデータ「Edge Communications」を使います。

テスト 1：取引先の概要を聞く

取引先の Edge Communications について教えて

期待される結果: Edge Communications の取引先レコードが返ってきます。会社名、業種、所在地、電話番号、年間売上といった基本情報がまとめて表示されます。SOQL を一切書かずに、会社名を伝えるだけでレコードの中身を引き出せていることがポイントです。

テスト 2：関連情報を深掘りする

Edge Communications の取引先責任者を教えて

期待される結果: Edge Communications に紐づく取引先責任者（Contact）の一覧が返ってきます。氏名、役職、メールアドレスなどが表示されます。取引先レコード単体だけでなく、関連オブジェクトの情報も自然言語で引き出せることがわかります。

テスト 3：さらに別の関連情報を聞く

Edge Communications に関連する商談を見せて

期待される結果: Edge Communications に紐づく商談（Opportunity）の一覧が返ってきます。商談名、フェーズ、金額、完了予定日などが表示されます。

※ Developer Edition のサンプルデータには Edge Communications の取引先責任者や商談があらかじめ含まれています。もし結果が返らない場合は、サンプルデータが削除されていないかご確認ください。

このように、1 つの取引先を起点に「概要 → 取引先責任者 → 商談」と自然言語で深掘りしていけるのが、General CRM トピックの強みです。

プレビューの活用ポイント

プレビューでエージェントの応答を確認する際、右側パネルにはエージェントの推論プロセスが表示されます（インタラクション概要）。どの トピックが選択され、どのアクションが実行されたかを確認できるため、想定どおりの動作をしているかのデバッグに役立ちます。

5. 注意事項

作業後はこまめに「保存」

Agentforce Builder では、保存しないまま画面を離れると変更内容が失われることがあります。トピックの追加やアクションの設定変更を行ったら、都度「保存」をクリックしてください。

Agentforce Builder はテストやプレビュー用途

今回使用した Agentforce Builder のプレビュー機能は、開発者がエージェントの動作をテスト・デバッグするための環境です。実際にエンドユーザーにエージェントを使ってもらうには、Salesforce の画面上にエージェントパネルを配置したり、Slack と連携するなど、別途チャネルの設定が必要になります。

応答精度はデータに依存

General CRM トピックの検索精度は、組織内のデータの量と品質に左右されます。今回のデモで使用した Edge Communications のように、取引先責任者や商談が紐づいたレコードであれば、関連情報の深掘りまでスムーズに行えます。一方、住所・業種などの項目が空欄のレコードが多い場合、期待どおりの検索結果が返らないことがあります。

6. よくあるトラブルと対処法

General CRM トピックが選択肢に表示されない

原因: Agentforce エージェントが有効化されていない、または組織のエディションが対応していない

対処: 設定画面で Agentforce エージェントが有効になっているか確認してください。Developer Edition では標準で無効化されています

期待した検索結果が返ってこない

原因: 組織にサンプルデータが入っていない、またはサンプルデータが削除されている

対処: Developer Edition を新規取得した直後であれば、Edge Communications などのサンプルデータが含まれています。既存の環境でサンプルデータを削除済みの場合は、取引先レコードを手動で作成するか、新しい Developer Edition を取得してください

日本語でのプロンプトに対して英語で応答される

原因: エージェントの言語設定やユーザーのロケール設定

対処: ユーザーの言語設定が日本語になっていることを確認してください。また、プロンプトをより具体的に日本語で書くことで、日本語での応答が返りやすくなります

7. 次のステップ

今回は標準の General CRM トピックを使いましたが、Agentforce ではさらに高度なカスタマイズが可能です。

カスタムトピック

自社固有の業務ルールやオブジェクトに対応したカスタムトピックを作成できます。たとえば「在庫管理トピック」や「承認依頼トピック」など、業務に合わせたエージェントを構築できます。

Agent Script

Agent Script を使うと、エージェントの推論にプログラム的な制御（if / else 条件分岐、変数、フォローアップアクションなど）を追加できます。キャンバスビューで視覚的に設定することも、スクリプトビューでコードを記述することもできます。

チャネル設定

作成したエージェントを実際のユーザーに公開するには、以下のようなチャネル設定が必要です。

• Salesforce 画面上へのエージェントパネルの配置
• Slack との連携

まとめ

Agentforce の Employee Agent に General CRM トピックを追加するだけで、自然言語による CRM データの検索・表示が実現できます。コードを書く必要はなく、設定だけで完結します。まずは Developer Edition で試してみてください。

参考リソース

• Salesforce Help: エージェントの設計と実装（日本語）
• Salesforce Help: Agentforce Studio および新しい Agentforce Builder へのアクセス（日本語）
• Trailhead: Explore the New Agentforce Builder（英語）

The post Agentforce を使って自然言語で CRM 検索を体験しよう！ appeared first on Salesforce Developers Blog.