Power Apps で SharePoint リストの参照列にデータを新規登録するときにハマりやすいポイントと応用パターン

序

Power Apps で複数品目をまとめて申請し、Power Automate（クラウドフロー）で承認フローを回したい...という要件などがあった場合、方法は色々あると思いますが、すぐに思い付くのはリストを「承認フロー用」と「品目登録用」の２枚に分ける運用です。

その際、データの整合性を保つために SharePoint リストの「参照列」を活用したい場面が訪れるはずです（もちろん、Power Apps での運用がベースにある場合は無理に参照列を使う必要はないと思いますが、万が一を考えて、SharePoint リストで業務を回せる状態にしておくと安心かもしれません）

1. ハマったポイント

今回ハマってしまったのは、承認フロー側のリストに振っている ID（数値型 / 既定では非表示）を、品目データ側の依頼ID列（参照列）に登録しようと試みたものの、思い通りの結果に至らなかった点です。

具体的には、上に付した画像のように Power Apps 側ではデータ入力時に採番できているにもかかわらず、下記画像のように参照列にリストの ID が振られていないような症状がありました（※表面上では見えていなくても裏側では採番されている可能性もあるので要注意です）

また、この症状が発生する前には、そもそも ForAll 関数と Patch 関数を設定している時にエラーが発生してしまったり、ようやく登録ができたかと思えば今度は、正となるリスト側の別のデータ行（ID）を参照していたり…と、少々ハマってしまいました。

なお、SharePoint リストの参照列そのものを自動採番する方法はありません。文字通り「参照」とあるように、親リストに存在しないデータを取得することができないためです。リストにおいて「既定では非表示となっている ID 行」を上手く利用しながらリストの参照列へデータを渡していく流れを覚えておくとよいでしょう。

2. 解決策

2.1. 参照列の構造と登録に必要なデータについて

参照列の構造や登録に必要なデータについては、以下の記事に詳しかったです。重要なのは、参照列が単純な数値型データや文字列型データではなく、レコード型のデータが保存されている点だと思います。

レコード型というのは、複数の項目をひとまとまりで持っているデータのことを指します。例えば、ID、品目名、申請者、日付…のような値を１セットで有している「データ１行分」と理解しておくとよいでしょう。

Power Apps の「コレクション（colTestData）」に、参照列やユーザー列を含む SharePoint リストを格納した際、格子状アイコンが確認できると思いますが、これがレコード型を合図しています。

展開してみると、まるでリストの中にもう１つリストが入っているかのような姿をしていることが分かります。したがって、登録時は Id と Value 双方のデータを意識しておく必要があります。

• Id：参照先の行 ID（SharePoint リストの ID 列）
• Value：参照先のアイテムそのもの（参照先として設定した列の値）

SharePoint リストを確認してみると、正のリスト側と一致していることが分かります。構造としては「ID：24」のデータの中から「依頼ID：1」を表示していると整理できます。まずはこの２点を押さえておきましょう。

2.2. フォームコントロールでの実装の場合

参照列を含んだ SharePoint リストにデータ登録するアプリを作成する際、複雑な数式を必要としないフォームコントロールを使用することがあると思います。

この時、参照列は「選択肢」と同じ扱いを受けるため「テキスト入力」ではなく「コンボボックス」が配置されます。こういったコンボボックスの既定値を設定する場合、Default プロパティではなく、DefaultSelectedItem プロパティを使用します。

{Value: 既定値として表示したい値}

基本的には、DefaultSelectedItem プロパティには上のように「レコード型」を入れるように設定することで規定値が表示されるようになります。しかし、データは上手く登録されません。

参照列へのデータ登録の際は次のように設定されていなければならないため要注意です。

{
	'@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference",
	Id: 参照先の行 ID（SharePoint リストの ID 列）,
	Value: 参照先のアイテムそのもの（参照先として設定した列の値）
}

仮に、2.1. で示した「ID：24、依頼ID：1」を取得する場合は次のような数式を設定すると良いでしょう （※この数式は委任やデータ競合といった懸念要素を抜きに考えています）

{
	'@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference",
	Id: First(データソース).ID,
	Value: First(データソース).依頼ID
}

参照先データソースの内、１件目が該当しているためコンボボックスには１が設定されるようになり、これによってデータ登録も行われるようになります。

…最後に登録したデータは NG 例ではなく OK 例でした。

2.3. ForAll + Patch での実装の場合

基本的な ForAll + Patch での一括登録フォームの作成については次の記事に詳しいです。真似しながら実装してみるとよいかと思います。

基本的な ForAll 関数 + Patch 関数の処理は次のような内容となっています。データ型の他にも、2.2. で示したように、参照列の構造にも意識を働かせなければならない点に注意です。これさえ押さえておけば後は応用でなんとかなります。

ForAll(
    コレクション名,
    Patch(
        参照列を含むリスト名,
        Defaults(参照列を含むリスト名),
        {
            参照列: {
                      '@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference",
                    　 Id: 参照先の行 ID（SharePoint リストの ID 列）,
                       Value: 参照先のアイテムそのもの（参照先として設定した列の値）
                    },
            タイトル: ThisRecord.タイトル,
            品目名: ThisRecord.品目名
        }
    )
)

3. 承認フローへの連携

以上の内容を応用すると、依頼単位で承認フローを回すアプリを作成できるようになります。Power Platform を触り始めたばかりの方々にとっては少々高難度だと思いますが、承認申請（依頼ID）を参照先のリストに設定し、品目単位で管理する側にデータを紐付けておくことで、承認伺いと品目管理の両立を実現できます。

結

複数明細を扱う要件に出会ったときは、まず「どう入力するか」ではなく「何を１件の依頼として扱うか」から出発するのが良いと考えます。

例えば、今回の記事のように、明細保存用と承認起動用のリストを分け、承認を依頼単位の方へ寄せる構成にしておくと、フローをかなり素直に保ちやすくなります（さらに、フォームコントロールだと添付ファイルの登録が容易である点も魅力です）

筆者の技量不足は棚に上げておき、Power Apps による SharePoint リストへのデータ登録は、データ型や既定値の扱いでハマってしまうことが多々あるように感じます。本記事が、同様の実装で悩まれている方の整理材料や実装時のヒントになれば幸いです。

SharePoint リスト（の参照列）は、容量と用法をお守りください。あまりにも運用が複雑化したりデータ量が膨大化したりする場合は Microsoft Dataverse をご利用ください（参考記事）