Salesforce Platform 持續推進其自動化結構,以滿足複雜業務流程的需求。先前的產生—工作流程規則和流程產生器—提供事件驅動邏輯的初始步驟,擴充事件驅動邏輯的自動化功能,並將範圍延伸至更廣泛的產生器。

此進化為高效能的整合結構,其核心為兩個互補的支柱:記錄觸發流程與 Apex 觸發程序。此文件提供在設計觸發自動化時做出明智決策的架構與原則。

在 Salesforce Platform 上建立可調整、可維護且效能高的記錄觸發自動化,需要以結構為導向的紀律化方法。流程與 Apex 之間的選擇,以及每個流程的實作,都由一組明確的原則所引導。這些點總結這些原則,並作為現代自動化設計的基礎規則。

• 根據 Salesforce 物件自動化密度為工作選擇正確的工具。

  • 使用 Salesforce 物件的記錄觸發流程來進行 低密度自動化。

  • 使用可叫用 Apex 增強記錄觸發流程邏輯,以進行 中密度自動化。

  • 針對 Salesforce 物件使用 Apex 觸發以進行 高密度的自動化。

• ���發非同步程序時請特別小心。
  無論您是在記錄觸發流程中叫用非同步程序,或從 Apex 建立可排列的工作,都適用此規則。雖然此模式對卸載工作來說很有吸引力,但可能會導入複雜的錯誤處理情境,並增加達到管理員限制的風險。

• 針對每個 Salesforce 物件使用一個進入點。
  針對指定的 Salesforce 物件,請使用一個機制作為自動化的進入點。嘗試避免將流程與 Apex 觸發混合為相同物件的進入點。

Flow 與 Apex 共用一組基本功能。每個工具都可以查詢記錄、執行條件邏輯、指派變數,以及執行 DML 作業,例如建立、更新和刪除記錄,順序以指定順序執行。

不過,此功能重疊不表示工具可互換。架構選擇的重點不在於工作是 否 可以完成,而在於工作 如何 完成,以及對效能、可擴充性和可維護性的長期影響。流程在簡易流程的陳述性清晰度和實作速度方面表現優異,而 Apex 提供複雜解決方案所需的細微控制和原始功能。

自動化密度是指放置在特定 Salesforce 物件上的負載。它會作為述詞來決定物件的最佳實作。隨著自動化密度增加,違反交易限制的可能性也會增加。

透過檢查三個特定大小和複雜度來計算自動化密度:

• **自動化數量:**在單一「資料操作語言」(DML) 事件期間執行的唯一自動化中繼資料項目 (流程、觸發動作等) 原始數目。

• **記錄量:**透過 API 載入或大量批次處理處理的每個交易記錄,其中效能會變為重要。

• **相依性擴展:**初始 CRUD 作業觸發的下游 DML 作業度量。它會量化圖表的深度,其中一個更新會串聯至相關物件的更新 (例如,個案 → 帳戶 → 連絡人 → 自訂累計)。

隨著 Salesforce 應用程式的範圍和複雜度增加,請認可單一主要進入點—記錄觸發流程或 Apex 觸發。避免在單一 Salesforce 物件上跨多個機制進行自動化分割,因為這會導致維護能力不佳和管治分割。

使用此矩陣可決定 Salesforce 物件的必要結構標準。

• 記錄觸發流程是低自動化密度的偏好解決方案。其提供的功能與無障礙平衡,非常適合直接且彼此獨立的自動化。

• 混合模式 (含可叫用 Apex 的記錄觸發流程) 是高複雜度的中密度自動化可維護強大選擇。此模式可讓小組在陳述性流程中維護排序的作法,同時將繁重運算作業委派至 Apex,以平衡無障礙與效能。

• Apex 觸發程序提供可支援高密度自動化的穩固結構基礎所需的建構組塊。Apex 的效能、細微控制,以及物件導向的抽象與多型,更適合管理這些案例的複雜性和規模。

此外,請考量每日 DML 作業的總數,因為 Salesforce 會在多租戶環境中強制執行共用資源管理和管理員限制,以防止流失的自動化對共用資源進行垄断。具有高每日 DML 量之 Salesforce 物件需要謹慎的自動化選取。例如,CPU 時間 (60,000 毫秒) 和堆疊大小 (12 MB) 的非同步限制高於同步限制。此外,非同步執行的全組織 24 小時限制 (計算為 250,000 或使用者授權的 200 倍) 需要將每日 DML 總數納入結構設計中,以避免執行階段例外。

「記錄觸發流程」是平台用於記錄觸發自動化的首要陳述性工具。流程的易用性和內建平台保護功能可讓小組輕鬆建立可調整且可靠的解決方案。這是大多數的小組在 Salesforce 平台上建立解決方案的理想選擇。

Apex 是平台專屬、強大類型的物件導向程式語言。針對高度自動化密度的 Salesforce 物件,以及需要高效能、複雜邏輯或對交易進行細微控制的使用個案,使用 Apex。

為協助進行決策流程,此矩陣可提供跨關鍵結構功能的流程與 Apex 直接比較。

此表格根據呈現的功能,提供一般使用個案的一般「最適合」建議。最後,您會考量其他考量事項,以找出最適合您特定案例的項目,例如此文件的「_相關最佳作法」_一節中包含的案例。在此,您將深入瞭解特定「流程」與 Apex 組合何時提供最佳方法。

設計實作時,延展性是重要的考量事項。當記錄觸發自動化的商業邏輯變得複雜、執行時間長或涉及大量資料時,Salesforce 平台的核心管理員限制會變成結構限制。大量資料更新、複雜的 API 呼叫或繁重計算等作業會增加違反限制的風險,例如總 CPU 時間或單一資料庫交易內的 DML 陳述式數量。由於限制例外,同步觸發失敗會導致使用者的整個儲存交易回復,導致使用者體驗不佳並可能遺失資料。此固有的風險需要結構模式來卸載複雜工作。

非同步自動化在此個案中至關重要。使用非同步機制,結構設計師可以有效地將長時間執行或大量工作與主要同步記錄儲存交易分離。儲存可快速且可靠地完成,而大量處理會委派至稍後執行的個別平台管理交易。分離可改善穩定性、防止交易失敗,對於建立可調整的企業應用程式而言至關重要。此平台為此提供數種專用工具,每種工具皆具有與可靠性、數量和複雜度相關的不同優點和權衡。

記錄觸發流程中的「非同步執行」路徑提供「觸發忘記」非同步邏輯的最簡單機制。原始記錄儲存交易成功認可至資料庫後,此路徑會在個別交易中執行。

• 理想使用個案:這適用於不需要立即執行或自訂錯誤處理的工作。範例包括傳送電子郵件通知、建立後續追蹤工作,或對外部系統進行簡單呼叫。

• 限制:此機制與其他非同步流程訪問共用相同的每日管理員限制。不適用於極大量處理。

Change 資料擷取 (CDC) 是一種高流量、可調整且彈性的模式,用於處理大量案例中記錄變更所觸發的非同步邏輯。在此模型中,觸發的唯一責任是同步儲存記錄。接著,平台會發佈詳細的事件訊息,其中包含記錄對大量 Event Bus 的變更。個別的專用 Apex 觸發會訂閱此變更事件。它會執行複雜、長時間執行或非同步的工作。

• 益處:此模式會將非同步流程與初始使用者交易分離。非同步處理失敗不會造成使用者的記錄儲存回復。模式也提供可供多個內部訂閱者或外部系統使用的永久事件串流,且事件最多可重新執行 72 小時,提供強大的彈性。

• 限制 事件訊息不包含記錄的先前狀態,亦即等同於 Apex Trigger.oldMap。事件裝載包含新的欄位值,但不包含其變更的值。這會使根據特定狀態轉換實作邏輯變得具有挑戰性 (例如,僅在 Status__c 從「待處理」變更為「已批准」時執行)。您可以透過在事件訂閱者中查詢物件的欄位歷程記錄來減輕此情況,但這會對流程增加複雜性,且欄位歷程記錄追蹤可能無法用於特定感興趣的欄位。這可能會限制您可以卸載至 CDC 的自動化類型。

依預設,CDC 最多可在五個 Salesforce 物件上啟用。需要更多的組織可以購買附加元件授權,以移除此限制並增加事件傳送配置。

直接從觸發程序執行可排列的 Apex 工作應視為具有風險的模式,僅在需要 Apex 提供的控制時使用 (例如,用於複雜邏輯或自訂重試機制),且 CDC 不是可行的選項。

如果 Apex 需要可排列,則實作必須包含適當的保護措施:

• 限制檢查:程式碼必須在嘗試新增其他工作之前,先檢查已在交易中建立的工作數目。

• 內容認知:程式碼必須偵測其是否在非同步環境 (例如批次工作 (System.isBatch()) 內執行,並修改其行為,以遵循該環境中更嚴格的一次性交易限制。

從同步觸發叫用非同步 Apex 會導致穩定性風險。為了防止組織層級影響 (例如超出限制),此模式需要嚴格的設計和測試。

• 非同步 Apex 執行的每日限制 (Batch、Queueable、@Future) 會在整個組織中共用 (通常為 250,000 個或以使用者授權為基礎的計算)。大量資料載入 20,000 個記錄會造成觸發以 200 個區塊執行,進而導致 100 個個別的觸發叫用—如果大量批次大小少於 200 個記錄,則更多。如果每個叫用都會將非同步工作加以排列,則可能會耗用單一資料載入中每日限制的很大部分。此耗用可能會使非同步資源的其他重要業務流程枯竭。

• 指派工作的管理員限制會根據內容顯著不同。透過 UI 中使用者動作 (即 _同步_交易) 觸發的觸發,最多可建立 50 個可排列的工作。然而,從在批次 Apex 類別 (_非同步_交易) 的 execute 方法中觸發的觸發,只能將一個可排入排列的工作列入。無法考慮此差異是常見且嚴重的失敗點,這會在大型資料作業期間導致發生 LimitException 錯誤。

• 直接從觸發內容呼叫可排程 Apex (System.schedule) 或批次 Apex (Database.executeBatch) 會構成反模式。這些方法並非為了從觸發內容叫用而設計。這麼做會導致您快速耗用非同步 Apex 配置,進而導致限制例外。

每個非同步機制都有與效能、管理員限制和可靠性相關的特定權衡。使用此決策樹為指南,協助您瀏覽這些選項,並為您的使用個案選擇正確機制。

如流程圖所示,當您面對大量的 DML 作業,但無法使用「變更 資料擷取」(可能是因為物件限制),最佳結構選擇通常是完全避免觸發叫用程序。

請考慮改用排程的流程。這可以是「排程的流程」或「排程的 Apex」。必要步驟包括:

1. 在同步觸發中執行簡單且低成本的更新。例如,將 Status__c 欄位設定為「待處理」,或插入低成本相關記錄 (例如 Chatter 貼文),以表示該記錄需要處理。

2. 建立排程工作,無論是排程流程還是排程 Apex,其會定期執行,例如每 15 分鐘或每小時執行一次。

3. 為所有處於待處理狀態的記錄排程工作查詢、在受控制的大量內容中執行複雜邏輯,然後將記錄更新為已處理。

此模式完全將大量處理與使用者的同步儲存分離,不受觸發批次的一個工作每個交易限制的約束,並為非即時需求提供高度可調整且可管理的解決方案。

如果已排程工作的延遲不適用於業務需求,且您仍然受限於使用 CDC 或觸發的可排列,則表示結構不相符。此時必須考量不同的機制。重新評估核心應用程式設計可能會導致某些結論,例如:

• 購買附加元件以移除 CDC 物件限制。

• 從根本上挑戰業務需求,以確定近乎即時處理是否為「必須」或已排程工作的延遲是否為平台穩定性的可接受權衡。

實作的複雜程度是解決方案的總擁有成本的一部分,以及其適應不斷變化的業務需求的能力。如果未遵循最佳作法,則複雜性可能會影響任何實作。在此文件的「相關最佳作法」區段中,有降低解決方案複雜程度的建議,包括以下模式:

• 混合模式:流程中複雜邏輯的可叫用 Apex

• 使用 Apex 觸發的中繼資料架構

• 超級流程與多個流程

文件與自動化本身一樣重要。它不僅確保可維護,而且對 AI 和以工作人員為基礎的工具至關重要。文件可協助您瞭解和管理業務流程。

在流程中

• 為所有元素和變數建立一致的命名慣例。

• 使用流程的「描述」欄位說明其整體目的、觸發條件和預期成果。

• 在每個個別元素上使用「描述」欄位 (例如,Get Records、Action、Transform)。此作法是傳達意圖的最佳方法。這對於可叫用動作和子流程而言特別重要,其中描述是說明動作執行之複雜邏輯的主要位置。

In Apex

• 清楚地為程式碼加上註解,以說明邏輯背後的_原因_,而不只是說明_什麼_。

• 如果使用中繼資料驅動的架構,請確保您的中繼資料記錄包含並填入人類可讀的「描述」欄位,以說明每個處理常式類別的執行方式和執行時間。

DevOps 與來源控制是成熟開發生命週期的一部分。一律使用來源控制工具,例如 Git for Salesforce 專案。Apex 類別與 Salesforce 流程都是定義您業務邏輯的中繼資料,且必須經過版本化與管理。

在記錄觸發自動化的管理內容中,現代 DevOps 管道提供重要的優點。

• **自動化品質檢查:**如 Salesforce Code Analyzer 等工具可設定為在您的管道中自動執行。靜態分析可以在兩個自動化工具升級前偵測到有問題的模式,並標記在「流程」迴圈內效率不佳的 Get Records 元素或迴圈內的 Apex 中的 SOQL 查詢等問題,這是效能降低的常見原因。

• **迴歸防止:**隨著自動化密度的增加,變更一個流程或 Apex 類別可能會對相同物件的其他自動化產生非預期的後果。強大的 DevOps 測試策略會根據任何建議的變更執行自動化 Apex 測試,這是確保新流程版本不會中斷現有 Apex 邏輯 (反之亦然) 的最可靠方法。

• **協同合作與可視性:**來源控制是「唯一的事實來源」。它可讓管理員和開發人員並列處理相同物件的自動化。它也提供寶貴的稽核追蹤:當生產流程中斷時,您可以立即查看變更自動化_的人員_、變更自動化_時機_,以及認可訊息—變更自動化_的原因_。

針對具有混合管理員與開發人員的小組,DevOps Center 提供統一介面,協助進行所有這些步驟的編程,讓小組中的每個人皆可存取可調整的來源控制開發流程。

此統一的文件與 DevOps 學科可確保貴組織的長期運作狀況與可維護性,這對您跟隨的每位結構設計師和管理員都有益。

計畫實作之前,最好使用上述決策指南。其目標是協助您為使用個案選擇最佳產品。選取產品後,瞭解實作的現有最佳作法十分重要。

_每個物件一個工具_原則對於管理高密度自動化而言至關重要,但請勿將其解譯為純陳述式或純程式設計堆疊之間的二進位選擇。更有效且可維護的結構模式利用「混合式」模型:將「記錄觸發流程」定位為協調流程層,同時在「可叫用 Apex」內壓縮高複雜度的作業。

「記錄觸發流程」可作為業務流程的協調流程層。它擁有輸入條件和執行內容 (什麼_和_何時)。透過在此層內保留決策邏輯和路由,結構的流程拓範可透過「流程觸發探索器」保持透明且可管理,進而防止重要業務邏輯在程式碼中隱藏。

複雜元件的一個常見範例為針對「個案」記錄實作「服務層級契約」(SLA) 計算。由於 BusinessHours 物件及其相關邏輯 (對於不含非工作時間與假日的準確計算而言至關重要) 無法在流程中原生存取,因此會使用專屬的 Apex 類別。此類別通常稱為 ServiceLevelAgreementCalculator 等名稱,其設計方式是使用單一靜態方法 (以 @InvocableMethod 註釋),以計算經過的營業時間、判斷 SLA 是「在目標內」還是「已到達」,並傳回結構化輸出。此方法會壓縮 Apex 中複雜且高效能的邏輯,同時允許流程順暢地執行並整合至記錄觸發流程的陳述性協調流程層。

定義 Apex ServiceLevelAgreementCalculator 類別後,即可在記錄觸發流程中使用:

此模式示範嚴格分隔關注。陳述性層用於管理交易生命週期和協調流程,而程式碼用於高複雜度執行。透過將程式碼視為功能公用程式而非基礎,我們能夠平衡效能與維護性。

模組性:決策會從整個程序使用 Apex 或流程的單數性遠離。而是會將複雜邏輯壓縮為離散、大量安全且可獨立測試的單元。這些單位會作為陳述性層耗用的可重複使用元件運作,確保自動化會調整規模,而不會使結構設計變得複雜。

可重複使用:性邏輯會與觸發事件分離。設計良好的程式碼單位 (例如 InvocableMethod) 會寫入一次,但會利用多個進入點:記錄觸發的流程、畫面流程或外部整合。此程式碼重複使用可免除冗餘開發。

永續性:流程流程邏輯在陳述性流程中保持可見且可管理。此集中化會大幅減少除錯負擔,並確保系統的執行指示是決定性且透明的。

雖然使用流程中可叫用 Apex 的混合式模型功能強大,但並非一體適用的方法。結構設計師必須先瞭解特定限制和權衡,才能認可混合式解決方案。

• 無儲存前支援:這是最嚴重的限制。「可叫用動作」僅適用於儲存後內容 (動作和相關記錄的流程)。無法在高效能儲存前內容 (快速欄位更新的流程) 中使用。因此,此模式無法用於委派相同記錄欄位更新。在儲存前流程或在內容前 Apex 觸發中,使用原生「流程」元素執行高效能工作。

• 無刪除後支援:「記錄觸發流程」目前不支援取消刪除後內容。如果 Salesforce 物件具有從資源回收筒還原記錄時執行自動化的業務需求,則 Apex 觸發是唯一的解決方案。

• **在大量案例中的效能負擔:**從流程執行階段轉換至 Apex 執行階段並非零成本作業。雖然通常快速,但從「流程」的執行階段放入「可叫用動作」的動作在運算上並非如同完全留在 Apex 觸發內的原生執行一樣快速。針對大多數的中密度自動化,此微重設為可提高無障礙性的可忽略且值得權衡。不過,針對極端高效能、大量案例,純粹 Apex 僅限架構將具有原始運算速度優勢。

雖然自動化密度摘要提供更新的綠色欄位結構最終指引,但企業 Salesforce 環境的實際狀況通常更為細微。在成熟的組織中,通常會找到記錄觸發的流程和在相同的 Salesforce 物件上作業的 Apex 觸發。此案例與之前所述的混合模式不同:在此,流程與 Apex 觸發並未與之配對,且並未設計為共同運作。

此共存通常是由於平台功能不斷發展或舊版技術債務所導致。雖然這是可接受的作業狀態,但結構設計師必須將其視為已計算的權衡,而非結束狀態。

區隔的協調流程會造成嚴重的管治與維護負擔,導致開發、測試和事件處理活動遭到中斷且繁琐。這會導致解決時間 (TTR) 和作業複雜度增加。

• 針對新的 Salesforce 物件,請遵循自動化密度原則作為主要指引。

• 針對具有混合式足跡和雙 Apex 觸發和記錄觸發流程進入點的現有 Salesforce 物件,請評估密度,然後將架構器重新產生至可維護的混合式狀態。

  • 針對低密度,重構器 Apex 會觸發記錄觸發流程,並指定執行順序,將其帶往單一自動化進入點。

  • 針對中度密度,重構器複雜的大型流程會以正確的執行順序流入流程子集。僅在絕對必要時 (例如支援取消刪除內容後) 導入 Apex 觸發。

  • 針對高密度,建議實作 Apex 觸發。

隨著組織在 Salesforce 平台上的業務流程成熟,記錄觸發自動化的數量和複雜度不可避免地增加。基礎最佳作法是維護每個 Salesforce 物件 一個 Apex 觸發。此規則十分重要,因為平台不保證針對相同事件在相同物件上執行多個觸發的執行順序。此限制可能會導致非決定性行為、種族條件和難以除錯的問題。

然而,遵循 _單一觸發_原則導致架構挑戰:如何以可維護且可調整的方式管理和協調從該單一進入點叫用的所有業務邏輯。

此結構的第一個進化是 Classic 觸發處理常式模式。在此方法中,單一 Apex 觸發會將其所有的邏輯委派給對應的處理常式類別 (例如,OpportunityTriggerHandler)。此方法會將邏輯與觸發檔案分開,並為開發人員提供對處理常式類別方法中執行順序的決定性控制 (例如,afterInsert())。

雖然是改善方式,但此模式通常會導致單一處理常式類別。隨著時間的推移,隨著業務需求增加,類別會變得較大、難以管理,且難以獨立測試。所有個別程序的執行順序會在單一方法中硬式編碼,使類別容易發生合併衝突,進而在大型企業環境中大幅增加監管和維護負擔。

為了解決模組化與協調的核心問題,結構設計師會改用「中繼資料驅動觸發架構」。這是一個重要的結構突破,將自動化邏輯本身與執行_方式_和執行_時間_的組態分開。

此架構以三個主要優點為基礎:

• **分割:**系統會將核心業務邏輯細分為小型原子 Apex 類別 (例如,RecalculateAccountValues 類別或 NotifySalesLeads 類別),每個類別都遵循「單一責任原則」。此模組性可讓邏輯在隔離中更容易測試、除錯和瞭解。

• **順序和作法:**執行指示不再以 Apex 硬式編碼。而是由組態記錄以宣告的方式定義,通常儲存在自訂中繼資料類型中 (例如,TriggerAction__mdt)。這可讓管理員透過修改中繼資料記錄來重新排序、新增或移除自動化動作,這不需要部署或程式碼變更。

• **略過功能:**架構提供標準化且細微的略過功能。每個自動化動作都可以透過其中繼資料記錄設定為全域關閉,或透過參照自訂權限來針對特定管理使用者略過。

物件的單一 Apex 觸發程序則只會作為動態分派員使用。它不包含業務邏輯,而是會例項化中央的 MetadataTriggerHandler 類別。此處理常式會查詢自訂中繼資料記錄,以動態決定執行順序,並以指定的順序叫用正確的原子 Apex 類別。自動化在單一、透明且可管理的層級之下統一。

在強大的架構中使用 Apex 的重要優點是能夠管理交易狀態,並透過去除冗餘工作來最佳化效能。隨著邏輯的累積,儲存訂單中的不同自動化通常會獨立執行相同昂貴的作業,進而耗用寶貴的管理員限制並增加 DML 作業時間。

架構的結構是透過兩個主要策略來解決此問題:

• **共用狀態管理:**在單一 Apex 交易的範圍內,會利用靜態內容和變數來快取資料。這可確保昂貴的作業 (例如組態設定的 SOQL 查詢) 僅執行一次,即使在不同記錄或觸發階段中多次叫用自動化邏輯。交易限制的耗用量大幅減少。

• **平台快取利用率:**若要超越簡單的交易內快取,請使用平台快取來避免查詢特定資料的整個資料庫。此受管理的記憶體內快取非常適合用於在整個交易過程中 (例如,設定檔、角色、營業時間) 檢索非原始資料、經常閱讀的資料。使用 Cache.CacheBuilder 介面,系統會先檢查快取,且僅在資料缺少時執行資料庫查詢,以最大化效能與延展性。

當自動化只需要變更啟動交易之記錄的欄位值時,請一律���用儲存前更新。這適用於流程中的快速欄位更新 (儲存前執行) 和 Apex 觸發中的內容前邏輯 (插入前、更新前)。

無論使用的工具為何,此模式都能執行,因為其會避免第二次 DML 作業和遞迴儲存週期。在記錄認可至資料庫 之前,系統會在記憶體中對記錄進行變更,並儲存為原始交易的一部分。系統會去除第二個儲存的額外負擔,否則會重新執行整個儲存訂單並再次觸發所有自動化。

未受控制遞迴是更新後觸發的常見陷阱,其中觸發邏輯會執行 DML 更新,進而導致再次觸發相同的觸發。這會建立一個無限迴圈,最終會以管理員限制例外來結束。雖然過去曾經用於防止此類遞迴的靜態布林值標記或已處理記錄識別碼的集合,但更精確且強大的模式是透過比較記錄本身新版本與舊版本之間的欄位值,來入口邏輯。

只有在特定感興趣的欄位實際已變更時,才執行邏輯。這可防止觸發程序在重要資料保持不變的相同交易中,對後續 DML 作業執行其邏輯。

在記錄觸發流程中,透過設定流程僅在記錄更新以符合條件需求時執行,以防止未受控制遞迴:

如果您選擇在流程中使用項目條件公式,您可以透過比較 $Record 全域變數 (代表新值) 與 $RecordPrior 全域變數 (代表儲存前的原始值) 來防止流失遞迴。例如,若要確保流程僅在「機會」上的「金額」欄位已變更時執行,請在項目條件中使用以下項目:

將新版本記錄 (Trigger.new) 的欄位值與舊版本記錄 (Trigger.oldMap) 的欄位值進行比較,以瞭解是否已發生您要尋找的特定變更。此方法可確保自動化是無效的,且只在需要時執行,進而提高系統效率並避免災難性遞迴迴迴圈。

結構良好的 Salesforce 組織需要一致且可靠的機制來略過自動化。這不是選用的功能,而是維護資料完整性和啟用管理工作的核心作業需求。

略過架構對於某些情況至關重要:

• 載入大量資料時,針對每個記錄觸發觸發程序會大幅減慢流程、造成限制例外,並建立錯誤的相關記錄和通知。略過可讓資料精簡且有效地插入。

• 整合使用者可能需要從記錄的外部系統同步化資料。當變更源自其他系統時,通常針對使用者起始的變更 (例如傳送電子郵件、建立工作) 觸發的自動化可能不理想或冗餘。

• 管理員或支援人員可能需要對記錄執行修正更新。略過機制可讓他們進行這些變更,而無須觸發標準業務自動化,這可能會造成非預期的後果。

自訂權限:實作略過邏輯的現代化、可調整標準為自訂權限。這些方法優於舊方法,原因如下:

• **彈性:**自訂權限可透過權限集指派給使用者。此作法與現代的 Salesforce 安全性和存取模型保持一致,允許細微且彈性的指派。可以將略過授與特定使用者,甚至可以暫時授與特定到期日/時間。

• **維護性:**使用自訂權限可避免將設定檔或使用者硬式編碼至自動化邏輯。如果使用者的角色變更,或新設定檔需要略過存取權,則變更為簡單的「權限集」指派,而非需要部署的程式碼或流程修改。

• **延展性:**自訂權限提供可調整的架構,可管理跨複雜使用者群組的例外狀況。這些權限集可以透過權限集、權限集群組或設定檔指派給使用者。其與權限集或設定檔的關聯也可在來源中繼資料中表示。

實作模式:將一致的略過模式套用至組織中所有記錄觸發的自動化。

略過記錄觸發流程:略過流程的最有效率方法,就是避免流程完全執行。透過將條件新增至流程的項目條件來達成此目標。

• 在記錄觸發流程的「開始」元素中,將「條件需求」設定為「公式評估為 True」。

  • 在公式產生器中,使用 $Permission 全域變數來納入自訂權限的檢查。將檢查與您現有的項目條件結合。

    • 公式模式:

  • 此模式可確保只有在使用者 未 獲指派指定的自訂權限時,流程才會執行。此檢查會在建立流程訪問之前執行,使其成為最具效能的方法。

略過 Apex 觸發架構:在 Apex 中,將略過邏輯直接整合至中繼資料驅動的觸發架構,進而允許細微控制。

• TriggerAction__mdt 自訂中繼資料類型應包含文字欄位,例如 BypassPermission__c。

  • 在 MetadataTriggerHandler 類別中,程式碼應先讀取此欄位的值,再動態執行動作。

  • 如果已填入欄位,則處理常式會使用 FeatureManagement.checkPermission() 方法判斷目前執行使用者是否具有指定的自訂權限。

  • 如果 checkPermission() 傳回 true,則處理常式會略過該特定動作並繼續進行序列中的下一個動作。

  • 此模式功能強大,因為它同時允許全域略過 (如果所有 TriggerAction__mdt 記錄都參照相同的權限) 和細微的各個動作略過 (如果不同的記錄參照不同的權限,或者有些記錄完全沒有略過權限)。

這是一種反模式,可將物件的所有自動化合併到單一的大型大型流程中。將合併為一個流程與分割為多個適當條件流程的邏輯,不會對效能造成重大影響。最顯著的績效提升來自於:

• 針對相同記錄欄位更新使用儲存前流程。

• 撰寫精確的輸入條件,以確保不會對其特定使用個案造成影響的變更排除執行流程。

流程觸發探索器可讓您將訂單值指派給物件上的每個流程,以保證依序執行訂單。