「You don’t have permission to this view」——このエラーを見て、まず疑うのはロール設定やセキュリティロールかもしれない。だが原因がテーブル作成時の所有権設定にある場合、ロールをいくら見直しても解決しない。そして、その設定は作成後に変更できない。
結論を先に書く。Power Apps / Dataverse でログインユーザーごとのデータを表示したいなら、テーブル作成時に「Rows in this table」を User or Team（ユーザーまたはチーム） に設定しなければならない。Organization（組織）を選んだ場合、Current User フィルターは構造的に動作しない。そして一度作ったテーブルの所有権は変更できないため、唯一のリカバリ手段はそのテーブルを削除して作り直すことだ。
「Rows in this table」の2択が意味すること
Dataverse でカスタムテーブルを作成するとき、「Rows in this table（テーブルの行）」という設定項目が表示される。選択肢は2つ。
| 設定値 | 意味 | Owner 列 |
|---|---|---|
| Organization | 行の所有者は「組織」全体。個人別の制御は設計上存在しない | 自動付与されない |
| User or Team | 各行に Owner 列（所有者列）が自動付与。レコード作成時にログインユーザーが自動入力される | 自動付与される |
この2択はテーブルの性格を決める根幹設定であり、Microsoft の公式ドキュメントは次のように明示している。
“This is a choice that happens at the time the table is created and can’t be changed.”
（これはテーブル作成時に決める選択であり、後から変更することはできない）
— Microsoft Learn「Types of tables - Power Apps」
つまり、この設定を間違えた場合に後から直す方法は、公式には存在しない。
Organization 設定と Current User フィルターが共存できない理由
「Organization を選ぶと個人別フィルターが動作しない」というのは設定の組み合わせが悪いのではなく、設計上の構造的矛盾だ。
Organization 所有権のテーブルに対して、Microsoft のセキュリティモデルが許可するアクセスレベルは次の通りと公式に定められている。
“For security purposes, records that are organization owned, the only access level choices is either the user can do the operation or can’t.”
（Organization 所有のレコードに対するアクセスレベルは「操作できる」か「操作できない」の2択しかない）
— Microsoft Learn「Security concepts in Microsoft Dataverse」
「全員に見せるか、誰にも見せないか」の2択——この構造では「ログインユーザー自身のデータだけ表示する」という個人別制御の余地がそもそもない。
対して User or Team 所有権のテーブルでは、各行に Owner 列（Lookup 型）が自動付与され、レコード作成時にログインユーザーのアカウントが自動入力される（公式確認済）。Dataverse の「Equals Current User（現在のユーザーと一致）」フィルターは、この Owner 列の GUID（内部識別子）とログインユーザーの GUID を照合することで個人別表示を実現している。
Owner 列のない Organization テーブルにこのフィルターを設定しようとすると、照合対象が存在しない——これが、Current User フィルターが機能しない理由だ。
なお、「You don’t have permission to this view」というエラーメッセージと Organization 所有権設定の直接的な因果関係は Microsoft 公式ドキュメントに明示されていない。ただし上記の構造から、このエラーが発生することは論理的に説明できる。同じ状況に直面した方は、まずテーブルの所有権設定を確認することを勧める。
変更不可仕様——グレーアウトの意味
Power Apps の Dataverse テーブル設定画面を開くと、既存テーブルの「Rows in this table」はグレーアウト（選択不可）になっている。これは操作ミスではなく、仕様だ。
“After you create a custom table, you can’t change the ownership. If you later determine that your custom table must be of a different type, you need to delete it and create a new one.”
（カスタムテーブルを作成した後に所有権を変更することはできない。後からタイプを変える必要があると判断した場合は、削除して新しく作り直す必要がある）
— Microsoft Learn「Types of tables - Power Apps」
この仕様は Dataverse の根幹設計に関わるものであり、UI の抜け道もスクリプトでの直接変更も公式には存在しない。
リカバリ手順——削除 → User or Team で再作成
リカバリの手順は一本道だ。
ステップ1：既存テーブルをエクスポートして構造を記録する
列名、データ型、リレーション、既存データを控えておく。データが入っている場合は Excel または CSV にエクスポートしてから削除する。
ステップ2：既存テーブルを削除する
Power Apps の「テーブル」画面から対象テーブルを削除する。削除前に、このテーブルを参照しているアプリやフローがないか確認する。
ステップ3：「User or Team」で新規テーブルを作成する
テーブル作成時の「Rows in this table」で今度は「User or Team」を選択する。作成後、Owner 列が自動で追加されていることを確認できる。
ステップ4：必要な列を再設定する
以下の3列を最初に設定しておくと、今後の運用が安定する。
| 列 | 用途 | 補足 |
|---|---|---|
| メールアドレス列（テキスト型）+ 代替キー設定 | Power Automate からの Upsert（更新挿入）の照合キー | 設定手順は連載第1回を参照 |
| GAコード列 | 社員番号・コード等の一意識別子 | テキスト型で設定 |
| ユーザー Lookup 列 | Owner 列とは別に「担当者」等の明示的な参照列が必要な場合 | Lookup 型 → SystemUser テーブルへの参照 |
作業時間はデータ量・列数・既存アプリとの依存関係によって大きく異なる。「この手順を把握していれば最短でリカバリできる」という意味で、手順の見通しを持っておくことが重要だ。
ステップ5：データを再インポートして動作確認
ビューに「Equals Current User」フィルターを設定し、ログインユーザー自身のデータだけ表示されることを確認する。
いつ Organization を選ぶか
Organization 設定が誤りというわけではない。用途が合えば正しい選択だ。
| 用途 | 推奨設定 |
|---|---|
| 製品マスタ・カテゴリマスタなど全員が参照するマスターデータ | Organization |
| 申請テーブル・ユーザー活動ログなど「誰がどのレコードを持つか」が必要なデータ | User or Team |
| 部署やチームに関係なく組織全体で共有する設定ファイル | Organization |
判断の軸は「このテーブルのレコードに『所有者』の概念が必要か」だ。Current User フィルターで個人別データを制御したい、またはレコードごとにアクセス権を分けたい場合は、必ず User or Team を選ぶ。
ローコードアプリの設計において、テーブルの所有権設定はアーキテクチャの最上流にある判断だ。アプリの完成度が上がってから所有権の誤りに気づくと、削除・再作成のコストは相応に大きくなる。テーブル作成の初手でこの2択を意識する習慣をつけておくと、後工程の手戻りを減らせる。
Current User フィルターが動作するロジックの補足
User or Team で作成したテーブルでは、各レコードの Owner 列にログインユーザーの SystemUser GUID（内部識別子）が自動入力される。「Equals Current User」フィルターは、この GUID を評価してレコードの表示可否を判定する。
このフィルタリングの内部構造（eq-userid 演算子と SystemUser テーブルの連携）については連載第3回「Dataverse ビューフィルターの裏側」で詳しく扱っている。
まとめ
テーブル作成時の「Rows in this table」設定が Current User フィルターの動作を左右し、一度設定したら変更できないのが Dataverse の仕様だ。
次の一歩
- 既存テーブルの所有権設定を確認する——Power Apps の「テーブル」画面を開いて「Rows in this table」がどちらになっているかチェックする
- Organization に設定されているテーブルで Current User フィルターを使っている場合、「削除 → User or Team で再作成」を計画する
- 新規テーブルを作成するときは、先にこの2択を決めてから列設計を始める
関連記事
- DataverseのName列をUpsertの突合キーに使ってはいけない理由と、代替キー設定の3ステップ（メールアドレス代替キー設定の手順）
- Dataverse ビューフィルターの裏側——ログインユーザーのデータだけ表示される3段クエリ処理の全体像（Current User フィルターの内部動作）
- DataverseでLookup列をやめる判断軸——複数担当者の共有が必要になったとき（Dataverse 設計シリーズ第2回）
参照ドキュメント
- Microsoft Learn「Types of tables - Power Apps」https://learn.microsoft.com/en-us/power-apps/maker/data-platform/types-of-entities
- Microsoft Learn「Security concepts in Microsoft Dataverse」https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds
- Microsoft Learn「User and team tables (Microsoft Dataverse)」https://learn.microsoft.com/en-us/power-apps/developer/data-platform/user-team-entities