フォームの作成

Agentforce 360 Platform でフォームを作成するオプションは複数あり、それらはローコードからプロコードまでのアプローチに及びます。この連続性の一方の端では、Lightning アプリケーションビルダーの動的フォームと Flow Builder の画面フローをローコードソリューションに使用できます。一方、プロコード ソリューションにはLWC(Lightning Webコンポーネント)フレームワークが使用されます。この連続性の中で、LWC によって拡張された画面フローと OmniStudio を使用して作成された顧客向けフォームを使用して、さまざまな方法でツールをブレンドできます。

このガイドでは、UI ソリューションのフォームの作成に関する決定フレームワークとガイダンスについて説明します。具体的には、多数のランタイムと機能以外の決定ポイントを使用して、特定の使用事例に最適なテクノロジーを適切に選択します。

• **Lightning ページの作成/編集/表示レイアウトを作成する場合は、動的フォームを使用します。**今後は、_Lightning アプリケーションビルダー_で_動的フォーム_を使用してレコード詳細ページを設定することをお勧めします。

• **1 つのオブジェクトのフォームを作成、作成、編集する必要がある場合は、_Lightning ページ_と_動的フォーム_を使用します。**これは、Agentforce 360 プラットフォームでフォームを作成する最も簡単な方法です。また、追加機能 (項目表示制御など) も提供されます。

• **複数ページのフォームまたはウィザードを作成する場合、厳格な UX 要件やブランド要件がなければ、画面フローを使用します。**画面フローには、複数のフォームを調整するための線形ナビゲーションフレームワークが用意されています。LWC を使用して、フォーム間を移動する独自のフレームワークを構築できますが、フォームの状態ではなくフォームそのものに焦点を絞ることができるように、フローに任せることをお勧めします。

• **フォームをサポートする追加のロジックまたはアクションが必要な場合は、画面フロー、OmniStudio、または LWC を使用します。**これらの各ツールは、1 つのレコードの作成や編集以外にも拡張できるようにすることで、さまざまな方法でソリューションを強化します。この場合、「さらに」という用語は、高度なロジック (分岐や反復など)、または外部システムとの統合、メールの送信、ユーザーのモバイルアプリケーションへの通知の転送などのアクションを指します。

• **高度なUX要件がある場合、またはUI表示以外の機能を動的に管理する必要がある場合は、LWCまたはOmniScriptを使用します。**テーマ設定と列ベースのレイアウトを使用して満たすことができる要件については、ローコードビルダーで直接フォームを作成できます。ただし、フォームのスタイルを詳細に制御するには、LWC の柔軟性が必要です。Industries のお客様で、ピクセル単位の完璧なブランド設定が必要な場合や、複雑な階層データを使用している場合は、OmniStudio を使用します。OmniStudio を使用すると、複雑なビジネスロジックとデータ変換を処理できるコンシューマーグレードのフォームを作成できます。

• **テスト自動化をリリースする必要がある場合は、LWC を使用します。**どの LWC を埋め込むかに関係なく、LWC の単体テストを作成できます。これにより、複数のレコードを使用した一括テストやネガティブテストなど、より堅牢なテスト戦略を作成できます。

• **「いずれか/または」の決定に縛られません。**複数のオプションを組み合わせて、使用事例に最適なソリューションを実現できます (たとえば、フローの組み込みナビゲーションシステムと LWC が提供する完全なスタイル設定の柔軟性が必要な場合、それらを組み合わせて使用できます)。

フォーム環境を実装および拡張するためによく使用されるツールを次に示します。

次の表に、Salesforce でフォームを作成するために使用できるツールと、必要なスキルおよびライセンスの考慮事項を示します。

**注意:**各ツールでサポートされている特定の機能、クリック ベースのツールとコード ベースのツールのどちらを選択するか、および組み合わせるタイミングについては、後のセクションで詳しく説明します。

商品とツールを選択するときには、いくつかの決定ポイントに留意してください。この表は、さまざまな決定ポイントの概要と高レベルのガイダンスを示しています。

注意: 後続の決定比較表には、ツールと機能のペアに関連付けられたいくつかの値があります。

• 使用可能: このツール/機能は、基本的な考慮事項に従って動作します。

• 利用不可: 今後 12 か月以内にサポートを追加する予定はありません。

• 最適でない: このツール/機能は機能する可能性がありますが、最適なツールではありません。

• 該当なし: このツールは特定のユースケースには適用されません。

次のシナリオを使用して、範囲、UX、運用ニーズに基づいてツーリングの選択肢を比較します。

1 つの画面フォームからすべてのユーザー入力を取得できる場合は、動的フォームから開始します。レコードページの動的フォームでは、パス機能を利用して段階的なビジネスプロセスをサポートできます。

• 1 つの画面が必要ですか? それとも、ユーザーが ToDo を完了するために複数の画面間を移動する必要がありますか?

• ユーザーがフォームに入力するときに、プロセスの進捗状況を視覚的に確認できるようにしますか?ユーザーは各画面の情報を特定の順序で入力する必要がありますか? それとも、必要に応じて画面間を行き来できる必要がありますか?

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

• フォームの下部にナビゲーションバーを表示しても問題ありませんか?画面フローとOmniScriptのナビゲーションエクスペリエンスが望ましくないUXを提供する場合は、LWCを検討してください。

• フォームの背後で何を実行する必要があるか?システム管理者が設定できる動作が必要な場合は、フローを使用します。複雑な複数オブジェクトリレーションの場合は、Omniscript または LWC を使用します。

フローまたは OmniStudio を選択した場合は、適切な UX を実現するために LWC の構築が必要な場合もあります。フォームのスタイルを正しく設定するために LWC をすでに作成している場合は、そのコンポーネントをフローに埋め込む必要があるかどうかを検討してください。

ウィザードスタイルのナビゲーション

一方、ソリューションがウィザード (ユーザーが複数の画面間を移動する) のように見える場合は、フローまたは OmniStudio を検討します。フローと OmniStudio にはナビゲーションモデルが組み込まれているため、複数の LWC を作成して管理する必要はありません。ナビゲーションは直線的で、前方に進むアクション、後方に戻るアクション、そしてフォームを後で保存するためのメカニズムがあります。目的に応じて、非線形ナビゲーションを使用するフォームを作成することもできます。

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

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

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

• ユーザーはデスクトップ、モバイル、またはその両方からフォームにアクセスする必要がありますか?

• ユーザーがユーティリティバーを使用してアプリケーションのどこからでもフォームにアクセスできる必要がありますか?

• クイックアクションを有効にして、ユーザーが現在のページから移動せずにフォームに入力できるようにしますか?

• フォームを外部 Web サイトで使用可能にする必要がありますか?

動的フォーム機能にはレコードコンテキストが必要なため、Lightning レコードページでのみサポートされます。ただし、動的フォームは Experience Cloud ページではサポートされません。

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

OmniStudioでは、フローを配置できる_ほとんど_の場所に配置できるコンポーザー可能なFlexCardとOmniScriptを作成できますが、これらはコンポーザー可能ですが、パッケージ化することはできません。

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

LWC コンポーネントは、Lightning-Flow コンポーネントを使用してフローを起動することもできます。

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

現在、このガイドで取り上げているフォーム技術は、Mobile SDK テンプレートでは正式にサポートされていません。Mobile SDK が使用事例に不可欠である場合は、フォーム要素を念頭に置いて、モバイルアプリケーションでネイティブにフォームを作成するか、Visualforce ページを作成することをお勧めします。

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

• バックグラウンドで実行する必要があるアクションまたはロジックは?

• 関連レコードの値を使用する必要がありますか?

• フォームの操作は 1 つのトランザクション内で完了する必要があるか、複数のトランザクションで完了する必要があるか?

• 外部システムと統合する必要がありますか?

• 再利用性とモジュール性の要件は?

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

OmniStudio では、インテグレーション手順とデータマッパーを使用して (Salesforce の外部と内部の両方で) データを取得して変換します。多数のコードフリー関数により、さまざまなレベルのリレーションでデータセットをフラット化および拡張することに長けています。

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

また、アクションをすぐに確定するか、フォームの特定の部分に割り当てるかを検討する必要があります。これは、複数ページのフォームを使用している場合に特に関連します。フローでは、複数のフォーム (フロー画面) からの入力を簡単に結合し、後でウィザード (フロー) で特定の操作を実行できます。これは、まさにフローの設計で推奨される方法です。最後にアクションを実行します (ユーザーが回答を変更するために画面を行き来する場合)。

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

いくつかの例を次に示します。

• ロールバック: フォームのバックグラウンドで複数のレコードを作成するとします。3 番目のレコードの作成に失敗した場合、最初の 2 つのレコードをロールバックする必要がありますか?各アクションが互いに独立している場合は、個別のトランザクションとして実行できます。ただし、相互に連動していて、一方の障害で他方もロールバックする場合は、それらを 1 つのトランザクションとして実装する必要があります。フォームがフロー内にある場合、障害パスのロールバック要素を使用してトランザクションをロールバックし、データの整合性を確保できます。

• ガバナの下流への影響: フォームでレコードを作成または更新するときに、その操作の下流への影響を考慮することが重要です。

  • 提案されたレコード変更に基づいて、保存順序内のどのプロセス、ワークフロールール、フロートリガー、Apexトリガー、またはその他のアイテムが起動されるか？

  • これらの変更全体が、そのトランザクション内でコンシュームされているガバナー制限にどのように影響しますか？

  • 特定のレコードの変更によってダウンストリームの変更が多数発生し、制限に影響する可能性がある場合は、そのレコードの変更をそのトランザクション内で分離することを検討することをお勧めします。

• 一括処理: 複数の更新をまとめて一括処理する必要がある場合があります (UI コンテキスト内であっても)。複数画面フォームで大量のレコードを反復処理するとします。各画面の後にレコードの更新を確定するのではなく、すべてのレコードの更新を収集するまで待ってから、すべてのレコードを更新する 1 つの要求を送信します。

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

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

1. エンドユーザーは画面を操作し、[次へ] をクリックします。

2. クライアントが入力要求を API に投稿します。

3. API が要求を受信し、トランザクションとデータベース接続を開きます。次に、API がフローエンジンをコールして要求を呼び出します。

4. フローエンジンは、画面またはローカルアクションノードに到達するまで、フロー定義の適切なパスを引き継ぎ、辿ります。次に、エンジンはそのノードに関する情報を API に返します。

5. API は、次に表示する画面の詳細を含む応答オブジェクトを作成し、そのオブジェクトをクライアントに返します。この時点で、保存順序の実行に従い、データベースの変更が確定され、データベース接続とトランザクションが閉じられます。

6. クライアントは API 応答を使用して、ユーザーが操作する次の画面を表示します。

7. ステップ 1 から開始し、プロセスを繰り返します。

つまり、画面によってトランザクションが中断されます。この場合、待機中のアクションまたは DML がコミットされ、前のトランザクションがクローズされ、新しいトランザクションが開始されます。 特定の設計要素 (特定のトランザクションにどの操作をグループ化するか) はユーザー次第です。

いくつかの例を次に示します。

• 開始すると、複数の画面で入力を収集し、1 つのトランザクション内で複数のアクションを実行するフローが表示されます。
• 次のフローでは、各操作を個別のトランザクションで実行します。
• フローでは、レコードのロールバックを使用して、一連のデータベース操作で 1 つの操作が失敗した場合にトランザクション全体をロールバックすることもできます。 レコードを作成し、レコードを更新して、追加のレコードを作成するフローがあるとします (次のフローを参照)。

このシナリオでは、最初の 2 つの要素が成功し、最後の 2 つの要素が失敗した場合、最初の 2 つの DML 操作で引き続き適切なレコードが作成および更新されますが、3 つ目の要素は作成および更新されません。 [レコードをロールバック] 要素を使用すると、3 つの操作をすべてまとめて実行する必要がある場合 (最終フローを参照)、トランザクション全体をロールバックできます。

注意: 詳細は、「Flows in Transactions (トランザクションのフロー)」および「Flow Bulkification in Transactions (トランザクションのフローの一括処理)」を参照してください。

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

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

• 各 UI API コールは、独自のトランザクション内で分離されます。

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

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

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

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

その他のすべてのインスタンスでは、フローの HTTP コールアウト機能 (外部サービスを使用) または OmniStudio の HTTP アクションを使用します。

OmniStudio には、インテグレーション手順を使用して外部システムにコールアウトし、データマッパーを使用してデータを変換できる豊富なインテグレーション機能が備わっています。

実装にカスタム Apex コードを使用するか外部サービスを使用するかに関係なく、コールアウトは引き続きコールアウトです。

必要な知識は次のとおりです。

• コールアウトの処理に非常に時間がかかる場合があります。

• コールアウトが同期的に実行される場合は、データベーストランザクションが開いている間に実行されます。

• 待機中のデータベース操作がある場合、Salesforce ではデータベーストランザクションを開いたままにすることはできません。

主な制限は、データの作成、更新、または削除操作を実行してから同じトランザクション内でコールアウトを実行するときに、データが不整合状態のままになる危険性です。このパターンは、上記の 3 番目の考慮事項により許可されません。これは、最初の 2 つの考慮事項により存在します。

フローでは、トランザクションを破棄することでこの制限をスキップできます。画面とローカルアクションにより、ブラウザコンテキストが再び導入されます。外部コールアウトを使用するときは画面とローカルアクションを使用できますが、呼び出し可能な詳細設定でトランザクション制御を有効にすることをお勧めします。トランザクション制御では、コールアウトが実行される前にトランザクションを自動的に終了できます。トランザクション制御を有効にするには、呼び出されたアクションの [詳細] セクションで [常に新規トランザクションを開始] を選択します。 LWC は、コールアウトがトランザクションに及ぼす影響を最小限に抑えるのに役立ちます。つまり、Lightning Data Service(LDS)を使用してデータ操作を実行し、Apexコントローラを使用して外部コールアウトを実行します。LDSコールは(Apexコールアウトとは別に)独自のトランザクション内で分離されるため、結果として生じるデータの不整合から保護されます。

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

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

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

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

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

注： Apex の実行順序をまだ確認していない場合は、確認してブックマークします。

• フォームにシステムレベルの検証以外の追加要件はありますか?

• フォーム内で必須項目または参照のみ項目を動的に設定する必要がありますか?

通常、フロー画面または OmniScript ステップの入力はバインドされていないため、フォーム自体は特定のオブジェクトに関連付けられたシステムレベルの検証にネイティブに準拠しません。ただし、レコードを作成または更新するために使用する値は保存順序で処理されます。つまり、オブジェクトのシステムレベルの検証を通過します。

注： 一部の画面フローコンポーネントでは入力の妥当性検査がサポートされていません。

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

フローでは、フォーム入力の検証を柔軟にカスタマイズできます。複数のチェックがクライアントレベルで実行されます (欠落している必須項目やデータ型のチェック、入力規則内の互換性のある数式へのフラグ付けなど)。セキュリティレベルを強化するために、入力検証もサーバーで評価されます。ユーザーが [次へ] をクリックすると、フローは入力をサーバーに再度送信して検証します。無効な入力が返されると、ナビゲーションがブロックされ、適切なエラーが表示されます。

サーバーは次のチェックを行って入力を検証します。

• 入力の必須設定、または入力された値が基礎となるデータ型と互換性があるかどうか。

• 入力のカスタム検証。Boolean 型の数式と、数式が満たされない場合に表示するエラーメッセージを指定する必要があります。

• 基盤となるコンポーネントのカスタム検証。フローのカスタム LWC を作成する場合、validate() メソッドに独自の検証コードを追加する必要があります。

画面フローのメッセージコンポーネントを使用してアクセス可能なユーザーアラートを提供することもできますが、ユーザーが他のページに移動したり、ガイド付きフローの次のステップに進むことを妨げることはありません。メッセージコンポーネント内の_エラー_状態は、ナビゲーションが無効になっている場合に障害パスを介してトリガーされる専用のエラー画面に最適です。

OmniStudio は、[エラーを設定] アクションと条件付きビューおよびメッセージングコンポーネントの組み合わせにより、堅牢なエラーおよび検証処理を特徴としています。

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

ユーザーがデータを入力する必要がある項目は、フォームの先頭に表示される必要があります。フォームを送信する前に (可能な場合) クライアント側でユーザー入力を検証します。

静的フォームは時代遅れです。現在では、_特定_のタイミングで_特定_のユーザー向けに_特定_の場所で適切なプロパティと値を使用してフォームを動的に更新することに重点が置かれています。Salesforce フォーム作成ツールを使用して何が実現できるかを詳しく見てみましょう。

• フォーム内で動的応答を引き起こすインタラクションや条件の種類は何ですか？

• フォームの入力中に画面外 (バックグラウンド) 操作を実行する必要がありますか?

• フィールドを表示、必須、参照のみ、または無効として設定する必要があるか、フォーム入力に基づいて書式を変更する必要があるか。

Reactive Screensは、Screen Flowのインタラクティブ性を有効にします。リアクティビティを使用すると、フロー画面の個々のコンポーネントが相互に通信できるため、画面フローがより強力になります。

画面外データ操作の実行

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

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

表示

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

• 動的フォームは、レコードフィールド値、参照フィールド、フォームファクターに基づいて表示を制御します。

• フローでは、他の画面入力や、フローの前半で入力された他のリソース (数式や他のレコードの値など) に基づいて表示ルールを設定できます。

  • デバイスベースのルール: 最初から明確ではないかもしれませんが、ユーザーがモバイルデバイスを使用しているときに数式を使用して特定のフィールドを表示または非表示にできます。$User.UIThemeDisplayed グローバル変数の値をチェックするフロー数式を記述します。値が Theme4t の場合、ユーザーは Salesforce モバイルアプリケーションを使用してフォームに入力しています。

  • **Evaluate Other Resources (**その他のリソースを評価): 手動変数および数式参照は、サーバ上でのみ評価されます。つまり、画面が最初に表示されるときのリソースの値は、別の画面に移動するまでの値になります。ナビゲーション中に、フローランタイムはフローエンジン (サーバー) に要求を送信し、最新の手動変数値と数式値を返します。ユーザーが 1 つの画面を通過するときに表示ルールが更新されることが予想される場合 (onblur など)、画面の他のコンポーネントの値のみを参照していることを確認する必要があります。

• OmniStudio では、[条件付きビュー] プロパティを設定することで、コンポーネントを条件付きで表示または非表示にできます。ただし、1 つの入力に複数の [条件付きビュー] プロパティを追加することはできません。

条件付き入力状態

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

他のプロパティを動的に制御する必要がある場合 (フィールドが必須か参照のみかなど)、短期的には LWC を使用します。これは、完全に制御できるためです。これは、onblur や onclick の処理方法に関するカスタム要件がある場合に特に当てはまります。

画面フローの反応型 LWC

画面フローの他のコンポーネントに反応して変更できる LWC を作成する場合は、『画面フローの 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 を作成することを意味します。

システム管理者は、画面コンテナまたは個々のコンポーネントに対して、制限された画面およびコンポーネントのスタイル設定の上書き (色、境界線、ボタンの表示など) を設定できます。これらの上書きはテーマとブランド設定の後に適用されるため、ビルダーはアプリケーションの他の部分に影響を与えることなく対象を絞った視覚的な調整を行うことができます。

スタイル上書きは、ローカライズされた視覚的な例外 (確認画面の強調表示や特定の行動要請 (CTA) の強調など) を目的としており、完全なスタイル設定システムではありません。CSS レベルの制御は提供されず、画面やフローで再利用できるようには設計されていません。

アーキテクチャの観点からは、スタイルは次の先行順序に従う必要があります。

1. テーマおよびブランド設定: Lightning テーマ、エクスペリエンスビルダーのブランドセット、または LWR サイトのテーマ設定

2. フロースタイル上書き: 対象を絞った画面またはコンポーネントの調整

3. カスタムコンポーネント (LWC): ピクセル単位で完璧な制御や再利用可能なデザインパターンが必要な場合

テーマとデザインシステムを使用すると、スタイル設定の一貫性、拡張性、およびメンテナンスの容易さを長期にわたって維持できます。

• 目的のスタイルと CSS はどの程度洗練されていますか?

• ピクセル単位で完璧なカスタムスタイルや標準テーマが必要ですか?

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

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

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

• フローと LWC は標準設計トークンを継承します。

• OmniScriptとFlexCardには、Newportを使用したカスタマイズ可能な設計システムのサポートが含まれます。

• LWC では、独自のコンポーネントを記述して、その HTML と CSS を完全に制御できます。

可能な場合は、テーマとデザインシステムを使用して、すべてのコンテンツでデザインの一貫性を確保することをお勧めします。

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

迅速かつ効率的なデータ入力を可能にし、データの整合性を高める合理化されたフォームを設計するには、適切なレイアウトを選択することが不可欠です。

• フォームレイアウトを構造化してユーザーエクスペリエンスを最適化する方法は?

• フォームに新しいデータを簡単に入力できるように、既存のデータをユーザーに表示する方法は?

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

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

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

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

異なる地域のユーザーや異なる言語を話すユーザーがフォームにアクセスできる必要がある場合、フォームの作成に使用するツールがローカライズ要件を満たしていることを確認する必要があります。

注意: 特にフォームの場合、ローカライズの要件として、通常、テキスト要素を他の言語に翻訳する必要があります。

• フォームを複数の国または地域で使用しますか?

• フォームのテキストを他の言語にローカライズする必要がありますか?

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

フローでは、トランスレーションワークベンチを介して、すべての標準およびカスタム画面コンポーネントのユーザー向けラベルの翻訳がサポートされます。

次の画面コンポーネントでは、表示ラベル、ヘルプテキスト、エラーメッセージをローカライズできます。

• テキスト
• ロングテキストエリア
• 数値
• 通貨
• チェックボックス
• ラジオボタン
• 選択リスト
• 複数選択リスト
• チェックボックスグループのパスワード
• 日付
• 日付/時間

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

OmniScriptでは、翻訳にカスタムラベルが使用されます。詳細については、このヘルプドキュメントを参照して、OmniScript が多言語に対応していることを確認してください。

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

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

このセクションを使用して、実装前にセキュリティ、品質、運用上の制約を評価します。

セキュリティは複雑なトピックであり、フォームの作成に関しては、明確ではない考慮事項がいくつかあります。基礎レベルでは、フォームが正しいコンテキストで実行され、基礎となるデータを操作するために必要な権限がユーザーに付与されていることを確認する必要があります。さらに、リッチテキスト項目から潜在的に悪意のあるコードや URL を削除したり、特定のユーザーがフォームにアクセスできないようにしたり、システム管理者が将来フォームを埋め込むことができる場所の種別を制限したりするための追加措置を講じる必要もあります。

ツールを選択する前に、セキュリティ要件を十分に文書化してください。この種別のドキュメントに関するその他の指針については、「Salesforce Well-Architected Security Policy Template (Salesforce の適切に構築されたセキュリティポリシーテンプレート)」を参照してください。

• 特定の操作を実行する前にフォームでユーザーのアクセス権を確認する必要がありますか?

• ユーザー入力をサニタイズする必要がありますか?

• フォームにアクセスできるユーザーを制御しますか?

• フォームを埋め込む場所を制御しますか?

プログラムをユーザーコンテキストで実行すると、Salesforce は一連のアクセスチェックを適用します。これには、項目レベルセキュリティ、CRUD 権限、および組織の共有ルールに基づくレコードアクセス権の検証が含まれます (たとえば、ユーザーがケースの更新フォームを実行できるのは、ケースを更新する権限、適切な項目レベルセキュリティ、該当のレコードへのアクセス権がある場合のみです)。

ユーザーがフォームを使用しているときに特定の操作を実行できるようにし、他のフォームやインタラクションからは実行できないようにする場合はどうすればよいでしょうか?ここでシステム コンテキストの出番です。

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

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

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

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

• システム コンテキストで実行されるフロー内に Lightning コンポーネントを埋め込む場合、そのフローでコンポーネントのコンテキストが上書きされることはありません。ユーザー アクセス チェックをスキップする必要がある場合は、フローを使用してこれらの操作を実行し、Lightning コンポーネントに適切なデータを渡します。一部の標準コンポーネント（たとえば、ルックアップ）は、システムコンテキスト内で動作できません。

• フローが Apex アクションを呼び出す場合、その他の注意点があります。

  • Apex クラスが_継承共有_に設定されている場合、フローの設定方法に関係なく、共有のシステム コンテキストで実行されます。

  • クラスに明示的な共有宣言がない場合、フローの設定方法に関係なく、共有なしでシステムコンテキストで実行されます。

  • クラスが_共有ありまたは_共有なしに設定されている場合、フローのコンテキストが上書きされます。

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

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

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

入力のサニタイズ

悪意のあるユーザーから組織を保護するには、入力のサニタイズを使用します。公開されているフォームに入力があり、それを組織内のリッチテキストフィールドにマッピングできるとします。悪意のある URL を隠す可能性のある HTML を削除する自動化を有効にすることを検討してください。

フォームレベルでサニタイズを実装することは理想的ではありません。これらの項目に書き込むソースがいくつもある可能性があるためです。この問題に対処するには、高速項目更新フロー（保存前）を作成するか、既存の Apex トリガーを使用してフォーム内に入力される可能性のある HTML を削除または変更します。

• フローをデフォルトのコンテキストで実行できるようにします (特定の操作で現在のユーザーのアクセス権を昇格させる必要がない限り)。

• ゲストユーザーのシステムコンテキストでのフローの実行は避けてください。項目アクセス権が制限されている権限セットを作成し、Experience Cloud ゲストユーザーのプロファイルに割り当てます。

• Experience Cloud サイトのシステムコンテキスト実行フローでレコードを照会する場合、必要なフィールドのみを [レコードを取得] 要素または呼び出し可能アクションに保存します。

• フローでさまざまな操作 (すべて昇格アクセス権を必要としない) を実行する場合、サブフローを使用してシステムコンテキスト内で実行する操作を分離します。

• 外部 Web ページ内にフォームを埋め込む場合、潜在的なフィッシング攻撃を防ぐために、フォームをリッチテキスト項目に対応付ける必要がある場合があります。これを行うには、高速項目更新フローまたは Apex トリガーを使用して、HTML を削除するようにユーザー入力をサニタイズします。

• OmniScript、FlexCard、LWCs は、デフォルトでユーザー コンテキストで実行されます。

• LWC はデフォルトでユーザーコンテキストで実行されます。

• フローはユーザ コンテキストで実行されますが、Apex コントローラを使用して上書きできます。

• UI API 内で実行される操作は、ユーザーコンテキストで実行されます。

• Apex コントローラを使用して実行される操作は、特定のクラスによって異なります。これらの操作をシステム モードで実行するには、Apex クラスを共有ありまたは共有なしに設定します。

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

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

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

注意： Apex クラスの権限チェックは、Apex クラスにのみ適用されます。また、インテグレーション手順およびData Mapperにプロファイルレベルの権限を設定することをお勧めします。

• フローをゲストユーザーに公開する場合は、ゲストユーザーが絶対に必要とするフローへのアクセス権をゲストユーザープロファイルにのみ付与してください。「フローを実行」をゲストユーザープロファイルに追加できますが、この方法はリスクが伴います。

• システムコンテキストで動作するフローを操作するときは注意してください。これらのフローは、データを保護するための抑制と均衡が少ないため、特定のユーザーセットに制限する必要があります。

• ゲスト・ユーザー・コミュニティ内でApexを実行するOmniScriptに、Apexクラス定義にリストされている共有が含まれていることを確認します。

• ゲスト・ユーザー・プロファイルの場合は、ゲスト・ユーザーにコールを許可するApexクラスのみを割り当てます。この慣行に従うことで、意図せずに追加のビジネスロジックがゲストユーザーに公開されるのを防ぐことができます。

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

LWC は、有効なターゲットとして追加された後にのみ、特定のロケーションで使用できます（たとえば、コンポーネントをレコードページで使用可能にしたり、ユーティリティバー項目として使用不可にしたりできます）。

画面フローを有効にすると、画面フローがサポートされているすべての場所で使用できるようになります。Flow Builder では、画面を含む複数の種類のフローがサポートされます。最も顕著な種類は画面フローですが、特定の場所に制限された特殊な種類もいくつかあります (Field Service Mobile アプリケーションでは Field Service Mobile フローのみがサポートされます)。これは、Experience Cloud でのみサポートされる連絡要求フローに似ています。

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

Salesforce Industries を使用している場合、OmniScript には若干の注意事項があります。OmniScript の対象は指定できませんが、埋め込む FlexCard の対象は指定できます。

Salesforce には、ユーザーがフォームを操作する方法をシミュレーションできるエンドツーエンドのテスト自動化ツール (Salesforce UTAM など) がいくつかあります。Lightning ページや画面フローなど、任意の標準またはカスタム UI のテストを作成できます。

注意: この種類のテストでは、実行中のメソッドの出力を検証できません。UI テストの自動化要件を設定するときは、次の点に留意してください。

• フォームの自動テストが必要ですか?

• どのような種類のテストを実行する予定ですか?

• テストのオートメーションに必要な粒度は？

UI テストの自動化要件の考慮

単体テストでは、業界標準のCI/CDシステムおよびツールに準拠した詳細な自動化と検証が提供されます。このツールでは、ビジネス ロジック、JavaScriptコントロール、特定のコンポーネントの出力をテストします。ローコードアプローチを選択した場合、自らテストを作成することはできませんが、Salesforceはすべてのエンドツーエンドのオファリングを厳密にテストしています。

コンポーネントのメソッドが複雑な場合、メソッドを専用の JavaScript ファイルに配置することで個別にテキスト送信できます。これにより、LWC にインポートし、さらに **Jest テスト (たとえば、**import { sort } from 'c/utils';) に取り込むことができます。

ISV のノーコードソリューションを使用するか、カスタムテスト自動化ソリューションを構築するか、オープンソースのテストフレームワーク (Selenium WebDriver や WebdriverIO など) を使用してエンドツーエンドの自動化を行うことができます。これらのソリューションは、すべての Salesforce UI インタラクション (Lightning ページの動的フォーム、ユーティリティバーの画面フロー、クイックアクションフローの LWC など) で有効です。

フォームを本番環境にリリースしたら、フォームが効果的に使用されていることを確認する必要があります。使用事例によっては、平均的なユーザーが情報を送信する前にフォームに入力していた時間まで、フォームに入力されている回数を追跡する必要がある場合があります。ツールを選択する前に追跡可能な KPI を特定することが重要です。

• フォームの利用状況を追跡する必要がありますか?

• フォームが有効に使用されているかどうかを判断できる KPI は?

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

動的フォームは標準では追跡できませんが、Lightning 利用状況オブジェクトを使用して親 Lightning ページの利用状況を追跡できます。標準Lightningページをトラッキングするには、Users with Lightning Usage by Page Metricsカスタムレポートを使用します。カスタム Lightning ページの場合は、FlexiPage Metrics による Users with Lightning Usage カスタム レポートを使用します。

フローは、特定のフォームの採用を追跡するのに役立ちます。サンプルフローレポート: 画面フローを使用して、次の種別の質問に回答します。

• このフォームの完了率は?現在、適切に採用されていますか?

• ユーザーがこのフォームを完了するまでにどのくらいの時間がかかりますか？

• ユーザーが最も長い時間をかけて完了する画面はどれですか？

• ユーザーはどのくらいの頻度で前の画面に戻りますか？

• エラーが発生する頻度は?

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

パッケージベースの OmniScript ランタイムを使用している場合は、OmniStudio for Vlocity Tracking Service も使用できます。このサービスでは、すべての種別のイベントを追跡します (たとえば、OmniScript のステップの完了に要する時間を追跡できるため、プロセスの改善点を特定するのに役立ちます)。

注意: 画面フロー、OmniScript、または Lightning ページに埋め込まれていない LWC を追跡する標準オプションはありませんが、Apex を使用してカスタムソリューションを作成できます。

変更セットやDevOpsセンターを使用してソリューションをテスト環境または本番にリリースすることはよくご存知の方もいらっしゃるでしょう。これらのリリースオプションでは、動的フォーム、フロー、LWC が完全にサポートされています。ただし、OmniStudio には別個のツールである IDX ワークベンチが必要です。

• フォームをどのようにリリースする予定ですか?

• フォームは複数の Salesforce 組織に配布する必要がありますか?

ソリューションをパッケージ化して AppExchange で配布する予定の ISV またはパートナーの場合は、「動的フォーム、フロー、および LWC」を参照してください。OmniStudio ではパッケージ化はサポートされていません。

このガイドは、動的フォーム、画面フロー、OmniStudio、LWC で使用可能な機能とカスタマイズレベルを示すことを目的としています。 概要を次に示します。

• フォームの作成に関しては、LWC が最も堅牢でカスタマイズ可能なオプションですが、配置されているガードレールの数が最も少なくなります。そのため、セキュリティと拡張性を念頭に置いてコンポーネントを構築することが重要です。

• 動的フォームは最も柔軟性の低いオプションですが、踏み間違いの可能性ははるかに低くなります。

• フローと OmniStudio は少し中間にあります。動的フォームよりも強力ですが、LWC レベルにはまだ達していません。ただし、動的フォームよりもガードレールの数が少なく、カスタムコードよりも破るのが困難です。

複数のツールがニーズに適している場合があります。その場合、最終的にどのツールがチームにとって最適かによって判断が変わります。考慮すべきその他の側面についての詳細は、次のアーキテクト決定ガイドを参照してください。

• ツールを比較する場合、各ツールに関するチームの専門知識を評価することが重要ですか?
• LWC または JavaScript に精通している開発者の数は?
• Flow Builder のエキスパートである開発者や、詳細について興味を示した開発者がチームにいますか?

具体的な詳細は説明しませんが、これらの特定のツールがこれまでに説明した評価にどのように関連するかについてもう少し詳しく説明します。

デリバリー委任

一部の要件で LWC が要求されていても、LWC を使用してソリューション全体を構築する必要はありません。ソリューションをモジュール形式で構築する方法を判断することが重要です。そのためには、コード化された LWC が必要な部品と不要な部品を識別する必要があります。LWC を必要としない部分は、ローコードソリューションを使用して構築する必要があります。

フローと LWC には、さまざまなコンポーネント (反応型画面コンポーネントや画面フローなど) があり、同じ画面で相互に同期して、アーキテクト、システム管理者、開発者向けの新しいツールを利用できます。開発者は、組織全体で再利用できる明確な目的のモジュールコンポーネントを作成できるようになったため、チームの生産性が向上します。これにより、開発者は標準フローコンポーネントとカスタムフローコンポーネントを組み合わせてフォームのダイナミズムを実現することで時間を節約し、新しい課題の解決により多くの時間を費やすことができます。フローでのリアクティブコンポーネントの導入により、フォームの作成時にフローと LWC を混在させるのにこれほど適切なタイミングはありません。

長期オーナーシップと保守性

複数ステップのフォームを作成する場合は、フロー、またはフローと LWC の組み合わせから開始します。フォームを管理しているチームがローコードチームの場合、ソリューションを対象利用者に合わせて可能な限り設定および拡張できるようにします。安定性とメンテナンス性を向上させるには、どのツールを選択しても、ソリューションを構成可能な単位にまとめることが重要です。

動的フォーム、画面フロー、OmniStudio、または LWC に関連するパフォーマンスの考慮事項は、テクノロジーが収容されているフレームワークに基づきます。LWC に基づく技術は、Aura に基づく技術よりも優れている傾向にあります。LWC は、フレームワークの抽象化を介した JavaScript ではなく、Web エンジンでネイティブに実装されるいくつかのコア機能によって、パフォーマンスが向上しています。

では、Salesforce のフォームテクノロジーでこれらのパフォーマンス上のメリットを活用するにはどうすればよいでしょうか?詳しく見てみましょう。

• 動的フォーム (Lightning ページメタデータ内に統合) は、LWC スタック基盤上に構築されており、これにより、長らく待ち望まれていた複数の機能を実装できます。動的フォームでは、パフォーマンスのさらなる向上として、多数の項目が含まれるページの読み込み時間を短縮する順次表示を使用します。

• 画面フローは LWC に基づいて構築されています。ファイルアップロードコンポーネントと画像コンポーネントを除き、個々の標準コンポーネントのほとんどは LWC に変換されました。フローチームはフローランタイムクライアントを LWC (およびそのほとんどのコンポーネント) に変換していますが、顧客は Aura 画面コンポーネントを LWC に変換する必要があります。Salesforce では、画面フローの反応型コンポーネントフレームワーク内の LWC コンポーネントのみがサポートされます。詳細については、「Lightning Web Components for Aura Developer」 Trailhead モジュールを参照してください。画面フロー（またはその他のコンテナ）のカスタムコンポーネント作成を検討している場合は、LWC! を選択してください。

• 使用可能な OmniStudio にはいくつかのバージョンがあります。長年の顧客の場合、Angular を使用している可能性があります。すべての新規ユーザーは、LWC ベースの OmniScript と FlexCard を使用することをお勧めします。また、既存のお客様には Angular からの移行も推奨しています。

• LWC は LWC を基盤としています。