アプリ開発の調査にかかる
時間を削減したい
内製化支援サービス
アプリを自分たちで
作成できるようになりたい
DX人材育成プログラム
プロに開発を依頼したい
アプリ開発導入支援サービス
SharePoint デザイン拡張サービス
X-SP Design
モダン化から運用管理までサポート
SharePoint 構築支援サービス
Power Appsモデル駆動型アプリは、Dataverseを基盤としたカスタム業務アプリを簡単に構築できるツールです。
Power Appsモデル駆動型アプリでは、添付ファイルを保存する先として、SharePointを選択可能です。 SharePoint 統合の設定を行うと、モデル駆動型アプリとSharePointを連携させ、アプリ上からドキュメントライブラリ上にファイルを保存することができるようになります。
また、統合設定を行う際、設定画面の１つに「エンティティに基づく」という項目があります。
この項目、どれを選べばいいのか迷ったことはありませんか？
この記事では、「エンティティに基づく」設定がどのようなものなのか、実際の挙動やパターンごとの使い分けを解説します。
Power Apps モデル駆動型アプリを構築されている方に向けた内容となっております。
弊社では、従来からPower AppsやPower Automateを用いたアプリ開発やその支援を行っております。
また、このような「ローコード」と呼ばれるサービスは、企業様の中で内製化するパターンも増えてきておりますが、 内製化を支援させていただくための、内製化支援サービスも提供しております。
参考：SharePoint統合の内容とそのメリット
Power Appsのモデル駆動型アプリとSharePointの統合とは、簡単に言うとモデル駆動型アプリ内で作成したレコードに関連付けられたファイルを、SharePointのライブラリに直接保存できる仕組みのことです。
モデル駆動型でアプリを構築する際、データソースとしてはDataverse（Microsoft 365上で用いられるクラウド型データベース）を用いることが一般的です。
また、Dataverseでファイルを保存する方法としては、以下２種類があります。
ファイル列で保存
メモ（annotation）テーブルで保存
上記でもファイルを保存することは可能ですが、どちらもDataverse上に保存されるため、ストレージ容量（正確には、ファイルとデータベース領域）を消費してしまいます。
SharePoint上でファイルを保存することができると、Dataverseのストレージ容量を節約することが可能となります。
※注意※
すべてのケースにおいて、SharePointへの保存が最適とは限りません。
もちろん、Dataverse上でファイルを保存する際のメリットもあります。
私が思う最大のメリットとしては、セキュリティに関する部分です。
Dataverseでは、レコードに関するセキュリティを細かく設定することができます。
（例：対象のレコードが「自分だけ閲覧できる」「自部署のユーザーだけ閲覧できる」「全員が閲覧できる」など）
Dataverse上にファイルを保存する場合は、レコードのセキュリティ設定が反映されるため、対象レコードに対して権限がないユーザーが、ファイルを閲覧することはできません。
一方、SharePoint上に保存する仕組みの場合は、Dataverse上のセキュリティ設定がSharePoint側に反映されません。
よって、Dataverseの対象レコードに対して権限がないユーザーが、SharePoint上のファイルにはアクセスできるという事象が発生します。
※Power Automateを作り込むことで、セキュリティ権限を同期させる方法もありますが、実装及び運用のハードルが高いのが実情です。
レコードへのアクセスが限られるテーブルのファイル保存については、ファイル列やメモテーブルを推奨します。
調査する内容
今回のポイントは、ドキュメント管理設定の「エンティティに基づく」というオプションです。
実際に選択肢として表示されるのは「空白」「取引先企業」「取引先担当者」の３つですが、それぞれ具体的にどのような挙動となるのか調査しました。
※参考：エンティティとは？※
エンティティとは、Dataverseのテーブルのことを指します。 以前はエンティティと呼ばれておりましたが、現在はテーブルと呼ばれることが一般的です。
調査では以下の3パターンを確認しました。
「エンティティに基づく」が空白
本パターンで使用するテーブルは以下です。
テーブル名：tbl_basedon_none
列名
データ型
備考
Name
1行テキスト
「エンティティに基づく」が取引先企業
本パターンで使用するテーブルは以下です。
テーブル名：tbl_basedon_account
列名
データ型
備考
Name
1行テキスト
basedon_account
検索（参照列）
取引先企業テーブルを参照
※参考：参照列とは？※
他のテーブル（例：今回は取引先企業テーブル）を参照するデータ列で、関連レコードをリンクする際に使用します。
「エンティティに基づく」が取引先担当者
本パターンで使用するテーブルは以下です。
テーブル名：tbl_basedon_contact
列名
データ型
備考
Name
1行テキスト
basedon_contact
検索（参照列）
取引先担当者テーブルを参照
各設定値におけるフォルダ構成と挙動
以下では、各パターンを調査した結果を紹介します。
「エンティティ」に基づくが空白 と設定した際のフォルダ構成
モデル駆動型アプリを作成し、tbl_basedon_noneテーブルに対してレコードを追加した後、ファイルを添付しました。
その結果、SharePointのドキュメントライブラリでは、以下のようなフォルダ構成となりました。
tbl_basedon_none（ドキュメントライブラリ）
└ レコード名（フォルダ）
└ 添付ファイル（ファイル）
テーブル名のドキュメントライブラリが作成されて、その配下にレコード名のフォルダが作成されました。
※参考※
フォルダの末尾に付与されている数字（上記図中の、「3297CBCC533DF0118C4E000D3A40B253」部分）については、 Dataverseに保存されたレコードGUIDの値でした。
※GUIDとは、対象レコードを表す一意識別子のことです。
「エンティティに基づく」が取引先企業 と設定した際のフォルダ構成
続いては、「エンティティに基づく」が取引先企業の場合です。
モデル駆動型アプリを作成し、tbl_basedon_accountテーブルに対してレコードを追加した後、ファイルを添付しました。
その結果、SharePointのドキュメントライブラリでは、以下のようなフォルダ構成となりました。
取引先企業（ドキュメントライブラリ）
└ 取引先企業レコード名（フォルダ）
└ tbl_basedon_account（フォルダ）
└ レコード名（フォルダ）
└ 添付ファイル（ファイル）
「取引先企業」を起点に、テーブル > レコードの順で階層化されました。
また、取引先企業欄（basedon_account列）に値を入力しない場合の挙動についても調査しました。
その結果、SharePointのドキュメントライブラリでは、以下のようなフォルダ構成となりました。
tbl_basedon_account（ドキュメントライブラリ）
└ レコード名（フォルダ）
└ 添付ファイル（ファイル）
取引先企業欄に値を入力しない場合は、「tbl_basedon_account」が起点となるようでした。
値の入力有無によって保存場所が変わるため、注意が必要ですね。
※保存場所が変わらないようにするためには、取引先企業欄を必須設定とするといった対応策があります。
「エンティティに基づく」が取引先担当者 と設定した際のフォルダ構成
最後は、「エンティティに基づく」が取引先担当者の場合です。
モデル駆動型アプリを作成し、tbl_basedon_contactテーブルに対してレコードを追加した後、ファイルを添付しました。
その結果、SharePointのドキュメントライブラリでは、以下のようなフォルダ構成となりました。
取引先担当者（ドキュメントライブラリ）
└ 取引先担当者レコード名（フォルダ）
└ tbl_basedon_contact（フォルダ）
└ レコード名（フォルダ）
└ 添付ファイル（ファイル）
「取引先担当者」を起点に、テーブル > レコードの順で階層化されました。
また、取引先担当者欄（basedon_contact列）に値を入力しない場合の挙動についても調査しました。
その結果、SharePointのドキュメントライブラリでは、以下のようなフォルダ構成となりました。
tbl_basedon_contact（ドキュメントライブラリ）
└ レコード名（フォルダ）
└ 添付ファイル（ファイル）
パターン２－２と同様、取引先担当者欄に値を入力しない場合は、「tbl_basedon_contact」が起点となるようでした。
まとめ
今回の調査結果をまとめると、以下となります。
パターン | 保存先のフォルダ構成 | 備考 |
|---|---|---|
１） | tbl_basedon_none（ドキュメントライブラリ） | |
２－１） | 取引先企業（ドキュメントライブラリ） | |
２－２） | tbl_basedon_account（ドキュメントライブラリ） | 取引先企業欄は未入力 |
３－１） | 取引先担当者（ドキュメントライブラリ） | |
３－２） | tbl_basedon_contact（ドキュメントライブラリ） | 取引先担当者欄は未入力 |
基本的には、「エンティティに基づく」に設定したテーブルが保存先の起点となるようです。
（設定しない場合は、レコードを保存するテーブルが起点となる）
また、「エンティティに基づく」が取引先企業または取引先担当者の場合において、 参照列に値を入力しない場合は、レコードを保存するテーブルが起点となりました。
「エンティティに基づく」オプションのパターン別解説
上記にて紹介した３パターンですが、それぞれどんなときに使うのが良いのでしょうか？
空白
おすすめ用途：
シンプルにレコードごとにファイルを管理したいとき
取引先企業や取引先担当者単位での分類が不要なとき
活用例：
備品管理アプリ
取引先企業
おすすめ用途：
取引先企業単位で情報を整理したいとき
活用例：
顧客ごとの案件管理アプリ
取引先担当者
おすすめ用途：
担当者個人単位で情報を整理したいとき
活用例：
BtoC向け製品の問い合わせ管理アプリ
アプリの目的や運用イメージに合わせて、最適な設定パターンを選択しましょう。
おわりに
本日は、Power Apps モデル駆動型アプリとSharePointの統合機能の設定値である、 「エンティティに基づく」という項目の挙動について調査した結果を紹介しました。
SharePoint統合機能は、Dataverseのストレージ容量を節約できる便利な仕組みです。 ぜひ活用を検討してみてください。
今すぐ無料相談で、貴社の課題に合わせた最適なプランをご提案します。
【こちらも合わせて読みたい】
小刀稱知哉
🖊小刀稱知哉さんのブログ一覧はこちら大分県出身（温泉大好き）、現在は東京都在住
1990年生まれ
30才でメーカーの技術営業からIT業界にジョブチェンジ!!!
趣味は読書
主にMicrosoftのローコード（SharePoint・Power Platform）に関するに関する営業活動や設計、開発などを担当しております！
（最近はCopilot Studioについても勉強中）
持ってる資格はPL-200/PL-300/PL-400/PL-600/MS-700/AZ-104/AZ-305/SC-200/SC-100
こんにちは。アーティサン株式会社の小刀稱（ことね）です。