Power Automate Dataverseコネクタ その② 検索列（参照列）のフィルター指定

はじめに

今回Power Apps Advent Calendar2023が空いていたためアプリ側へ本記事を連携しました。
フローでのDataverse操作はモデル駆動型アプリやキャンバスアプリ→フロー連携でも出てきますし、
Dataverse for Teamsの場合も同様なのでアプリと関連は深いですね。ということで。

先日、Power Automate Advent Calendar 2023 12月10日担当分の記事でDataverseコネクタはいいよ！
という記事を書きました。
今回はその中で少しクセがありつまづきポイントだなーと思う検索列（参照列）でのフィルターの書き方について記事にしました。

Dataverseコネクタのトリガー、アクションの概要は上記で書いた記事をご参考ください。

TIPSDataverseコネクタはDataverse for Teamsでも基本同様の内容となりますので、
そちらの実装の場合の参考ともなるかと思います。

検索列について

検索列は参照列ともよく言ってしまいますが（個人的に）日本語の記載は検索列となっていますね。英語だとLookup列です。
こちらはDataverseで１：Nのリレーションを設定した際にN側に出来る列です。

代表的には既定で出来る所有者列だったり修正者列であったりです。
今回のサンプルでは見積テーブルと1：Nのリレーションとしている明細テーブルの
明細テーブル側に見積テーブルへの検索列（参照）が出来るイメージです。

TIPS検索列は参照している側に検索列を作成またはN:1のリレーションを組むと作成されます。
参照されている側（１側）は対象が複数あるのでこの列はないです。代わりにサブグリッドで複数行を表示するイメージです
また、N：Nのリレーションの場合はどちらにもこの列はありません。（システムが裏に関連テーブルを用意してそこで管理している）

リレーションシップの説明については今回の記事では割愛していますので、他の有識者の記事や公式記事をご参考ください。

以下先日デモで作った構成ですが、見積と明細が1：Nの関係です。この際に明細側に見積テーブルの検索列が出来ます。
※他のリレーションも同様ですが今回の記事では割愛

明細テーブルのリレーションシップ
明細テーブル（自分）と見積テーブルでN：１の関係

明細テーブルの検索列
見積テーブルを参照する検索列として「見積」列がある（名前は任意に変更可能）

フォーム上の検索列
以下のようになっています。選択時に表示される項目はそのテーブルのプライマリ列で固定です。

テーブルのレコードを一意に指定する際の列（一意識別子：GUID）

本題の前に、Dataverseのテーブルにはレコードを一意に指定するためにデフォルトで作成される一意識別子列があります。
GUID列とも言います。

テーブルを作成した際にシステムが自動でその列を作成します。表示名はテーブル名と同じ（変更は可能）、
内部名（スキーマ名）はテーブル名＋id となっています。

Automateでレコードを一意に指定する際は、基本このGUID列を使用します。
また、基本的にはスキーマ名ではなく論理名を使います。（スキーマ名は大文字も対応するが論理名は小文字のみ）

この辺の指定方法は以降で説明します。

テーブルのデータを見ると以下のように見積列にはGUID形式の値が入っています。
レコードを一意に指定する際はこの値を使うイメージです。

一意識別子列でレコードを指定して取得の例

見積テーブルから以下のレコードのみ取得するにはこの値を指定すればOKです。
動的に指定する場合（こちらが主）はそのテーブルと同じ名前の一意識別子列を指定すればこの値となります。

対象：インポートテスト見積２　見積列の値：9e338893-028c-ee11-8179-00224862713b

実行すると以下のようにレコードが取得できます。

検索列でのフィルタークエリの書き方（NG例）

本題ですが、フローでこのGUID列を指定してフィルター取得する場合にこの列名と値をそのまま書いてもうまくいきません。
結論からいうと、_<列の論理名>_value　としないといけません。

以下、明細テーブルから同じ見積テーブルを参照するレコードのみ抽出する際を例にします。
※明細テーブルには同じ見積レコードを参照しているレコードが複数あり、その分だけ取得するイメージです。

アクションは「行を一覧にする」を使用します。
この行のフィルター部分にFilter Queryというのを書いてフィルターします。

TIPS※Filter Queryの書き方の説明は割愛していますので、以下などの参考記事をご参考ください。
すべての Power Automate (MS Flow) フィルター クエリ – Power Platform コミュニティ (microsoft.com)

ためしに明細列の検索列（見積列を参照）の論理名（new_mitsumori）を指定してみます。

上記だとエラーになります。翻訳すると型が違うと言っていますね。

エラーの翻訳互換性のない型の二項演算子が検出されました。演算子の種類 ‘Equal’ のオペランド型 ‘Microsoft.Dynamics.CRM.new_mitsumori’ と ‘Edm.Guid’ が見つかりました。

取得される結果を確認する

一旦フィルターを外して取得した結果を確認してみます。
結果を見ると以下のように「new_mitsumori」はなく、new_mitsumoriを含む5つの列が見つかります。

Codenew_mitsumori列自体は取れずに以下の5つの情報が取れる
・ラベル（プライマリ列の値）
“_new_mitsumori_value@OData.Community.Display.V1.FormattedValue”: “YOUSEI-001046”,
・リレーションのプロパティ？（関連テーブル名）
“_new_mitsumori_value@Microsoft.Dynamics.CRM.associatednavigationproperty”: “new_mitsumori”,
・検索列名（関連テーブル名）
“_new_mitsumori_value@Microsoft.Dynamics.CRM.lookuplogicalname”: “new_mitsumori”,
・値のデータ形式（GUID型で固定）
“_new_mitsumori_value@odata.type”: “#Guid”,
・値（GUID値）
“_new_mitsumori_value“: “69139309-5575-4d56-85b0-672a55806f7c”,

上記の通り、検索列はシンプルなテキスト列のようなものではなく、構造化したデータなので
上記のようにそれぞれの情報が取れるようになっています。

この中でGUID値がある「_new_mitsumori_value」を使用する必要があります。

TIPS形式としては元の検索列の論理名の先頭に「_」が付き、末尾に「_value」が付きます。
この法則を覚えておけば毎回結果を取らないで済みます！
※GUID値以外の情報はその後に「＠～～～」となっています。このうちラベルは用途によっては使えるかと。

検索列でのフィルタークエリの書き方

上記を踏まえて「_new_mitsumori_value」をフィルターへ指定してみます。
取得結果がわかるように選択アクションも使っています。

Code_new_mitsumori_value eq 9e338893-028c-ee11-8179-00224862713b

実行すると以下のように同じ見積レコード（同じGUID値）の明細レコードのみが取得出来ています。

上記サンプルでは固定値でやっていますが、本来は動的な値を指定するイメージです。
この場合は見積テーブルの一意識別子の見積列ですね。

既定の所有者列で指定なども同様

以下のように所有者列（ownerid）や作成者列（createdby）もおんなじですね。

TIPS法則は「_<列の論理名>_value」です。

おわりに

今回はテーブルの一意識別子列（GUID列）を指定してフィルターする際の書き方でした。
初見ではまずつまづきますよね💦　今回ご紹介した法則を抑えておけば大丈夫です。

フィルタークエリでいうと他にも選択肢列のフィルターの場合もコツがあるのでまたご紹介しようと思います。
また、レコードの作成や更新時に参照列を指定する方法もひとクセあるのでこちらもご紹介予定です。
それでは！

関連

モデル駆動型のカスタマイズ（カスタムページ・コマンドバー）で登壇しました。

Dataverse 関連：