※本記事は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 six 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 Slackbot: Your Personal Agent for Work
• Introduction to Agentforce in Slack
• Introduction to Platform
• Introduction to Enterprise Vibe Coding with Agentforce Vibes

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.

Beyond “it’s a CRM” and a dizzying array of “Clouds”, I felt like I was learning a whole new language. To avoid boiling the ocean, I went back to basics to answer a simple question: What is the core platform for developers?

To find out, I decided to build something. Not a “Hello World,” but something interactive that requires state management, UI logic, and data persistence. A Drag-and-Drop Tier List for Office Snacks.

But here’s the twist: I built it twice. First in React (my comfort zone), and then I rebuilt it entirely in Salesforce using Lightning Web Components (LWC).

Unlike the React version, which I “vibe-coded” with AI in one shot, I approached the Salesforce build differently. I used AI as a paired-programming tutor alongside official documentation and Trailhead. My goal wasn’t just to get working code, but to actually learn the architecture.

(Note: If you’re an experienced Salesforce developer, nothing here will wow or surprise you; you’ve likely seen these errors a thousand times. But for those of us new to the ecosystem, I wanted to document exactly what the transition feels like.)

Here is what I learned when I stopped reading the marketing brochures and started writing code.

Phase 1: The Control Group (React + Vite)

To make this a fair experiment, I needed a baseline. I spent about 20 minutes spinning up the React version. I didn’t need to learn anything here – I already understand React state. I just needed a functioning “Control Group” to accurately measure the friction and differences once I switched to the Salesforce ecosystem.

I’ll be honest: I “vibe-coded” this one. I fed an LLM a screenshot of a Tier List and told it: “Build me a similar drag-and-drop tier list app in React (Vite) with Tailwind CSS that lets you rank office snacks into S/A/B/C/D tiers, with localStorage persistence.”

After some minor tweaks, the resulting app worked perfectly. I could drag a bagel to S-Tier and candy corn to D-Tier (where it belongs—please never bring this as an office snack.)

But looking at the generated code, I realized two things:

1. Heavy Dependencies: The LLM immediately reached for a third-party library (dnd-kit) to handle the drag-and-drop mechanics. I wondered what the equivalent would be when developing on the Salesforce platform.
2. Manual Persistence: To save my rankings, the app needed a 40-line function just to read from and write to the browser’s localStorage. I assumed that in the Salesforce ecosystem, there would be a more streamlined way to handle this—and I was right.

If I wanted to make this “real”—shareable with coworkers or persistent across devices—I would have needed to spin up a backend (Node, Supabase, or Firebase) and write API endpoints.

That was the perfect segue to Salesforce.

Phase 2: The Variable – Salesforce LWC

My goal was simple: Recreate the exact same app using strictly Salesforce platform tools. No external database, no Node server. Just me and the Org.

Library vs. Native Web Standards

I expected a proprietary nightmare or a weird, archaic language. What I found was… JavaScript.

Salesforce uses Lightning Web Components (LWC). The code felt shockingly similar to React, but simpler in a key way: for the drag-and-drop logic, I didn’t need a massive npm package. I used standard HTML events (ondragstart, ondrop). Because LWC runs right in the browser without a heavy virtual DOM layer, the standard web APIs just worked.

Phase 3: Where React Needs a Backend, Salesforce Is the Backend

This was the biggest “aha!” moment. In my React app, “saving” data meant writing 40 lines of code to manually serialize JSON into the browser’s localStorage. And if I wanted to make that data permanent? I’d have to learn SQL, spin up a Postgres database, build a Node API, and handle CORS.

In Salesforce, I didn’t need to do any of that. I just created a Custom Object.

I went to the Object Manager, created a Tier_List_Item, and instantly had a secure, scalable relational database with an auto-generated API. And while I didn’t explore it deeply for this specific project, I realized I also got a full-blown enterprise security model right out of the box. If I ever needed to handle granular permissions—like ensuring only managers could edit the S-Tier snacks—I could configure that entirely through the standard UI instead of spending a week writing authentication middleware.

To get that data into my component, I used the @wire service—a reactive direct line to the database.

Manual State Management in React:

 

// In React, we have to manually load the initial state from storage 
const [boardState, setBoardState] = useState(loadInitialState); 

// And we have to manually save it every time something moves const handleDragOver = (event) => { 
// ... calculation logic ... localStorage.setItem(STORAGE_KEY, JSON.stringify(next)); 
}; 

Declarative Data Binding in Salesforce:

 

// The platform fetches the data for us
@wire(getAllItems) wiredItems; 
	
// We just tell the server to update the record 
handleDrop(event) { 
updateItemTier({ itemId: id, tier: newTier }); 
} 

The Takeaway

• In React: I spent my time managing libraries and local storage.
• In Salesforce: I spent more time writing logic. The platform provided the database, and the browser provided the interactivity.

The deployment cycle was slower (no hot-reload!), but the amount of “boilerplate” code required to get persistent data was significantly less. If I had known about Salesforce Live Preview before starting, my process would have been faster.

Phase 4: The “Chicken and Egg” Deployment Check

Connecting that frontend in Phase 2 to the backend in Phase 3 is where things got tricky. I wrote my LWC and my Apex controller to talk to the database, then hit deploy. The terminal screamed at me:

My instinct was to assume I had made a typo or something silly along the way. I checked all the usual suspects: spelling, file names, file paths, etc. But the code checked out.

In my React workflow, I would have simply pasted the error into an LLM, copied the fix, and moved on. But because I was using AI and the documentation to actually check my understanding, I stopped to figure out the why. This led me to a crucial difference: the Platform Compilation Model.

While not an official Salesforce term, this became a helpful mental model for how the platform validates code. In React, the browser is the only judge of your code. You can write a frontend function that calls an API that doesn’t exist yet, and the browser won’t care until the moment you actually run it.

In Salesforce, the server is the judge. When you deploy, the platform compiles your code to ensure it’s valid. It saw that my LWC was trying to shake hands with a backend method (getAllItems) that didn’t exist on the server yet.

I had to deploy the Apex Class (Backend) first, then the LWC (Frontend). It wasn’t just a syntax error—it was a reminder that I was coding for a tightly integrated platform, not just a browser.

Phase 5: Low-Code Superpowers (The “Real Dev” Moment)

Once I understood the architecture, I realized I had access to way more than just a database. Since my “Snacks” were now actual data records, I could use the full power of the Salesforce automation engine.

I wanted to add some hard-hitting business logic: “If a snack is demoted to D-Tier, notify the team on Slack.”

In my React app, this is where the fun stops and the infrastructure work begins. I would need a webhook, a cron job, or maybe a Zapier subscription. In Salesforce, I didn’t write a single line of code. I simply used a Flow.

I built a “Record-Triggered Flow” that listens for the Tier field changing to D. When it happens, it sends a message to a Slack channel.

The Humble Pie (Error 500)

Of course, it wasn’t all seamless. I got confident and tried to add a second feature: posting a “congratulations” message to the internal feed (Chatter) when a snack hit S-Tier.

I set it up, ran it, and… Error 500.

The error message was cryptic, even though my logic was sound. I spent way too long debugging my Flow before a mix of AI nudging and diving into the platform documentation pointed me to the object settings.

Turns out, there’s a small checkbox for “Feed Tracking” on my Custom Object that I hadn’t turned on. The system was trying to post to a feed that didn’t exist yet.

It was a frustrating, head-desk moment, but it was also a validating one. It was a good reminder that Low Code ≠ No Knowledge. You still need to think like a developer and know which switches to flip to make the platform work for you.

Conclusion: It’s a Platform, Not Just a CRM

So, what did I learn in my first three weeks?

I learned that the gap between a “Modern Web Developer” and a “Salesforce Developer” is much smaller than I thought. If you know JavaScript, you already know a large chunk of the syntax.

But more importantly, I learned what the platform actually does. It handles the boring but essential stuff—Auth, Database, Hosting, and APIs—so you can focus on the logic that matters. Whether that logic is “closing a million-dollar deal” or “ranking crackers as D-Tier,” the tools are fundamentally the same.

…And for the record: Bagels always belong in the S-Tier.

Want to Learn Along with Me?

I’m just getting started, and I used the Beginner Developer Trailmix in conjunction with my AI buddy to help learn the basics. If you want to build your own Tier List (or something actually useful), join me here:

• Beginner to Advanced Developer Roadmap (Trailhead)
• Introducing Lightning Web Components (Developer Documentation)
• Data Modeling (Trailhead)
• Salesforce Flow Basics (Trailhead)

About the Author

Sean Keegan is a Lead Developer Advocate at Salesforce based in New York City. A former math teacher, he is passionate about making complex tech accessible to everyone. Outside of work, you can find him playing video games, tending to his houseplants, or on the Ultimate Frisbee pitch. Connect with him on X/Twitter or LinkedIn.

The post React vs. Salesforce: How I Rebuilt My “Vibe-Coded” App on the Platform appeared first on Salesforce Developers Blog.

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

エンタープライズグレードのAIエージェントの構築には、根本的なジレンマがあります。大規模言語モデル（LLM）は、自然な会話を得意としているものの、エンタープライズ規模のワークフローに必要な一貫性には欠けています。注文の詳細を伝える前に顧客の本人確認を行うように指示しても、LLMが毎回その手順を守るとは限りません。この問題は、従来のプロンプトエンジニアリングでは解決できません。プロンプトが長くなり、指示が増えると、AIエージェントの振る舞いが予測しにくくなることもあります。

Agent Script（英語）は、AIエージェントを構築するためのSalesforceの新しい言語です。Agent Scriptにはハイブリッド推論が導入されており、同じ命令ブロックの中で決定論的なコードと自然言語のプロンプトを組み合わせることができます。Agent Scriptを使えば、ビジネスに重要なロジックを毎回確実に実行しながら、柔軟な会話を維持できます。

Agent Scriptは、コンテキストエンジニアリングのためのツールでもあります。LLMが重要な情報をくみ取ることを漠然と期待するのではなく、変数、条件、会話の状態に応じて、LLMに渡すプロンプトをプログラムで組み立てられます。LLMは、その時点で必要な情報だけを参照します。

この記事では、Agent Scriptの基礎とAIエージェントの基本的な構成ブロックについて説明します。構文を学び、制御の流れを理解し、Agent Scriptが実行時にプロンプトを構築する仕組みを見ていきます。

Agent Scriptの基礎

AIエージェントの構築を始める前に、Agent Scriptの基本的な構文を押さえておきましょう。基本を理解しておくと、この後の記事の内容がわかりやすくなります。

プロパティベースの構文

Agent Scriptは、すべてkey: valueのペアで記述されます。読みやすい、宣言型の言語です。

description: "顧客の注文を処理する"
agent_name: "Order_Management_Agent"
is_required: True

スペースの重要性

Agent Scriptは、Pythonと同様に、インデントを使って構造を定義します。タブではなく、スペースを使用する必要があります。スクリプトが正しく解析されるには、インデントが一貫していることが重要です。推奨される記述方法は、インデントの各レベルを3つのスペースで表すことです。

inputs:
   customer_id: string
   order_id: string

注 – インデントに一貫性がないと、スクリプトがコンパイルされません。コードをコピー＆ペーストするときは、特にこの点に注意してください。

@でリソースを参照

Agent Scriptでは、@記号を使って、変数、アクション、トピック、出力などのリソースを参照します。この仕組みで、AIエージェントを構成する各要素が情報をやり取りします。

@variables.customer_email    # 変数を参照
@actions.lookup_order        # トピックで定義されたアクションを参照
@topic.order_status          # 別のトピックを参照
@outputs.status              # アクションの出力を参照（アクションの実行後のみ有効）
@utils.transition to         # ユーティリティ関数を参照
@utils.escalate              # 別のユーティリティ関数を参照

注 – @がSalesforceの差し込み項目のように機能し、どの組織のリソースも参照できると思われるかもしれませんが、これはよくある間違いです。たとえば、@actions.get_orderが機能するのは、トピックのactions:ブロックでget_orderが定義されている場合だけです。@Account.Nameのような記述は、スクリプト内のブロックでも、組み込みのユーティリティでもないため、機能しません。

コメントアウトは#で

#記号を使うと、スクリプト内のどこにでもコメントを追加できます。その行の#以降の内容はすべて、コンパイラーに無視されます。AIエージェントのロジックを説明するために、コメントは積極的に使いましょう。Agent Scriptには、複数行のコメント専用の構文はありません。コメントが複数行にわたる場合は、各行の先頭に#を付けてください。

# このアクションは注文管理システムから注文の詳細を取得する
lookup_order:
   description: "IDで注文情報を取得する"  # LLMはこの説明を参考に、アクションを使用するタイミングを判断する

矢印構文（->）で手続き型ロジックを記述

条件分岐、アクションの実行、変数の設定など、段階的なロジックを記述する場合は、矢印構文を使用します。これにより、ブロックが宣言型モードから手続き型モードに切り替わります。

instructions:->
   if @variables.is_verified:
      run @actions.get_order
         with order_id=@variables.order_id
         set @variables.status = @outputs.status

矢印は、「この後に続くのは、単なる設定ではなく、実行可能なロジックである」ことをAgent Scriptに伝えます。

注 – :も使用できますが、表記を明確にするために->の方がよく使われます。

プロンプトテキストにはパイプ構文（|）を使用

パイプ記号は、プロンプトの一部としてLLMに渡されるテキストを示します。自然言語の指示は、この方法で記述します。

instructions:|
   | このテキストは、LLMが受け取るプロンプトの一部になります。
     インデントされたテキストは、同じ行の続きとして扱われます。
   | このパイプは、プロンプト内での新しい行の開始を意味します。

パイプは、手続きブロックの外側で複数行の文字列を表す場合にも使用できます。

instructions:|
   あなたは親切で有能なアシスタントです。
   常に礼儀正しく、プロフェッショナルに対応してください。
   お客様の機密情報は決して共有しないでください。

重要なポイントは、ロジックは決定論的に実行される一方で、パイプテキストはLLM向けのプロンプトとして組み立てられるということです。この分離が、ハイブリッド推論の中核を成しています。

動的な値を埋め込むためのテンプレート式（{! }）

変数の値または式をプロンプトテキストに埋め込むには、数式構文{! }で囲みます。Agent Scriptは、実行時にそれらを実際の値に置き換えます。

| こんにちは、{!@variables.customer_name}さん。ご注文の状況は、{!@variables.order_status}です。
| ご注文の合計金額は、{!@variables.order_total}ドルです。

上記のスクリプトで、customer_nameが「ジョン」で、order_statusが「出荷済み」、order_totalが「150」の場合、LLMは以下のような入力を受け取ります。

こんにちは、ジョンさん。ご注文の状況は、出荷済みです。
ご注文の合計金額は150ドルです。

LLMは変数名ではなく、具体的な値を受け取ります。これにより、LLMの処理が簡単になり、AIエージェントの信頼性が高くなります。

注 – テンプレート値に使えるのは、変数だけはありません。演算子を使った式にすることもできます。サポートされている演算子の詳細については、こちらのドキュメント（英語）を参照してください。

...による入力値の抽出

アクションをツールとしてLLMに公開する場合、会話の中から必要な入力値をLLM自身に抽出させたいことがあります。...構文は、LLMにパラメーターの値をユーザー入力から抽出する（スロットフィリング）ように指示します。

reasoning:
   actions:
      lookup: @actions.get_order
         with order_id=...                       # LLMが会話から抽出
         with customer_id=@variables.customer_id  # 特定の変数にバインド
         with limit=10                            # 固定のリテラル値

この例では、LLMが会話の内容からorder_idを特定し、変数からcustomer_idを取得し、定数のlimitを10に設定します。

注 – ...構文は、アクション入力のスロットフィリングでのみ使用できます。よくある間違いですが、変数のデフォルト値としては使えません。

式の演算子

Agent Scriptは、比較と論理式に使われる一般的な演算子をサポートしています。これらの演算子は、if文やavailable when条件で使用します。

# 比較演算子
@variables.count > 10
@variables.count >= 10
@variables.count < 5
@variables.count <= 5
@variables.status == "shipped"
@variables.email != ""

# 論理演算子
@variables.is_verified and @variables.has_order
@variables.is_premium or @variables.is_vip
not @variables.is_blocked

# Nullチェック
@variables.order_id is None
@variables.customer_name is not None

注 – Agent Scriptは、算術演算子として+と-をサポートしていますが、現時点では*、/、%はサポートしていません。複雑な計算が必要な場合は、FlowまたはApexのアクションを使ってください。

条件分岐

条件分岐（if/else）は、どの命令を実行するか、またはどのプロンプトを組み立てるかを制御します。

instructions:->
   if @variables.is_verified:
      | こんにちは。ご用件をどうぞ。
   else:
      | 最初に本人確認をお願いします。

   if @variables.order_total > 100:
      run @actions.apply_discount

注 – else ifは現時点ではサポートされていません。代わりに、複数のif文を個別に使用してください。

基本のブロック

Salesforce DXプロジェクトでは、Agent ScriptはaiAuthoringBundlesディレクトリ内に配置されます。たとえば、「HelloWorld」エージェントを構築している場合、スクリプトは次のパスにある.agentファイルに配置されます。

force-app/main/aiAuthoringBundles/HelloWorld/HelloWorld.agent

このファイルは、AIエージェントの頭脳で、これから取り上げる設定、変数、会話トピックを含んでいます。

すべてのAgent Scriptファイルは、ブロック単位で構成されます。ブロックは、特定の順序で記述する必要があります。以下は、最上位のブロックを順番に並べた全体像です。

config:
   # AIエージェントの識別情報

variables:
   # 状態管理

system:
   # グローバルな指示とメッセージ

start_agent topic_selector:
   # 開始点 – すべての会話の起点

topic my_topic:
   # それぞれのアクションと推論を含む会話領域

注 – この記事では、languageとconnectionは扱いませんが、connectionの使い方については、別の機会に詳しく説明する予定です。

では、顧客の注文情報を照会する「Order Management」エージェントを例として、順番に各ブロックを見ていきましょう。

1. config – AIエージェントの識別情報

configブロックでは、AIエージェントに関する基本的なメタデータを定義します。少なくとも、agent_nameを指定する必要があります。外部の顧客とやり取りするAgentforceサービスエージェントの場合は、default_agent_userも必要です。従業員支援エージェントでは、default_agent_userは必須ではありません。

config:
   agent_name: "Order_Management_Agent"
   agent_type: "AgentforceServiceAgent"
   default_agent_user: "orderagent@acme.com"

agent_nameは、AIエージェントの一意の識別子として機能します。

2. variables – 状態管理

変数を使うと、AIエージェントが会話の複数のターンにわたって情報を保持できます。これはきわめて重要です。LLMは本来、過去のやり取りを記憶しません。そのため、状態を明示的に管理する必要があります。

Agent Scriptには、2種類の変数があります。

• 可変変数 – AIエージェントが読み書きできる変数です。可変変数には、デフォルト値を設定することが推奨されます。
• リンク変数 – 読み取り専用の変数で、外部コンテキスト（現在のセッションなど）から値を取得します。リンク変数にはsourceが必要で、デフォルト値は設定できません。

variables:
   # 可変変数 – AIエージェントが読み書きできる変数
   customer_email: mutable string = ""
      description: "本人確認用の顧客のメールアドレス"
   customer_name: mutable string = ""
      description: "確認済みの氏名"
   is_verified: mutable boolean = False
      description: "顧客の本人確認が完了しているかどうか"
   order_id: mutable string = ""
      description: "現在問い合わせを受けている注文のID"
   order_status: mutable string = ""
      description: "注文の現在の状態"
   order_total: mutable number = 0
      description: "注文の合計金額"
   delivery_date: mutable string = ""
      description: "配達予定日"

   # リンク変数 – 読み取り専用で外部コンテキストから値を取得
   session_id: linked string
      description: "現在のセッションID"
      source: @session.sessionID

サポートされるデータ型の詳細については、公式ドキュメント（英語）を参照してください。

以下の点に注意してください。

• ブール値は、True、Falseのように、先頭を大文字にする必要があります。true、falseは使用できません。
• descriptionフィールドを使用すると、LLMが変数の内容を理解しやすくなり、スロットフィリングの精度が向上します。
• 可変変数にはデフォルト値を設定することが推奨されますが、リンク変数にはデフォルト値を指定できません。

3. system – グローバルな指示とメッセージ

systemブロックでは、AIエージェントの性格を定義し、2つの必須メッセージであるwelcome（会話の開始時に表示）とerror（問題の発生時に表示）を指定します。

system:
   messages:
      welcome: "こんにちは。注文サポートアシスタントです。ご用件をどうぞ。"
      error: "申し訳ありません。問題が発生しました。もう一度やり直します。"

   instructions:|
      あなたは、Acmeストアのフレンドリーで優秀な注文サポートエージェントです。
      注文の詳細情報を共有する前に、必ず顧客の本人確認を行ってください。
      簡潔に、顧客の役の立つ回答をしてください。
      回答がわからない場合は、率直にそう伝えてください。

注 – これらの指示は、すべてのトピックに対してグローバルに適用されます。ただし、特定のトピックでAIエージェントの振る舞いを変えたい場合は、トピックレベルで指示を上書きできます。以下は、トピックレベルで指示を上書きする例です。トピックについては、後ほど詳しく説明します。

topic professional:
   description: "ビジネス向けのフォーマルなコミュニケーション"

   system:
      instructions: "あなたは、礼儀正しいビジネスパーソンです。ビジネスに適した言葉を使い、くだけた表現を避け、敬意のある口調を保ってください。"

   reasoning:
      instructions:->
         | ご用件をお伺いします。

トピックで独自のsystem.instructionsを定義している場合、そのトピックではグローバルな指示がトピック独自の指示に置き換えられます。この方法は、会話領域ごとにAIエージェントの性格や振る舞いを変えたい場合に便利です。

4. start_agent – 開始点

start_agentブロックには、独特の機能があります。すべてのユーザーメッセージは、1番目であっても50番目であっても、ここから実行が開始されます。AIエージェントの入り口となるところです。

通常、start_agentは、ユーザーを迎え入れ、その目的にもとづいて適切なトピックへ振り分けるために使用します。

start_agent topic_selector:
   description: "ユーザーを歓迎し、適切なトピックへ案内する"

   reasoning:
      instructions:|
         ユーザーのメッセージと会話履歴に最も適したツールを選択してください。不明な場合は、最も妥当と思われるものを選択してください。

      actions:
         go_to_verification: @utils.transition to @topic.verification
            description: "注文情報にアクセスする前に顧客の本人確認を行う"
            available when @variables.is_verified == False
         go_to_order_status: @utils.transition to @topic.order_status
            description: "注文の処理状況、追跡、配達情報を確認する"
            available when @variables.is_verified == True

available when条件に注目してください。go_to_order_statusへの遷移は、顧客の本人確認がすでに完了している場合にのみ、選択肢として表示されます。これが、状態に応じてフローを制御する仕組みです。

注 – アクションと遷移については、後ほど別のセクションで説明します。

5. トピック – 会話領域

トピックは、AIエージェント内の個別の機能領域を表します。たとえるなら、「本人確認」、「注文状況の確認」、「返品手続き」など、1つの会話の中のチャプターのようなものです。各トピックには、固有のアクション、指示、ツールがあります。この例では、AIエージェントはverificationとorder_statusという2つのトピックを使用します。

topic verification:
   description: "顧客の本人確認を行う"
   # ... ここにアクションと推論を記述する

topic order_status:
   description: "注文に関する問い合わせに対応する"
   # ... ここにアクションと推論を記述する

descriptionは重要です。特にstart_agentブロックでトピックを分類する際に、トピックが適切であるかどうかをLLMが理解する助けとなります。

重要な原則 – すべてのユーザーメッセージはstart_agentから始まります。そこから、AIエージェントはコンテキストにもとづいて適切なトピックに遷移します。

6. アクション – トピックが実行できることを定義

アクションは、トピックが呼び出せる機能を定義します。たとえば、FlowやApexクラス、APIなどです。アクションは、トピックごとにactions:ブロックで定義されます。

アクションは、いわば定義レイヤーです。存在する外部インターフェースを宣言し、その入力と出力を定義します。

topic order_status:
   description: "注文に関する問い合わせに対応する"

   actions:
      get_order:
         description: "IDで注文の詳細を取得する"
         inputs:
            order_id: string
               description: "照会する注文ID"
               is_required: True
         outputs:
            status: string
            total: number
            delivery_date: string
         target: "flow://Get_Order_Details"

      get_tracking:
         description: "配送の追跡情報を取得する"
         inputs:
            order_id: string
         outputs:
            carrier: string
            tracking_number: string
         target: "flow://Get_Tracking_Info"

上記の例では、Agentforceに「このトピックでは2つのアクションを利用できる。そのアクションはどう呼ばれるものか、どのような入力が必要か、どのような出力を返すか」を伝えています。ターゲットの種類とサポートされるデータ型については、公式ドキュメントのこちら（英語）を参照してください。

アクションは、定義しただけでは実行されません。関数を宣言するのと同じで、呼び出されるまでは何も起きません。では、どのようにアクションを呼び出すのでしょうか。それを行うのが推論レイヤーです。

7. 推論 – オーケストレーションレイヤー

推論ブロックでは、トピックの振る舞いを組み立てます。推論ブロックは、アクションの定義と実際の実行を橋渡しする役割を担います。すべてのトピックには、reasoning:ブロックを含める必要があります。reasoningの中には、次の2つの重要なセクションがあります。

1. instructions – 各ターンで実行されるロジックとプロンプト
2. actions – LLMに公開するツール（「公開レイヤー」）

topic order_status:
   description: "注文に関する問い合わせに対応する"

   actions:
      # 定義レイヤー – 何を呼び出せるか
      get_order:
         description: "注文の詳細を取得する"
         inputs:
            order_id: string
         outputs:
            status: string
         target: "flow://Get_Order_Details"

   reasoning:
      # オーケストレーションレイヤー – いつどのように処理が行われるか

      instructions:->
         # ロジックとプロンプトをここに記述する
         ...

      actions:
         # 公開レイヤー – LLMが選択できるツール
         ...

推論の指示 – ロジックとプロンプト

reasoning内のinstructions:ブロックでは、オーケストレーションが行われます。ここでは、次の要素を組み合わせて記述します。

• 手続き型ロジック（-> または :を使用）– 上から下に決まった順序で決定論的に実行されます。
• プロンプトテキスト（|を使用）– 組み立てられて、LLMに送信されます。

reasoning:
   instructions:->
      | 注文に関する顧客の問い合わせに対応してください。

      if @variables.order_id != "":
         | 顧客の注文IDは{!@variables.order_id}です。
      else:
         | 顧客に注文IDを質問してください。

矢印（->）は、手続き型コードであることを示します。
注 – 矢印の使用は任意であり、「:」を使うこともできます。パイプ（|）は、プロンプトテキストであることを示します。

次のように実行されます。

1. Agentforceが、ロジックを上から下へ処理します。
2. 条件を満たしているかどうかに応じて、プロンプトテキストが追加されていきます。
3. 最終的に組み立てられたプロンプトがLLMに渡されます。

シナリオA – order_id = ""

作成されたプロンプト → 「注文に関する顧客の問い合わせに対応してください。顧客に注文IDを質問してください。」

シナリオB – order_id = "12345"

作成されたプロンプト → 「注文に関する顧客の問い合わせに対応してください。顧客の注文IDは12345です。」

状態にもとづいて、プロンプトが動的に作成される点に注目してください。

注 – 条件を満たしたパイプテキストはすべて、個別のタスクとして並べられるのではなく、1つのプロンプトに追加されていきます。LLMは1つにまとめられた指示ブロックを受け取ります。ここで重要なのは、reasoningループがターンごとにこれらの指示を再実行することです。ターンが進んで変数が変化すると、一致する条件が変わり、それに応じてプロンプトも書き換えられます。これにより、LLMは過去の会話の中で積み重なった指示ではなく、常にその時点のコンテキストに適した新しい指示を受け取ります。

指示からのアクションの呼び出し

アクションを呼び出す方法は2つあります。

方法1 – runによる決定論的な実行

LLMの判断なしで、特定の条件下で必ずアクションを実行する必要がある場合は、reasoning.instructions内でrunを使用します。

topic order_status:
   actions:
      get_order:
         description: "注文の詳細を取得する"
         inputs:
            order_id: string
         outputs:
            status: string
            delivery_date: string
         target: "flow://Get_Order_Details"

   reasoning:
      instructions:->
         | 注文に関する顧客の問い合わせに対応してください。

         # 条件を満たした場合は常に実行する
         if @variables.order_id != "" and @variables.order_status == "":
            run @actions.get_order
               with order_id=@variables.order_id
               set @variables.order_status = @outputs.status
               set @variables.delivery_date = @outputs.delivery_date

         if @variables.order_status == "shipped":
            | ご注文の商品は発送済みです。到着までしばらくお待ちください。

runコマンド

• 処理がその箇所に到達すると、直ちに実行されます。
• withを使用して入力を渡します。
• 出力を変数に格納するにはsetを使います。

用途 – データの自動取得、必須の検証、ユーザー入力が何であれ、必ず実行するあらゆるロジック

方法2 – reasoning.actions内のLLMツール

会話のコンテキストにもとづいて、アクションを呼び出すかどうかをLLMに判断させる場合は、reasoning.actionsを使います。

topic order_status:
   actions:
      get_order:
         description: "注文の詳細を取得する"
         inputs:
            order_id: string
         outputs:
            status: string
         target: "flow://Get_Order_Details"

   reasoning:
      instructions:->
         | 注文に関する顧客の問い合わせに対応してください。

      actions:
         # このアクションで、LLMが使用可能なツールを作成する
         lookup_order: @actions.get_order
            description: "顧客から注文について問い合わせがあったら、その注文を照会する"
            with order_id=...
            set @variables.order_status = @outputs.status

このスクリプトでは、lookup_orderという次のようなツールが作成されます。

• 定義されたアクション（@actions.get_order）を参照する
• LLMがいつアクションを呼び出すか判断するためのdescriptionがある
• LLMが会話から値を抽出できるように、...を使用してスロットフィリングを行う
• setを使用して出力を取得する

用途 – ユーザー起点のアクション、任意の機能、または会話のコンテキストにもとづいて判断すべきシナリオ

注 – わかりやすくするために、上記の例では1つのアクションだけを示していますが、1つのトピックに複数のアクションを含めることができます。また、{!@actions}を使って、これらのアクションをプロンプトの中で参照することもできます。以下に例を示します。

topic order_status:
   actions:
      get_tracking:
         description: "配送の追跡情報を取得する"
         inputs:
            order_id: string
         outputs:
            tracking_number: string
         target: "flow://Get_Tracking_Info"
   reasoning:
      instructions:->
         | 注文に関する顧客の問い合わせに対応してください。
         | 顧客が追跡情報を希望する場合は、{!@actions.get_tracking}を使用してください。

         actions:
            # このアクションで、LLMが使用可能なツールを作成する
            get_tracking: @actions.get_order
               description: "注文を追跡する"
               with order_id=...
               set @variables.tracking_number = @outputs.status # 追跡番号が変数であることが前提

変数の設定

実行時に変数を設定する一般的な方法は2つあります。

1. アクションの出力を取得する – setを使用して、実行されたアクションの結果を格納します。

   run @actions.verify_customer
      with email=@variables.customer_email
      set @variables.customer_name = @outputs.name
      set @variables.is_verified = @outputs.is_valid
   

2. LLMによるスロットフィリング – @utils.setVariablesを使用して、LLMに会話から直接、値を抽出させます。

   reasoning:
      actions:
         collect_email: @utils.setVariables
            description: "顧客のメールアドレスを取得する"
            with customer_email=...   # LLMが会話から抽出
   

用途 – 外部システム、Flow、Apexのデータの場合は、アクションの出力を使用します。会話からユーザー入力を収集するには、setVariablesを使います。

制御の流れ – 実行の仕組み

以下の図は、トピック、アクション、推論が実行時に連携して動作する仕組みを示しています。

覚えておきたいポイント

1. Agent Scriptでは、ハイブリッド推論を利用できます。ハイブリッド推論は、LLMの柔軟性とプログラムによる制御を組み合わせたものです。重要な思考モデルは次の3つです。
   1. トピック – 会話領域（AIエージェントが扱える会話の範囲）
   2. アクション – トピックレベルの定義（何を呼び出せるか）
   3. 推論 – 指示とLLMに公開されるツールを含む、オーケストレーションレイヤー
2. すべてのメッセージはstart_agentから始まります。これは会話の途中であっても同様です。
3. 指示は上から順に実行されます。LLMには、最終的に組み立てられたプロンプトのみが渡されます。
4. 遷移は一方向です。@utils.transitionでトピックを遷移すると、前のトピックに自動的に戻ることはありません。
5. 完了後は入力を待機します。その後、フローはstart_agentに戻ります。

注 – トピックの委任を使って、元のトピックに戻る方法があります。この方法については、トピックの委任（呼び出し元に戻す）セクションで後述します。

推論後 – 後処理用のフック

オプションのafter_reasoningブロックは、LLMが応答を完了した後に実行されます。トピックが終了した後に必ず実行したいクリーンアップや遷移に使用します。

topic verification:
   reasoning:
      instructions:->
         | 顧客の本人確認を行う。

   after_reasoning:
      if @variables.is_verified == True:
         transition to @topic.order_status

LLMが選択するreasoning.actionsとは異なり、after_reasoningは条件が満たされれば必ず実行されます。LLMが応答した後にガードレールや必須フローを強制する場合に最適です。

トピックの遷移

トピック間の移動には、コンテキストに応じて、異なる構文を使用します。

• LLMが選択 – reasoning.actionsの中で@utils.transitionを使用

reasoning:
   actions:
      go_to_returns: @utils.transition to @topic.returns
         description: "返品をサポートする"
         available when @variables.is_verified == True

LLMはこれを利用可能なツールとして認識し、会話のコンテキストにもとづいて、使用するタイミングを判断します。

• 決定論的 – reasoning.instructionsまたはafter_reasoningの中で、そのままtransition toを使用して即時に実行します。

reasoning:
   instructions:->
      if @variables.end_conversation:
         transition to @topic.farewell

after_reasoning:
   if @variables.needs_escalation:
      transition to @topic.escalation

上記の例では、LLMの判断を必要とせず、条件が満たされるとすぐに遷移が実行されます。

重要な構文のルール

• @utils.transition to → reasoning.actionsの中でのみ使用すること
• 単純なtransition to → reasoning.instructions:->またはafter_reasoningの中でのみ使用すること

注 – この2つを取り違えないようにしてください。使う場所を間違えると、エラーの原因になります。

トピックの委任（呼び出し元に戻す）

上記の方法は一方向ですが、直接の@topic.<name>参照を使うと、実行を別のトピックに委任できます。参照先のトピックが完了すると、フローは自動的に元のトピックに戻ります。

reasoning:
   actions:
      consult_specialist: @topic.specialist_topic
         description: "スペシャリストに相談してから、ここに戻る"

この方法は、別のトピックの専門的な対応を必要とし、その後に現在の会話を続けたい場合に便利です。

まとめ

この記事では、Agent Scriptの構文と基本的な構成ブロックを紹介しました。コードのサンプルをもっとご覧になりたい場合は、Agent Script Recipesサンプルアプリ（英語）を参考にしてください。次回の記事では、Agentforce DX（英語）や新しいAgent Builderなどの開発者向けツールを使って、AIエージェントを開発、デバッグ、テスト、デプロイする方法を詳しく見ていきます。

関連情報

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

The post Agent Script徹底解説 – Agent Script言語の基本を学ぼう appeared first on Salesforce Developers Blog.

• AI isn’t replacing the Salesforce Developer role. It’s reshaping it around three higher-value capabilities: system design, quality engineering, and cross-system thinking.
• Adopting AI-assisted development tooling will slow you down before it speeds you up. The investment is in redesigning your workflows, not just adding tools.
• Most Salesforce development is brownfield engineering: working inside complex, inherited orgs where undocumented decisions outnumber documented ones. AI can’t navigate this context alone.
• The Salesforce Developer career path in 2026 and beyond rewards developers who pair deep platform knowledge with broad architectural judgment, not the fastest code writers.
• Whether your organization has adopted AI tools or not, you can start building the skills that matter most today.

Adopting AI-assisted development might initially make you slower.

This isn’t because the tools are bad, or because you’re doing it wrong. Based on patterns we are seeing across Salesforce development teams adopting AI tooling, there is a consistent J-curve: Using AI effectively requires rethinking the task itself: your workflows, your team’s processes, and the way your organization builds software. That kind of change often creates new types of errors before it delivers new types of speed.

Skipping this part of the conversation has consequences. It feeds the fear of slop flooding codebases and fuels anxiety about whether AI improves outcomes or just creates the illusion of developer productivity.

Those feelings are valid, but aren’t the full picture. Here’s what’s actually happening to the Salesforce Developer role: where it’s been, what AI is changing, and where the career path is headed.

How the Salesforce Developer Role is Evolving

For most of the platform’s history, the Salesforce Developer’s value was clear: you made the platform do what it couldn’t do declaratively. When a Flow wasn’t enough, when a formula hit its limits, or when a business requirement went beyond configuration, you wrote Apex. You built Lightning Web Components. You designed integrations and extended the platform with code.

The core skill was implementation. You took a requirement and turned it into a working solution. Along the way, you navigated governor limits, bulkification patterns, the trigger execution order, and the nuances of multi-tenant architecture. Deep Salesforce-specific knowledge was what set the best developers apart. They didn’t just understand the platform’s constraints; they knew how to build effectively within them.

That era isn’t ending, but it is receding. The implementation skill still matters, but it is no longer the primary source of a developer’s value. That source is shifting toward system design, quality engineering, and cross-system thinking.

The shift underway isn’t just about AI writing code. That’s the visible part. What matters is what it exposes. 

Will AI replace Salesforce Developers? No. AI is replacing parts of the work, especially first-draft code generation. But it’s not replacing the Salesforce Developer entirely. In fact, it’s increasing demand for the skills that remain: system design, quality validation, and cross-system thinking. The role is being redefined, not eliminated.

AI has inverted the bottleneck. For decades, the hard part was implementation: you knew what to build, and the challenge was writing the code. Now implementation is fast and cheap. An AI coding assistant – whether Agentforce Vibes, Claude Code, or Cursor paired with the Salesforce Extensions – can generate an Apex class, scaffold a Lightning Web Component, draft a test suite, or stub out an integration in seconds. The quality varies. The speed doesn’t.

What this exposes is that the real bottleneck was always system design. It was in understanding what to build, why to build it that way, and how it fits into the broader system. That bottleneck was invisible when implementation was slow. The time spent writing code also served as thinking time: time to discover edge cases, reconsider approaches, and absorb complexity.

When AI compresses implementation to near-zero, that thinking time is no longer built in by default. Developers who don’t replace it deliberately with design and analysis end up shipping faster but understanding less. That’s where the problems start.

AI isn’t just a code generation tool. It’s the most powerful learning tool developers have ever had. You can ask questions about unfamiliar codebases, explore platform behaviors in real time, and get instant feedback on design decisions. This changes the learning curve, not just the production curve. That distinction matters, and we’ll come back to it.

Why Brownfield Salesforce Orgs Are AI’s Biggest Challenge

There’s another reality that AI demos consistently ignore: most software in the world is not greenfield. The demos show new apps built in minutes from a blank canvas. But most Salesforce Developers walk into existing orgs every morning. These orgs have hundreds of custom objects. They have layered automations built across multiple releases. They have managed packages interacting in ways nobody fully mapped. They have business logic in configuration that hasn’t been documented since the person who built it left three years ago.

This is brownfield engineering, and it’s where the vast majority of Salesforce development happens.

The Salesforce ecosystem supports millions of developers working across orgs that have evolved over years. In these environments, the systems themselves are the specification. That specification lives in code, metadata, tribal knowledge, and the collected judgment of everyone who’s ever touched the org. AI is increasingly good at analyzing the structural layer. What it can’t reach is the why underneath: why a data model was chosen, which trade-offs were made to serve a specific customer segment, what constraints shaped the architecture. That context lives in people, not in code.

A practical framework for brownfield AI-assisted development:

1. Map before you build. Before using AI to generate code in an existing org, understand the current architecture. Look at trigger execution order, automation dependencies, sharing rules, and integration boundaries.
2. Make the implicit explicit. Document the trade-offs behind the current data model, the reasons certain patterns exist, and the governor limit risks that only surface at scale.
3. Treat context as input. The more system context you give AI tools, the better their output. A prompt grounded in your org’s real architecture produces results you can ship. A generic prompt produces results you have to rewrite.

Example: You ask an AI assistant to generate an after-update trigger on an Account that queries child Contacts to sync a status field. The code compiles. The tests pass. But your org already has two triggers on Account – one that recalculates territory assignments and another that fires a platform event to an external ERP. Combined, the three triggers exceed the 100-SOQL-query governor limit during bulk data loads. The AI had no visibility into the existing triggers, the execution order, or the cumulative query count. A developer with system context would have caught this before deployment. That’s the difference system design makes.

Future Salesforce Developer Skills: What Will Matter Most

The sections below dive deeper into each skill, demonstrating how they play out in practice.

System Design: The Core Salesforce Developer Skill of the Future

The most important work a Salesforce Developer will do in the coming years is not writing new code. It’s designing systems, understanding the systems they’ve inherited, deciding how those systems should evolve, and creating the structures and guardrails that AI operates within.

The brownfield framework above gives you the process. The harder question is what it actually takes to execute it – and why AI can’t do it for you. Why do triggers fire in a specific order? What trade-offs shaped the current data model? How do integrations behave under load? What does the security model assume? Where do the real governor limit risks live? Not just documenting what exists, but designing what comes next.

This work requires deep technical skill and creative judgment. AI is already strong at structural analysis. It can generate documentation drafts from code analysis, find patterns across metadata, and map dependency chains – often faster than any human could. But the design decisions depend on the why: why a pattern exists, why a trade-off was accepted, why a constraint matters to the business. That reasoning lives in relationships and institutional memory, not in a codebase.

In practical terms, a developer who can look at a complex, undocumented Salesforce org and build a clear architectural picture is the one who enables an entire team (and its AI tools) to work effectively. That capability matters far more than speed at writing Apex. The architectural thinker unlocks everyone else’s productivity. The fast coder is doing work that AI is already learning to do.

This applies whether you’re preparing an org for Agentforce, building new automations with Flow, or integrating AI coding assistants into your workflow. In each case, the quality of your output depends on system design thinking. A vague prompt produces vague output. A clear understanding of your org’s real architecture produces something you can ship.

Quality Engineering in AI-Assisted Salesforce Development

When AI generates code fast, the risk isn’t that the code is wrong. It’s that developers accept mediocre code because it arrived fast and looked plausible. This is where slop comes from: not from the model, but from the human who stopped reviewing.

Validation, not generation, is becoming the center of the developer’s daily work. That means treating every AI-generated class, Flow, and test suite as a first draft that needs editorial judgment. Read critically. Ask whether the approach fits the existing architecture, not just whether the syntax compiles. Refactor before committing.

AI-generated tests deserve special attention. These tests can confirm that code behaves as written, but not that it behaves as intended. An AI that writes both the code and the tests can easily generate tests that pass without testing anything meaningful. Write tests with the same rigor you’d apply to production code.

In brownfield Salesforce environments, the stakes are high. A poorly validated trigger can cascade into bulk data failures. An Agentforce agent without proper guardrails produces confusing outputs for end users. A Flow that wasn’t tested against concurrent record updates creates data integrity issues that take weeks to fix. The developer who sets non-negotiable validation checkpoints (tests passing, static analysis clean, manual walkthrough complete) is the one protecting the system’s long-term health. Pushing back when speed threatens integrity is part of the job. That role is more critical now than before AI, not less.

This is also a skill upgrade. When the first draft arrives in seconds instead of hours, you reclaim time for the work where human judgment matters most: architecture decisions, trade-off analysis, and knowing when to trust AI output versus when to override it.

This doesn’t mean every developer becomes an architect. It means every developer builds a stronger sense of system context. In many cases, developers become the person overseeing AI agents that do implementation work – and owning what ships. Frameworks, coding patterns, human code reviews, and thoughtful test design: these remain in human hands. For many companies, speed is the only variable leadership teams measure. Without developers who hold the quality line, AI becomes a multiplier of technical debt and vulnerabilities.

Why Cross-System Thinking Is the New Salesforce Developer Advantage

Deep specialization remains essential. Someone has to understand the platform internals that AI doesn’t yet grasp. But the premium is on developers who can pair that depth with breadth and see how their specialty connects to the wider system.

Salesforce itself is one piece of a wider architecture. Think about how Apex interacts with Flows. How Flows interact with platform events. How platform events interact with external middleware. And how all of it serves the end user. The developer who understands these connections is far more valuable than one who goes deep on a single layer without seeing the bigger picture.

This means holding the whole product in your head, not just the feature you’re building. It means understanding the data model, the integration landscape, the security architecture, and the business logic that ties it all together. It also means translating technical consequences into business language and surfacing risks early, even when doing so slows momentum.

On the Salesforce platform, this shift is already visible. Agentforce requires developers who understand not just code but agent design, guardrail configuration, data architecture, and user experience. The line between clicks and code keeps blurring with every release. Integration patterns grow more complex as Salesforce connects to AI services, data platforms, and external apps. The developer who can see across all of these layers and make smart decisions about where code is needed is the one teams will depend on.

Salesforce Developer Career Advice for the Agentic AI Era

If you’re reading this and feeling the weight of transition, you’re not alone. You’re not wrong to feel it. This is a shift in what the profession asks of you. But it’s an expansion, not a contraction.

What if I’m already using AI tools in my workflow?

Don’t let speed become your primary metric. The real investment is in redesigning your workflows: building the system designs, guardrails, and frameworks that AI operates within. This takes time. There will be errors. Once the new patterns take hold, you’ll be working at a level that wasn’t possible before. Treat AI output as a draft. Validate with rigor. Don’t let the pressure to ship override the judgment that makes your work effective.

What if my organization hasn’t adopted AI tooling yet?

You’re not as far behind as the FOMO suggests. The distinction between organizational adoption and individual learning matters. Your organization’s timeline for AI tools is out of your hands; your own learning timeline isn’t.

You can use AI assistants today to explore codebases, practice system design thinking, and generate documentation drafts. You can build the habits described in this post regardless of what your team has officially adopted. The system design work itself (understanding your systems in depth, making implicit knowledge explicit, and thinking about architecture as a whole) will make you more effective right now. It also positions you to move fast when organizational adoption happens.

What skills will set me apart in the Salesforce Developer career path?

Can you look at a complex, undocumented org and produce a clear architectural picture? Can you spot when an AI suggestion would work in isolation but break in context? Can you see across system boundaries and make decisions that account for the full architecture?

These are the capabilities that grow in value as AI handles more of the implementation work.

What if I’m learning or early in my Salesforce Developer career?

This is one of the best times to start. AI is now the most powerful tool available for building the skills that matter most.

A junior Salesforce Developer today can use AI to explore unfamiliar codebases and understand platform internals in real-time, simulate system design decisions, and get instant feedback on code. None of that existed two years ago. The path to becoming systems-minded is faster now, not slower.

You still need to learn how things work under the surface. You can listen to a language and understand it, but you don’t learn the rules until you start producing it. AI gives you a way to compress that learning curve.

Go broad before you go deep. Build the habit of documenting what you learn. Lean into the platform fundamentals on Trailhead. Certifications like Platform Developer I validate your foundational knowledge, but the skills described here (system thinking, architectural judgment, and quality discipline) go beyond any exam.

How the Salesforce Community Navigates the AI Transition

The shift to AI-assisted engineering is creating new knowledge faster than the ecosystem has seen before. That knowledge is spread unevenly. Some developers experiment with AI daily. Others are at organizations that haven’t made the leap yet. The gap between them is about access to shared, honest experience, not talent.

The most useful thing anyone in this community can do right now is share what they’re learning. Share openly, honestly, and without polish. Don’t just share the successes. Share the slowdowns, the failures, and the moments where AI made things harder before it made them easier. The admission that “this made us slower for three months before it made us faster” is one of the most helpful things a team can share. It normalizes the transition cost and helps others plan for it.

Whether it’s through the Trailblazer Community, GitHub discussions, Community Conferences, Salesforce user groups, or internal channels: Your experience speeds up someone else’s adoption. The collected, honest knowledge of the Salesforce Developer Community is our greatest asset in navigating this transition. Use it. Contribute to it. Community is more important than ever.

What This All Means for Your Salesforce Career

The future needs more Salesforce Developers, not fewer. It needs people who can design systems, not just implement them. People who can hold whole products in their heads. People who can guide AI with judgment, push back when speed threatens integrity, and share what they learn so the entire ecosystem gets stronger.

The tools are new. The opportunity is significant. And the capabilities that matter most are the ones that have always defined the best engineers: judgment, context, and the willingness to understand the whole system.

Related Reading

• Get Started with Salesforce Development on Trailhead
• Agentforce Developer Documentation
• Apex Developer Guide
• Lightning Web Components Developer Guide

About the Author

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

The post The Future of the Salesforce Developer in the Agentic AI Era appeared first on Salesforce Developers Blog.

However, improving performance at scale is only part of the story. As Lightning Experience becomes faster overall, there is a growing opportunity to optimize performance within individual orgs based on their unique usage patterns and configurations. This is why our focus is expanding: alongside continuous platform-level improvements, we are providing developers with better tools to understand, diagnose, and improve Lightning Experience performance within their own environments. 

At Dreamforce 2025, we took a major step forward by launching Lightning Experience Insights in Scale Center as a Beta feature. With the Spring ’26 release, we are excited to announce that these insights are now Generally Available (GA).

Introducing Salesforce Scale Center

Salesforce Scale Center is your central hub for understanding how your org behaves at scale. It provides self-service, near real-time access to performance metrics to improve the scalability of your Salesforce implementation. Scale Center brings together performance, reliability, and usage insights to help developers proactively identify risks, prioritize optimizations, and operate their orgs with confidence as they grow.

Scale Center has powerful root cause analysis, enabling you to resolve issues earlier in the development cycle. This analysis works by retrieving customized insights and diagnosing root causes or “hot spots.” In addition to identifying hot spots, Scale Center provides recommendations for addressing them. 

Scale Center offers a unified, curated view of how your org performs under real-world conditions across users, pages, and customizations. This visibility allows developers to move from reactive troubleshooting to intentional, proactive performance management.

As of Dreamforce 2025, Scale Center is available for all major editions. It continues to expand with new insights tailored to the most critical scaling challenges on the Salesforce Platform, including our newest addition: Lightning Experience Insights. These insights are specifically designed to help you understand and improve your individual Lightning Experience performance.

Lightning Experience Insights: Turning Data into Action

Lightning Experience Insights in Scale Center are built with a singular goal: to help developers understand and optimize their org’s performance. These insights move beyond aggregate platform metrics to focus on the actual user experience, providing the data necessary to take specific, impactful action.

With the Spring ’26 release, Lightning Experience Insights are Generally Available. Moving beyond its Beta phase, this version features expanded coverage, clearer guidance, and deeper integrations across Scale Center.

Let’s explore the key components of Lightning Experience Insights.

Performance Overview

The Performance Overview in Lightning Experience Insights provides a clear, high-level view of how Lightning pages perform across your org. It enables developers to quickly assess overall Lightning Experience performance before diving into granular details.

At the center of this view is Lightning Experience Page Time (EPT), the primary metric Salesforce uses to measure Lightning page load performance. EPT represents the total time required for a page to load into a state where a user can fully interact with it. 

A lower EPT indicates faster page loads and provides a better user experience. We use the industry-standard 75th percentile (P75) to calculate the EPT, which represents the time it takes for 75% of pages to load for your users. By focusing on the P75, we identify issues affecting the majority of your user base, providing a more accurate reflection of how real-world performance impacts your customers.

Ultimately, the Performance Overview helps developers quickly answer a fundamental question: Is Lightning Experience performing well for our users, or is further investigation required? It highlights overall health and surfaces specific areas where your attention is needed most.

To reflect the actual user journey, EPT is categorized into First Page Load EPT and Subsequent Page Load EPT. First Page Load EPT captures the initial experience when a Lightning session starts, while Subsequent Page Load EPT measures performance as users navigate between pages. 

The initial page load typically takes longer than subsequent page load because it includes both the complete page render and the initialization of the framework, also known as the Lightning Experience Bootstrap. Once the framework is initialized, subsequent page load times are generally faster because they do not need to reload the core framework during navigation.

Viewing these metrics together—and analyzing their distribution—enables developers to identify which optimizations have the greatest impact. Whether the goal is to improve the user’s initial entry into Lightning or to make everyday navigation faster and more responsive, these insights help you prioritize optimizations where they matter most.

Key Insights and Best Practices

The Key Insights section is your starting point for understanding Lightning Experience performance in your org. Rather than surfacing raw metrics, it highlights where Lightning pages may be deviating from recommended performance best practices, helping developers focus on the areas with the greatest impact.

Key Insights provide visibility into whether your Lightning Experience is structured for speed and responsiveness. For example, pages with an unusually high number of components can lead to slower load times. Key Insights flag these early so developers can optimize page composition to improve performance.

Key Insights also evaluate whether your org is utilizing available performance optimizations designed to support Lightning Experience performance. Key Insights highlight settings and capabilities, such as Lightning CDN, that help jump-start the Lightning framework and are developed to improve First Page Load performance. 

Seeing the optimizations available, together with areas that can benefit from the optimizations, makes it easier for developers to understand where and how to implement performance best practices across their orgs.

These examples represent only a subset of the insights available. Key Insights covers a range of best practices across configuration and page design, giving developers a comprehensive view of how to strengthen Lightning Experience performance.

Performance Trends

The Performance Trends section helps developers understand how Lightning Experience performance changes over time. It visualizes your org’s Experience Page Time (EPT) for a selected period, making it easier to spot patterns, shifts, and anomalies in page load behavior.

Additional charts in this section break EPT down across common dimensions such as geography and browser, providing context into where performance may vary for different users. When not explicitly separated, EPT reflects a blended view of first and subsequent page loads and is referred to simply as “EPT.”

This specific definition excludes Lightning Experience bootstrap and combines only non-bootstrap EPT from both first and subsequent page navigations. Because bootstrap performance isn’t directly actionable, this metric represents the portion of page load time that developers can meaningfully influence. It also provides a simplified baseline for further breakdowns across geographies, browsers, and slow-performing pages.

Viewing trends this way helps developers quickly determine whether performance changes are isolated—affecting a specific region or browser—or reflect broader shifts across the org.

Actionable Insights for Slow Pages

Finally, developers can connect performance signals to concrete opportunities for specific page optimization. The High-Impact, Slow-Performing Pages view identifies pages that are both slow to load and frequently accessed, highlighting areas where performance issues most significantly affect users. These pages are the highest priority because their latency impacts a significant portion of your org’s daily activity.

For each high-impact slow page, Lightning Experience Insights surfaces the underlying custom components and actions contributing to longer load times. Developers can use this information to pinpoint the exact elements causing delays. With targeted visibility, developers can prioritize the optimizations that have the biggest effect on the real-world user experience.

By combining usage and performance data, this view ensures developers focus on the slow pages that matter most. It enables faster, more precise action instead of guesswork or broad refactoring, turning insights into measurable improvements for your org’s Lightning Experience.

Looking Ahead: Faster Lightning, Smarter Insights

Salesforce remains deeply committed to advancing Lightning Experience performance. Simultaneously,  we are investing in tools that give developers greater visibility and control over performance within their own orgs.

Our goal is to empower developers to understand and optimize performance confidently as Lightning continues to evolve. With that in mind, Lightning Experience Insights in Scale Center will continue to expand and become smarter, deeper, and more actionable.

Together, these platform innovations and customer-facing insights ensure you have the resources needed to deliver fast, responsive Lightning Experiences your users expect.

Resources

• Our Details Plan to Improve Lightning Experience Performance
• Lightning Experience Performance: First Anniversary, Results, and Outlook
• Announcing 25% Faster Lightning Experience
• How Salesforce Secures Lightning Performance Gains by Preventing Regressions
• Scale Center in Salesforce Help
• Lightning Experience Insights Generally Available Release Note
• Lightning Experience Insights in Salesforce Help
• Lightning Experience Performance Optimization in Trailhead

About the authors

Gery Gutnik is a Senior Director of Product, focusing on the performance and scale of the Salesforce web platform. His work spans Lighting Experience performance, content delivery networks (CDN), and performance observability tools. He can be reached at LinkedIn. 

Ravi Raina is a Director of Product, working on the Scalability Products portfolio. He can be reached at LinkedIn and X (Twitter).

The post Harness Lightning Experience Insights to Improve Performance appeared first on Salesforce Developers Blog.