"Map a Value" for Flow

上記の和訳です。

マップは、Apex 開発者にとって馴染みのあるデータ構造ですが、Flow にもメリットがあります。それらは、多くの分岐があるいくつかの決定ノードを単一のノードに置き換えることができます。

このシナリオは多くの場所で発生します。たとえば、使用する電子メールテンプレートが選択リストフィールドの値に基づいている電子メールを送信します。または、フィールドの値に基づいてレコードの所有権を割り当てます。

ブログのフロー内のマップも参照してください。

簡単な例: Type からの Account Record Type

実証するために、タイプ (取引先の標準選択リスト項目) に基づいて取引先のレコードの種類を設定するおもちゃの例を使用します

決定ノードの使用
まず、決定ノードを使用した従来のアプローチ:

ご想像のとおり、このフローはType決定ノードをチェックインし、対応するアカウントレコードタイプの開発者名を変数に割り当てます。次に、レコードタイプ ID を照会し、それをアカウントに割り当てます。

マップノードの使用

それは問題ありませんが、Map を使用して簡略化できます。

Typeこのバージョンでは、からRecord Type Developer Name へのマッピングは1 つのステップです。その魔法の「Map a Value」ノードの構成を見てみましょう。

構成には次の 2 つが必要です。

入力変数の名前
マッピングデータのテーブル
次に、マッピングされたデータを出力します。シンプルで効果的！

別の方法: カスタムメタデータタイプ

Get Records で Flow の効率的なクエリを利用して、カスタムメタデータレコードにマッピングテーブルを保存することもできます。これにはフローでさらにいくつかのノードが必要ですが、カスタムコードは必要ありません。また、フローからマッピングを外部化するため、フローを開かなくてもマッピングを変更できます。

カスタムメタデータルックアップテーブル

ルックアップテーブルのカスタムメタデータタイプを定義できます (マップが何をするかを調べる別の方法)。次に、そのテーブルの行を記録する別の型を使用できます。例でこれがどのように機能するかを簡単に確認できます。

複数のフローでこのアプローチを採用した場合にキーの衝突が発生しないように、このレコードの 2 層セットアップがあると便利です。たとえば、2 つのフローが「重要」キーに関心がある場合、それらが分類されないようにするために、異なるルックテーブルレコードに格納されます。

カスタムメタデータルックアップフロー

ここでは、マッピングを行うために 2 つのクエリが必要です。まず、ルックアップテーブルの ID を取得します (現在、親の名前に基づいて行をクエリすることはできません)。Type次に、ルックアップテーブルの行をクエリして、Account をレコードタイプ DeveloperName にマップします。フローの残りの部分は他のフローと同じで、レコードタイプ ID をロードして割り当てます。

評価

カスタムメタデータを使用すると、「値をマップする」アクションでマッピングするよりも設定に手間がかかります。ただし、構成をフローの外に持ち出すと、状況によっては役立つ場合があります。

フローの例

これらの手法を使用したフローの例は、例で見つけることができます。

インストール

「値のマッピング」アクションはパッケージではなく、単なる Apex クラス、設定用の LWC、および Apex テストです。したがって、次のディレクトリにあるファイルを組織にコピーします。

同様に、カスタムメタデータソリューションは、cmdtFlowMap ディレクトリにある個々のファイルとしてインストールすることもできます。

呼び出し可能なメソッド: フローと Apex の間でデータを送信する方法

Apex の呼び出し可能なメソッドは常に List を受け取り、戻り値の型が null でない限り、List を返します。詳しくは、こちらの「インプットとアウトプット」をご覧ください。