Salesforce Platform でのフォームの作成を検討していますか?ローコードからプロコードまで、連続する複数のオプションがあります。ローコードを表すのは、Lightning アプリケーションビルダーの動的フォームと Flow Builder の画面フローです。連続性の真ん中に位置するのは、LWC を使用して画面フローを拡張し、OmniStudio を使用して顧客向けフォームを作成する機能です。また、プロコードを表すものとして、LWC フレームワークとその成長を続けるベースコンポーネントのライブラリがあります。

オプションは優れていますが、どのオプション (またはどの組み合わせ) が適切なオプションかを判断する方法は?そこでこのガイドの出番です。

• **ポイント#1 ページの作成/編集/表示レイアウトを作成する場合は、動的フォームを使用します。**このガイドの比較表にページレイアウトが含まれていないことに気付くかもしれません。今後、レコード詳細ページを設定するために推奨される方法は、Lightning アプリケーションビルダーで動的フォームを使用することです。ページレイアウトをさらに強化する予定がない理由についての詳細は、「ページレイアウト」のセクションを参照してください。
• **ポイント#2:1 つのオブジェクトのみの作成フォームまたは編集フォームを作成する必要がある場合は、まず Lightning ページと動的フォームを作成します。**これは、Salesforce Platform でフォームを作成する最も簡単な方法です。また、項目の表示を制御する機能など、いくつかの追加機能も提供されます。要件がより高度な場合は、読み進めてください。画面フロー、OmniStudio、または Lightning Web Components(LWC)が適しています。
• **ポイント#3:複数ページのフォームまたはウィザードを作成し、厳格な UX 要件やブランド要件がない場合は、画面フローから開始します。**画面フローには、複数のフォームをまとめて調整するための線形ナビゲーションフレームワークが用意されています。LWC を使用して、フォーム間を移動する独自のフレームワークを構築できますが、フォームの状態を気にすることなくフォーム自体に集中できるように、難しい作業はフローに任せることをお勧めします。
• **ポイント#4:フォームの背後に追加のロジックまたはアクションが必要な場合は、画面フロー、OmniStudio、または LWC を使用します。**これら 3 つのツールはすべて、ソリューションで 1 つのレコードの作成や編集以上のことを行うための手段を提供します。この「さらに」は、分岐や反復などの高度なロジックの場合もあれば、外部システムとの統合、メールの送信、ユーザーのモバイルアプリケーションへの通知の転送などのアクションの場合もあります。
• **ポイント#5:高度な UX 要件がありますか?表示以外の機能を動的に処理する必要がある場合は、LWC または OmniScript を使用します。**シンプルなテーマ設定と列ベースのレイアウトで要件を満たせる場合は、ローコードビルダーで直接フォームを作成できます。フォームのスタイルをより詳細に制御するには、LWC の優れた柔軟性が必要です。Industries のお客様で、ピクセル単位の完璧なブランド設定が必要な場合や複雑な階層データがある場合、OmniStudio を使用すると、複雑なビジネスロジックとデータ変換を処理できるコンシューマーグレードのフォームを作成できます。
• **ポイント#6:テストの自動化が必要な場合は、Lightning Web コンポーネントから開始します。**どの LWC に組み込むかに関係なく、LWC の単体テストを作成できます。これにより、複数のレコードを使用した一括テストやネガティブテストなど、より堅牢なテスト戦略を作成できます。フォームが機能要件と非機能要件にどの程度適合しているかを確認するテストの作成についての詳細は、「Salesforce Well-Architected - Testing Strategy (Salesforce の適切な設計 - テスト戦略)」を参照してください。

選択肢は、どちらかまたは両方である必要はありません。複数のオプションを組み合わせることができます。たとえば、フローの組み込みナビゲーションシステムと、LWC が提供する完全なスタイル設定の柔軟性の両方が必要な場合は、これらを併用します。

次の表に、Salesforce でフォームを作成するために使用できるツールとその必須スキルおよびライセンスに関する考慮事項を示します。後で、各ツールでサポートされている特定の機能と、クリックベースのツールとコードベースのツールのどちらを選択するか (および組み合わせるタイミング) について詳しく説明します。

次の表に、商品を選択するときに考慮すべき決定ポイントと、各決定ポイントについて自問すべき質問の概要を示します。このガイドの残りの部分では、これらの各トピックについて詳しく説明します。

比較表で使用する用語とその定義を次に示します。

• **使用可能:**基本的な考慮事項で適切に機能します。
• **理想的ではない:**機能しますが、最適なツールではありません。
• **ロードマップ:**今後 12 か月 (2025 年 6 月) 以内のサポート予定。
• 将来:今後 12 か月を超えるサポートの見積。
• **使用不可:**今後 12 か月以内にこの機能をサポートする予定はありません。

お約束のとおり、動的フォーム、画面フロー、OmniStudio、組み込み LWC を使用する画面フロー、および LWC フレームワーク自体のさまざまな比較ポイントと機能の違いについて詳しく見ていきましょう。

フォームが 1 つの Salesforce オブジェクトに対して操作される場合、比較しているツールはどれも機能します。クロスオブジェクトフォームやオブジェクトに依存しないフォームでは、状況は少し複雑になります。オブジェクトに依存しないとは、どの Salesforce オブジェクトにも対応付けられない入力を意味します。フォームは、Stripe や DocuSign などの外部サービスに送信するデータ構造を表す場合があります。または、フォームで複数の入力を使用して値を計算して、その値をデータベースにコミットしている場合があります。

• フォームの操作対象オブジェクトは?
• 1 つのオブジェクトのみか、複数のオブジェクトか?
• 特定のオブジェクト (取引先、取引先責任者、商談、リード、ケースなど) を使用しているか、フォームを他のオブジェクトでも使用する必要がありますか?

クロスオブジェクトフォームとオブジェクトに依存しないフォームの両方で、Flow と OmniStudio はどちらも有効なオプションです。フロー画面で使用できるコンポーネントは本質的にすべてに対応しているため、バックグラウンドでそのデータをどのように処理するかを選択できます。たとえば、1 つのフォームに入力されたデータを使用してバックグラウンドで複数のレコードを作成したり、データを使用して Chatter 投稿の生成、Slack メッセージの送信、メールの送信、外部サービスへの接続などの他のアクションを実行したりできます。

単純なケースでは、Lightning-record-form などの既存の LWC コンポーネントを使用することで、堅牢なソリューションを提供するために必要なコードを削減できます。ただし、複数のオブジェクトが関連するシナリオでは、フローですべてのオブジェクトを包括的に制御できるため、開発者が複雑なリレーションや連動関係を移動する必要がなくなります。

OmniStudio は、さらに一歩先を行き、ユーザーに表示されるフォームを基盤となるデータモデルから分離し、完全にオブジェクトに依存しません。代わりに、OmniStudio は、データ マッパーやインテグレーション手順などのツールを使用して、Salesforce オブジェクト (または外部データ) にマッピングされた基礎となる JSON を操作します。データマッパーと Integration Procedure は、OmniStudio フォームを Salesforce の内部および外部のデータに接続するための 2 つの主要なコンポーネントです。ドラッグアンドドロップ要素を使用して、外部システムの複雑な階層データを操作してから、データの格納場所に応じてニーズに合わせてデータを変換できます。また、数式を使用して、Apex のように配列やデータのリストに対して計算やロジックを実行することもできます。

OmniStudio Integrations

1 つの画面フォームからすべてのユーザー入力を取得できる場合は、動的フォームから開始します。ただし、レコードページの動的フォームではパス機能を使用してビジネスプロセスのさまざまなフェーズを緩やかに表すことができますが、ほとんどの使用事例には適していない可能性があります。

• 1 つの画面が必要ですか? それとも、ユーザーが ToDo を完了するために複数の画面間を移動する必要がありますか?
• フォームへの入力プロセスの進行状況を視覚的にユーザーに表示しますか?
• ユーザーは各画面の情報を特定の順序で入力する必要がありますか? それとも、必要に応じて画面を行き来できるようにする必要がありますか?

動的フォームで提供される機能よりも多くの機能が必要な場合は、フロー、OmniStudio、LWC のいずれかを選択するかどうかも、他のいくつかの質問に応じて異なります。

• チームにはどのようなスキルがありますか?管理者の作業負荷が高い組織では、フローから開始することをお勧めします。Industries ソリューションがある場合、チームはすでに OmniStudio に精通しており、プロジェクトの UX 要件が厳しいため、OmniStudio から開始します。
• フォームの下部にナビゲーションバーを表示しても問題ありませんか?画面フローと OmniScript ナビゲーション環境が望ましくない UX の場合、LWC に傾けます。
• フォームの背後で何を実行する必要があるか?システム管理者が設定できる動作が必要な場合は、フローを作成するか、項目の表示ラベルの変更などの基本的な変更については OmniScript を作成します。それ以外の場合、複雑な複数オブジェクトリレーションでは OmniScript または LWC を作成します。
• フローまたは OmniStudio を選択した場合は、適切な UX を実現するために LWC の構築が必要な場合があります。フォームのスタイルを正しく設定するために LWC をすでに作成している場合は、そのコンポーネントをフローに埋め込むことが過剰ではないかどうかを検討してください。

一方、ユーザーが複数の画面間を移動するウィザードのようなソリューションの場合は、フローまたは OmniStudio を検討します。フローと OmniStudio には組み込みのナビゲーションモデルが付属しているため、複数の LWC を作成して管理する必要はありません。ナビゲーションは直線的で、前方に移動するアクション、後方に移動するアクション、後で使用するためにフォームを保存するメカニズムがあります。目的に応じて、非線形ナビゲーションを使用するフォームを作成することもできます。画面フローを使用した優れた例については、Salesforce Labs の Digital Store Audit パッケージを参照してください。

OmniStudio では、フォームの「ステップ」が表示される標準ナビゲーションから進行状況インジケーターが表示されるため、ナビゲーション上の重要な利点があります。このステップビューには、ユーザーが特定の複数ステップフォームのどこにいるかが自動的に表示されます。フローとは異なり、ユーザーはフォームのさまざまなステップをクリックして画面間を「ジャンプ」できます。

単一画面フォームを作成するか複数画面フォームを作成するかに関係なく、ユーザーが操作しやすいようにフォームが合理化されていることを確認してください。

フォームを標準の Lightning レコードページに埋め込む場合、動的フォームは現在デスクトップでのみ使用できるという警告付きで、比較対象のどのツールでも機能します。ただし、ユーザーが他の場所からフォームにアクセスできる環境を提供する場合、代替オプションを考慮する必要がある場合があります。

• ユーザーはデスクトップ、モバイル、またはその両方からフォームにアクセスする必要がありますか?
• ユーザーがユーティリティバーを使用してアプリケーションのどこからでもフォームにアクセスできる必要がありますか?
• クイックアクションを使用して、ユーザーが現在表示しているページから移動せずにフォームに入力できるようにしますか?
• フォームを外部 Web サイトで使用可能にする必要がありますか?

動的フォームにはレコードコンテキストが必要なため、Lightning レコードページでのみサポートされます。ただし、動的フォームは Experience Cloud ページではサポートされません。この制限は、Experience Cloud で動的フォームが依存する基礎となるフレームワークが使用されないためです。Lightning ページ。Experience Cloud の動的フォームの要求に基づいてこれを評価しています。

レコードコンテキストを必要とするフローやグローバルに機能するフローを作成できます。そのため、さまざまな場所にフローを埋め込むことができます。レコードコンテキストフローの場合、Lightning レコードページ、Experience Cloud レコードページ、オブジェクト固有のアクション、またはアクション & おすすめリリースを使用できます。グローバルフローの場合、ユーティリティバー、他の Lightning ページまたはエクスペリエンスビルダーページ、Snap、外部アプリケーションなどがあります。現在、フローはグローバルアクションとしてサポートされていませんが、回避策として Aura コンポーネントでフローをラップできます。

OmniStudio では、フローを配置できるほぼすべての場所に配置できる構成可能な FlexCard と OmniScript を作成できます。ただし、構成可能ですが、パッケージ化することはできません。

LWC では、Salesforce 全体、コミュニティ、さらにはオープンソースプロジェクトでもメタデータを使用して対象に関連付けることができるコンポーネントが作成されるため、高度な再利用がサポートされます。LWC コンポーネントは、Lightning Out を使用して独自の Web サイト内に埋め込むこともできます。

外部サイトでの Lightning Out

Lightning Web コンポーネントは現在、クイック アクション （オブジェクト固有またはグローバル） としてサポートされていませんが、回避策として、フローの場合と同様に、LWC を Aura コンポーネントでラップできます。LWC コンポーネントは、Lightning フロー コンポーネントを使用してフローを起動することもできます。

OmniStudio は、OmniOut 機能を使用してコンテンツを外部サイトに公開するのに適しています。OmniStudio と OmniOut を使用すると、OmniScript フォームと FlexCard コンポーネントを標準コンポーネントにコンパイルし、サードパーティサイトまたはアプリケーションでプラットフォーム外で実行できます。

このガイドで扱うフォーム技術は、現在 Mobile SDK テンプレートで正式にサポートされていません。Mobile SDK が使用事例に不可欠である場合は、Salesforce Well-Architectedフォーム要素ガイダンスに留意しながら、モバイル アプリケーションでネイティブにフォームを作成するか、Visualforce ページを作成することをお勧めします。

**ロードマップメモ:**Mobile SDK チームは、Visualforce ページ内の LWC のサポートに積極的に取り組んでいます。

動的フォームは、フォームの値を使用してレコードを作成または更新する必要がある場合に最適です。それ以上の機能を使用するには、フロー、OmniStudio、または LWC を使用する必要があります。これらの機能には、判断や反復のレイヤー、フォームからの入力を使用した Slack 投稿やメールの生成などがあります。

• バックグラウンドで実行するアクションまたはロジックは?
• データモデルに階層データが含まれていますか?
• フォームの操作は 1 つのトランザクション内で完了する必要があるか、複数のトランザクションで完了する必要があるか?
• 外部システムと統合する必要がありますか?
• 再利用性とモジュール性の要件は?

フローには、Slack への投稿、メールの送信、Quip 文書の操作を行うための標準アクションが用意されているため、これらの操作のコードを記述する必要はありません。LWC は、ユーザーインターフェース API とやりとりするワイヤーアダプターを使用して、1 つのレコードと関連オブジェクトとの豊富なやりとりを提供します。LWC は、getListInfoByName 用の回線を使用する場合にも複数のレコードを操作できます。

Lightning Web Components Interaction via Wire Adapters

前述のように、OmniStudio では Integration Procedure とデータマッパーを使用して、Salesforce の外部および内部のデータを簡単に取得して変換できます。使用できる多数のコードフリー関数により、さまざまなレベルのリレーションでデータセットをフラット化および拡張できます。

**ロードマップメモ:**フローでは、レコードコレクションの更新/挿入機能と階層データの管理機能がまもなくサポートされる予定です。

フロー、OmniStudio、LWC はすべて Apex と統合されるため、選択したソリューションのギャップを簡単に埋めることができます。たとえば、LWC からのレコードの絞り込みが必要な場合は、常に Apex のワイヤ アダプタを使用して複雑な SOQL クエリを作成できます。クリック ベースのストーリーに悩まされている場合は、サーバー側のニーズに合わせて、Apex コントローラーに代わる実行可能な方法としてフローまたは OmniStudio を検討してください。

ここでの副次的な質問は、アクションをすぐに確定するか、フォームの特定の部分に割り当てるかです。これは、複数ページのフォームを使用している場合に特に関連します。フローを使用すると、複数のフォーム (フロー画面) からの入力を簡単に組み合わせることができ、ウィザード (フロー) の後半でそれらを使用していくつかの操作を実行できます。実際には、ユーザーが画面を行ったり来たりして回答が変わったりした場合に備えて、フローはこの方法で設計することをお勧めします。

Salesforce Platform では、トランザクションと Virtustream の制限が適しています。使用事例が非常に単純な場合、特定の操作が発生するトランザクションを制御することはさほど重要ではない可能性があります。ただし、複数の操作を複数のトランザクションで実行するのではなく、1 つのトランザクションに組み合わせる必要がある使用事例がいくつかあります。いくつかの例:

• ロールバックするかしないか:それが問題だフォームでバックグラウンドで複数のレコードを作成するとします。3 番目のレコードの作成に失敗した場合、最初の 2 つのレコードをロールバックする必要がありますか?各アクションが互いに独立している場合は、自由に個別のトランザクションで実行できます。ただし、それらが連動していて、1 つの障害で他の障害もロールバックする必要がある場合は、1 つのトランザクションに実装します。フォームがフロー内にある場合、障害パスのロールバック要素を使用してトランザクションをロールバックし、データの整合性を確保できます。
• ガバナ制限に対する下流への影響:特に、フォームでレコードを作成または更新する場合は、その操作の下流への影響を考慮してください。このレコード変更に基づいて起動されるプロセス、ワークフロールール、フロートリガー、Apex トリガー、または保存順序の他の項目は?また、これらの一括変更は、そのトランザクションで消費されるガバナ制限にどのように影響しますか?特定のレコードの変更によってダウンストリームの変更が多数発生し、制限に影響する場合は、そのレコードの変更を独自のトランザクションに分離することを検討してください。
• バッチ処理 コンテキストでも、複数の更新を一括処理する必要がある場合があります。複数画面フォームで大量のレコードを反復処理するとします。各画面の後にレコードの更新を確定するのではなく、すべてのレコードの更新を収集してから、すべてのレコードを更新する要求を 1 回送信します。

動的フォームを使用してレコードを作成または編集する場合、1 つの操作のみを実行し、その操作は常に純新規トランザクションの開始になります。

画面フローを作成する場合、特定のトランザクションで何を実行するかを大幅に制御できます。画面とローカルアクションは、トランザクション間の境界として機能します。画面フローアーキテクチャでトランザクションを管理する方法の概要を次に示します。

1. エンドユーザーは画面を操作し、[次へ] をクリックします。
2. クライアントは入力を使用して要求を API に投稿します。
3. API が要求を受信し、トランザクションとデータベース接続が開かれます。次に、API がフローエンジンをコールして要求を呼び出します。
4. フローエンジンはフロー定義の適切なパスを引き継ぎ、画面または [ローカルアクション] ノードに到達するまで辿ります。その後、エンジンはそのノードに関する情報を API に返します。
5. API は、次に表示する画面の詳細を含む応答オブジェクトを作成し、そのオブジェクトをクライアントに返します。この時点で、データベースの変更がコミットされ (保存注文実行のキュー)、データベース接続とトランザクションが閉じられます。
6. クライアントは API 応答を使用して、ユーザーが操作する次の画面を表示します。
7. ステップ 1 から繰り返します。

つまり、画面では取引が「中断」されます。その場合、待機中のアクションまたは DML がコミットされ、前のトランザクションがクローズされ、新しいトランザクションが開始されます。

適切な設計 (特定のトランザクションにどの操作をグループ化するか) は、コールです。いくつかの例を見てみましょう。

左側には、複数の画面で入力を収集し、1 つのトランザクションで複数のアクションを実行するフローが表示されています。

右側のフローは、各操作を個別のトランザクションで実行します。

右側の次のフローに示すように、レコードを作成し、レコードを更新して、さらにレコードを作成するフローがあるとします。

このシナリオでは、最初の 2 つの要素が成功し、最後の 2 つの要素が失敗した場合でも、最初の 2 つの DML 操作でこれらのレコードが作成および更新され、3 つ目の要素は更新されません。

レコードのロールバック要素を使用すると、3 つの操作をすべて連動して実行する必要がある場合にトランザクション全体をロールバックできます (左側の最終フローを参照)。

詳細は、「Flows in Transactions (トランザクションのフロー)」および「Flow Bulkification in Transactions (トランザクションのフローの一括処理)」を参照してください。「Salesforce Well-Architected」の「Automated(自動化)」セクションでは、データ処理についても詳しく説明します。

LWC からトランザクションを制御する機能は、LWC が操作を実行するために使用している基盤となるサービスに集約されます。Lightning レコードフォームベースコンポーネントを使用している場合、基礎となる操作 (レコードの作成または更新) は、フォームの送信直後にスタンドアロントランザクションで実行されます。

一般に、次のルールが適用されます。

• 各 UI API コールは独自のトランザクションに分離されます。
• 1 つのトランザクション内で複数の操作を実行する必要がある場合は、入力を Apex コントローラやフローなどのサーバ側テクノロジーに送信します。そのテクノロジーの通常のトランザクションルールが適用されます。

フロー、OmniStudio、LWC はすべて、プラットフォームイベント (イベント駆動型アーキテクチャ用) と API インテグレーションをサポートしています。カスタム Apex コードに加えて、フローと OmniStudio の両方で API を統合する宣言型メカニズムがサポートされています。

Mulesoft API または RPA ボットに接続する必要がある場合は、Mulesoft サービスを使用します。これにより、外部サービスが生成されます。

Mulesoft API と RPA ボットを使用した Mulesoft 外部インテグレーション __

API に OpenAPI スキーマがある場合は、外部サービスを作成します。

OpenAPI スキーマを使用した API への外部インテグレーション

それ以外の場合は、フローの HTTP コールアウト機能または OmniStudio の HTTP アクションを使用します。フローの HTTP コールアウトは外部サービスによって提供されます。

HTTP による外部インテグレーション

OmniStudio には、インテグレーション手順を使用して外部システムにコールアウトし、データマッパーを使用してデータを変換できる豊富なインテグレーション機能が備わっています。(詳細については、「オブジェクトへの影響」を参照してください)

カスタム Apex または外部サービスのどちらを使用して実装しているかに関係なく、コールアウトはコールアウトです。必要な知識は次のとおりです。

1. コールアウトには時間がかかる場合があります。
2. コールアウトが同期的に実行される場合は、データベーストランザクションが開いている間に実行されます。
3. 待機中のデータベース操作がある場合、Salesforce ではデータベーストランザクションを開いたままにできません。

留意すべき主な制限は、作成、更新、削除操作を実行してから同じトランザクションでコールアウトを実行する、いわゆる**ダーティ トランザクション**の危険性です。このパターンは、上記の考慮事項 #3 のために許可されていません。もちろん、考慮事項 #1 と #2 のために存在します。

フローでは、トランザクションを破棄することでこの制限を回避できます。画面とローカルアクションの両方でブラウザーコンテキストが再導入され、トランザクションが中断されます。外部コールアウトを使用する場合は画面とローカルアクションを使用できますが、呼び出し可能な詳細設定でトランザクション制御を有効にすることをお勧めします。トランザクション制御は、コールアウトが行われる前にトランザクションを自動的に終了できる呼び出し可能なアクションの機能です。呼び出されたアクションの [詳細] セクションで [常に新しいトランザクションを開始] を選択すると、トランザクション制御を有効にできます。

Apex コールアウト、外部サービス、およびデータ統合機能全般についての詳細は、『Architect's Guide to Data Integration with Salesforce (Salesforce とのデータ統合に関するアーキテクトガイド)』を参照してください。

動的フォームでは再利用はサポートされません。各動的フォームは、特定のオブジェクトの特定の Lightning レコード ページに関連付けられています（ただし、その Lightning レコード ページを複数のアプリケーションやプロファイルなどに割り当てることができます）。

ほかの複数のコンポーネントで使用するライブラリ、ユーティリティー、およびコンポーネントを記述する場合と同様に、**サブフロー**の機能を使用してフローを作成するときに同様のデザインパターンを適用できます。フローをより小さくモジュール化されたバケットに保存し、サブフロー要素を使用して他のフローからコールします。設計で必要な場合は、両方独立して別のフローのサブフローとして役立つフローを作成できます。

OmniStudio は、本質的にモジュール化を目的として構築されています。データマッパー、OmniScript、FlexCard、Integration Procedure はすべて独立して構築され、相互に連動できます。さらに、FlexCard は他の LWC、OmniScript、レコードページ、Experience Cloud サイトに組み込むことができる LWC コンポーネントとして構築できます。

画面フロー、OmniScript、LWC はすべて再利用できるように構築でき、外部サイトや Lightning Out アプリケーションなどのさまざまな場所に組み込むことができます。ソリューションを構成可能に設計すると、適応性や安定性などの追加のメリットが得られます。

レコードの作成または更新に使用されるすべてのテクノロジーは、従来の入力規則であるか、Apex トリガーに組み込まれたカスタム入力規則であるかに関係なく、システム・レベルの入力規則に準拠します。レコードの変更の実行に使用しているテクノロジーに関係なく、すべての変更は保存順序に従います。つまり、入力規則に加えて、レコードの変更は保存前または保存後フロー、トリガーの前または後、エスカレーションルール、割り当てルールなど、任意の数で処理されます。ブックマークしていない場合は、必ずブックマークして、Apex の実行順序に慣れてください。

• フォームにシステムレベルの検証以外の追加要件はありますか?
• 項目をフォーム内で動的に必須または参照のみに設定する必要はありますか?

フロー画面または OmniScript ステップの入力は本質的にバインドされていないため、フォーム自体は特定のオブジェクトに関連付けられたシステムレベルの検証にネイティブに準拠しません。ただし、レコードを作成または更新するために使用する値は保存順序で処理されます。つまり、オブジェクトのシステムレベルの検証を通過します。ただし、すべての画面フローコンポーネントで入力検証がサポートされるわけではありません。Summer '24 の時点で、入力検証をサポートしていない残りの画面コンポーネントは、ラジオボタン、選択リスト、複数選択リスト、チェックボックスグループ、選択肢ルックアップです。

動的フォームでは、ページレイアウトと同様に、必須性と参照のみの状態をページレベルで設定できます。ただし、システムレベルの設定を上書きすることはできません。

フローでは、フォームの入力の検証を柔軟にカスタマイズできます。クライアントでいくつかのチェック (必須項目の欠落や互換性のない値へのフラグ付けなど) が実行されますが、クライアント側の検証でユーザーの移動がブロックされることはありません。実際の検証はサーバーで行われます。ユーザーが [次へ] をクリックすると、フローによって入力が検証のためにサーバーに送信されます。入力が無効として返された場合、ナビゲーションがブロックされ、適切なエラーが表示されます。サーバーは次のチェックを行って入力を検証します。

1. 入力の必須設定、または入力された値が基礎となるデータ型と互換性があるかどうか。
2. その入力に対するカスタム検証:いくつかの標準コンポーネント (チェックボックス、通貨、日付、日付/時間、ロングテキストエリア、数値、パスワード、テキスト) では、画面ごとのカスタム検証がサポートされています。Boolean 型の数式と、数式が満たされない場合に表示するエラーメッセージを指定します。
3. 基盤となるコンポーネントに対するカスタム検証:フローのカスタム LWC を作成する場合は、独自の検証コードを validate() メソッドに追加します。

OmniStudio は、条件ビューおよびメッセージングコンポーネントと組み合わせて [エラーを設定] アクションを使用することで、豊富なエラーおよび検証処理を実現します。

LWC 側では、ほとんどのベースコンポーネントが独自のクライアント側検証を実行します。たとえば、Lightning-record-form では、システム レベルの要件は考慮されますが、ページ レベルの要件は考慮されません。カスタムコンポーネントの場合は、Build Your Own 検証メカニズムを作成できます。

ユーザーがデータを入力する必要がある項目は、フォームの早い段階で表示する必要があります。可能な限り、フォームを送信する前にクライアント側でユーザー入力を検証します。フォームの合理化に関するその他のベスト プラクティスについては、「Salesforce Well-Architected - Engaging」のフォーム ガイダンスを参照してください。

セキュリティは一般に複雑なトピックであり、フォームの作成に関しては、思いもよらなかった考慮事項がいくつかあります。基礎レベルでは、フォームが正しいコンテキストで実行され、基礎となるデータを操作するために必要な権限がユーザーに付与されていることを確認します。さらに、リッチテキスト項目から潜在的に悪意のあるコードや URL を削除したり、特定のユーザーがフォームにまったくアクセスできないようにしたり、今後システム管理者がフォームを埋め込むことができる場所の種別を制限したりするための追加措置を講じる必要もあります。ツールを選択する前に、セキュリティ要件を徹底的に文書化してください。Salesforce Well-Architected Security Policy Template には、この種別のドキュメントに関するガイドラインが含まれています。

• 特定の操作を実行する前にフォームでユーザーのアクセス権を確認する必要がありますか?
• ユーザー入力をサニタイズする必要がありますか?
• フォームにアクセスできるユーザーを制御しますか?
• フォームを埋め込む場所を制御しますか?

**ユーザーコンテキストで何かが実行されると、Salesforce は、組織の共有ルールに基づいて項目レベルセキュリティ、CRUD 権限、レコードアクセス権の検証など、一連のアクセスチェックを適用します。そのため、たとえば、ユーザーがケース更新フォームを実行できるのは、ケースを更新する権限、適切な項目レベルセキュリティ、および当該レコードへのアクセス権がある場合のみです。ただし、ユーザーが自分のフォームを使用しているときに特定の操作を実行できるようにし、他のフォームやインタラクションからは実行できないようにするにはどうすればよいでしょうか。ここで、システムコンテキスト**の出番です。

システムコンテキストは、セッション中に実行ユーザーの権限を昇格させる手段であり、たとえば、ケース更新フォームを正常に入力するためにケースオブジェクトへの更新アクセス権をユーザーに付与する必要はありません。これは、認証されていないコミュニティで特に便利です。ゲストユーザーに潜在的に危険な機能を付与する代わりに、システムコンテキストで実行するようにフォームを設定します。

もちろん、システムコンテキストは両刃の剣であり、必要な場合にのみ使用する必要があります。フォームがシステムコンテキストで実行されると、関心のある特定の操作だけでなく、すべての CRUD 操作がオブジェクトレベルおよび項目レベルのセキュリティと共有をスキップします。また、システムコンテキストは、Salesforce がアクターとみなすユーザー ([最終更新者] 項目に表示される名前) には関係ありません。ケースの更新など、フォームで実行される各操作では、フォームが別のコンテキストで実行されていても、アクターが実行ユーザーになります。

動的フォーム、OmniScript、LWC は常にユーザーコンテキストで実行され、この動作を上書きする方法はありません。

画面フローはデフォルトでユーザーコンテキストで実行されますが、システムコンテキストで実行するように設定することもできます。フローですべてのデータへのアクセス権を付与するのか、それとも共有などのレコードレベルのアクセス権を適用するのかを選択できます。

• システム コンテキストで実行されるフローに Lightning コンポーネントを埋め込む場合、そのフローでコンポーネントのコンテキストが上書きされることはありません。ユーザー アクセス チェックをスキップする必要がある場合は、フローを使用してこれらの操作を実行し、Lightning コンポーネントに適切なデータを渡したり、Lightning コンポーネントから適切なデータを渡したりすることをお勧めします。一部の標準コンポーネント (ルックアップなど) は、システムコンテキストで操作できません。
• フローで Apex アクションをコールする場合、さらに理解すべき微妙な違いがあります。Apex クラスが継承共有に設定されている場合、フローの設定に関係なく、共有のシステム コンテキストで実行されます。クラスに明示的な共有宣言がない場合、フローの設定に関係なく、共有なしでシステムコンテキストで実行されます。クラスが共有ありまたは共有なしに設定されている場合、共有され、フローのコンテキストが上書きされます。

Experience Cloud サイトを使用したシステムコンテキストでのレコードの照会

Experience Cloud サイトのシステムコンテキスト (特に未認証) でフローを実行している場合は、[レコードを取得] 要素に特定のフィールドのみを保存することをお勧めします。フローを使用していて、レコードを取得要素の結果をサブフロー、呼び出し可能なアクション、または Lightning コンポーネントに渡すと、そのオブジェクトのすべての項目をブラウザの開発者ツールを使用して検査できます。これにより、Experience Cloud サイトユーザーが意図しない項目を使用できるようになる可能性があります。[レコードを取得] 要素で特定の項目を指定することで、システムコンテキストが有効になっていても適切な項目のみが表示されるようにできます。

OmniScript ロジックはクライアント側で実行されます。これにより、攻撃者は OmniScript の予期される実行を変更し*、*ブラウザーの開発者ツールを使用して Integration Procedure、データ マッパー、Apex メソッド コールへの応答を表示できます。OmniScript を使用している場合は、可能な限りサーバー側でビジネス ロジックを実行し、@InvocableMethod アノテーションを介して公開される Apex メソッドに入力規則を実装することをお勧めします。

入力のサニタイズ:

悪意のあるユーザーから組織を保護するには、入力のサニタイズも検討します。公開されているフォームに入力があり、それを組織のリッチテキスト項目に対応付けることができるとします。悪意のある URL を隠す可能性がある HTML を削除する自動化を検討することをお勧めします。一般に、このサニタイズをフォームレベルで実装することは理想的ではありません。これらの項目には任意の数のソースを書き込むことができるためです。Fast Field Update フロー（保存前）を作成するか、オブジェクトで既存の Apex トリガーを使用して、フォームに入力される可能性のある HTML を削除または変更することをお勧めします。

ベスト プラクティス:

• 特定の操作で実行ユーザーのアクセス権を昇格させる必要がない限り、フローはデフォルトのコンテキストで実行されるようにします。
• セキュリティ上の理由により、ゲストユーザーのシステムコンテキストでのフローの実行は避けてください。代わりに、Experience Cloud サイトのゲストユーザープロファイルに割り当てられた項目アクセス権が制限された権限セットを作成します。
• Experience Cloud サイトのシステムコンテキスト実行フローでレコードを照会する場合、[レコードを取得] 要素または呼び出し可能なアクションに必要なフィールドのみを保存します。
• フローでさまざまな操作を実行し、すべての操作に高度なアクセス権が必要ない場合は、サブフローを使用してシステムコンテキストで実行する操作を分離します。
• フォームを外部 Web ページに埋め込む場合は、ユーザー入力をサニタイズして高速項目更新フローまたは Apex トリガーを使用して HTML を削除し、最終的にリッチ テキスト フィールドにマッピングして、悪意のあるユーザーからのフィッシング攻撃を防ぐことを検討してください。

• OmniScript、FlexCard、LWC は、デフォルトでユーザーコンテキストで実行されます。
• LWC はデフォルトでユーザ コンテキストで実行され、フローはユーザ コンテキストで実行されますが、Apex コントローラで上書きできます。
• UI API を介して実行される操作は、ユーザーコンテキストで実行されます。
• Apex コントローラを介して実行される操作は、そのクラスによって異なります。これらの操作をシステム モードで実行するには、Apex クラスを共有ありまたは共有なしに設定します。

フォームにアクセスできるユーザーを制御する必要がある場合、多くの場合、フォームが埋め込まれているコンテナを参照できます。たとえば、特定のアプリケーション、レコード タイプ、プロファイルで使用できるように Lightning ページを割り当てることができます。フォームの特定の入力が機密である場合、表示ルールを使用して誰に表示するかをさらに制御します。この機能は動的フォームと画面フローの両方に適用されます。

Apex クラスや Visualforce ページと同様に、特定のプロファイルまたは権限セットにフローを制限できます。デフォルトでは、フローは無制限です。つまり、「フローを実行」ユーザー権限を持つすべてのユーザーがフローを実行できます。

OmniStudio を使用している場合は、OmniScript、Flexcard、Classic Card、または REST API からコールされたリモート・アクションを管理する Apex クラスへの明示的なアクセスをユーザーに要求するようにApex クラス権限チェッカーを設定できます。

• 注: Apex クラスの権限チェックは、新規作成されたスクリプトではデフォルトで有効になっています。ただし、既存のスクリプトでは手動で有効にする必要があります。
• また、Apex クラス権限チェックは Apex クラスにのみ適用されます。インテグレーション手順とデータマッパーにもプロファイルレベルの権限を設定することをお勧めします。

ゲストユーザー権限の詳細とベストプラクティスについては、次を参照してください。

• ゲストユーザーレコードアクセスのベストプラクティス
• セキュアサイトの開発:認証済みユーザーとゲストユーザー

ベストプラクティス:

• フローをゲスト ユーザに公開する場合は、ゲスト ユーザ プロファイルに必要なフローのみへのアクセス権を付与します。ゲストユーザープロファイルに「フローを実行」を追加することもできますが、これはリスクの高い方法であると考えられます。
• システムコンテキストで動作するフローには特に注意してください。これらのフローは特定のユーザーセットに制限することを強くお勧めします。データを保護するための抑制と均衡が少ないためです。
• ゲスト ユーザー コミュニティで Apex を実行するすべての OmniScript で Apex クラス定義に「with sharing」が含まれていることを確認します。
• ゲストユーザープロファイルで、ゲストユーザーがコールできるようにする Apex クラスのみを割り当てます。割り当てないと、意図せずに追加のビジネスロジックがゲストユーザーに公開される危険があります。

LWC の場合、実行ユーザーの権限割り当てをチェックして、特定の標準権限またはカスタム権限があるかどうかを確認できます。JavaScript から直接、@salesforce/userPermission および @salesforce/customPermission 範囲設定済みモジュールから Salesforce 権限をインポートできます。または、Apex を使用して確認することもできます。

Lightning Web コンポーネントは、有効なターゲットとして追加された場合にのみ、特定の場所で使用できます。たとえば、コンポーネントをレコードページで使用可能にしたり、ユーティリティバー項目として使用できないようにしたりできます。

画面フローを有効化すると、画面フローがサポートされているすべての場所で、あらゆる場所で使用できるようにするかどうかに関係なく、使用できるようになります。ただし、Flow Builder では、画面を含む複数の種類のフローがサポートされます。ブレッド & バター種別は [画面フロー] ですが、特定の場所に制限された特殊な種別がいくつかあります。たとえば、Field Service Mobile アプリケーションでは Field Service Mobile フローのみがサポートされます。Experience Cloud でのみサポートされる連絡要求フローも同様です。

フロー種別に関係なく、フローを作成した個人は、フローを埋め込むことができる場所を制御できません。フローは、そのフロー種別でサポートされるすべての場所で使用できます。

Salesforce Industries を使用している場合は、OmniScript に関して少し注意が必要です。OmniScript 自体に対象を指定することはできませんが、OmniScript に埋め込む FlexCard に対象を指定できます。

静的形式は過去のものです。今日は、このユーザー (今回はこの場所) に適切なプロパティと値でフォームを動的に更新することです。Salesforce のフォーム作成ツールについて、この流れで何ができるかを説明します。

• フォーム内で動的応答をトリガーする必要があるインタラクションまたは条件の種別は?
• フォームの入力時にバックグラウンドで画面外操作を実行する必要がありますか?
• 項目を表示、必須、参照のみ、無効として設定するか、フォーム入力に基づいて書式設定を変更する必要がありますか?

反応型画面のおかげで、画面フローのインタラクティブ性が実現しました。リアクティビティを使用すると、フロー画面の個々のコンポーネントが相互に通信できるため、画面フローが無限に強力になります。

**画面外データ操作の実行:**画面フローでは、画面アクションを使用して同じ画面のデータを取得する宣言型のアプローチが提供されます。画面アクションを使用すると、画面の変更時やユーザーがアクションボタンコンポーネントをクリックしたときに自動起動フローをトリガーできます。その後、これらの自動起動フローの結果を同じ画面にマッピングできるため、ユーザーが別の画面に移動する必要がありません。

LWC には、Salesforce データにアクセスしてフォームのコンポーネントのデータを動的に入力できるワイヤ アダプタが多数用意されており、開発者は Apex コントローラを使用してレコードを更新、削除、作成できます。

Lightning Web コンポーネント オフ画面データ操作

**表示:**表示は、すべてのフォーム作成ツールで動的に制御できます。動的フォーム、Flow Builder、OmniStudio は、コンポーネント表示機能を使用してこれに対応します。これにより、フォームの他の値やユーザーがモバイルデバイスを使用しているかどうかに基づいて、宣言的に項目を表示または非表示にできます。

• 動的フォームでは、レコード項目値、参照項目を介して関連するレコード、フォーム要素に基づいて表示を制御できます。
• フローでは、表示ルールを画面の他の入力や、数式や他のレコードの値など、フローの前半で入力された他のリソースに基づいて設定できます。
  • **デバイスベースのルール:**最初から明確ではありませんが、ユーザーがモバイルデバイスを使用しているときに数式を使用して特定の項目を表示または非表示にできます。$User.UIThemeDisplayed グローバル変数の値をチェックするフロー数式を記述します。値が Theme4t の場合、ユーザーは Salesforce モバイルアプリケーションを使用しています。
  • **その他のリソースの評価:**手動変数および数式参照はサーバーでのみ評価されます。そのため、画面が最初に表示されるときのリソースの値は、別の画面に移動するまでの値になります。ナビゲーションでは、フローランタイムがフローエンジン (サーバー) に要求を送信し、手動変数と数式の最新の値を取得します。ユーザーが 1 つの画面を通過するときに表示ルールが更新されることが予想される場合 (onblur など)、画面の他のコンポーネントの値のみを参照していることを確認してください。
• OmniStudio では、[条件付きビュー] プロパティを設定して、コンポーネントを条件付きで表示または非表示にできます。ただし、1 つの入力に複数の条件付きビュープロパティを追加することはできません。

**条件付き入力状態:**項目が必須、無効、参照のみなど、他のプロパティを動的に制御する必要がある場合は、いくつかのオプションがあります。期待どおり、LWC では入力状態を完全に反応的に制御できます。反応型画面フローコンポーネントでは、そのコンポーネントをサポートする標準コンポーネントの [参照のみ]、[無効]、[必須] などのコンポーネント属性を動的に制御できます。OmniStudio では、コンポーネント固有の属性の全範囲がサポートされます。要件によってフローが必要と判断され、コンポーネントで特定の属性状態がサポートされていない場合は、埋め込み可能な LWC を作成して動的入力状態を実現できます。

項目が必須か参照のみかなど、他のプロパティを動的に制御する必要がある場合、短期的には LWC が最適です。LWC では、完全に制御できます。特に、ぼかしやクリックの処理方法に関する特注の要件がある場合に顕著です。

画面フローの反応型 LWC:画面フローの他のコンポーネントに反応したり変更したりできる LWC を作成する場合は、この LWC Best Practices for Screen Flows (画面フローの LWC のベストプラクティス) ガイドを参照して、コンポーネントがフローランタイムエンジン内で適切に統合され、将来にわたって期待どおりに動作することを確認してください。

カスタムイベントの場合。入力の一部またはフォーム全体がページ内の他のものと通信する必要がある場合は、LWC が唯一のオプションです。

• 同じ DOM ツリー内で通信するには、CustomEvent インターフェイスを使用します。
• DOM 間で通信するには、Lightning Messaging Service を使用します。
• Lightning Messaging サービスが対象コンテナでサポートされていない場合は、pub/sub モジュールを使用します。

• 詳細については、『Lightning Web Components Dev Guide』の「Communicate with Events and Communicate Across the DOM」を参照してください。
• OmniStudio の場合は、「Lightning Web コンポーネントからの Omniscript との通信」を参照してください

最適なユーザーエクスペリエンスを提供するには、フォームのスタイルが埋め込まれている他のアプリケーションまたはサイトと一貫していることを確認する必要があります。これを実現するには、Salesforce で提供される標準テンプレートの使用から、デザインのすべてのピクセルを完全に利用してよりシャープなデザインを実現するカスタム CSS の作成まで、あらゆることが考えられます。

• 目的のスタイルと CSS はどの程度洗練されていますか?
• ピクセル単位で完璧なカスタムスタイルが必要ですか? それとも標準テーマで問題ありませんか?

FlexCards は、ツールで作成する UI (余白やパディング、タイポグラフィ、色など) のスタイルやレイアウトを宣言的に直接制御できる唯一の製品です。

動的フォームとフローはどちらも宣言型テーマ機能を尊重します。Salesforce テーマ、エクスペリエンスビルダーブランドセット、または LWR Experience Cloud サイトでサポートされる以上の制御が必要な場合は、プログラムソリューションを検討してください。

CSS の使用に慣れているチームには、いくつかのオプションがあります。

• フローと LWC は標準設計トークンを継承します。
• OmniScript と FlexCard には、カスタマイズ可能な設計システムのサポートが含まれます。Newport。
• LWC では、独自のコンポーネントを記述し、その HTML と CSS を完全に制御できます。

可能な限り、テーマとデザインシステムを使用して、すべてのコンテンツに一貫したデザインを適用することをお勧めします。

リマインダー コンポーネントはフローに組み込むことができます。そのため、フォームのデザインをピクセル単位で完璧に制御する必要があり、ナビゲーションモデルなど、フローの他の利点を使用する場合、両方の利点を活用できます。同じ原則が OmniScript と FlexCard にも適用されます。

迅速かつ効率的なデータ入力を可能にし、データの整合性を高める合理化されたフォームを設計するには、適切なレイアウトを選択することが不可欠です。このトピックについての詳細は、「Salesforce Well-Architected - Forms (Salesforce の適切なアーキテクチャ - フォーム)」を参照してください。

• フォームのレイアウトを使用してユーザーエクスペリエンスを最適化する方法は?
• フォームに新しいデータを簡単に入力できるように、既存のデータをユーザーに表示する方法は?

動的フォームでは 2 列レイアウトがサポートされ、項目を使用して個々のセクションに分割できます。これらのセクションをタブやアコーディオンなどのコンポーネントに配置すると、使いやすく整理されたレイアウトを作成できます。

フローは、必要に応じてセクションコンポーネントを使用して表示できます。セクションを使用すると、フロー画面に最大 4 つの列と必要な数のセクションを追加できます。このコンポーネントは画面幅にも反応するため、小さな画面でも使用できます。最後に、条件付き表示をセクション全体に適用できるため、セクション内の複数の項目に表示を一括適用しやすくなります。フローセクションは列ヘッダーもサポートし、表示ラベルをクリックしてセクション全体を折りたたむことができるアコーディオンのような環境を提供します。

OmniScript には、項目とデータを表示するためのさまざまなレイアウトオプションがあります。条件付き折りたたみ可能なアコーディオンを含め、最大 12 列のデータセクションを作成できます。

LWC では、Lightning-record-［edit|view］-form およびサポートされる Lightning-［input|output］- フィールドを使用してレイアウトを制御できます。レイアウトの制限は HTML/CSS の制限のみです。Lightning-record-form は、関連付けられたページレイアウトのセクション設定に従います。たとえば、ページレイアウトでセクションが 2 列の場合、このコンポーネントでは 2 列になります。

異なる地域のユーザーや異なる言語を話すユーザーがフォームにアクセスできるようにするには、フォームの作成に使用するツールがローカライズ要件を満たしていることを確認する必要があります。その他の指針と推奨事項については、「Salesforce Well-Architected - Localization (Salesforce の適切なアーキテクチャ - ローカライズ)」を参照してください。特にフォームの場合、ローカライズ要件として、通常、テキスト要素を他の言語に翻訳する必要があります。

• フォームを複数の国または地域で使用しますか?
• フォームのテキストを他の言語にローカライズする必要がありますか?

カスタム項目をローカライズした場合、動的フォームでは翻訳された表示ラベルが適用されます。動的フォームでは、Lightning アプリケーションビルダーでコンポーネントの表示ラベルと属性に割り当てたカスタム表示ラベルも尊重されます。

トランスレーションワークベンチにより、フローではすべての標準画面コンポーネントとカスタム画面コンポーネントのユーザー向け表示ラベルの翻訳がサポートされます。次の画面コンポーネントの表示ラベル、ヘルプテキスト、エラーメッセージをローカライズできます。テキスト、ロングテキストエリア、数値、通貨、チェックボックス、ラジオボタン、選択リスト、複数選択リスト、チェックボックスグループ、パスワード、日付、日付/時間。

標準のアクション ([メールを送信] や [Chatter に投稿] など) に対する翻訳サポートは組み込まれていません。ただし、回避策があります。翻訳済み表示ラベルをカスタム表示ラベルで定義する場合、Flow Builder で設定するときにアクションまたはコンポーネントでそのカスタム表示ラベルを参照できます。カスタム表示ラベルを参照するフロー数式を作成し、フローの適切な場所でその数式を参照します。

OmniScript では、翻訳にカスタム表示ラベルが使用されます。このヘルプドキュメントを参照して、OmniScript を多言語に対応させます。

LWC だ特定のベース コンポーネントは、トランスレーション ワークベンチで設定されている場合、関連付けられたオブジェクトの項目、ヘルプ テキスト、検証メッセージの翻訳を自動的に継承します（Lightning-record-form など）。

新しい翻訳可能な表示ラベルをコードに導入する必要がある場合、カスタム表示ラベルが依然として主役です。必要なカスタム表示ラベルを宣言し、@salesforce/label 範囲設定モジュールからコンポーネントにインポートします。

Selenium など、いくつかのエンドツーエンドのテスト自動化ツールがあり、ユーザーがフォームを操作する方法をシミュレーションできます。これらのテストは、Lightning ページや画面フローなど、任意の標準またはカスタム UI に対して記述できます。ただし、この種のテストでは、実行中の各メソッドの出力を確認できないことに注意してください。UI テストの自動化の要件を検討するときは、この点を考慮してください。

• フォームの自動テストが必要ですか?
• どのような種類のテストを実行する必要がありますか?
• テスト自動化に必要な粒度は?

UI テスト自動化の要件を考慮します。

単体テストを使用すると、業界標準の CI/CD システムおよびツールと連携するより詳細な自動化と検証が可能になり、コンポーネントのビジネスロジック、JavaScript コントローラー、出力をテストできます。ローコードのみを使用してテストを自分で作成することはできませんが、Salesforce ではエンドツーエンドのサービスを厳密にテストしています。

コンポーネントのメソッドが複雑で、個別にテストする場合は、メソッドを専用の JavaScript ファイルに格納します。これにより、import { sort } from 'c/utils'; などの LWC および Jest テストにインポートできます。

Salesforce でエンドツーエンドの自動化を構築するためのさまざまなオプションの比較については、「Salesforce での UI テストの自動化」を参照してください。ISV のノーコードソリューションを使用するケース、Build Your Own テスト自動化ソリューションを使用するケース、または Selenium WebDriver や WebdriverIO などのオープンソースのテストフレームワークを使用するケースに関する考慮事項が含まれます。これらのソリューションは、Lightning ページの動的フォーム、ユーティリティ バーの画面フロー、クイック アクションのフローの LWC など、Salesforce のあらゆる UI インタラクションで有効です。

フォームを本番環境にリリースしたら、フォームが効果的に使用されていることを確認します。使用事例によっては、単に入力回数を追跡することから、ユーザーが情報を送信する前に入力に費やす時間まで、あらゆるものを指します。ツールを選択する前に、追跡する KPI を必ず特定してください。

• フォームの利用状況を追跡する必要がありますか?
• フォームが効果的に使用されているかどうかを決定する KPI は?

フォームの全体的な使用状況と採用を追跡する必要がある場合は、まずローコードツールを使用します。動的フォームと画面フローは、どちらも標準のカスタムレポートタイプを使用して追跡できますが、画面フロー追跡レポートではより詳細に追跡できます。LWC の利用状況を追跡する必要がある場合、すぐに使用できるかどうかは、その LWC を使用している場所によって異なります。Lightning ページにある場合は、Lightning ページの使用状況の追跡に使用できるすべてが LWC に適用されます。フローに埋め込まれた LWC についても同様です。

動的フォーム自体は標準では追跡できませんが、Lightning 使用オブジェクトを使用して親 Lightning ページの使用状況を追跡できます。標準 Lightning ページを追跡するには、Users with Lightning Usage by Page Metrics カスタム レポート タイプを使用します。カスタム Lightning ページでも同様に、カスタム レポート タイプ「Users with Lightning Usage by FlexiPage Metrics」を使用します。

特定のフォーム (そのフォームが属するページだけではない) の採用を追跡するために、フローが役立ちます。「サンプルフローレポート:画面フロー」で、次のような質問に回答できます。

• このフォームの完了率は?適切に採用されているか?
• ユーザーがこのフォームに入力するのにどのくらい時間がかかりますか?
• ユーザーが最も時間を費やしている画面は?
• ユーザーが逆方向に移動する頻度は?
• エラーが発生する頻度は?

標準レポートがニーズに合わない場合は、標準レポートをコピーして独自の変更を加えるか、画面フローレポートタイプを使用して独自のレポートをゼロから Build Your Own します。

パッケージベースの OmniScript ランタイムを使用している場合は、OmniStudio for Vlocity Tracking Serviceを使用できます。このサービスでは、あらゆる種別のイベントを追跡します。たとえば、OmniScript のステップの完了に要する時間を追跡して、プロセスの改善を特定できます。Standard OmniStudio でこのサービスをサポートするための OmniStudio チームのロードマップに記載されています。

画面フロー、OmniScript、Lightning ページに埋め込まれていない LWC で同じものを追跡するには、標準オプションはありません。Apex を使用してカスタムソリューションを構築できます。

テストや本番へのリリースのためにソリューションを上位の環境にリリースする必要がある場合、変更セットや DevOps センターを使用することに慣れている可能性があります。これらのリリースオプションでは、動的フォーム、フロー、LWC が完全にサポートされています。OmniStudio には別のツールが必要です。IDX ワークベンチ。

• フォームをどのようにリリースする予定ですか?
• フォームは複数の Salesforce 組織に配布されますか?

AppExchange で配布するためにソリューションをパッケージ化する予定の ISV またはパートナーは、最初に動的フォーム、フロー、および LWC を確認することをお勧めします。OmniStudio ではパッケージ化はサポートされていません。

このガイドでは、動的フォーム、画面フロー、OmniStudio、LWC でどのような機能とカスタマイズレベルが可能かを理解するのに役立つことに重点を置いています。概要:

• LWC は、フォームを作成するための最もカスタマイズ可能で堅牢なオプションですが、配置するガードレールの数が最も少なくなります。セキュリティと拡張性を確保する方法でコンポーネントを構築するかどうかは、ユーザー次第です。
• 動的フォームは最も柔軟性に欠けますが、ミスステップが発生する可能性ははるかに少なくなります。
• フローと OmniStudio は中間に位置します。動的フォームよりも強力ですが、LWC のレベルにはまだ達していません。同じトークンで、動的フォームよりもガードレールが少なくなっていますが、カスタムコードよりも破られにくくなっています。

複数のツールが請求に適している場合、どのツールがチームに適しているかが判断されます。他のアーキテクト決定ガイドでは、その決定を行うときに考慮すべき追加の側面が紹介されています。

ここでは、これらの各側面の詳細には触れませんが、このドキュメントで評価する特定のツールについて解釈します。

専門スキル:比較するツールに関するチームの専門知識は?LWC または JavaScript に精通しているメーカーはどれくらいいますか?Flow Builder のエキスパートであるか、つま先を浸すことに関心を示したメーカーはどうでしょうか?概して、動的フォームとフローのスキルは、フォームを作成する幅広いユーザーがより容易に習得できます。動的フォームは最も宣言型のフォーム作成ツールであり、フローよりも常に簡単に学習できます。とはいえ、フローチームはそのハードルをできるだけ低くすることに取り組んでいます。複雑さという点で、OmniStudio はフローと LWC の中間に位置し、フォーム作成の強力な機能を提供します。

配送の委任 を必要とする要件があるからといって、ソリューション全体を LWC で構築する必要があるわけではありません。LWC が必要な部分はコーディングし、不要な部分はローコードソリューションで作成するなど、ソリューションをモジュール化する方法を検討します。これにより、多様なチームの効率を最大化し、各個人が専門分野に適した問題を解決できるようになります。

次に、フローと LWC について説明します。反応型画面コンポーネントを使用すると、画面フローコンポーネントが同じ画面上で相互にやりとりできるようになり、アーキテクト、システム管理者、開発者向けのまったく新しいツールが使用可能になります。開発者は、組織全体で再利用できる明確な目的に基づくモジュールコンポーネントを作成できるようになり、チームの全員の生産性が向上します。開発者は、標準フローコンポーネントとカスタムフローコンポーネントを組み合わせてフォームのダイナミズムを実現することで、新しい課題の解決に集中し、時間を節約できます。フローの反応型コンポーネントを使用すると、フォームの作成時にフローと LWC を混在させることができます。

メンテナンス性と長期所有:複数ステップのフォームがある場合は、フローから開始するか、フローと LWC を組み合わせて使用することをお勧めします。ローコードのチームがソリューションをメンテナンスしている場合、その利用者向けにソリューションを可能な限り設定および拡張できるようにする方法を検討します。どのツールを選択しても、ソリューションを構成可能な単位に整理して、メンテナンス性と安定性を向上させます。

今後、レコード詳細ページを設定するための推奨方法は、Lightning ページを使用した Lightning アプリケーションビルダーでの動的フォームです。ページレイアウトが強化されて久しく、今後もその傾向は続くでしょう。その理由は次のとおりです。

• 動的フォームの柔軟性は向上しています。Lightning アプリケーションビルダーでは、項目やセクションを任意の場所に直接配置できます。ここでは、セクション、タブ、アコーディオンを利用できます。また、Lightning ページのコンポーネントと同様に、複数のページレイアウトやレコードタイプを定義しなくても、項目やセクションの表示を制御できます。
• アコーディオンおよびタブコンポーネントでは、最初に表示される項目の数を制限できます。どういう意味だと思う?ページの読み込み時間を短縮。
• Lightning ページでは、ページの内容やページへのアクセス権を持つユーザーなど、ページに関するすべてを Lightning アプリケーションビルダーから管理できるため、レイアウト管理がシンプルになります。Lightning ページに変更を加えるためにページレイアウトを更新する必要がなくなりました。言うまでもなく、表示ルールを使用することで、誰がいつどの項目を表示するかを制御するために複数のページ (またはページレイアウト) を作成する必要がなくなります。また、Lightning ページとページレイアウトの両方を割り当てるのではなく、Lightning ページのみをユーザーに割り当てる必要があります。

可能な限り動的フォームを使用し、必要な場合にのみページレイアウトに戻ることをお勧めします。いつものように、組織にとって最も影響のある改善点に関するフィードバックを Idea Exchangeでお待ちしています。

動的フォーム、画面フロー、OmniStudio、LWC に関連するパフォーマンスに関する考慮事項は、これらのテクノロジー自体がどのようなフレームワークに基づいているかが中心になります。LWC ベースのもの (もちろん LWC も) は、Aura ベースのものよりもパフォーマンスが優れています。LWC フレームワークでは、コア機能がフレームワークの抽象化を介して JavaScript ではなく Web エンジンでネイティブに実装されるため、パフォーマンスが向上します。よく知らない場合は、このブログ投稿を参照してください。

2019 年に、Aura と LWC の同じ機能のパフォーマンスを比較したケース スタディを実施しました。DreamHouse を Aura から LWC に変換した結果、開発環境が現在の Web フロントエンド開発標準とパターンにはるかに適合しただけでなく、パフォーマンスが大幅に向上しました。ラボでの測定値では、同じ 2 つのページで、コールド キャッシュでは2.4%~24.7%、ウォーム キャッシュでは**31.83%~****63.32%**の向上が示されています。

では、フォームテクノロジーはどのフレームワークを使用していますか?つまり、この優れたパフォーマンスからメリットを得られるフォームテクノロジーは?

• Lightning ページのメタデータに統合されている動的フォームは、LWC スタックを使用する基盤上に構築されており、要求の厳しい機能を実装できます。パフォーマンスのボーナスとして、動的フォームでは順次表示が使用されます。これにより、多数の項目が含まれるページのページ読み込み時間が短縮されます。
• 画面フローは LWC に基づいて作成されており、2 つの標準コンポーネントを除き、ほとんどの標準コンポーネントが LWC に変換されています。ファイルのアップロードと画像。フローチームはフローランタイムクライアントとそのほとんどのコンポーネントを LWC に変換しましたが、顧客は Aura 画面コンポーネントを LWC に変換する必要があります。さらに、Salesforce では画面フローの新しい反応型コンポーネントフレームワークの LWC コンポーネントのみがサポートされます。その方法を説明する優れた Trailhead モジュールがあります。Lightning Web Components for Aura Developers (Aura 開発者向けの Lightning Web コンポーネント)。言うまでもなく、画面フローまたはその他のコンテナのカスタムコンポーネントを作成する場合は、常に LWC を使用してください。
• 使用可能な OmniStudio のバージョンがいくつかあります。長年の顧客の場合、Angular を使用している可能性があります。すべての新規ユーザーは LWC ベースの OmniScript と FlexCard から開始し、既存のユーザーは Angular から移行することをお勧めします。
• LWC は . . .LWC かこれはフリービーです。

アーキテクトは、使用可能なすべてのオプションと、それを特定の使用事例でどのように適用できるかをしっかり理解することが重要です。Salesforce でフォームを作成する場合、オプションはローコード (Lightning アプリケーションビルダーの動的フォーム、Flow Builder の画面フロー、OmniStudio の OmniScript を使用) からプロコード (LWC フレームワークを使用) まで多岐にわたり、画面フローまたは OmniScript と LWC が中間に組み合わされます。Salesforce でフォームを作成または再設計する場合は、このガイドを参考にしてください。合理化された便利なフォームを設計する方法に関するガイダンスが必要な場合は、Salesforce Well-Architected にお問い合わせください。Engaging。

お客様に最も関連性の高いコンテンツを公開するには、アンケートにご協力ください。このコンテンツに関するフィードバックをいただき、次に何をご覧になりたいかお聞かせください。