Power Platform Solution 環境變數完整解析：Definition、Current Value、Default Solution 與匯出機制

2026-08-12 15:12:04 JST | PowerPlatform | 2 Reads

Copyright Notice: This article is an original work licensed under the CC 4.0 BY-NC-ND license. If you wish to repost this article, please include the original source link and this copyright notice.
Source link: https://v2know.com/article/1347

第一次接觸 Power Platform 的 **Solution（解決方案）**與 **Environment Variable（環境變數）**時，很容易被它的設計搞得一頭霧水。

最常見的疑問包括：

• 環境變數到底屬於 Solution，還是屬於 Environment？

• Environment Variable Definition 與 Current Value 到底是什麼關係？

• 為什麼在 Solution 裡修改 Current Value，Environment 裡的值也跟著改？

• Remove from this solution 到底刪除了什麼？

• 為什麼 Current Value 從 Solution 移除後，Canvas App 還是能正常使用？

• 為什麼修改環境變數的值，有時又要進入 Default Solution？

• 為什麼 Power Platform 裡甚至有兩個看起來像「Default Solution」的東西？

這些問題真正的根源，其實是對 Solution 的定位產生了誤解。

先記住本文最重要的一句話：

Power Platform 的 Solution 不是「資料夾」，而比較像「元件收錄清單＋部署套件」。

而真正存放 App、Flow、Dataverse Table、Environment Variable 等物件的地方，是 Environment（環境）。

理解這一點之後，Power Platform 很多原本看起來反常識的設計就會突然合理許多。

---

一、環境變數真正屬於 Environment，不屬於某一個 Solution

假設我們建立一個環境變數：

ReportUrl

它真正存在的地方是：

DEV Environment
└─ ReportUrl

而不是：

MySolution
└─ ReportUrl

Solution 做的事情比較像：

MySolution
└─ 我決定把 ReportUrl 收錄進這個 Solution

因此，正確的結構比較接近：

Environment
│
├─ Canvas App
├─ Flow
├─ Dataverse Table
├─ Environment Variable
│
├─ Custom Solution A
└─ Custom Solution B

Solution 只是在 Environment 裡挑選哪些元件要被這個 Solution 管理、部署與匯出。

這點非常重要。

因為如果把 Solution 理解成 Windows 資料夾：

Solution A 裡有自己的 ReportUrl
Solution B 裡有自己的 ReportUrl

後面幾乎所有 Environment Variable 的行為都會顯得莫名其妙。

---

二、一個環境變數其實拆成 Definition 與 Value 兩部分

Power Platform 的環境變數並不是單純一個：

名稱 = 值

而是至少拆成兩個不同物件：

Environment Variable Definition
Environment Variable Value

這是理解整套機制的核心。

Environment Variable Definition

Definition 可以理解成：

這個環境變數的「定義」或「規格」。

例如：

Display Name：
審査請求事件一覧 URL

Schema Name：
abc_Report3003Url

Data Type：
Text

Default Value：
空白

這些資料都屬於 Environment Variable Definition。

用傳統程式設計的概念來類比，很像：

string ReportUrl;

也就是先告訴系統：

有一個叫做 ReportUrl 的設定，而且它是文字型別。

---

Environment Variable Value

另外還有：

Environment Variable Value

它保存的是：

Current Value

例如：

https://app.powerbi.com/...DEV_REPORT_ID

所以真正的資料模型比較接近：

Environment Variable Definition
│
├─ Display Name
├─ Schema Name
├─ Data Type
└─ Default Value
        │
        ▼
Environment Variable Value
└─ Current Value

這兩者不是同一筆資料。

---

三、Default Value 與 Current Value 到底誰會生效？

規則其實非常簡單：

有 Current Value
       ↓
使用 Current Value

沒有 Current Value
       ↓
使用 Default Value

兩個都沒有
       ↓
Blank

例如：

Default Value = AAA
Current Value = BBB

實際使用：

BBB

如果：

Default Value = AAA
Current Value = 空白

實際使用：

AAA

所以可以直接記成：

Current Value 優先，Default Value 是備援值。

---

四、最反常識的一點：Solution 不是元件真正的「家」

假設畫面裡看起來是：

MySolution
├─ Canvas App
├─ Dataverse Table
└─ ReportUrl

人很自然會認為：

ReportUrl 是 MySolution 裡面的一個物件。

但更準確的理解是：

Environment
│
├─ Canvas App
├─ Dataverse Table
└─ ReportUrl

然後：

MySolution
├─ 收錄 Canvas App
├─ 收錄 Dataverse Table
└─ 收錄 ReportUrl

也就是說：

Solution 比較像 Manifest，而不是 Container。

元件真正存在於 Environment。

Solution 只是記錄：

「這一套應用程式部署時，需要包含哪些元件？」

---

五、同一個元件可以出現在不只一個 Solution 裡

這也是 Solution 不是資料夾的一個重要證據。

例如同一個：

ReportUrl

可能同時：

Default Solution
→ 看得到

MySolution
→ 有收錄

AnotherSolution
→ 也可能有相依關係

但 Environment 裡並沒有三份 ReportUrl。

真正存在的仍然只有：

Environment
└─ ReportUrl

不同 Solution 只是用不同方式「收錄」或「引用」這個物件。

---

六、在 Solution 裡修改 Current Value，其實就是直接修改 Environment 裡的值

這是非常容易誤會的一點。

假設目前：

DEV Environment

ReportUrl
Current Value = AAA

你進入：

MySolution
→ ReportUrl
→ Current Value

把：

AAA

改成：

BBB

很多人可能會以為系統變成：

MySolution：
Current Value = BBB

Environment：
Current Value = AAA

然後 Power Platform 再做某種同步。

實際上不是。

修改完之後真正的結果就是：

DEV Environment

ReportUrl
Current Value = BBB

因為從頭到尾就只有這一份 Current Value。

---

七、所以根本不存在「Solution 的 Current Value」與「Environment 的 Current Value」兩份資料

這一點值得單獨強調。

不是：

Solution Current Value
        ↓
同步
Environment Current Value

而是：

Environment Current Value
        ↑
        │
Solution Designer 只是其中一個編輯入口

換句話說：

你在 Solution 畫面裡看到 Current Value，不代表這是一份屬於 Solution 的值。

它仍然是 Environment 裡真正的 Current Value。

Solution 只是另外記錄：

「這一筆 Environment Variable Value 是否也被這個 Solution 收錄？」

---

八、這就是 Remove from this solution 真正的意思

假設現在：

DEV Environment

ReportUrl
Current Value = DEV_URL

同時：

MySolution

Definition ✅
Current Value ✅

如果你執行：

Current Value
→ ...
→ Remove from this solution

很多人第一反應會是：

那 Current Value 不就被刪掉了？

其實完全沒有。

操作後：

DEV Environment

Current Value = DEV_URL ✅

仍然存在。

只是：

MySolution

Definition ✅
Current Value ❌

也就是：

把這筆 Current Value 從 Solution 的收錄清單中移除。

而不是：

把 Environment 裡的值刪除。

---

九、因此 Canvas App 完全不會因為 Remove from this solution 而失去值

Canvas App 執行時讀的是：

Environment
└─ Environment Variable Current Value

不是：

Solution ZIP
└─ Current Value

因此即使變成：

MySolution
Current Value ❌

只要 Environment 中仍然是：

ReportUrl
Current Value = DEV_URL

Canvas App 還是正常取得：

DEV_URL

所以：

Solution 是否收錄 Current Value，影響的是部署與匯出，不是目前 Environment 中 App 的執行。

這是整套設計中非常重要的分界。

---

十、Remove from this solution 不是 Checkbox，而是一個立即執行的操作

它不是：

☑ 匯出 Current Value

也不是：

下次 Export 時不要帶 Current Value

這種「匯出設定」。

你點下：

Remove from this solution

當下就會解除：

Current Value
↔
MySolution

之間的 Solution Membership。

所以：

執行前

Environment：
Current Value ✅

Solution：
Current Value ✅

執行後：

Environment：
Current Value ✅

Solution：
Current Value ❌

之後 Export Solution 時，只是按照「現在 Solution 裡有哪些元件」進行打包。

---

十一、所以不是每次 Export 都要執行一次 Remove

這點也很容易搞錯。

假設第一次交付前：

MySolution
Current Value ✅

你執行：

Remove from this solution

之後：

MySolution
Current Value ❌

只要未來沒有再次把 Current Value 加回 Solution，那麼之後：

Version 1.1 Export
Version 1.2 Export
Version 2.0 Export

都不需要再 Remove 一次。

它不是 Export 前固定執行的步驟。

而是：

確保交付用 Solution 沒有收錄 DEV Current Value。

---

十二、甚至可以一開始就不要讓 Current Value 進入 Custom Solution

例如你自己的 Solution：

MySolution

Environment Variable Definition ✅
Current Value ❌
Canvas App ✅

但是 DEV Environment 本身仍然可以有：

Current Value = DEV_URL

此時根本不需要：

Remove from this solution

因為 Current Value 從一開始就沒有被這個 Custom Solution 收錄。

這也是比較乾淨的 ALM 思路：

Custom Solution
→ 管 Definition

Environment
→ 管這個 Environment 自己的 Current Value

---

十三、那麼 Current Value 要去哪裡設定？

這裡又會遇到另一個反常識設計。

明明說：

Current Value 屬於 Environment。

但實際操作時，有時會進入：

Default Solution

去修改。

這是不是表示 Current Value 屬於 Default Solution？

不是。

Default Solution 只是一個特殊的：

Environment 全景檢視入口。

它可以讓你看到目前 Environment 裡的各種元件。

所以：

Default Solution
→ Environment Variable
→ Current Value

真正修改的仍然是：

Environment
└─ Current Value

不是把值儲存在 Default Solution 裡。

---

十四、Default Solution 最好理解成「Environment 的全景檢視」

可以這樣理解：

Environment
│
├─ App
├─ Flow
├─ Table
├─ Environment Variable
│
└─ Default Solution
     ↑
     提供一個能看到整個 Environment 元件的特殊視角

它比較像 Windows 的：

檔案總管

你透過檔案總管修改：

C:\Config\ReportUrl.txt

不能因此說：

這個檔案屬於「檔案總管」。

同樣：

從 Default Solution 修改 Current Value，不代表 Current Value 屬於 Default Solution。

---

十五、最離譜的地方：Power Platform 裡真的有兩個 Default Solution

在 Dataverse Environment 的 Solutions 頁面中，可能會看到：

Common Data Services Default Solution

以及：

Default Solution

日文介面中後者可能顯示為：

既定のソリューション

這不是重複顯示。

它們確實是兩個不同的系統 Solution。

---

十六、Common Data Services Default Solution 是什麼？

可以粗略理解為：

系統預設用來建立與自訂元件的 Solution。

如果沒有設定 Preferred Solution，又沒有特別進入某個 Custom Unmanaged Solution 進行開發，建立的元件常常會進入這個 Solution。

因此可以在腦中記成：

Common Data Services Default Solution
=
預設「做東西」的地方

---

十七、Default Solution 又是什麼？

另一個真正叫：

Default Solution

的特殊 Solution，角色則完全不同。

它可以粗略理解成：

目前 Environment 的全景 Solution。

也就是：

Default Solution
=
預設「看整個 Environment」的地方

例如：

• 找某個元件

• 查看 Environment 中現有的 Customization

• 找 Environment Variable

• 查看 Current Value

• 排查設定

因此兩個 Default Solution 雖然名字非常像，角色卻完全不同。

---

十八、所以 Default Solution 與 Custom Solution 並不是普通的並列關係

從型別上來說，它們全部都是 Solution：

Default Solution
Common Data Services Default Solution
MySolution
AnotherSolution

但在用途上，它們並不是單純的平級「資料夾」。

可以理解成：

Environment
│
├─ Default Solution
│   └─ Environment 全景檢視
│
├─ Common Data Services Default Solution
│   └─ 系統預設自訂位置
│
├─ MyCustomSolution
│   └─ 專案自己的 ALM／部署套件
│
└─ AnotherCustomSolution

所以：

UI 上並列，不代表設計角色完全平級。

---

十九、三個看起來並列的 Current Value 選項，其實操作層級完全不同

在 Current Value 的 ... 選單中，可能看到類似：

Remove this value

Remove from this solution

Delete from this environment

乍看之下像是三個同類型功能。

其實完全不是。

功能	真正操作的層級
Remove this value	Value 本身
Remove from this solution	Solution Membership
Delete from this environment	Environment 中的物件

也就是說，Microsoft 把：

值操作
Solution 操作
Environment 操作

全部塞進同一個選單。

這也是為什麼介面看起來特別容易讓人產生錯誤理解。

---

二十、正確的 Environment Variable ALM 做法

假設現在要部署一個 RDL Report URL。

開發環境

先在自己的 Unmanaged Solution 建立 Definition：

Display Name：
審査請求事件一覧 URL

Schema Name：
abc_Report3003Url

Data Type：
Text

Default Value：
空白

Solution：

MySolution

Environment Variable Definition ✅

---

DEV Environment 設自己的值

例如：

Current Value =
https://app.powerbi.com/...DEV_REPORT_ID

DEV Environment：

abc_Report3003Url
Current Value = DEV_RDL_URL

Canvas App 正常使用：

DEV_RDL_URL

---

交付前確認 Current Value 沒有被 Custom Solution 收錄

理想狀態：

MySolution

Definition ✅
Current Value ❌
Canvas App ✅

如果 Current Value 已經被 Solution 收錄：

Current Value
→ ...
→ Remove from this solution

之後：

DEV Environment

Current Value = DEV_RDL_URL ✅

但：

MySolution

Current Value ❌

---

Export Solution

最後匯出的 Solution：

Canvas App ✅
Environment Variable Definition ✅
DEV Current Value ❌

因此不會把開發環境專用 URL 交給客戶。

---

二十一、客戶 Import 後會發生什麼？

客戶 Environment 匯入 Solution 後會建立相同的：

Environment Variable Definition

例如：

abc_Report3003Url

但是客戶 Environment 可以擁有自己的：

Current Value = CUSTOMER_PROD_URL

最終形成：

DEV Environment

abc_Report3003Url
= DEV_RDL_URL

以及：

Customer Environment

abc_Report3003Url
= CUSTOMER_PROD_RDL_URL

Canvas App 的程式碼完全不需要修改。

這才是 Environment Variable 真正要解決的問題。

---

二十二、Default Value 要不要填？

要視用途而定。

例如功能開關：

TestMode

可以設定：

Default Value = No

這樣即使 Production 沒有設定 Current Value，也會安全地使用：

No

但像：

客戶 Power BI Report URL

這種每個 Environment 都一定不同的設定，反而可以考慮：

Default Value = 空白

讓部署時明確要求提供該 Environment 自己的設定。

簡單來說：

真正有合理共通預設值
→ 設 Default Value

每個 Environment 必須明確設定
→ Default Value 留空

---

二十三、Managed Solution 中看不到 Current Value，不代表值不存在

如果 Environment Variable Definition 是透過 Managed Solution 部署到 Production，可能會遇到：

在 Managed Solution 裡看不到 Current Value。

這時可以從 Default Solution 找到該 Environment Variable。

原因仍然是一樣的：

Managed Solution
→ 管部署進來的 Definition

Current Value
→ 是目標 Environment 自己的設定

也就是：

Definition 是部署內容；Current Value 是環境設定。

這個分界是理解 Power Platform ALM 的關鍵。

---

二十四、Environment Variable 修改後不一定立即反映

還有一個實務上容易踩的坑。

修改 Current Value 後：

AAA
↓
BBB

Canvas App 或 Flow 不一定立即取得 BBB。

Environment Variable 的設定可能存在快取或非同步更新，因此測試時可以：

• 關閉後重新開啟 App

• 重新整理

• 等待一段時間後再次確認

如果剛改完仍然讀到舊值，不一定代表設定失敗。

---

二十五、用傳統開發概念翻譯 Power Platform

如果本身有 .NET、Web 或一般系統開發經驗，可以直接這樣理解：

Power Platform	傳統開發概念
Environment	DEV / TEST / PROD 執行環境
Environment Variable Definition	Config Key 定義
Default Value	Fallback 設定
Current Value	該環境目前實際設定
Custom Solution	Deployment Package / Manifest
Remove from this solution	從部署清單排除
Default Solution	Environment 全景 Component Explorer
Common Data Services Default Solution	系統預設自訂 Solution

這樣理解通常比直接硬背 Microsoft 的 UI 名稱容易很多。

---

二十六、最終只需要記住這 10 件事

如果不想再被 Power Platform 的 Environment Variable 搞亂，只要記住：

1. Environment 才是 App、Flow、Table、Environment Variable 真正存在的地方。

2. Solution 不是資料夾，而是元件收錄與部署機制。

3. Environment Variable Definition 與 Environment Variable Value 是不同物件。

4. Default Value 屬於 Definition。

5. Current Value 是目前 Environment 的實際設定。

6. 同一個 Environment 不存在一份「Solution Current Value」與另一份「Environment Current Value」。

7. 從 Solution 裡修改 Current Value，本質上就是修改 Environment 裡那一份值。

8. Remove from this solution 只解除 Solution Membership，不會刪除 Environment 中的 Current Value。

9. Environment Variable Definition 應隨 Solution 部署，而 Current Value 通常應由每個目標 Environment 自己提供。

10. Power Platform 的確存在 Default Solution 與 Common Data Services Default Solution 兩個系統 Solution，而且角色不同。

最後用一張結構圖總結：

                        Environment
                             │
        ┌────────────────────┼────────────────────┐
        │                    │                    │
    Canvas App       Environment Variable        Flow
                            │
                 ┌──────────┴──────────┐
                 │                     │
             Definition              Value
                 │                     │
          Default Value          Current Value
                                       │
                                       └─ App 實際使用


                    Custom Solution
                 ┌────────┴────────┐
                 │                 │
          Canvas App ✅       Definition ✅
                              Current Value
                              可收錄，也可不收錄


Default Solution
→ Environment 的全景檢視

Common Data Services Default Solution
→ 系統預設的自訂／建立 Solution

結語

Power Platform 的 Environment Variable 本身並沒有想像中那麼複雜。

真正讓人困惑的是 Microsoft 把三件不同的事情混在同一套介面裡：

Environment 中真正存在的物件

Solution 對物件的收錄關係

透過 Solution Designer 編輯 Environment 物件

因此你明明人在 Solution 畫面中，實際上卻可能正在直接修改 Environment 裡真正的資料；你按下 Remove from this solution，又不是刪除資料，而只是解除部署關係。

一旦理解：

Environment 是「東西真正存在的地方」，Solution 是「我要帶哪些東西走」。

整套 Environment Variable、Current Value、Default Solution 與 Solution Export 的邏輯就會清楚許多。

This article was last edited at 2026-08-12 15:12:04 JST

Related Articles

• 从 Access VBA 重构到 Microsoft Power Platform：这不是迁移，而是整套系统重做

  结论：不是“迁移”，而是“重做一套”。Access 的数据可以迁到 Dataverse，但 VBA、窗体 UI、报表、复杂按钮逻辑基本不能原封不动搬过去。你这个方向等于是把「処理状況等管理システム」迁到 Power Platform

  2026-05-13 15:00:58 JST | PowerPlatform | 19 reads
• Access 系統移行到 Power Platform 時的三種架構方案比較：Dataverse、Azure SQL、Azure Functions 的差異

  最近在研究一個既有的 Access 系統移行問題。這類 .accdb 系統通常不只是「資料庫檔案」，而是把資料表、查詢、畫面、VBA、報表、列印預覽等功能全部包在一起的小型業務系統。以「処理状況等管理システム」這類 Access 系統為例，它本身就是準備往 Power Platform 方向移行的既有 Access 系統

  2026-05-20 14:25:40 JST | PowerPlatform | 13 reads
• Dataverse 路線下，Access SQL 不能直接搬過去嗎？——Power Apps / Power BI / Dataverse View 的分工整理

  在 Access 系統移行到 Power Platform 時，最容易誤解的一點是： 「既然資料都搬到 Dataverse 了，那我原本 Access 裡寫好的 SQL，是不是可以直接拿來用？」 答案其實很殘酷： 如果後端選 Dataverse，那麼 Power Apps、Power BI、Dataverse View 這三個地方，基本上都不是直接寫 SQL 的地方。 這也是為什麼傳統 Access 系統移行到 Dataverse 時，不能單純理解成「把資料庫搬過去」。 它更像是把原本集中在 Access 查詢裡的邏輯，拆散到 Power Platform 的不同元件裡

  2026-05-20 13:16:35 JST | PowerPlatform | 13 reads
• 實測成功：使用 Codex 編輯 Power Apps Canvas App 的前置條件與配置

  過去編輯 Power Apps Canvas App，通常都要在 Power Apps Studio 裡逐個新增控制項、調整屬性和編寫 Power Fx。現在透過 Microsoft 提供的 Canvas Authoring MCP，Codex 也可以把 Canvas App 同步到本機，以 .pa.yaml 形式修改，經過服務端驗證後再同步回正在執行的 Power Apps Studio 共同創作會話

  2026-07-21 14:08:25 JST | PowerPlatform | 10 reads
• Azure Functions 发布成功但 API 返回 HTTP 500 的处理手顺

  ——以 Azure SQL Database 连接设定缺失为例 在使用 Visual Studio 发布 Azure Functions 时，可能会遇到这样一种情况： 发布画面显示

  2026-06-04 09:41:33 JST | PowerPlatform | 10 reads
• 從 Access 移行到 Power Platform，最合理的架構其實不是「全搬到 Dataverse」

  最近在研究一個既存的 Access 系統移行問題。 這個系統不是單純的資料庫，而是典型的 Access 業務系統

  2026-05-20 12:49:09 JST | PowerPlatform | 10 reads