欄位也是架構

🌐 另有 28 種語言版本

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

圖片由 AI 生成

由 AI 翻譯，尚未經過社群審閱。 閱讀英文版

第 6 個模組，共 10 個，屬於 Data Architect 課程第 3 章Salesforce 資料架構。每個模組都可以單獨閱讀。 上一篇：選擇合適的物件 · 下一篇：關係會帶來後果

**本模組回答的問題：**Salesforce 應該如何在物理上表示每一份資料？

建立一個欄位大約只要一分鐘。新建欄位，選個類型，起個名字，下一步，下一步，儲存。正因如此，欄位才沒有被當作架構來對待。

走進一個已經運行了十年的 org，開啟客戶物件。五百個欄位。Status2__c、Legacy_Status__c、Old_Status__c、Status_New__c。三個不同的客戶編號。一個沒人敢刪的核取方塊，因為沒人知道還有哪個整合在用它。建立欄位只花了一分鐘，和它共處卻要好幾年。所以本模組的思想很簡單：**一個欄位就是一個架構決定。**不一定是大決定，但每個欄位都編碼了關於資料的含義、行為、身分或品質的某些東西，而且和物件一樣，欄位容易新增，拿掉卻出人意料地難。

這份資料實際上意味著什麼？

在第 2 章裡，我們給實體加上了屬性：一次配送有一個排定的時間視窗，一輛卡車有一個 VIN。現在我們要實現它們，而人們往往會在這裡直接跳到「文字欄位」。等一下。在選類型之前，我想知道資料意味著什麼。它是一個數字，還是一個恰好由數字組成的識別符號？是一個日期，還是一個時刻？是自由文字，還是一組認可值中的一個？由人輸入，還是由另一個系統擁有？它會變嗎？必須唯一嗎？可以缺失嗎？它應該被儲存，還是計算出來？這些不是設定介面上的問題，而是資料架構問題，欄位類型要在我們回答它們之後才定。

數字不一定是數字

Steve Trucking 給每輛卡車一個車隊編號，比如 001247。用數字欄位？多半不是。我們會把車隊編號相加嗎？1247 號卡車減去 1246 號卡車等於一輛卡車嗎？它是一個恰好包含數字的識別符號，而數字欄位甚至會把前導零去掉。郵政編碼、產品程式碼、帳號和運單號也都一樣。一個值看起來是什麼樣，並不能告訴你它意味著什麼。按你需要的行為來選類型，而不是按樣本資料看起來的樣子。

需要人來識別它嗎？

每個自訂物件都有一個 Name 欄位，第一個決定就是用文字還是自動編號。我會問：**需要人來識別這樣東西嗎？**人們通過名字認識零售合作夥伴，通過車隊編號認識卡車。但系統每晚生成的裝貨清單呢？沒有人應該因為 Salesforce 要求填 Name，就去敲「10-02 第 3 號裝貨清單」。給它一個自動編號。只是不要把這個生成的 Name 和記錄的身分混為一談：自動編號是幫助使用者的，Salesforce ID 識別記錄，而零售合作夥伴自己的裝貨清單編號可能在各個系統間識別同一樣東西。三份不同的工作。

詳細資訊介面

選一個類型，點選「下一步」，設定就會要求你填寫詳細資訊。本模組裡的大多數決定，實際上都是在這個介面上做出的，而且通常是匆匆做出的。

新建自訂欄位，第 2 步：詳細資訊（截圖，2026-10-12）。 檢視大圖

有兩個框看起來很像，乾的卻是不同的活。Description（描述）是給維護這個 org 的人看的，現在也是給讀取它的 AI 工具看的：這個欄位是什麼意思，誰擁有它，它從哪裡來。Help Text（幫助文字）是給介面前的使用者看的：這裡該填什麼。兩個都要填。接下來是 Required（必填）、Unique（唯一）和 External ID（外部 ID），它們每一個都值得單獨用一節來講。在它們下面，Default Value（預設值）可以是一個公式，這樣新記錄一開始就能有一個合理的值，而不是空白。

必填是一個比看上去更大的決定

欄位嚮導裡有一個小小的核取方塊，標籤是必填，而正如我們在第 1 章看到的，它可能是一顆定時炸彈。你有一個用了五年、有兩百萬條記錄的物件，現在有人決定一個新欄位必須始終有值。那兩百萬條在它之前就存在的記錄怎麼辦？不傳送這個值的整合怎麼辦？在值還不知道時就建立記錄的自動化怎麼辦？值要到三步之後才出現的流程怎麼辦？

「必填」聽起來像一個數據品質的決定，有時它確實是。但值什麼時候為人所知，是業務流程的一部分。所以不要因為有人說「我們總是想要那個值」就勾選必填。要問它什麼時候能知道，由誰提供，以及不知道時會怎樣。我們會在模組 7 中把這一點放到完整的一致性階梯上。

唯一也是有含義的

如果我把一個欄位標記為唯一，我就是在對業務做出一個宣告：不是「它通常不會重複」，而是**「兩條記錄永遠不能有這個值」。**這是很強的宣告。而且這個介面還要你再決定一件事：「ABC」和「abc」是同一個值，還是不同的值？對於任何由人輸入的內容，不區分大小寫是更安全的預設選擇。第 2 章關於鍵的規則，唯一、不變、無含義、絕不是 PII，在這裡同樣適用。如果有人告訴我員工郵箱是唯一的，我就會開始問：它會變嗎？有人離職後會回來嗎？地址會被重複使用嗎？收購之後會怎樣？郵箱也許有用，甚至今天是唯一的，但這不會讓它成為一個好的識別符號。

外部 ID：跨越邊界的身分

這正是外部 ID 大顯身手的地方。介面上的說明講得很好：這個欄位會成為「來自外部系統的唯一記錄識別符號」。ERP 裡有客戶 873492；Salesforce 有自己的記錄 ID。當 ERP 發來一次更新時，我們怎麼知道它屬於哪條記錄？把一個欄位標記為外部 ID，整合就可以基於它做 upsert（更新插入）：記錄不存在就建立，存在就更新（Upsert a Record Using an External ID (opens in a new tab)，英文）。而且當你載入子記錄時，可以通過外部 ID 來指向父記錄，而不必先去查詢 Salesforce ID。我常說，你讓 Salesforce 替你做了查閱。非常強大。

注意，ERP 的編號並沒有成為 Salesforce 記錄的身分。它是一個屬性，而一條記錄可以帶有好幾個：一個 ERP 客戶 ID、一個遺留 ID、一個合作夥伴的 ID。這沒問題。一個業務實體可以被好幾個系統以不同的方式認識。架構問題是哪個系統擁有每個識別符號，以及它做出了什麼承諾：只有當業務真的保證唯一時，才把它標記為唯一。

逐個欄位類型來看

現在來看類型本身。在任何物件上開啟 New Field（新建欄位），設定就會把整個清單展示給你，分組方式和我接下來要講的順序一樣：Salesforce 替你計算的欄位、關係欄位，然後是各種資料類型。

設定，新建自訂欄位，第 1 步：資料類型（截圖，2026-10-12）。 檢視大圖

下面是整個清單的一覽，每一種都附上我希望你記住的那一點。

分組	類型	要記住的
計算型	自動編號（Auto Number）	最多 30 個字元，其中 20 個用於字首或字尾；是給人看的標籤，而不是記錄的標識
	公式（Formula）	讀取時計算，不儲存；3,900 個字元
	彙總（Roll-Up Summary）	對明細記錄計數、求和、取最小值或最大值；僅限主要-詳細資料關係
關係	查閱、主從、外部查閱（Lookup、Master-Detail、External Lookup）	模組 7
資料	核取方塊（Checkbox）	真或假，預設值由你選擇；在流程中仍可能出現 null
	數字、百分比、貨幣（Number、Percent、Currency）	舍入規則；前導零會被去掉；15 位小數
	日期、日期/時間、時間（Date、Date/Time、Time）	一天、一個時刻，或一天中的某個時間；時刻以 UTC 儲存
	電子郵件、電話、URL（Email、Phone、URL）	儲存時會格式化並檢查：80、40 和 255 個字元
	Geolocation、地址（Address）	複合字段，佔用不止一個欄位：3 個和 9 個
	挑選清單、多選挑選清單（Picklist、Multi-Select）	一套受控詞彙，由管理員擁有
	文字、文字區域、長文字區域、富文字區域、加密文字（Text、Text Area、Long、Rich、Encrypted）	最多 255 個字元時儲存在記錄上，可以建索引；超過之後，就不能建索引，也不能篩選

Salesforce 替你計算的欄位

自動編號會按你定義的格式（比如 T-{000000}），給每條新記錄分配序列中的下一個編號。當人需要一個好用的稱呼、又不該讓任何人去編一個的時候，就用它。整個值最多 30 個字元，其中 20 個留給字首或字尾。只是要記住第 2 章講的：它是給人看的標籤，而不是記錄的標識，而且編號並不總是嚴格連續的。

公式欄位根據其他欄位計算出一個值。它們很強大，而且是在記錄被讀取時計算，而不是在儲存時計算，所以沒有存下來的東西會過時。公式返回什麼由你選擇：核取方塊、貨幣、日期、日期/時間、數字、百分比、文字或時間。

新建自訂欄位，公式：選擇返回類型（截圖，2026-10-12）。 檢視大圖

然後你用欄位、運算子和函式寫出公式本身，並檢查它的語法。注意那個 Use Formula Assistant（使用公式助手）按鈕：Salesforce 的 AI 現在會幫你寫公式。用它，然後讀一讀它寫了什麼。公式歸你負責，而不是歸助手負責。

公式編輯器，帶有公式助手（截圖，2026-10-12）。 檢視大圖 一個公式最多可以有 3,900 個字元，儲存或編譯後不能超過 15,000 位元組；一個很長的公式可以拆分到幾個相互引用的公式欄位中。長文字區域、加密欄位和 Description 欄位都不能在公式中使用。

彙總欄位放在主記錄上，對它的明細記錄計數、求和，或者取最小值、最大值。它們只能跨主從關係使用，這是選擇主要-詳細資料關係的最大理由之一。我們會在模組 7 中再回到它們以及它們的限制。

儲存還是推導？

**我們到底需不需要儲存這個值？**如果我有數量和單價，是否需要有人或某個自動化去維護一個總額？也許應該用一個公式來推導它：計算只有一個來源，讀取時重新計算，所以改了數量，答案就跟著變。公式有它自己的限制（儲存大小和顯示長度；Formula Field Limits and Restrictions (opens in a new tab)，英文），而複雜的公式會很難維護。

但有時業務要的不是今天的答案，而是當時的答案。如果折扣規則明年變了，去年的發票應該突然顯示一個不同的金額嗎？當然不應該。所以問題不是「Salesforce 能不能算出這個？」，而是**「這是一個當前的計算，還是一個歷史事實？」**歷史事實要儲存下來。

關係欄位

查閱（Lookup）、主從（Master-Detail）和外部查閱（External Lookup）關係也都是欄位，你的模型裡的那些連線正是在這裡變成現實的。查閱是鬆散的連線；主從把子記錄的生命週期、所有權和安全都綁在父記錄上；外部查閱則通過外部 ID 進行比對，連線到模組 4 裡講的外部物件。在它們之間做選擇，是一個大到值得單獨一個模組的決定。

核取方塊

核取方塊是最簡單的欄位：真或假，勾選或不勾選。它非常適合表示關於記錄的一個是/否事實：是否有效（Is Active）、是否需要安裝（Install Required）、是否已簽收（Signed For）。建立核取方塊時，Salesforce 會要求你選擇它的預設值，勾選還是不勾選，而這是一個真正的決定：每條新記錄都從這個值開始，包括整合在沒有傳送這個欄位的情況下建立的記錄。報表和清單檢視按 True 和 False 來篩選它；匯入工具和每週匯出則把它顯示為 1 和 0。

有一個陷阱要知道。記錄上的欄位只有兩個值，但它周圍的自動化可能有第三個值。在流程（Flow）中，一個從未被賦值的核取方塊變數是 null，而不是 false，把它儲存到記錄上會失敗（Trailblazer Community (opens in a new tab)，英文；另見 Salesforce 已知問題 W-11208535 (opens in a new tab)，英文）。選一個合理的預設值，並讓你的流程和程式碼有意識地處理 null。

數字、百分比和貨幣

數字儲存一個實數，並且會去掉所有前導零，這正是像 001247 這樣的車隊編號不能用數字欄位的原因。Salesforce 對數字欄位採用四捨五入（遠離零方向）：12.345 變成 12.35，−12.345 變成 −12.35。而在合併欄位中，它會按使用者的區域設定來舍入，而不是按你在欄位上設定的小數位數。

百分比儲存一個小數，並以百分比顯示：輸入 0.10，你看到的是 10%。超過 15 位小數後，值會失去精度。

貨幣按金額格式顯示，在使用多種貨幣的 org 中，它帶有貨幣程式碼，並且可以使用匯率；啟用高階貨幣管理 (opens in a new tab)（英文）後，商機可以使用帶日期的匯率，也就是交易成交那個期間的匯率。只有商機及其周邊的東西（產品、計劃、拆分以及它們的報表）使用帶日期的匯率；其他物件上的貨幣欄位仍使用單一的靜態匯率。注意舍入：沒有小數位時，Salesforce 會直接截斷（23.5 變成 23）；有一位或更多小數位時，則四捨五入（遠離零方向）。

日期、日期/時間和時間

三種類型，三種不同的含義。日期是一天：合同在某個日期到期。日期/時間是一個時刻：配送在那天上午 9:42 到達。時間是一天中的某個時間，完全不帶日期：門店每天 7:00 開門。

陷阱在於時刻。Salesforce 以 GMT（UTC）儲存日期/時間值。使用者輸入的時間按他們自己的時區來解讀、轉換，然後儲存；當有人讀取它時，又會再轉換成讀取者的時區。大多數時候，這正是你想要的。但這是我在課上舉的例子：洛杉磯（Los Angeles）的一位協調員在週日深夜，太平洋時間晚上 10 點，記錄了一次配送。在底層，Salesforce 儲存的是週一早上，GMT 早上 5 點。一份在另一個時區按天分組的報表，或者一個讀取原始值的整合，都可能把這次週日的配送算到週一。「發生的那一天」取決於你問的是誰的時鐘。留意使用者的時區，並決定業務指的是哪一個。

比較它們時也要小心。在底層，日期/時間就是一個很大的數字：Apex 把它讀作自 1970 年 1 月 1 日 00:00:00 GMT 起的毫秒數（Datetime Class (opens in a new tab)，英文）。它是一個精確的時刻，而不是一天。所以問兩個日期/時間是否相等（==），幾乎從來都達不到你想要的效果：9:42:00 和 9:42:01 不相等，「週一」和週一的任何一個時刻也不相等。應該改為問一個範圍：大於等於開始時間（>=），並且小於等於結束時間（<=）。「週一的每一次配送」就是每一次 >= 週一 00:00 並且 <= 週一 23:59:59 的配送，用的是你認定業務所指的那個時區。

還有一個有趣的：Salesforce 不能儲存任意日期。有效日期的範圍是從 1700 年 1 月 1 日到 4000 年 12 月 31 日，Salesforce 對日期和日期/時間給出的是同一個範圍（Data Import Dates (opens in a new tab)，英文）。連這兩端也是 GMT 的時刻，所以對於太平洋時區的使用者，最早的有效值是 1699 年 12 月 31 日下午 4 點。你所在的歷史學會的成立日期可能就存不進去。而經典的「沒有結束日期」的招數，9999 年 12 月 31 日，會被拒絕；如果你需要一個遙遠未來的佔位值，它必須在 4000 年或之前。

電子郵件、電話和 URL

這些是有格式的欄位，它們做的不只是儲存字元。電子郵件最多 80 個字元，會檢查格式是否正確；在連絡人和潛在客戶上，點選它就會開始給這個地址寫郵件。電話最多 40 個字元，按電話號碼格式顯示，當 org 接入了電話系統時，就可以點選撥號。URL 最多 255 個字元，會作為連結開啟。這是平台免費送給你的行為，所以我絕不會把電話號碼存在一個普通的文字欄位裡。

整合也會被檢查。一個不符合欄位格式的值，比如一個格式錯誤的電子郵件地址，會驗證失敗，而整條記錄都會被拒絕，不只是那個欄位。所以當源系統的資料很亂時，要在它到達之前清理乾淨，或者為那些載入不進來的記錄做好計劃。

Geolocation 和地址

Geolocation 儲存一個緯度和一個經度。在底層，一個叫 Location__c 的欄位其實是兩個可以單獨讀取和設定的值：Location__Latitude__s 和 Location__Longitude__s。而且你可以基於它查詢：SOQL 的 DISTANCE 和 GEOLOCATION 函式可以找出某個半徑內的記錄，或者按距離遠近排序。「這輛卡車 25 英里範圍內的每一次未完成配送」只需要一條查詢：WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25（Location-Based SOQL Queries (opens in a new tab)，英文）。地址（Address）儲存一個完整的地址：街道、城市、州或省、郵政編碼和國家，使用者可以搜尋一個地址，然後自動填好各個部分。

兩者都是複合字段：介面上是一個欄位，底層是好幾個。而且在物件的欄位數量限制中，它們佔用的不止一個欄位：一個 Geolocation 算作三個自訂欄位，一個地址算作九個。在一個已經很擁擠的物件上，這一點很重要。

挑選清單和多選挑選清單

挑選清單控制使用者可以輸入什麼：從你定義的清單中選一個值。狀態？多半是挑選清單。但這些值是後設資料，必須由管理員來新增或修改。所以我仍然會問：誰擁有這些值，它們多久變一次，是否有多個物件需要同一份清單，這些值是否帶有自己的資訊，是否有另一個系統擁有這套詞彙。

值放在哪裡也是一個決定。當一份清單只用一次、只用在一個欄位上時，就把值放在欄位本身、放在物件上；這也是 Salesforce 的預設做法。但當同一組值開始出現在好幾個地方，比如客戶上、配送上和倉庫上都有一個區域（Region），就要把它提升為全域值集，以免各個副本漸漸走樣。全域值集為它們共同維護一份清單，最多 1,000 個值，有效和無效的加在一起計算（Picklist Limitations (opens in a new tab)，英文）。設定介面自己的說明道出了它為什麼重要：這個值集「is restricted so users can’t add unapproved values through the API」（受到限制，使用者無法通過 API 新增未經批准的值）。一份清單，一個所有者，沒有哪個整合能偷偷塞進一個新的拼寫。

最後這一點，就是受限和不受限的區別。在受限挑選清單上，只允許管理員定義的值，無論來自哪裡：使用者、匯入或整合只要傳送了別的值，就會收到一個錯誤，「bad value for restricted picklist field」，記錄也不會被儲存。在不受限挑選清單上，使用者在介面上仍然從清單中選擇，但 API、匯入和自動化可以傳送任何值，Salesforce 會儲存它，並把它新增為一個無效值（Picklist Limitations (opens in a new tab)，英文；Create a Custom Picklist Field (opens in a new tab)，英文）。一個 org 就是這樣最後同時有了「Delivered」、「delivered」和「Dlvrd」。全域值集總是受限的。我的預設選擇是受限；不受限是一個有意的選擇，只用於確實由另一個系統擁有這些值的情況，而且那時要有人負責清理那些無效值。

設定，挑選清單值集：一個新的全域值集（截圖，2026-10-12）。 檢視大圖

多選挑選清單允許使用者選擇多個值，這些值以分號分隔，儲存在一起。在介面上很方便，在其他所有地方都很彆扭：更難篩選、做報表和整合，而且不能用在彙總摘要欄位的篩選條件裡。一條記錄有好幾個值，通常意味著第 2 章的那一課：有一個子物件正想要冒出來。

挑選清單還比你定義的那些值多一個值：空白。一條記錄可以什麼都沒選，這一點會讓人掉坑。在公式或驗證規則中，你不能單獨用 ISBLANK 來測試挑選清單；你要寫 ISBLANK(TEXT(Field__c))，或者 ISPICKVAL(Field__c, "")（Trailblazer Community (opens in a new tab)，英文）。所以要為每個挑選清單決定「沒有值」意味著什麼：允許嗎？出現時又意味著什麼？然後讓你的公式、驗證規則和篩選條件處理好它。

有時一個屬性其實是一個實體。有人要一個配送中心的挑選清單。一共九個。很簡單。然後我們瞭解到，每個配送中心都有地址、經理、營業時間、容量、區域和卡車。那不是挑選清單，那是一樣東西。**不要只因為它們現在數量還不多，就把一個實體變成挑選清單。**第一年感覺很好，第五年就很糟。（第 2 章的模組 5 裡有我關於一份清單何時掙得自己的物件的經驗法則。）

文字家族

我把文字分成兩類來講，兩者的分界線是 255 個字元。

最多 255 個字元：和記錄儲存在一起。 文字最多 255 個字元，幾乎在任何地方都能用：公式、篩選條件、報表、清單檢視，可以作為唯一欄位或外部 ID，還可以建索引。文字區域同樣最多 255 個字元，可以分行，就像一條簡短的備註。

超過 255 個字元：通過引用儲存。 長文字區域最多 131,072 個字元，富文字區域容量相同，還能帶格式、連結和圖片。我把它們想像成存放在旁邊，記錄上只保留一個指標，而它們的表現也確實如此：沒有索引，所以不能把它們設為唯一或外部 ID；不能在 SOQL 的 WHERE 子句中篩選它們（SOQL WHERE (opens in a new tab)，英文）；公式不能使用它們（Formula Field Limits and Restrictions (opens in a new tab)，英文）；報表對自訂的這類欄位只顯示前 254 個字元，報表篩選條件也只搜尋前 255 個字元左右（Filter Restrictions for Text Area (Long) Fields (opens in a new tab)，英文）。上傳到富文字欄位裡的圖片每張最大 1 MB，計入檔案儲存，而文字計入資料儲存（Rich Text Area Field Considerations (opens in a new tab)，英文）。所以，如果有人需要對這個值做搜尋、排序、比對或報表，就把它控制在 255 個字元以內，並保持為文字欄位。

加密文字（Text (Encrypted)）使用經典加密（Classic Encryption），以加密形式儲存最多 175 個字元。如果你的 org 使用 Shield Platform Encryption，你就改為加密一個普通的文字欄位，而且很多其他類型也可以用這種方式加密。

給每個欄位寫描述

我的標準是：**每個欄位都要有描述。**我堅持這一點很久了，而在 AI 時代，它比以往任何時候都更重要：每一個讀取你的 org 的 AI 工具和代理程式，都要靠讀描述來理解一個欄位的含義。空著的描述，就是一個隨時會發生的猜測。Customer_Status__c 是什麼意思？誰擁有它？它從哪裡來？使用者能編輯它嗎，還是今晚 ERP 會把它覆蓋掉？六個月後我就不記得了，三年後維護這個 org 的管理員也不會知道，除非我們告訴過他們。標籤不是文件，API 名稱也不是。

在共用程度很高的物件上（客戶、連絡人、商機），我還會給專用欄位使用命名字首，讓它們的來源和用途直接體現在名字裡：比如 ERP 擁有的所有欄位都以同一個字首開頭。我不是追求十二個單詞長的 API 名稱。我要的是模型能自己解釋自己。

給重要的東西分類：分類欄位

Salesforce 為每個欄位提供了一組分類後設資料。我把它們叫作分類欄位。你可以記錄 data owner（資料所有者）；field usage（欄位用途：Active、DeprecateCandidate、Hidden）；data sensitivity level（資料敏感級別：Public、Internal、Confidential、Restricted、MissionCritical）；以及 compliance categorization（合規分類）：PII、HIPAA、GDPR、PCI、CCPA 等。它們既適用於自訂欄位，也適用於標準欄位（Data Classification Metadata Fields (opens in a new tab)，英文）。

為什麼要費這個事？因為流程可以讀取它們。把一個欄位標記為 GDPR，一個流程就能找出一條記錄上所有的 GDPR 欄位，並把它們遮罩或刪除。而當 Salesforce 的信任層把一個提示傳送給大語言模型時，它可以正是用這種分類來遮罩敏感欄位：在發出去時把客戶的名字，比如「Maria Lopez」，換成一個佔位符，模型永遠看不到這個名字，在回來時再把名字換回響應裡（Einstein Trust Layer (opens in a new tab)，英文）。

一則更新。Salesforce 現在的文件說明，針對大語言模型的基於模式和基於欄位的遮罩對代理程式是停用的：遮罩可能會剝離代理程式回答所需的上下文（Data Masking Limitations in Agentforce (opens in a new tab)，英文）。分類仍然會為其他生成式 AI 功能驅動遮罩，但不要指望它讓個人資料遠離代理程式；那是一個存取和設計層面的決定（第 12 章）。

我的立場是：**分類在關鍵時刻很重要。**不要因為治理部門說了，就把它變成三週時間去填滿每一個框。在重要的地方使用它：個人資料、財務資料、受監管的資料，以及業務需要一位指定所有者的欄位。重點是，敏感性不再是某個人腦子裡的知識，而是成為欄位的一部分。

**考試之外：AI 改變了什麼。**糟糕的欄位文件過去懲罰的是下一位管理員。現在它會誤導每一個讀取結構的 AI 工具和代理程式：Flag2__c 是敏感的嗎？是權威的嗎？還在用嗎？AI 建立欄位的速度也比任何團隊都快，所以名稱、描述和分類是架構的一部分，而不是打掃衛生。

每個欄位都是一份承諾

一個欄位一旦投入使用、開始收集資料，所有東西就都開始依賴它。介面顯示它，流程根據它分支，驗證規則檢查它，報表按它分組，整合傳送它、讀取它，而現在 AI 工具還會基於它進行推理。它們每一個都對這個欄位做了假設：它的類型、它的長度、它是否會為空，以及它的值意味著什麼。以後要修改這個欄位，你得先把這些假設一個個找出來。重新命名一個挑選清單值、縮短一個文字欄位，或者把一個文字欄位改成挑選清單，聽起來都是小改動，卻可能讓另一家公司系統裡的一個整合崩掉。這就是為什麼一個欄位是一份承諾。

Click to enlarge

我不希望你學完這個模組後就不敢建立欄位了。Salesforce 生來就是要被擴充套件的；用它。我希望問題從「我該選哪種欄位類型？」變成**「這份資料意味著什麼，我們在承諾什麼樣的行為？」**類型、必填、唯一、外部 ID、挑選清單、公式、描述、分類：它們合在一起，就是第 2 章邏輯模型的物理表達。

架構師在這裡決定什麼

• 在選擇欄位類型之前，這個值意味著什麼，以及它是一個屬性、一個識別符號、一套受控詞彙，還是其實是另一個實體。
• 一個值是可以推匯出來的當前計算，還是必須儲存的歷史事實。
• 哪個系統擁有每個識別符號，以及它的唯一性是否是一項真正的業務承諾。
• 一個必填的值實際上什麼時候能知道，以及沒有這個值的記錄和整合會怎樣。
• 欄位需要什麼樣的描述、命名和分類，才能讓人、流程和 AI 安全地使用它。

延伸探索

• Salesforce Help，Data Classification Metadata Fields (opens in a new tab)（英文），查閱日期 2026-10-02。
• Salesforce Help，Einstein Trust Layer: Designed for Trust (opens in a new tab) 和 Data Masking Limitations in Agentforce (opens in a new tab)（英文），查閱日期 2026-10-02。
• Salesforce Developers，Insert or Update (Upsert) a Record Using an External ID (opens in a new tab)（英文），查閱日期 2026-10-02。
• Salesforce Help，Picklist Limitations (opens in a new tab)（英文），查閱日期 2026-10-02。
• Salesforce Help，Formula Field Limits and Restrictions (opens in a new tab)（英文），查閱日期 2026-10-02。
• Salesforce Developers，Date Formats and Date Literals (opens in a new tab)（英文），查閱日期 2026-10-02。