在 Microsoft Dataverse 中，每張資料表及每個欄位通常同時具有 Display Name（顯示名稱）與 Logical Name（邏輯名稱）。
顯示名稱決定使用者在 Power Apps、資料表設計器及表單中看到什麼； 邏輯名稱則是程式、API、SQL 查詢、報表與部署工具真正用來識別元件的名稱。 因此，顯示名稱影響的是操作體驗，而邏輯名稱影響的是系統能否長期維護。
一、Display Name 與 Logical Name 的差別
| 比較項目 | Display Name | Logical Name |
|---|---|---|
| 主要用途 | 提供給使用者閱讀 | 提供給系統、程式及整合工具識別 |
| 可否使用日文或中文 | 可以 | 通常使用英文字母、數字及底線 |
| 建立後能否修改 | 通常可以修改 | 建立後不能直接修改 |
| 常見使用位置 | 表單、View、Power Apps 編輯器 | API、RDL、SQL、Power Automate、外部程式 |
| 是否需要全系統唯一 | 不一定 | 必須能唯一識別元件 |
例如，一張資料表可以具有以下兩個名稱：
- Display Name：
合議体 - Logical Name：
kfs_gougitai
使用者在 Power Apps 畫面中看到的是「合議体」，但程式及外部報表通常依靠 kfs_gougitai 識別這張資料表。
二、Logical Name 為什麼比想像中重要？
1. Logical Name 建立後不能直接修改
Dataverse 的 Logical Name 並不是普通的標籤，而是資料結構的一部分。 資料表或欄位建立完成後，即使修改 Display Name，原有 Logical Name 也不會跟著改變。
假設一開始建立的欄位是：
crb63______
後來把顯示名稱改成「担当審判官」，其 Logical Name 仍然是 crb63______。API、SQL 及報表中看到的也仍會是這個名稱。
如果一定要更換 Logical Name，通常只能建立新欄位或新資料表，再搬移資料及修改所有依賴關係。 因此，Logical Name 應在建立資料結構之前仔細設計。
2. RDL 與 Dataverse SQL 依賴 Logical Name
Power BI Paginated Report 或其他 RDL 報表若透過 Dataverse TDS Endpoint 執行 SQL 查詢， SQL 中通常需要使用資料表及欄位的 Logical Name。
SELECT
kfs_id,
kfs_tantou_shinpankan
FROM
kfs_gougitai
ORDER BY
kfs_id;
Display Name 可以是日文，但 SQL 維護人員真正看到的是 kfs_gougitai、kfs_id 等 Logical Name。
如果 Logical Name 是大量底線、隨機字元或無法理解的縮寫，報表仍然可能運作， 但幾個月後再修改 SQL 時，維護人員很難判斷每張表及每個欄位的真正含義。
3. Web API 與外部程式也依賴 Logical Name
Dataverse Web API、C# SDK、JavaScript、Azure Functions 及其他整合程式， 都需要透過穩定的技術名稱存取資料。
GET /api/data/v9.2/kfs_gougitaies?$select=kfs_id,kfs_tantou_shinpankan
即使日後把 Display Name 從「合議体」改成「合議體管理」， 只要 Logical Name 沒有改變，外部程式通常仍可繼續運作。
這也說明 Logical Name 的另一項價值： 它是跨越語言、畫面及名稱變更的穩定識別符。
4. Power Automate 與 Canvas App 也會受到影響
Canvas App 的 Power Fx 編輯器通常會向開發者顯示 Display Name， 因此公式可能看起來像下面這樣：
Filter('*合議体', ID = "001")
但是在 Dataverse 中，資料來源、欄位中繼資料、Solution 相依性及連接器設定， 仍然依靠 Logical Name 或其他固定識別資訊。
同樣地，Power Automate 設計器可能顯示日文名稱， 但流程定義的內部內容通常會保留資料表或欄位的技術識別資訊。
因此，Power Fx 畫面上沒有直接看到 Logical Name， 不代表 Logical Name 對應用程式不重要。
5. Solution 無法自動修正不良命名
將資料表加入 Solution，只代表這張資料表及相關元件可以一起部署。 Solution 不會自動把難以閱讀的 Logical Name 重新命名。
如果來源環境中使用的是 crb63______， 匯出再匯入其他環境後，通常仍會保留相同 Logical Name。 不良命名會隨著 Solution 一起進入測試環境、正式環境及後續整合系統。
三、Publisher Prefix 的作用
Dataverse 自訂資料表及欄位的 Logical Name 通常包含 Publisher Prefix。 例如：
kfs_gougitai
kfs_getsumei
kfs_tantou_shinpankan
其中 kfs 是 Publisher Prefix，用來表示這些元件屬於同一套系統或開發範圍。
合理的 Prefix 可以帶來以下好處：
- 區分系統自訂元件與 Dataverse 標準元件。
- 避免不同 Solution 建立同名資料表或欄位。
- 方便進行中繼資料盤點與自動化檢查。
- 讓 SQL、API 及程式碼中的來源更加明確。
Prefix 應在正式建立資料表之前決定。 如果先使用臨時 Publisher 建立資料表，之後即使換成新的 Solution， 已建立元件的 Logical Name Prefix 也不會自動改變。
四、Logical Name 應該使用編號還是可讀名稱？
例如，以下兩種命名都符合基本格式：
kfs_001
kfs_002
kfs_gougitai
kfs_getsumei
純編號名稱比較短，但閱讀 SQL 或 API 時，無法直接判斷資料表的用途。 開發者必須另外查閱對照表，才能知道 kfs_001 代表什麼。
相較之下，kfs_gougitai 與 kfs_getsumei 雖然稍長，卻可以直接理解其含義，更適合需要長期維護的業務系統。
因此，除非編號本身具有不可替代的業務含義，否則建議使用 Prefix 加上可讀的羅馬字或英文名稱。
五、推薦的命名原則
一套容易維護的 Dataverse Logical Name，建議遵守以下原則：
- 統一使用同一個 Publisher Prefix，例如
kfs_。 - 表名及欄位名應能直接表達業務含義。
- 同一個日文詞彙只使用一種固定羅馬字拼法。
- 避免純流水號，例如
kfs_001。 - 避免無法解讀的縮寫及大量底線。
- 不要把臨時名稱帶入正式環境。
- 不要在名稱中加入容易改變的年份、部門名稱或版本號。
- 建立資料表前，先完成命名清單及重複檢查。
例如：
| Display Name | 建議 Logical Name |
|---|---|
| 合議体 | kfs_gougitai |
| 月名テーブル | kfs_getsumei |
| 担当者紹介 | kfs_tantousha_shoukai |
| 事件処理区分 | kfs_jiken_shori_kubun |
六、已經使用不良 Logical Name 時怎麼辦？
由於既存 Logical Name 不能直接修改，通常需要採用「建立新結構並搬移資料」的方法：
- 盤點所有舊資料表、欄位、型別、選項及關聯。
- 建立舊名稱與新名稱的完整對照表。
- 使用正確 Prefix 建立新資料表及新欄位。
- 保留原有記錄 GUID，或建立可追蹤的新舊 ID 對照。
- 搬移全部資料，包括空值、Owner、狀態及必要系統欄位。
- 重建 Alternate Key、Relationship、View、Form 及相關元件。
- 修改 Power Apps、Power Automate、RDL、API 及外部程式中的引用。
- 以程式逐表、逐筆及逐欄位比較結果。
- 完成備份並確認沒有依賴後，才刪除舊資料表。
這類工作不能只確認資料筆數相同。 兩邊各有 1,000 筆資料，不代表每筆資料的值、GUID、Owner 及狀態完全一致。 正式遷移應留下可稽核的 Mapping、備份、雜湊及比對報告。
七、結論
Dataverse 的 Logical Name 並不是只有開發者才需要關心的內部名稱。 它直接影響 SQL、RDL、API、Power Automate、Solution 部署及系統的長期維護成本。
Display Name 可以隨著語言及業務需求調整， 但 Logical Name 一旦建立，便很可能陪伴整套系統直到退役。
一個好的 Display Name，讓使用者知道自己正在操作什麼； 一個好的 Logical Name，讓未來的維護人員知道系統正在做什麼。
因此，建立 Dataverse 資料表之前，最值得投入時間的工作之一， 就是確定一致、可讀且能長期使用的 Logical Name 命名規則。