在規劃 Power Platform 架構時，一個非常重要的基本原則是：
一般情況下，Power App 應該使用與自己位於同一個 Power Platform 環境中的 Dataverse。
Canvas App 技術上可以連接其他環境的 Dataverse，但「App 與主要 Dataverse 同環境」才是最常見、最適合 Application Lifecycle Management（ALM）的設計。
一、什麼是 Power Platform 環境？
Power Platform 環境可以理解為一個獨立的應用程式與資料邊界。每個環境可以包含自己的：
- Power Apps
- Dataverse 資料庫
- Dataverse 表、欄位及關聯
- Power Automate Cloud Flow
- Connection Reference
- Environment Variable
- Security Role
- Solution
不同環境中的 Dataverse 是彼此獨立的資料庫。即使兩個環境中存在 Logical Name 完全相同的表，它們仍然是兩套不同的表和資料。
二、一般的 Dev、Test、Production 架構
企業通常會建立至少三個環境：
| 階段 | Power App | Dataverse | 主要用途 |
|---|---|---|---|
| Development | Dev App | Dev Dataverse | 功能開發及單元測試 |
| Test／UAT | Test App | Test Dataverse | 整合測試及使用者驗收 |
| Production | Production App | Production Dataverse | 正式業務運作 |
部署方向通常是：
Development Solution
↓
Test / UAT Solution
↓
Production Solution
每個環境都有自己的 App、Dataverse 表及資料。開發環境不應直接操作正式環境的業務資料。
三、Canvas App 如何找到 Dataverse 表？
Canvas App 並不是在所有 Dataverse 環境中搜尋同名表。其查找過程可以簡化為：
先確定 Dataverse 環境
↓
再依據 Table Logical Name 找到表
因此，一個 Dataverse 資料來源實際上包含兩個重要概念：
- 連接哪一個 Dataverse 環境
- 使用該環境中的哪一個 Logical Name
例如，Canvas App 使用 Logical Name 為 contoso_case 的表。當 App 使用 Current Environment 時：
Dev App → Dev Dataverse → contoso_case
Test App → Test Dataverse → contoso_case
Prod App → Prod Dataverse → contoso_case
三個環境中的表具有相同 Logical Name，但資料彼此獨立。
四、Solution 部署後為什麼不需要重寫 Power Fx？
Canvas App 預設使用目前環境的 Dataverse。當包含 App 的 Solution 被匯入另一個環境後，Current Environment 會指向新的目標環境。
例如，在開發環境中：
Canvas App
└─ Current Environment
└─ contoso_case
將 Solution 匯入測試環境後，會變成：
Canvas App
└─ Test Environment
└─ contoso_case
只要目標環境具有相同 Logical Name 的表，App 一般不需要修改以下公式：
Filter('案件', 狀態 = "處理中")
Patch(
'案件',
Defaults('案件'),
{
標題: "新的案件"
}
)
Power Apps Studio 中可能顯示表和欄位的 Display Name，但底層仍然保存 Dataverse Metadata 與 Logical Name 的對應關係。
五、把 Dataverse 表加入 Solution 的作用
Power App 在目前環境中操作 Dataverse，並不要求表一定與 App 出現在同一個 Solution 中。
把表加入 Solution 的主要目的，是管理及部署表的結構，例如：
- 表定義
- 欄位
- 表關聯
- Choice
- View
- Form
- Business Rule
- 其他 Metadata
當目標環境尚未建立這些表時，匯入 Solution 可以使用相同的 Logical Name 建立表。
Solution 一般不包含表內的業務資料。如果需要將測試資料、主資料或正式資料搬到另一個環境，必須使用另外的資料匯入、資料遷移或整合機制。
六、匯入後 Logical Name 會改變嗎？
不會。
假設來源環境中的表名稱如下：
- Display Name：案件
- Schema Name：
Contoso_Case - Logical Name：
contoso_case
將包含這張表的 Solution 匯入另一個環境後，Logical Name 仍然是：
contoso_case
它不會根據目標環境的 Default Publisher 重新產生 Prefix，也不會自動改成另一個名稱。
如果目標環境中已經存在 Display Name 相同、但 Logical Name 不同的表，Dataverse 會將它們視為兩張不同的表，Power App 也不會僅憑顯示名稱自動改綁。
七、Canvas App 能不能連其他環境的 Dataverse？
可以。Power Apps Studio 在加入 Dataverse Data Source 時，可以使用 Change environment 選擇另一個使用者有權限的環境。
例如：
位於 Test 環境的 Canvas App
↓
明確連接 Production Dataverse
↓
操作 Production 的 contoso_case
但這不是一般 ALM 架構的首選。跨環境存取通常需要額外考慮：
- 使用者是否同時擁有兩個環境的存取權限
- 遠端 Dataverse 的 Security Role
- DLP Policy
- 租戶與網路邊界
- Connection Consent
- Solution 部署後是否仍然指向正確環境
- 測試 App 是否可能誤改正式資料
跨環境 Dataverse 比較適合中央主資料、共用資料服務或特殊整合架構，不應在沒有明確理由的情況下使用。
八、同環境設計的主要優點
- 資料隔離：開發、測試及正式資料彼此分離。
- 部署簡單：Solution 匯入後自動使用目標環境 Dataverse。
- 公式穩定：Logical Name 保持不變，一般不需要修改 Power Fx。
- 權限清楚：使用者只需要取得對應環境及 Dataverse 表的權限。
- 降低風險：避免開發或測試 App 誤刪正式資料。
- 維運容易：備份、還原、監控和故障排查都以環境為單位。
- 符合 ALM：適合使用 Solution、Pipeline 及 Managed Solution 管理版本。
九、部署時仍然需要另外處理的內容
即使 App 和表已經透過 Solution 正確部署，以下內容仍可能需要額外設定：
- Dataverse 業務資料
- Security Role 與使用者指派
- Connection Reference
- Environment Variable
- 外部 API URL
- SharePoint Site URL
- 特定資料記錄的 GUID
- 使用者、Owner 或 Team 的對應關係
尤其不應在 Power Fx 中硬編碼特定環境的 URL 或資料 GUID。環境差異值應優先使用 Environment Variable 管理。
十、結論
Power App 與主要 Dataverse 位於同一個環境，是 Power Platform 最常見、最安全，也最適合 Solution ALM 的架構。
Canvas App 並不是在所有環境中搜尋 Logical Name 相同的表。它會先確定要連接的 Dataverse 環境，再在該環境中依 Logical Name 找到表。
使用 Current Environment 時，Solution 從 Development 部署到 Test 或 Production 後，App 會自動使用目標環境的 Dataverse。表和欄位的 Logical Name 保持不變，因此一般不需要重寫 Power Fx。
跨環境 Dataverse 雖然可行，但應視為特殊架構，而不是預設做法。