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.

※本記事は2026年3月3日に米国で公開された Agent Script Decoded: How to Debug Agent Scriptの抄訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。

Agent ScriptでAIエージェントを構築したものの、テストをしてみると、思ったように動作しない、ということもあるでしょう。AIエージェントが誤ったトピックに振り分けられているのか、実行すべきアクションをスキップしているのか、あるいは指示とは異なる形で応答しているのかもしれません。

そんなときには、会話の各ターンで生成されるトレースが役立ちます。トレースを見れば、確実な根拠にもとづいてデバッグできます。選択されたトピック、実行可能だったアクションや実行されたアクション、変更された変数、推論ループが時間を費やした箇所がわかるのです。

この記事では、まずAgent Scriptの実行フローについて説明します。次に、Agentforce BuilderとAgentforce DX（英語）を使ってAgent Scriptをデバッグする方法を見ていきます。最後に、Agentforce Vibesを使ったバイブデバッグのワークフローを紹介します。バイブデバッグでは、JSON形式の実行トレースをAgentforce Vibesに貼り付けて、期待していた結果と実際の結果を言葉で説明し、Agentforceの提案を利用してAgent Scriptを改善します。

Agent Scriptの実行フロー

Agent Scriptで構築したAIエージェントを効果的にデバッグするには、まず、実行の流れを理解しておく必要があります。以下に、実行フローがわかる図を用意しました。Agent Scriptのデバッグは、スクリプトを上から下へと直線的にチェックするというよりも、決定論的な命令の実行と非決定論的な推論という異なる2つの実行モードからなるループをたどっていくイメージです。

では、この実行フローをステップごとに見ていきましょう。

ステップ1 – すべての会話ターンは、必ずstart_agent（英語）が起点になります。ユーザーが何を発言したか、前のターンがどこで終了したかにかかわらず、AIエージェントのエントリーポイントとして最初に実行されます。このエントリーポイントで、現在の会話の状態が評価され、AIエージェントが適切なトピックに振り分けられます。

デバッグでまず確認すべき点は、「想定したトピックにAIエージェントが振り分けられたかどうか」です。答えが「ノー」なら、問題の原因はトピックの説明か会話の状態にあります。

ステップ2 – トピックに入ると、reasoning.instructions（英語）は上から順番に、決定論的に実行されます。ここは通常のコードのように動作する部分です。すべてのif条件が評価され、runブロックが実行され、想定どおりに変数が代入されます。一方、プロンプトテキストの行（|で始まる行）は実行されず、プロンプトバッファーに蓄積されていきます。ここが重要な違いです。ロジックは直ちに実行されますが、プロンプトテキストは蓄積されるだけです。instructionsでは、一般的な命令型プログラムでステップ実行を進めるようにバグをトレースできます。

ステップ3 – 組み立てられたプロンプトと利用可能なツールが、Einstein Trust Layerによって保護された大規模言語モデル（LLM）に渡されます。ここで、決定論的な処理から非決定論的な推論に実行が切り替わります。Einstein Trust Layerによって保護されたLLMは、instructionsフェーズで蓄積されたプロンプトテキスト、会話履歴、reasoning.actions（英語）のツール一覧を受け取り、その情報をもとに推論を行います。LLMは直接応答することもあれば、ツールを呼び出すこともあります。このフェーズを確実に予測することはできませんが、入力された情報（組み立てられたプロンプト）を確認することで、LLMがなぜそう推論したかを理解できます。ツールが実行されるたびに、システムはステップ2に戻ってプロンプトを再評価します。LLMがツールを使わずに直接応答するまで、このサイクルが繰り返されます。

ステップ4 – after_reasoning（英語）（定義されている場合）が実行され、ユーザーに応答が返されます。後処理のロジックが実行され、AIエージェントが応答を返し、待機します。サイクルは一時停止しているだけで、終了したわけではありません。

ステップ5 – ユーザーが別のメッセージを送り、ステップ1からループが再開されます。各ターンの切れ目で、どの変数が変わったのか、会話の状態はどう変化したのか、start_agentの振り分け先が変わっていないかを確認してください。複数のターンにまたがるバグは、ほとんどがこのような遷移に潜んでいます。更新されていない変数や、トピックの振り分け条件が当てはまらなくなっている箇所があれば、それがバグの原因かもしれません。AIエージェントの変数はグローバルな状態として扱われ、ターンをまたいで保持されることに注意しましょう。

Agentforce Builderを使ったAgent Scriptのデバッグ

新しいAgentforce Builderを使うと、AIエージェントの実行フローをデバッグし、トレースできます。Agentforce Builderでは、実際のデータに変更を加えずにテストできるシミュレーションモードと、実際のアクションをテストできるライブテストモードを利用できます。どちらにも［Interaction Summary（インタラクション概要）］パネルが用意されており、AIエージェントの会話ロジック、トピックの遷移、トリガーされたアクションを追跡できます。

［Interaction Summary（インタラクション概要）］パネルには、入力、推論、トピックの遷移、アクション、出力の評価という各ステップが、視覚的なわかりやすいタイムラインで表示されます。このパネルは、会話の流れを把握するのにとても便利で、問題が発生している箇所の特定にも役立ちます。

もっと詳しく確認したい場合は、Agentforce Builderの下部にある［Trace（トレース）］タブ（以下のスクリーンショットを参照）を展開します。このタブでは、ミリ秒単位でインタラクションの内訳が表示され、時間がかかっている箇所をタイミングバーで確認できます。各インタラクションをクリックすると、動的に生成されてLLMに送信されたプロンプトなどの詳細を確認できます。

変数を調べたい場合は、［Variables（変数）］サブタブに切り替えると、各ステップの変数の値を確認できます。

Agentforce DXを使ったAgent Scriptのデバッグ

Visual Studio CodeのようなIDEで作業したい場合は、Agentforce DX拡張機能を使って、エディターの［Agent Tracer（エージェントトレーサー）］タブ（下図を参照）で同じトレース機能を利用できます。

左側のパネルでは、ユーザーの入力、選択されたトピック、変数の更新、有効化されたツール、推論ステップ、トピックの遷移など、実行プランの全体を確認できます。

任意のテスト会話をクリックし、ファイルを開くアイコン（赤線で囲んだ部分）をクリックすると、会話ターンについてプランの生の応答を確認できます。このJSONファイルが、判断基準となる情報です。このファイルには、内部のAgent Script変数を含む、実行中の各時点におけるすべての状態変数の値が記載されているため、見つけにくいロジックの問題を調べるうえで非常に役立ちます。

Agent Scriptのバイブデバッグ

Agentforce BuilderとAgentforce DXの拡張機能では、きわめて詳細な実行トレースが可能です。しかし、こうしたツールでステップごとにデータを調べるのは、根気のいる作業です。そうした手間を解消する新しいワークフローが、バイブデバッグです。

ビルダーのUIを操作して問題を調べるのではなく、Agentforce Vibesをペアプログラミングの相棒として活用すれば、トレースを任せることができます。やり方は簡単です。Visual Studio Codeで会話のターンをシミュレーションし、［Agent Tracer（エージェントトレーサー）］タブからJSON形式の実行トレースをコピーしてAgentforce Vibesに貼り付け、期待していた応答をプロンプトで伝えるだけです。Agentforce Vibesは、意図していなかったトピックの振り分け、上書きされた変数、LLMが本来の流れから外れるきっかけになったプロンプトをすぐに見つけ出し、具体的なAgent Scriptの修正コードを提案します。

AIを活用したこのワークフローを活用するには、コンテキストが何より重要です。Agent Scriptの構文と推論ループを理解できるように、Agentforce Vibesに正確な構成図を与える必要があります。そのために、リポジトリに2つの軽量なファイルを追加します。1つは.airules/AGENT_SCRIPT.mdなどのルールファイル、もう1つはルートに配置するインデックスファイル、AGENTS.mdです。すぐに設定できるように、agent-script-recipesレポジトリに、そのまま使えるサンプルが用意されています。

ルールファイルを用意すれば、孤独で地道な作業だったデバッグが、会話しながら進められるワークフローに進化します。Agentforce Vibesで仮説をすばやく検証して、Agent Scriptをレビューしながら繰り返し改善できます。普遍的なコンテキスト基盤を利用したアプローチなので、このワークフローはClaude CodeやCursorといったAIコーディングエージェントやその他のツールにも適用できます。これで、Agent Scriptのデバッグや改善を自由自在に進められるようになります。

まとめ

Agent Scriptのデバッグは、ときにブラックボックスとの闘いのように思えるかもしれません。しかし、Agentforce BuilderとAgentforce DXの拡張機能で実行トレースを活用すれば、勘に頼ることなく原因を突き止められます。

AIエージェントの開発をマスターするうえで重要なのは、直感ではなく、データを信じることです。常に、実行ループの流れを念頭に置いておきましょう。最初に必ずstart_agentがAIエージェントをトピックに振り分けること、ステップごとに実行されるコードとプロンプトテキストはまったく別のものであることを忘れないでください。厳密なロジックとプロンプトを切り分け、LLMに渡される正確なコンテキストを検証することで、問題をすばやく解決できます。手作業で変数値のずれをたどる場合でも、複雑なJSON形式のトレースをAgentforce Vibesで解読する場合でも、信頼できるインテリジェントなAIエージェントを構築できるツールが一式そろっています。次にAIエージェントが想定どおりに動かなくなったときは、トレースログを掘り下げ、データを追ってみてください。

関連情報

• Agent Script Recipesサンプルアプリ（英語）
• Agent Script Decoded動画シリーズ（英語）
• Agent Scriptガイド（英語）
• Agentforceガイド

執筆者について

Mohith ShrivastavaはSalesforceのプリンシパルデベロッパーアドボケイトです。15年にわたってAgentforce 360 Platform（旧Salesforce Platform）でエンタープライズ規模の製品を開発してきました。Salesforce開発者が質問し合い、知識を共有できる開発者向けフォーラムのSalesforce Stack Exchangeでも積極的に活動しています。LinkedInのプロフィールはこちら。

The post Agent Script徹底解説 – Agent Scriptのデバッグの仕方 appeared first on Salesforce Developers Blog.

This post covers how to set up observability for operations across systems and how to architect a traceable system using Salesforce native identifiers and propagation patterns. It then explores a variety of integration scenarios demonstrating how to set up observability.

Tracking operations across systems

When multiple operations are chained together across systems, it becomes harder to diagnose issues and to measure performance. To compensate for this, developers use two techniques: logging and telemetry.

Logging is the first level of traceability. It provides a historical journal of activities within a given application. This information is generally stored in text-based log files or a database. Logs are easy to set up and great for debugging or compliance. However, because they are specific to each system, they don’t give a full picture of the user experience.

Telemetry focuses on real-time analytics and is based on event-driven data streams captured from multiple sources. It enables tracking a given user operation as it travels through different systems. The key that links the events across these systems is a shared correlation ID.

Correlating Salesforce Platform requests

The core concept: How to correlate

Every transaction in Salesforce is assigned a unique ID that is logged in the Event Monitoring logs. For example, this ID is represented by the REQUEST_ID field in EventLogFile logs. Using this native ID, you can seamlessly join your custom application logs with standard Salesforce logs.

As per the EventLogFile documentation, the request ID value is either a 32-character OpenTelemetry (OTel) and W3C compatible Trace-Id or a 22-character alphanumeric ID. This ID serves as the “parent” span for all subsequent operations (logs, callout, queueable, platform event, and so on).

Working with Apex

If you want to correlate some of your debug logs, you can prepend your lines with the request ID yourself:

// Retrieve the native Salesforce Request ID
String correlationId = Request.getCurrent().getRequestId();
System.debug(correlationId +' <- Transaction Correlation ID');

Or, you can let a third-party logger like Nebula Logger handle it for you.

Passing a request ID when calling the Salesforce Platform APIs

When calling Salesforce Platform APIs, the correlation ID must travel with the request so that the receiving systems (Salesforce and possibly other systems) can log it. This enables “distributed tracing”, allowing you to see the full lifecycle of a request as it crosses system boundaries.

To set a request ID with the Salesforce REST API, set the X-SFDC-REQUEST-ID HTTP header with your unique correlation ID value. While it isn’t required for correlation, we also recommend that you set a client name using the Sforce-Call-Options header as a best practice. Just like for the request ID, the supplied client name will be reported in the CLIENT column of EventLogFile.

Here’s an example of how to configure a request for a custom Apex REST web service with such headers using the Salesforce Platform APIs collection for Postman:

Although this is beyond the scope of this blog post, note that other Salesforce products let you achieve this. For example, MuleSoft lets you set custom correlation IDs for Flows with HTTP endpoints and Salesforce Commerce APIs (SCAPI) let you pass correlation IDs as part of your requests.

Propagating correlation IDs in Apex HTTP Callouts

When calling a third-party API with Apex HTTP callouts, use a custom header in your request to propagate the current transaction’s unique request ID (correlation ID).

HttpRequest req = new HttpRequest();
req.setEndpoint('callout:My_External_Service');
req.setMethod('POST');

// Pass the correlation ID as a header
String requestId = Request.getCurrent().getRequestId();
req.setHeader('', requestId);

Http http = new Http();
HttpResponse res = http.send(req);

Note: If your downstream systems support the Trace Context W3C standard, you can map your request ID to a traceparent header. This allows you to simplify the correlation configuration and unify the event representation across logs.

Propagating correlation IDs in Platform Events

Platform event publishing is asynchronous. This means that the following three elements that control the life cycle of an event are transactionally separate and do not natively share the same request ID:

• the Apex code or client that enqueues the event for publication
• the event bus process that publishes the event
• the Apex trigger or client that subscribes to the event.

While Salesforce provides a system EventUuid to identify event messages, this UUID is generated after publish and does not identify the originating transaction. In order to pass correlation information in a platform event, you must create a custom field (e.g., SourceRequestId__c) on your platform event object to carry the context.

Here’s an example of how you can do this when publishing an event with Apex:

// Create the event
Order_Event__e event = new Order_Event__e();
event.Order_Number__c = '12345';

// Manually propagate the correlation ID
event.SourceRequestId__c = Request.getCurrent().getRequestId();

// Publish
EventBus.publish(event);

When the subscriber (e.g., an external app or an after insert Apex trigger) receives the event, it reads the SourceRequestId__c value to retrieve the correlation ID and continue the logging trace.

Propagating correlation IDs when working with asynchronous Apex

Asynchronous jobs like Queueable, Batch, Schedulable, and future methods run in fresh transaction contexts with brand new request IDs. To trace the parent transactions that enqueued the jobs, you must pass the parent request ID through the constructor.

Here’s an example of how you can store the parent transaction’s correlation ID as a state variable within a Queueable class:

public class AsyncProcessor implements Queueable {
    private final String parentCorrelationId;

    // Constructor captures the ID from the calling transaction
    // Same logic applies to batch
    public AsyncProcessor() {
        this.parentCorrelationId = Request.getCurrent().getRequestId();
    }

    public void execute(QueueableContext context) {
        // Log using the parent ID to maintain continuity
        System.debug('Processing Queueable linked to: ' + this.parentCorrelationId);
        
        // If making further callouts, pass the parent request ID, not the current request ID
	 Assert.areNotEqual(
this.parentCorrelationId,
Request.getCurrent().getRequestId(),
'The two request IDs are different because of the asynchronicity'
);
    }
}

Use a similar approach for Batchable and Schedulable.

Use a String parameter to pass the ID in @future methods.

Propagating correlation IDs in Flow

When working with Flow, you can call third-party APIs declaratively with an HTTP callout action or with an external service action.

Regardless of the action type that you use, you first need to obtain the request ID. Flow does not have a native “Get Request ID” action so you must build your own. To do so, you can write and call a simple invocable Apex class to expose the current request ID to the flow:

public class FlowCorrelationHelper {
    @InvocableMethod(
        label='Get Correlation ID'
        description='Returns the current Request ID'
    )
    public static List<String> getCorrelationId() {
        return new List<String>{
            Request.getCurrent().getRequestId()
        };
    }
}

At this point, if you use an HTTP callout action, you can pass the correlation ID as a custom header.

However, if you use an external service action, you might need to modify your service’s definition manually to add the proper header for passing the correlation ID in your operations. At run time, you won’t be able to create headers that are not part of the service definition.

Sample integration scenarios

Now that we’ve covered the theory, let’s take a look at four integration scenarios that mix the different techniques for passing request IDs across systems.

Scenario 1: Inbound request with custom Apex execution

In this scenario, a third-party system sends a REST API request to the platform with a correlation ID passed in the X-SFDC-REQUEST-ID HTTP header. Upon receiving the request, the correlation ID is automatically retrieved and saved as the current request ID natively by the platform. Some custom Apex code (either a trigger or a custom Apex REST web service) is then executed. As part of the Apex execution, the correlation ID can be retrieved via Request.getCurrent().getRequestId(). Request IDs are saved in the event log file.

Scenario 2: Inbound platform event with custom Apex execution

In this second scenario, a third-party system publishes a custom platform event thanks to a REST API call. The request holds a correlation ID in the X-SFDC-REQUEST-ID HTTP header and the custom event holds the same correlation ID in a custom SourceRequestId__c field.

Upon receiving the request, the correlation ID is automatically retrieved and saved in the event log file and the platform event is published. The platform event is captured by the platform as part of an after insert Apex trigger.

Due to the asynchronous nature of triggers, the code runs in a separate transaction and cannot reuse the original request ID. Instead, the correlation ID is retrieved from the SourceRequestId__c event field and can be propagated further or logged.

Scenario 3: REST exchange with asynchronous processing

In this third scenario, a third-party system sends a request to the platform. This triggers some asynchronous processing. Once the process completes, the platform sends a request to a third-party system (either the one that triggered the scenario or a different one). The same correlation ID is shared across systems during the entire sequence.

As in previous scenarios, the correlation ID is passed to the platform via a header. The API request triggers the execution of custom Apex code. The code creates and enqueues a job for some long-running processing.

Since the queueable job runs asynchronously, a distinct request ID is generated in this context. In order to propagate the original correlation ID, we retrieve the Apex caller’s request ID and pass it to the job via the Queueable constructor.

Once the job is completed, it runs an Apex callout that sends a request back to the third-party system with the correlation ID passed in the request body or in a header.

A variation of this scenario may include a platform event being sent back to the third-party system. This variant still includes asynchronous processing as the event bus assigns its own EventUuid after publish and doesn’t carry the original request ID. Hence, a custom SourceRequestId__c field is required to propagate the correlation ID.

Scenario 4: Flow with an HTTP callout

In this scenario, a screen or record flow processes some data, which then makes a callout to a third-party system. Since flows do not have a native “Get Request ID” action, an Apex class with an invocable method is required to expose the current Request ID to the Flow. Once retrieved, the request ID can be sent as part of the outbound request either in the body or as a header.

If you are using HTTP Callouts via Flow, you cannot dynamically set headers in Flow Builder. You may need to configure external credentials with custom headers to manage how metadata is passed, though dynamic injection often requires an Apex invocable action.

As with the previous scenario, a variation of this scenario may include a platform event being sent back to the third-party system. In this case, the request ID is propagated to the third-party system using a custom event field.

Conclusion

The techniques and patterns covered in this post provide a framework for implementing observability across the Salesforce Platform and third-party systems. The platform’s native request IDs serve as the foundation for end-to-end distributed tracing, and the key to success is consistent propagation across every boundary.

Once this transmission chain is correctly assembled, you can move beyond siloed logs to gain immediate and deep insights into cross-system interactions. This unified view is critical for efficiently troubleshooting issues and investigating performance bottlenecks, allowing teams to focus on a shared trace rather than wasting time cross-referencing multiple logs by date and time. Implementing these correlation patterns is essential for building and maintaining highly performant and resilient distributed applications.

Resources

• EventLogFile documentation
• Request Apex class documentation
• ApiEvent documentation

About the authors

Sébastien Colladon is a Salesforce Certified Technical Architect (CTA). He loves contributing to the Salesforce ecosystem. He is passionate about his craft. Follow him on LinkedIn and check out his GitHub projects.

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

The post Set Up Cross-System Observability with Correlation IDs appeared first on Salesforce Developers Blog.

You can now expose React-based composable storefront components directly in Page Designer, without maintaining ISML versions. Also, Page Designer now uses dynamic component loading, which loads only components that are in use. The new Page Designer streamlines your workflow and reduces maintenance, saving you development time while boosting storefront performance through dynamic component loading! In fact, the seamless integration of Page Designer with composable storefronts can save significant development time as reported by some early adopters. 

In this post, we explain how the new headless Page Designer architecture works and how to use it in your storefront.

Comparing new and old Page Designer approaches

The diagram below shows a side-by-side comparison of the data flow in the old approach and the new approach. It illustrates the shift from a legacy ISML-dependent architecture to a direct Page Designer integration with the PWA-Kit based Composable Storefront. The new architecture removes the ISML rendering layer. Page Designer now injects your composable storefront directly, where React components render the page. The metadata cartridge contains reusable pages and components and defines component structure. In the new approach, Page Designer doesn’t execute server-side JavaScript from the metadata cartridge. Instead, all logic is implemented in the React storefront components.

Check out the differences between the new headless approach and the old approach of building reusable pages and components in Page Designer. 

Page Designer new metadata attributes for PWA Kit

Page Designer uses a hierarchical architecture with three main concepts: pages, regions, and components. (To learn more, see Integrate Page Designer with PWA Kit in the Composable Storefront Developer Guide.) Page Designer components are defined using metadata files in the metadata cartridge. When the new headless mode is enabled, the storefront is responsible for rendering the components.

To enable headless rendering, two metadata attributes are required: arch_type and route. With the arch_type attribute, Page Designer recognizes your storefront as headless, and doesn’t render ISML components. The route attribute specifies a page’s location in the storefront. The route attribute enables Page Designer to open the correct storefront route when rendering the page in edit and preview mode.

The arch_type field in Page Designer metadata files

Add "arch_type": "headless" to Page Designer metadata files such as pages, components, and aspect types.
When arch_type is set to "headless", preexisting custom JavaScript in Page Designer metadata isn’t executed—all logic must be in your React components.

The route field in pages

Add the route field to specify a page’s location in the storefront. For example, "/" for homepage or "/about" for the About page. Also, you can set dynamic routes with parameters. For example, "/product/:productId" or "/category/:categoryId". Route parameters must match the attribute IDs defined in the page’s aspect type.

To learn more about routes, see Understanding Page Designer Components in the Composable Storefront Guide.

Example page

In this example, we show how to use the headless attribute with the home route of /.

{
    "name": "Home Page",
    "description": "Main landing page",
    "arch_type": "headless",
    "route": "/",
    "region_definitions": [...]
}

Example: Card component metadata

In this example, we show metadata for a card component with the headless attribute.

{
    "name": "Content Card",
    "description": "Flexible card component",
    "group": "commerce_assets",
    "arch_type": "headless",
    "region_definitions": [],
    "attribute_definition_groups": [...]

}

To learn more about Page Designer best practices and permissions, see Page Designer in the B2C Commerce Guide.

Migration Checklist: ISML to Headless

To migrate your app to the new headless architecture, follow this sequence of steps.

1. Install the required dependency, the @salesforce/storefront-next-runtime package.
2. Update component metadata to headless.
3. Update page metadata with routes.
4. Update the aspect type metadata for the product detail page (PDP), the product list page (PLP), and search, by adding the arch_type field.
5. Migrate from manual mapping to the dynamic registry lazy loading.
6. Set up PageDesignerProvider in the App component.
7. Create a PageDesignerInit component.
8. Create the useGlobalAnchorBlock Hook.
9. Add PageDesignerInit to the App.
10. Deploy and test the storefront.

For details, see Migration Steps in the Composable Storefront Developer Guide.

Conclusion

The new headless Page Designer architecture removes one of the biggest pain points when building composable storefronts: maintaining duplicate ISML implementations. Developers can now build Page Designer components once in React, while merchants continue to use the familiar Page Designer UI to compose pages. This approach reduces maintenance, simplifies development workflows, and improves performance through dynamic component loading.

Resources

• B2C Commerce Guide: Page Designer 
• Composable Storefront Developer Guide: Integrate Page Designer with PWA Kit

About the Authors

Maria Juraschik is a Lead Software Engineer at Salesforce, working on Page Designer and Content Management.

Katia Hage is a Lead Technical Writer at Salesforce. Katia writes documentation for storefront solutions for Commerce Cloud. Previously, Katia also covered documentation and Trailhead for the Salesforce Platform and Data 360.

The post Expose Your Composable Storefront in Page Designer Without ISML appeared first on Salesforce Developers Blog.

Be at the forefront of the largest technological shift in decades and get hands-on with the latest tools, features, and best practices to build the next generation of apps and agents. Whether you’re attending in person or tuning in virtually on Salesforce+, we’ve curated our top recommendations to help you jumpstart your agentic AI journey while maximizing your time at TDX 2026. 

With Agenda Builder live, now’s the time to start bookmarking your must-attend sessions to plan your perfect two days.

Experience the big moments and must-see keynotes

Get started by bookmarking the event’s can’t-miss sessions, including a visionary keynote, Hackathon Showdown, and an exciting product roadmap discussion. Add these sessions to your agenda if you’re attending in person, and follow the livestream on Salesforce+ if you’re joining remotely.

TDX Main Keynote

Discover how to build your Agentic Enterprise with Salesforce and unlock the power of humans and agents driving customer success together.
Add to your agenda
Watch on Salesforce+

True to the Core

Join Co-Founder Parker Harris and Salesforce product leaders to hear the latest Agentforce 360 roadmap highlights, followed by a live Q&A. This is a unique opportunity to ask your questions and get answers directly from the experts.
Add to your agenda
Watch on Salesforce+

TDX Hackathon Showdown

Watch finalists pitch Agentforce solutions to esteemed judges for a $50,000 prize. Discover how these innovators are building the future of the Agentic Enterprise.
Add to your agenda
Watch on Salesforce+

Learn how to build the Agentic Enterprise in the Campground

Once you’ve secured your badge, head to the Campground to see the Agentic Enterprise in action. This is where apps, agents, data, and Slack come to life through immersive demos, hands-on experiences, and customer stories highlighting what’s possible with Agentic AI.

Get hands-on with Agentforce Vibes

The Agentforce Vibes area is an immersive, hands-on space designed to help you unlock the power of enterprise vibe coding and experience Agentforce Vibes in action. Participate in a guided, 15-minute hands-on project and build a React app with Agentforce Vibes to earn an exclusive t-shirt. 

Dive deeper with product demos at Platform Park

Platform Park features 18 expert-led demos designed to take technical audiences beyond the keynote stage and theater sessions, and into the “how” of building, scaling, and customizing next-generation solutions. Whether you’re looking to deepen what you’ve learned so far at TDX26 or explore specific innovations, you’ll gain practical insights through guided product demonstrations that sharpen your technical expertise.

Attend introductory sessions at Basecamp Theater

Located in the heart of Platform Park, Basecamp Theater features five repeating sessions that break down the fundamentals of Agentforce, Data 360, and more. Whether you’re a seasoned pro or new to the Salesforce ecosystem, these introductory sessions provide the essential grounding you need to tackle more advanced demos and workshops. Sessions include:

• Introduction to Agentforce
• Introduction to Data 360
• Introduction to Platform
• Introduction to Enterprise Vibe Coding with Agentforce Vibes
• Agentforce in Slack and MCP Tools in Slackbot

To find these theater sessions in the TDX session catalog, select “Session Type” in the left navigation and then select “Activity”.

Test your skills at Camp Mini Hack

Visit Camp Mini Hack to get hands-on with Agentforce and earn exclusive prizes. Designed for all skill levels, these 30-minute challenges focus on building intelligent agents, automating complex workflows, and integrating data across the Agentforce 360 Platform.

Explore The Agentic Enterprise

Visit The Agentic Enterprise to see how global leaders are building the future through immersive stories that showcase real-world enterprise success in Agentforce City. This is your destination to get “under the hood” with technical specifications and implementation details from teams already managing agents at scale. From autonomous service to complex workflow chaining, you’ll find the practical insights needed to construct your own agentic future.

Scale faster with Agentforce Consultations

Agentforce Consultations connect you with technical experts to translate product capability into a practical, validated build plan. This is your opportunity to solve technical blockers and walk away with the specific technical specifications needed to maintain momentum the minute you’re back to work.

Build your Agentic Enterprise at the Agentforce Zone

Explore the full lifecycle of trusted, autonomous AI agents at the Agentforce Zone, featuring six specialized booths and one featured Mega Demo. This is the space to move beyond theory and see how data, human judgment, and autonomous AI agents come together in production. Whether you’re looking to master Agentforce Studio, explore workflow chaining, or dive into Agentforce Observability, you’ll find the technical immersion needed to build and govern real-world enterprise systems. 

Unify your Agentic Enterprise with Slack

Experience Slack as the front door to Salesforce, apps, and agents. This interactive journey transforms traditional demos into a hands-on adventure where you’ll see how Slack and the Real-Time Search API turn isolated tools into collaborative teammates. Chat with Slackbot using your unique context, build with Agentforce agents, and explore native automations with Salesforce Flow and Workflow Builder. Complete the journey to earn an exclusive TDX26 Slackbot plushy.

Skill up with developer sessions

Developer sessions are your opportunity to learn directly from product experts, Salesforce Developer Advocates, and peers building the Agentic Enterprise. These sessions cover technical deep dives, real-world implementations, and innovative solutions across the Agentforce 360 Platform. Join us to sharpen your skills and deliver production-ready solutions at scale. 

To find developer-focused sessions in the TDX session catalog, select “Role” in the left navigation and then select “Developer”.

Agentforce and AI integration sessions

Master Agentforce Vibes and vibe coding with these essential sessions to architect secure, production-ready agents and LWC apps.

Create High Quality Apps with Agentforce Vibes

What to expect: Master the creation of high-quality applications using Agentforce Vibes for instant generation and validation. This session will deliver practical workflows for integrating Code Analyzer and ApexGuru to ensure your LWC and Apex code is resilient, secure, and production-ready.
Featured speakers: John Belo, Mayuresh Verma, and Jeff Douglas
Add this session to your agenda

Design Rich Inputs and Outputs for Agents

What to expect: Move from building basic, text-heavy chatbots to delivering high-quality, streamlined conversational experiences. Master Lightning Type Overrides to eliminate frustrating back-and-forth dialogue and harness LWC-driven interactions that drive successful Agentforce adoption.
Featured speakers: Charles Watkins
Add this session to your agenda

Build Enterprise-Ready Apps with Grounded Vibe Coding

What to expect: ​​Bridge the “Context Gap” by integrating the Salesforce API Context, Metadata Experts, and Unified Catalog into your development lifecycle. Master the technical engine that transforms AI-generated output into trusted, production-grade metadata through real-world architectural patterns.
Featured speakers: Gonzalo Gambino and Sally El Ghoul
Add this session to your agenda

Agentforce 360 Platform sessions

Scale the Agentic Enterprise with these essential sessions to master core platform innovations, advanced Apex patterns, and modern API security.

Enhancing API Security with SOAP API Login Retirement

What to expect: Modernize your integration strategy by migrating from legacy SOAP login methods to secure, modern authentication standards. This session provides the architectural blueprint required to audit existing integrations, implement robust authentication flows, and ensure your APIs remain secure as support for legacy login ends.
Featured speakers: Jeremy Westerman
Add this session to your agenda

Deep Dive into Apex Best Practices for Apps and Agents

What to expect: ​​Master advanced Apex patterns designed for enterprise-scale agents and applications. You will learn to architect for concurrency, implement robust exception logging, and optimize trigger performance to ensure your code remains resilient and efficient as agent interactions scale.
Featured speakers: Daniel Ballinger, Markus Neubrand, Mitch Spano, and Peter Churchill
Add this session to your agenda

Platform Integration Championship Live

What to expect: Put your integration skills to the test in a fast-paced, live game show format. Compete against your peers to showcase your expertise in APIs, external services, and event-driven architectures, with a prize for the champion who demonstrates the sharpest technical knowledge.
Featured speakers: Tyson Read, Raj Advani, and Jeremy Westerman
Add this session to your agenda

Roadmap sessions

Align your long-term strategy with these essential sessions to get an exclusive look at the future of Data 360, LWC, and Agentforce.

Salesforce Developer Tools Roadmap: Vibe Coding, MCP and ALM

What to expect: Get an exclusive look at the future of our developer tooling, covering the latest advancements in Vibe Coding, MCP, and ALM. This session will provide the roadmap for the technologies you need to build, test, and deploy resilient agents and apps at scale.
Featured speakers: Dan Fernandez and Karishma Lalwani
Add this session to your agenda

Apex Roadmap: What’s New and What’s Coming

What to expect: This must-see roadmap session offers an exclusive look at the future of Apex, including upcoming enhancements engineered for agents. You will gain critical updates on security models and asynchronous limits, equipping you to build efficient, scalable code on the Agentforce 360 Platform.
Featured speakers: Daniel Ballinger and Markus Neubrand
Add this session to your agenda

Explore the Agentforce Roadmap

What to expect: Review the strategic trajectory of the Agentforce 360 Platform. This session outlines upcoming innovations in autonomous agent capabilities, governance frameworks, and data integration patterns, providing the architectural foresight needed for your enterprise deployments.
Featured speakers: Austin Javellana, Will Matteson, Deepak Mukunthu, and Shiv Ramanna
Add this session to your agenda

Explore the Data 360 Roadmap for Developers

What to expect: Gain technical insight into the evolution of Data 360, the foundational data layer of the Agentforce 360 Platform. Get a peek at upcoming enhancements in data ingestion pipelines, as well as learn about identity resolution and semantic modeling, so you can build scalable data foundations that ground your agents in trusted, real-time context.
Featured speakers: Pradeep Krishna, Jitin Mehndiratta, and William Yeh
Add this session to your agenda

LWC Roadmap: What’s New and What’s Coming

What to expect: Explore the LWC roadmap and future of front-end development. Discover how Micro Frontends, Lightning Out 2.0, and new base components simplify building scalable enterprise applications.
Featured speakers: Clay Martin, Shalini Jain, and Ben Sklar
Add this session to your agenda

More product sessions

Extend your agentic logic with these essential sessions to automate Data 360 deployments using Data Kits and architect secure solutions using Slack, Zero Trust, and more.

Automate Data 360 Deployments: DevOps for Data Kits

What to expect: You will learn how to implement automated deployment pipelines for Data 360 using Data Kits. Master techniques for managing environment parity, versioning, and lifecycle management for your data assets, ensuring consistent, repeatable configurations across your development and production environments.
Featured speakers: Jitin Mehndiratta and William Yeh
Add this session to your agenda

Build Employee Agents for Slack and Experience Cloud

What to expect: Architect and deploy employee-facing agents within Slack and Experience Cloud. Learn the patterns for integrating agent logic into these interfaces to ensure secure, context-aware interactions that allow employees to solve complex tasks natively within their flow of work.
Featured speakers: Simon Finney
Add this session to your agenda

Secure AI Integrations with Zero Trust & MCP

What to expect: Architect secure AI integrations by leveraging Zero Trust principles and the Model Context Protocol (MCP). You will learn to implement granular access controls, validate agent connections, and enforce security policies across your multi-agent architecture, ensuring data protection and compliance in your enterprise environment.
Featured speakers: Aman Sahu and Roushan Kumar
Add this session to your agenda

More things to look out for at TDX

Grow your network at Community Cove

Community Cove is the destination for Trailblazers across the ecosystem to connect, network, learn, and have fun. From technical deep dives to joining a slide-free meetup, you’ll find the peers and experts needed to empower your Salesforce journey.

Skill up at Camp Trailhead

Get hands-on with Salesforce in just 20-30 minutes at Camp Trailhead. Whether you’re a new learner or an experienced pro, this is your stop to get hands-on with apps, agents, data, and Slack. Dive into curated Trailhead badges with expert assistance, complete badges to claim exclusive rewards, and celebrate your new skills at the photo booth.

Learn and earn with the TDX Quest

The TDX Quest is an interactive experience designed to help you build practical skills and earn exclusive prizes. This year, we’ve simplified the path to focus on 1:1 engagement at each activation so you can learn at your own pace. Complete the Quest to build your own custom swag bag and celebrate your achievements with the Trailblazer Community.

Explore the Admin and Architect tracks

Looking to diversify your agenda? Check out all the sessions on the Admin and Architect tracks to see how the Agentic Enterprise is being built, governed, and scaled in this new Agentic AI era. Explore the Admin and Architect Guides to TDX 2026 to learn more about what TDX has in store for these roles.

Quick TDX tips

Watching from home? Join on Salesforce+

Can’t make it to TDX in person? Select keynotes and sessions will be live-streamed on Salesforce+ during both days of the event. In addition to the live experience, a selection of on-demand episodes will be available for viewing after TDX ends.

Register for Salesforce+ for free to get access to featured content.

Accessibility at TDX

We’re dedicated to ensuring an exceptional and accessible experience for all Trailblazers, including those with disabilities and/or medical conditions. If you’re unsure if you’ll need support during TDX, reach out to the Disability Help Desk to chat with a dedicated accessibility manager. We can answer questions, provide information, and assist you in determining if further accommodations are necessary. Email us at DisabilityHelpDesk@Salesforce.com. For more accessibility information, visit the TDX FAQ page.

Your TDX 2026 checklist

TDX 2026 will be here before you know it. Take these steps now to prepare for the big event.

• Register to attend TDX if you haven’t already. 
• Start building your perfect TDX agenda now with Agenda Builder. Refer to the sessions in this post to guide you. 
• Download the Salesforce Events app in the App Store or Google Play Store to keep track of everything on your agenda in one easy-to-access place.
• If you’re not attending in person, be sure to register and watch on Salesforce+. 

Follow Salesforce Developers on X and LinkedIn for more TDX updates.

About the author

Sarah Welker is a Developer Marketing Manager at Salesforce. She balances her love for sustainable shopping and Sunday league soccer with a mission to visit every MLB ballpark, while maintaining her status as her kids’ #1 fan on the sidelines. Find her on LinkedIn.

The post The Salesforce Developer’s Guide to TDX 2026 appeared first on Salesforce Developers Blog.

Creating a custom property editor

With custom property editors, you can create any type of UI field for configuring a property value in Experience Builder. For instance, instead of a text field where your users type in a date, you can offer a date selector with a pop-up calendar in the component property panel, where users can click to select a date.

Because a custom property editor is simply a Lightning Web Component, creating one is just like creating any other Lightning Web Component, just with a few extra details. Let’s take a look at how to create one, using text alignment as an example.

Scenario: Say that you’re working with a custom Lightning Web Component named CustomArticle. For the textAlignment property, instead of the default String editor, you envision having a button group where users can adjust alignment with one click.

To create this button group, you can create a Lightning Web Component that acts as a custom property editor for the textAlignment property of the String type. Let’s call this new custom editor alignmentCPE. To create it, follow these basic steps.

Step 1: Create a component class

For the alignmentCPE component to act as a custom property editor, it must adhere to the property editor contract. The contract requires your custom property editor component to include certain public properties in its element class: label, value, errors, and schema. See the documentation for more information about the property editor contract, including other public properties that it exposes.

Here’s a basic class snippet for creating a component class.

export default class AlignmentCPE extends LightningElement {
    @api value;
    @api label;
    @api schema; // Derived from the associated property type.
    @api errors;
    @track buttons = [...]

    handleAlignmentClick(event) {
        const value = event.target.value;
        this.value = value;
        this.dispatchEvent(
            new CustomEvent('valuechange', { detail: { value: this.value } })
        );
    }
}

Note the custom event being dispatched by the click handler. The event name must be exactly valuechange, and the detail must include the value property as part of the property editor contract.

Step 2: Create the component UI

Next, craft a user-friendly UI for your property editor using HTML and CSS, just as you would for other Lightning Web Components.

Here’s a code snippet for the alignmentCPE component.

<template>
    <label>Text Alignment</label><div>
        <lightning-button-group onclick="{handleAlignmentClick}">
            <template>
                <lightning-button-icon-stateful key="{button.value}" value="{button.value}" selected="selected" icon-name="{button.icon}">
                </lightning-button-icon-stateful>
            </template>
        </lightning-button-group>
    </div><p>
</p></template>

Step 3: Update the component’s metadata configuration

Finally, ensure that the js-meta.xml file of your component recognizes alignmentCPE as a property editor by adding the lightning__PropertyEditor target.

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
  <apiVersion>66.0</apiVersion>
  <isExposed>true</isExposed>
  <masterLabel>Alignment Editor Component</masterLabel>
  <targets>
    <target>lightning__PropertyEditor</target>
  </targets>
</LightningComponentBundle>

Creating a custom property type

While a single custom property editor is powerful, you can go even further. For example, you may have multiple properties on your custom Lightning Web Component, and you may want to group these properties in a specific way, such as in tabs or in accordion sections. Or, you may have multiple properties that you want to reuse in different Lightning Web Components.

In these cases, you can create a custom property type. With a custom property type, you can:

• Group properties in tabs or accordions
• Put multiple properties in a custom property type and reuse this custom type without having to re-create each of these properties for each component
• Add more validation rules to certain properties. For example, for a URL field, you can specify which protocols to allow, such as https or http.

A custom property type is defined using a new metadata type called LightningTypeBundle. To create a custom property type, follow the steps below.

Scenario: Say that you’re working with your custom Lightning Web Component, CustomArticle. You want to create a complex property type, layoutProperty, that includes sub-properties for borderStyle, borderWeight, borderRadius, layoutHeight, and layoutWidth. You also want to organize these properties on tabs named Borders and Size.

To create this complex type, follow these steps. 

Step 1. Structure the LightningTypeBundle

First set up the folder for the new metadata type. Create a lightningTypes folder to describe layoutProperty, the custom property type in this example.

 
+--myMetadataPackage
     +--lightningTypes
          +--layoutProperty
              +--experienceBuilder
                  +--editor.json
              +--schema.json

Step 2. Define the schema: schema.json

A schema.json file is integral to defining the structure, type, and validation of a property. By adhering to the JSON Schema specifications, you ensure that the property values that you set for your component align with the necessary structure and format, maintaining data integrity and component functionality.

See our documentation for a full list of keywords that you can specify in a schema.json file. Unless otherwise noted, the keywords follow the JSON Schema specification.

Here’s the schema JSON for the complex layoutProperty property type:

{
    "title": "Layout Properties",
    "lightning:type": "lightning__objectType",
    "properties": {
        "borderStyle": {
            "lightning:type": "lightning__textType",
            "title": "Border Style"
        },
        "borderWeight": {
            "lightning:type": "lightning__integerType",
            "title": "Border Weight (px)"
        },
        "borderRadius": {
            "lightning:type": "lightning__integerType",
            "title": "Border Radius (px)"
        },
        "layoutHeight": {
            "lightning:type": "lightning__integerType",
            "title": "Layout Height (px)"
        },
        "layoutWidth": {
            "lightning:type": "lightning__integerType",
            "title": "Layout Width (px)"
        }
    },
    "required": []
}

In the schema.json file, you specify a lightning:type for each property in your complex property type. Salesforce offers several Lightning property types out of the box that act as the basic types. See our documentation for the full list of Lightning types. Each Lightning property type is associated with a default property editor in Experience Builder, so if you do use one of these property types, you don’t have to create a property editor yourself.

For example, here’s the default property editor for the Lightning type lightning__dateTimeType.

Step 3. Define the editor: editor.json

This optional step covers what to do when you want to create a custom property editor for your custom property type. Whereas schema.json defines a property type structure, the optional editor.json file lets you override the property editors for a property and lay out the property as you wish, such as in a vertical layout, on tabs, or in accordion sections.

See our documentation for the full list of keywords that you can specify in an editor.json file. Unless otherwise noted, the keywords follow the JSON Schema specification.

Here’s an example of an editor.json file for laying out properties on tabs for layoutProperty.

{
  "editor": {
    "layout": {
      "definition": "lightning/tabSetLayout",
      "children": [
        {
          "definition": "lightning/tabLayout",
          "attributes": {
            "label": "Borders"
          },
          "children": [
            {
              "definition": "lightning/propertyLayout",
              "attributes": {
                "property": "borderStyle"
              }
            },
            {
              "definition": "lightning/propertyLayout",
              "attributes": {
                "property": "borderWeight"
              }
            },
            {
              "definition": "lightning/propertyLayout",
              "attributes": {
                "property": "borderRadius"
              }
            }
          ]
        },
        {
          "definition": "lightning/tabLayout",
          "attributes": {
            "label": "Size"
          },
          "children": [
            {
              "definition": "lightning/propertyLayout",
              "attributes": {
                "property": "layoutHeight"
              }
            },
            {
              "definition": "lightning/propertyLayout",
              "attributes": {
                "property": "layoutWidth"
              }
            }
          ]
        }
      ]
    }
  }
}

Linking custom property editors and types to a Lightning Web Component

After you create a custom property editor or custom property type, the final step is to link them to your Lightning Web Component. Here’s an example of an XML configuration that integrates the custom property editor alignmentCPE and the custom property type layoutProperty.

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>66.0</apiVersion>
    <isExposed>true</isExposed>
    <targets>
        <target>lightningCommunity__Page</target>
        <target>lightningCommunity__Default</target>
    </targets>
    <targetConfigs>
        <targetConfig targets="lightningCommunity__Default">
            <!-- Linking the Custom Property Editor for Text alignment-->
            <property name="textAlignment" type="String" editor="c/alignmentCPE" label="Text Alignment" />            
            <!-- Linking the Custom Property Type for Layout & border style -->
            <property name="layoutProperty" type="c__layoutProperty" label="Layout & border style" />
        </targetConfig>
    </targetConfigs>
    <masterLabel>Custom Article</masterLabel>
</LightningComponentBundle>

This example shows how to use a custom property editor and custom property type together, but you can choose to use either independently, depending on your component’s needs.

Conclusion

Custom property editors and custom property types empower developers to dramatically improve the configuration experience for users in Experience Builder. By moving beyond basic fields to create intuitive, interactive UIs, you can make your Lightning Web Components easier to configure and reuse. Whether you need fine-grained control over a single property’s UI with a custom editor, or you need to group and structure multiple related properties with a custom type, these tools give you the flexibility you need to deliver a superior low-code development experience.

Resources

• Create a Custom Property Editor or Type for a Custom Component in Experience Builder: A comprehensive resource for creation through deployment
• Lightning Types Developer Guide: A detailed resource for developing new Lightning Types
• Code samples: Ready-to-use sample components

About the authors

Henry Chen is a Software Engineer on the Salesforce Platform team, working on low-code builders. He enjoys spending his free time playing video games, ice skating, and watching movies.

Sudheer Kumar Reddy Gowrigari is an Engineering Manager on the Salesforce Platform team leading the content builder and builder framework areas. Outside work, he loves playing cricket, diving into books, and watching movies.

The post Build Custom Property Editors and Types for Experience Builder appeared first on Salesforce Developers Blog.

The good news? The new Omnistudio Standard Designers, runtime, and components are now built directly into the Salesforce Platform. This eliminates the old packaged installation process and ensures everything runs natively on the Platform.

What are Omnistudio standard designers?

The Omnistudio standard designers are tools that run directly on the Salesforce Platform, rather than a separate managed package. This includes runtime components like Flexcards, Data Mappers, Integration Procedures, and Omniscripts.

If Omnistudio is the engine for building these experiences, what are the parts that make it run? It breaks down into four key components: Omniscripts and Flexcards handle the frontend UI experience, while Data Mappers and Integration Procedures manage the backend data orchestration. Together, they bridge the gap between user interaction and backend data processing.

Example: You might use an Omniscript to take a student’s application, collecting their name, GPA, and program choice on a Lightning Web Runtime (LWR) site. A Flexcard on an Experience Site could then show those account details and launch an Omniscript flyout to update that information. Upon submission, a Data Mapper loads Omniscript input fields (name, GPA) into the appropriate Student Profile record in Salesforce. If the student enters GPA and tuition information in an Omniscript, an embedded Integration Procedure orchestrates the backend logic to calculate scholarship amounts before displaying the results.

Omnistudio’s journey: Past, present, and future on Platform

To understand the change, we need to rewind a bit. In the past, Omnistudio was managed through packages. If you were using it with  Communications, Media, and Energy & Utilities (CME) or insurance packages, everything was bundled together. The tools used to build ( designer), basic data components (entities), and the engine that ran scripts (the runtime) all resided within that specific industry package.

Following the acquisition of Vlocity, we introduced a new layer called the Foundation package. This new package housed Omnistudio designers and entities separately. This was a crucial phase because industries such as Agentforce Health, Agentforce Education, Agentforce Manufacturing, and Agentforce Financial Services (FS) could install the Omnistudio package directly without needing the older CMT or INS packages.

Today, Omnistudio is a native, deeply integrated part of the Salesforce Platform. With this transition, you no longer need to install separate packages. Once you enable your industry license (which includes Omnistudio licenses), the designers and runtime are available immediately. There’s no need to rely on packages, so you’re always using the fastest and latest version.

Who can access the new standard designers?

Now the question arises: Who can or ‌can’t access the new designers? We’ve got you.

• New customers: If your org has a Salesforce Industries license and no existing package, enabling your bundled Omnistudio license gives you direct access to designers and runtime on the Platform. No separate Omnistudio package installation is needed.
• Existing customers already on the Platform: If you already have Omnistudio license enabled, and the org is on the Platform, you’re in luck. Once the package is updated to the latest version, you’ll get the standard designers by default.
• Existing customers still on the package runtime: If your org is on the package runtime, you won’t automatically get access to standard designers. You’ll need to take steps to migrate to the Platform runtime to gain access to it.

Benefits of standard designers

To be honest, the package designer’s list page for managing components was often difficult to navigate. Navigating the hierarchical view made it difficult to find what you were working on.  Locating properties and elements while switching between tabs to build and configure a component was troublesome, and moving between versions required multiple steps.

With the standard designers, you’re automatically on the best and latest versions. You get immediate access to new features, better performance and user experience (UX), faster Omniscript activation, and security enhancements without waiting for complex package updates. These enhancements allow you to go live faster and enhance productivity. However, it doesn’t stop here. Let’s see some more benefits.

Enhanced developer experience with general UI improvements

The new Omnistudio standard designers bring a huge leap forward in the daily developer experience. They are more responsive and intuitive, and they are visually aligned with familiar Salesforce interfaces.

Salesforce standard list view page

The new designers use traditional Salesforce list views for all four major components.

• Familiar look and feel: The list page follows Salesforce standards, meaning it looks and acts like your familiar Account or Contact pages.
• Customization power: This is a significant benefit for developers working in teams. Since it is a standard Salesforce list view, you can create custom views and filters, choose which columns to display, and filter components to show only what you are actively working on.
• Focus on recent work: No more old hierarchical list view. The new list view defaults to showing the most recently modified records, ensuring your current components are front and center.

Organized designer canvas for Flexcard and Omniscript

The new designer canvas has been completely reconfigured to be more intuitive and aligned with experiences like the Lightning App Builder. The layout is much more logical and intuitive. For example, creating a Flexcard now takes just three steps: click New, enter details, and Save. To select a data source, click the Setup icon, scroll to Data Source, and choose from the dropdown. You will also find:

• Elements on the left: All available elements (such as steps, blocks, Data Mappers, and standard actions) appear neatly on the left side of the canvas. You can drag and drop them directly onto the canvas.
• Canvas in the center: The canvas where you build and visualize your components is centrally located.
• Properties on the right: The properties panel automatically loads on the right side of the screen when you drag, drop, or click a component. The necessary configuration options appear instantly when needed.
• Organized elements: To improve clarity, elements are now grouped logically. For example, Data Mapper actions are clubbed into one section to make them easily understandable.
• Setup panel access:  Less frequently used configurations (such as the setup panel for knowledge articles, currency fields, or cache configurations) are accessible through a top menu or dedicated icon instead of cluttering the workspace.

Intuitive version management

Managing multiple versions of your components within the builder interface is now significantly easier, eliminating unnecessary navigation steps.

• Switching inside the designers: Users can easily switch versions via a drop-down menu located at the top of the designer interface (available for Omniscript, Flexcard, and Integration Procedures). This eliminates the need to return to the main list page to access an older version.
• Creating new versions: To create a new version, simply click the New Version button and confirm.
• Track older versions: Select Manage Versions from the dropdown on the right side of the record to view all versions and drill down as needed (available for Omniscript, Flexcard, Integration Procedure list pages).

The Design Assistant

In the managed package runtime, there were no guardrails or limits set on creativity. Developers could unknowingly create overly complex components that were so large or heavy, they broke the designer itself. This meant developers often didn’t realize they had exceeded system limits until discovering the issue during activation.

The Design Assistant reviews your Omniscript or Flexcard with soft guardrails, not hard warnings, during design. Instead of reaching the checkout line (activation) and realizing the cart is too heavy (breaking the component), you’re gently reminded mid-shopping (during design) to split items (heavy child cards) into smaller carts for smoother processing.

Design Assistant provides two types of feedback: 

• Information messages: Displayed when designs approach system limits. For example, a data table component is approaching the 500-row limit. These act as early warnings.
• Warning messages: Displayed when the design exceeds recommended limits, signaling that the component may be too complex.

Component-specific design transformations

Through component-specific enhancements, the standard environment is now more responsive, intuitive, and developer-friendly. This shift allows you to spend less time managing the tools and more time delivering meaningful digital experiences.

Instant activation and creation speed

In the package designers, activating an Omniscript required activation, compilation, and deployment. It was a time-consuming bottleneck that disrupted workflow.

With the new designers:

• Activation for Omniscripts, Flexcards, and Integration Procedures is nearly instantaneous.
• Performance is up to nine times faster than the legacy package.
• Creation of Omniscripts and Flexcards is up to six times faster.
• Flexcard creation now requires just two clicks: New and Save.

Note: All data presented above is derived from internal testing.

Integration Procedure Designer

The Integration Procedure Designer has undergone significant visual and functional upgrades. The older Angular-based package designer was simply not as intuitive. It dumped you directly onto a blank canvas without guidance on where to start. Even dragging elements was clunky and frustrating.

Now, when you click New, you are prompted to enter a Name, Type, Subtype, and Description. After saving, the designer opens in a new browser tab with a playground-type structure. Once you land on the designer’s canvas, you immediately see a Plus (+) icon indicating where to begin adding components. This structure is much more visual and clearly shows the flow of data.

The new Integration Procedure interface also introduces several key usability enhancements such as:

• Easy component setup: Add components using Plus (+) icons between cards. The properties panel appears instantly in the right tray for configuration, and you can view the Type and Subtype through the gear icon in settings.
• Visual connectors: After adding components, connectors automatically appear between components, clearly displaying execution flow. Since Integration Procedures are headless, these connectors make data flow transparent and easy to understand.
• Easy manipulation: Use drag-and-drop functionality to add components, shuffle them within the canvas, and rearrange them easily.
• Undo/Redo: To make development easier, we’ve introduced undo and redo options.
• Explicit saving: Changes (like dragging a component or adding an action) require clicking an explicit Save button to ensure they are intentional.
• Intuitive preview: Entering ‌preview mode and executing your Integration Procedures now includes color indicators to show which action was successful and which component failed during execution, significantly improving troubleshooting.

Data Mapper Designer

The Data Mapper, an essential backend tool for Omnistudio, handles data extraction, loading, and transformation. 

The first thing you will notice is the visual upgrade. The new Data Mapper UI visually aligns with the new Integration Procedure Designer, ensuring a consistent experience across backend components.

Key improvements include:

• Select interface: Start by selecting an interface type (such as Extract or Load), then use the Plus (+) icon to add objects and formulas intuitively.
• Connectors: Link elements using connectors, with options to move rows up or down or insert rows within a clean table structure. 
• The new table view: The table-based layout resembles JSON paths and outputs, making mappings easier to visualize and configure.
• Transformation setup: This visual alignment makes defining how data is extracted, transformed, and loaded more accurate, saving significant time during configuration.

Start exploring the standard designers today

The new Omnistudio standard designers mark a massive architectural shift, delivering instant activation with a simplified, intuitive canvas, and essential future-proofing for next-generation features. Now is the perfect time to ensure your organization is positioned to benefit from these improvements. Sign up today.

Resources

• Learn about Omnistudio Development Essentials on Trailhead
• Watch a video to learn how to Build Low-Code Digital Experiences with All-New Omnistudio
• Learn about Omnistudio Omniscript Fundamentals on Trailhead

About the author

Krishna Kruthiventi is a Senior Product Manager at Salesforce, specializing in Industries Cloud solutions. His primary focus is on the Omnistudio product suite, simplifying complex enterprise workflows and elevating Omnistudio to deliver best-in-class, consumer-grade digital experiences for both administrators and end users. Follow him on LinkedIn.

Payal Verma is a Content Marketing Analyst at Salesforce with over four years of professional experience in product, brand, and content marketing. She has worked across B2B and B2C markets, developing and executing content strategies for a wide range of formats, including blogs, social media, scripts, e-books, guides, etc. Follow her on LinkedIn.

The post What’s New in Salesforce Omnistudio Standard Designers appeared first on Salesforce Developers Blog.