| 流程 | Salesforce 流程是一種功能強大的點選自動化工具,可讓使用者使用 Flow Builder 以視覺化方式建立複雜的業務流程、畫面和邏輯,而無須撰寫程式碼。它會自動化資料更新、傳送電子郵件和引導使用者等工作,透過如「畫面流程」(使用者互動) 和「觸發的流程」(記錄/排程事件) 等類型提供彈性。 |
| Apex | Salesforce Apex 是 Salesforce 平台的專屬物件導向程式語言,類似於 Java,用於建立自訂業務邏輯、自動化流程,並將核心 CRM 功能延伸至陳述性工具之外。 |
隨著 Salesforce 應用程式的範圍和複雜度增加,請認可單一主要進入點—記錄觸發流程或 Apex 觸發。避免在單一 Salesforce 物件上跨多個機制進行自動化分割,因為這會導致維護能力不佳和管治分割。
### 密度選取矩陣
使用此矩陣可決定 Salesforce 物件的必要結構標準。
- **記錄觸發流程**是低自動化密度的偏好解決方案。其提供的功能與無障礙平衡,非常適合直接且彼此獨立的自動化。
- **混合模式 (含可叫用 Apex 的記錄觸發流程)** 是高複雜度的中密度自動化可維護強大選擇。此模式可讓小組在陳述性流程中維護排序的作法,同時將繁重運算作業委派至 Apex,以平衡無障礙與效能。
- **Apex 觸發程序**提供可支援高密度自動化的穩固結構基礎所需的建構組塊。Apex 的效能、細微控制,以及物件導向的抽象與多型,更適合管理這些案例的複雜性和規模。
| 密度層級 | 自動化數量 | 資料量 (批次大小) | 相依性流程 | 結構標準 |
|---|---|---|---|---|
| 低 | < 15 自動化 |
標準 使用者驅動的 UI 互動或小型 API 載入 (1–200 筆記錄) |
不定 獨立邏輯。相同物件或相關物件上的 0–1 下游 DML 作業。 |
記錄觸發流程 |
| 中型 | 15–30 自動化 |
中度 標準批次處理 (具有需要謹慎大量處理的邏輯) |
已配對 「父系/子系」會更新 2–4 個下游 DML 作業。遞迴風險 |
混合模式 流程 + 可叫用 Apex |
| 高 | > 30 自動化 |
高 大量載入 API 的資料量 (2,000 – 10,000+ 筆記錄) |
複雜與遞迴 深度相依性圖表 (5+ 下游 DML 作業)。三角遞迴迴圈的風險 |
Apex 觸發中繼資料架構 |
| 能力 | 記錄觸發流程 | Apex 觸發 |
|---|---|---|
| 傳送與維護速度 | 建議 Flow Builder 的視覺使用者介面可讓管理員和其他陳述性產生器比撰寫、測試和部署 Apex 程式碼更快建立和修改自動化。此介面可讓更廣泛的小組成員提供業務價值,並減少對專門開發人員資源的依賴。 |
需要專業知識 Apex 需要適當技能的軟體開發人員來實作、測試和維護程式碼。 |
| 模組性 | 可用 記錄觸發流程預設為模組化。小組會針對特定需求建立離散流程,並使用「流程觸發探索器」將其組合進行編程,而不是使用單一邏輯。此模組化功能可啟用隔離修改與簡單擴充,大幅降低長期擁有成本。 |
可用 Apex 依設計分為功能模組。每個 Apex 類別都可實作單一功能模組。 |
| 可視性和管治 | 建議 「流程」的視覺性質提供直覺式的業務邏輯表示。「流程觸發探索器」提供物件上所有流程的合併檢視,讓結構設計師和管理員無須閱讀程式碼即可輕鬆瞭解、管理和疑難排解。 |
需要專業知識 使用中繼資料架構組織觸發是有益的,但 Apex 需要嚴謹的開發小組,才能讓程式碼保持井然有序且可維護。 |
| 高效能大量資料處理 | 不建議 處理複雜邏輯或大量資料時,達到管理員限制的風險增加。 |
建議 Apex 程式碼執行方式更接近平台的核心服務,並為開發人員提供查詢最佳化、資料處理和演算法效率的進階控制權。這會造成更佳的效能與規模,特別是在涉及大量資料的複雜案例中。 |
| 強大的邏輯與資料結構 | 可用 流程轉換元素可協助處理一些複雜的處理工作。然而,Flow 缺少原生「對應」與「設定」資料結構,使複雜的資料處理變得繁琐且計算效率不佳。 |
建議 Apex 提供對「對應」、「集」和程式設計迴圈的完整存取權,以高效率、大量安全地操作資料。作為功能完整的程式語言,Apex 也提供複雜邏輯建構、資料結構和設計模式的存取權,可協助以可維持且有效的方式解決複雜的業務問題。Apex 包含進階功能的豐富標準文件庫 (例如 BusinessHours、Crypto),目前無法在陳述性工具中使用。 |
| 交易控制 | 不可用 流程不提供部分交易認可或回復的 `Database.savepoint`、`Database.rollback` 或部分成功 DML 作業存取權。 |
可用 Apex 提供交易完整性和複雜錯誤復原情況的完整細微控制。 |
| 電子郵件散佈 | 建議 從記錄觸發流程傳送預先設定的電子郵件警示很簡單且可調整。自訂電子郵件警示可在執行階段建立與散佈。自訂電子郵件受限於 每日電子郵件傳送限制。 |
可用 Apex 可以產生和傳送自訂電子郵件訊息。所有從 Apex 傳送的電子郵件皆受限於 每日電子郵件傳送限制。 |
| 套用平台保護 | 建議 流程包含內建的保護,例如自動批次和自動重試。這些防護措施會增加對值的速度,並防止其他需要複雜手動編碼的效能陷阱。 |
需要手動實作 如大量處理等保護措施必須明確編碼 (例如管理集合並避免迴圈內的 SOQL)。自動重試並非觸發的原生功能,且需要複雜的自訂邏輯實作。 |
| 非同步處理 | 可用 流程為需要在非同步路徑中進行個別交易的自動化提供簡單機制。這些自動化會受限於每日限制。 |
可用 Apex 可透過「變更資料擷取」和由分離的觸發訂閱者處理的可排列事件來啟用完整控制。 |
| 排程處理 | 建議 流程的已排程路徑提供獨特且強大的排程功能 (例如,「結束日期前 3 天觸發」)。如果記錄的資料變更,此功能包括自動取消和重新排程。這些自動化會受限於每日限制。 |
不可用 Apex 觸發無法原生排程具有自動取消的時間記錄特定事件。雖然已排程 Apex 存在,但這是一個基本不同的機制,會在特定時間執行,且不會在作為觸發一部分的個別記錄處理期間進行排程。 |
| 排序和作法 | 可用 「流程觸發探索器」可讓管理員定義相同物件上多個流程的相對執行指示。 |
可用 觸發架構提供對自動化確切順序的細微控制。 |
| 相同記錄欄位更新 | 可用 (儲存前) 「記錄觸發流程」是最有效的陳述性選項,用於在初始 DML 認可之前更新觸發記錄。 |
可用 (儲存前) Apex 提供最高的效能產品,而且額外成本最低。 |
| 跨物件 CRUD | 可用 (儲存後) 流程適用於簡單、低複雜、跨物件 DML 作業。 |
可用 (儲存後) Apex 為跨物件 DML 作業提供超級的還原、錯誤處理和效能控制權。 |
| 減少重複的昂貴運算 | 可用 流程在透過自動大量處理來去除冗餘的查詢和 DML 陳述式方面表現出色。不過,狀態無法在不同的流程觸發之間或在一個交易內同一個流程的多個叫用之間快取或共用。在極端效能情況下,此限制可能會變得重要。 |
建議 Apex 提供用於刪除重複昂貴作業的機制。開發人員可以利用使用靜態內容與變數的交易快取,以及使用「平台快取」的平台層級快取來儲存及重複使用資料。這些技術對於減少交易管理員限制 (例如 SOQL 查詢) 的耗用,並確保高效能與延展性十分重要。 |
| 自訂錯誤處理 | 可用 CustomError 元素可以封鎖儲存作業,並向使用者顯示訊息。 |
建議addError() 方法提供彈性的欄位級和條件式錯誤傳訊。 |
| 使用個案 | 描述 | 最適合 | 理由 |
|---|---|---|---|
| 高效能批次處理 | 必須有效率地處理數千筆記錄的任何自動化 | Apex | Apex 提供豐富的 API,可用於與平台的介面和原始速度。 |
| 複雜資料處理 | 需要進階資料操作的案例 | Apex | Apex 提供「流程」中原生無法使用的資料結構,例如「對應」與「集」,這些結構對於撰寫效能高且安全的程式碼而言至關重要。 |
| 交易控制 | 控制如儲存點、結轉和部分認可等機制 | Apex | Apex 提供如 Database.savepoint 和 Database.rollback 等機制的存取權,並能夠處理部分成功的 DML 作業。 |
| 精密的自訂驗證 | 記錄中多個欄位的資料驗證 | Apex | 雖然「流程」可以防止使用「CustomError」元素儲存,但並非所有流程類型皆可使用,包含子流程。Apex addError() 方法提供多個欄位特定錯誤訊息,可在觸發處理期間隨時新增至記錄。 |
| 簡單程序內的中度複雜邏輯 | 由標準功能庫簡化,中度複雜度的邏輯與資料操作,作為不複雜流程的一部分發生 | 流程 + Apex | 「記錄觸發流程」會作為協調流程層,而高複雜度的作業會壓縮在「可叫用 Apex」內。 |
| 簡單到中度複雜的邏輯 | 低至中度複雜度的資料操作,其中會觸發主要與相關資料物件的更新 | 流程 | 流程通常是執行選項,因為其以陳述性模型為基礎,可供管理員和開發人員存取。 |
| 通知與輸出訊息 | 傳送輸出電子郵件與訊息 | 流程 | 流程可讓在記錄變更時傳送電子郵件警示和輸出訊息輕鬆且高度調整。 |
| 排程處理 | 未來動態日期自動化 (例如結束日期前 3 天) | 流程 | 已排程路徑為流程提供獨特的優勢,因為當記錄的資料變更時,平台會自動處理這些路徑的排程、取消和重新排程。 |
### 已排程工作替代項目
如流程圖所示,當您面對大量的 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](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/overview) 等工具可設定為在您的管道中自動執行。靜態分析可以在兩個自動化工具升級前偵測到有問題的模式,並標記在「流程」迴圈內效率不佳的 `Get Records` 元素或迴圈內的 Apex 中的 `SOQL` 查詢等問題,這是效能降低的常見原因。
- **迴歸防止:**隨著自動化密度的增加,變更一個流程或 Apex 類別可能會對相同物件的其他自動化產生非預期的後果。強大的 DevOps 測試策略會根據任何建議的變更執行自動化 Apex 測試,這是確保新流程版本不會中斷現有 Apex 邏輯 (反之亦然) 的最可靠方法。
- **協同合作與可視性:**來源控制是「唯一的事實來源」。它可讓管理員和開發人員並列處理相同物件的自動化。它也提供寶貴的稽核追蹤:當生產流程中斷時,您可以立即查看變更自動化_的人員_、變更自動化_時機_,以及認可訊息—變更自動化_的原因_。
針對具有混合管理員與開發人員的小組,[DevOps Center](https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5) 提供統一介面,協助進行所有這些步驟的編程,讓小組中的每個人皆可存取可調整的來源控制開發流程。
此統一的文件與 DevOps 學科可確保貴組織的長期運作狀況與可維護性,這對您跟隨的每位結構設計師和管理員都有益。
## 相關最佳作法
計畫實作之前,最好使用上述決策指南。其目標是協助您為使用個案選擇最佳產品。選取產品後,瞭解實作的現有最佳作法十分重要。
### 利用混合模式:流程中複雜邏輯的可叫用 Apex
_每個物件一個工具_原則對於管理高密度自動化而言至關重要,但請勿將其解譯為純陳述式或純程式設計堆疊之間的二進位選擇。更有效且可維護的結構模式利用「混合式」模型:將「記錄觸發流程」放置為協調流程層,同時在「可叫用 Apex」內壓縮高複雜度的作業。
#### 協調流程層級:流程
「記錄觸發流程」可作為業務流程的協調流程層。它擁有輸入條件和執行內容 (_什麼_和_何時_)。透過在此層內保留決策邏輯和路由,結構的流程拓範可透過「流程觸發探索器」保持透明且可管理,進而防止重要業務邏輯在程式碼中隱藏。
#### 複雜元件:可叫用 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 觸發。
### 使用 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` 全域變數 (代表儲存前的原始值) 來防止流失遞迴。例如,若要確保流程僅在「機會」上的「金額」欄位已變更時執行,請在項目條件中使用以下項目:
```
$Record.Amount != $Record__Prior.Amount
```
#### 在 Apex 中控制遞迴
將新版本記錄 (`Trigger.new`) 的欄位值與舊版本記錄 (`Trigger.oldMap`) 的欄位值進行比較,以瞭解是否已發生您要尋找的特定變更。此方法可確保自動化是無效的,且只在需要時執行,進而提高系統效率並避免災難性遞迴迴迴圈。
### 略過自動化
結構良好的 Salesforce 組織需要一致且可靠的機制來略過自動化。這不是選用的功能,而是維護資料完整性和啟用管理工作的核心作業需求。
略過架構對於某些情況至關重要:
- 載入大量資料時,針對每個記錄觸發觸發程序會大幅減慢流程、造成限制例外,並建立錯誤的相關記錄和通知。略過可讓資料精簡且有效地插入。
- 整合使用者可能需要從記錄的外部系統同步化資料。當變更源自其他系統時,通常針對使用者起始的變更 (例如傳送電子郵件、建立工作) 觸發的自動化可能不理想或冗餘。
- 管理員或支援人員可能需要對記錄執行修正更新。略過機制可讓他們進行這些變更,而無須觸發標準業務自動化,這可能會造成非預期的後果。
**自訂權限**:實作略過邏輯的現代化、可調整標準為自訂權限。這些方法優於舊方法,原因如下:
- **彈性:**自訂權限可透過權限集指派給使用者。此作法與現代的 Salesforce 安全性和存取模型保持一致,允許細微且彈性的指派。可以將略過授與特定使用者,甚至可以暫時授與特定到期日/時間。
- **維護性:**使用自訂權限可避免將設定檔或使用者硬式編碼至自動化邏輯。如果使用者的角色變更,或新設定檔需要略過存取權,則變更為簡單的「權限集」指派,而非需要部署的程式碼或流程修改。
- **延展性:**自訂權限提供可調整的架構,可管理跨複雜使用者群組的例外狀況。這些權限集可以透過權限集、權限集群組或設定檔指派給使用者。其與權限集或設定檔的關聯也可在來源中繼資料中表示。
**實作模式**:將一致的略過模式套用至組織中所有記錄觸發的自動化。
**略過記錄觸發流程**:略過流程的最有效率方法,就是避免流程完全執行。透過將條件新增至流程的項目條件來達成此目標。
- 在記錄觸發流程的「開始」元素中,將「條件需求」設定為「公式評估為 True」。
- 在公式產生器中,使用 `$Permission` 全域變數來納入自訂權限的檢查。將檢查與您現有的項目條件結合。
- 公式模式:
```
( ) && NOT($Permission.Bypass_This_Flow)
```
- 此模式可確保只有在使用者 _未_ 獲指派指定的自訂權限時,流程才會執行。此檢查會在建立流程訪問之前執行,使其成為最具效能的方法。
**略過 Apex 觸發架構**:在 Apex 中,將略過邏輯直接整合至中繼資料驅動的觸發架構,進而允許細微控制。
- `TriggerAction__mdt` 自訂中繼資料類型應包含文字欄位,例如 `BypassPermission__c`。
- 在 `MetadataTriggerHandler` 類別中,程式碼應先讀取此欄位的值,再動態執行動作。
- 如果已填入欄位,則處理常式會使用 `FeatureManagement.checkPermission()` 方法判斷目前執行使用者是否具有指定的自訂權限。
- 如果 `checkPermission()` 傳回 true,則處理常式會略過該特定動作並繼續進行序列中的下一個動作。
- 此模式功能強大,因為它同時允許全域略過 (如果所有 `TriggerAction__mdt` 記錄都參照相同的權限) 和細微的各個動作略過 (如果不同的記錄參照不同的權限,或者有些記錄完全沒有略過權限)。
### 多個流程與多個流程
這是一種反模式,可將物件的所有自動化合併到單一的大型大型流程中。將合併為一個流程與分割為多個適當條件流程的邏輯,不會對效能造成重大影響。最顯著的績效提升來自於:
- 針對相同記錄欄位更新使用儲存前流程。
- 撰寫精確的輸入條件,以確保不會對其特定使用個案造成影響的變更排除執行流程。
[流程觸發探索器](https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer)可讓您將訂單值指派給物件上的每個流程,以保證依序執行訂單。
## 資源
| Apex | 流程 | 作業 |
|---|---|---|