前回のエントリの続きとなります。
お問い合わせアプリ（拡張版）利用の流れは以下のようになります。
- ユーザーが問い合わせる
- 問合せリストに入る
- 担当者がAcceptする
- 調査してログ（コメント）を記入する
- ユーザーは内容を確認する
- 問題なければクローズ または さらにコメントを追加する
ここでのポイントはユーザーと担当者が何回かやり取りをするということです。これを実現するためにはいくつかの方法がありますが、ここでは以下のように「お問い合わせ」（お問い合わせの各情報を格納するテーブル）と「お問い合わせ詳細」（ログを格納するテーブル）を分けることにしました。
このうちカテゴリID（何についてのお問い合わせ？）とステータス(新規？対応中？完了）については選択肢列として設定します。ユーザーと担当者は個人列にします(AzureADからデータを持ってくる）。
従って、必要なテーブルは上記の2つのみとなります。
さて、「お問い合わせ」は１つのお問い合わせごとにレコードが一つです。一方で、「お問い合わせ詳細」は、対応の過程で以下のように複数できるでしょう。
ぱっと見た限りでは両方のテーブルに「お問い合わせID」があれば両テーブルを関連付けることはできそうです。
もちろんそれで問題ありません。例えばSharePointのリストで同じようなアプリを作るのであればそうするべきでしょう。
例）あるお問い合わせを選択する→選択したお問い合わせのログをすべて抽出したい場合
Filterで「お問い合わせ詳細」テーブルの中からお問い合わせIDが一致するものを抽出する。通し番号or日付で並び替え
しかし、Dataverseには便利な機能があります。それがリレーションです。
リレーションを設定しておけば参照元テーブルから参照先テーブルにある値を簡単に参照することができます。
Teams から Power Apps を起動し、「テーブル」→「参照元テーブル名」→「リレーションシップ」を開き、リレーションシップの追加から「多対１」を選択します。
参照先のテーブルを選択します。
設定はこれで完了です。どのように参照できるのか確認してみましょう。
新規アプリを作成し、垂直ギャラリーを追加します。データソースを参照元（ここではお問い合わせ詳細）にします。
フィルタなどは設定していないので「すべてのお問い合わせ詳細（ログ）を表示する」というギャラリーになります。
このギャラリーのラベルを以下のように設定すると「お問い合わせ詳細」には入っていないタイトル列が表示できます。
ThisItem.お問い合わせ.タイトル
自動的に「結合」処理をしてくれるというわけです。
ちなみに、いずれかのレコードが削除された場合どうなるのでしょう。
たとえば「お問い合わせ」テーブルのあるレコードを削除した場合、それに関連づいている「お問い合わせ詳細」はどうなるか？
・そもそも「お問い合わせ詳細」にログ（レコード）がある「お問い合わせ」は削除できない
・そのお問い合わせ自体が不要になったものと判断して、関連している「お問い合わせ詳細」のログ（レコード）をすべて消す
・お問い合わせのレコードは削除していいけど、何らかの形で参照したいのでお問い合わせ詳細のレコードは残す
上記のいずれも設定で可能です。（上記スクリーンショットの詳細オプションで設定）
リレーションを使いこなすためにはある程度データベース理論の知識が必要ですが、使ってみると便利ですのでぜひ試してみていただければと思います。