傑出作業 - 自動化模式
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 顯示面板 | ✅ 與 KPI 相關的所有度量都包含在至少一個顯示面板中 |
| 平台 | 文件 | ✅ 每個自動化的輸出皆為可測量且繫結時間 |
| 平台 | 文件 | ✅ 會針對每個 KPI 列出負責的利害關係人 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 顯示面板 | ⚡️ KPI 報告不存在,或顯示面板缺少與某些 KPI 相關的度量 |
| 平台 | 文件 | ⚡️ KPI 存在於沒有負責的利害關係人的情況下 |
| 平台 | 文件 | ⚡️ KPI 不存在於自動化,或有不明確的測量時間範圍 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 流程 | ✅ Flow Builder 用於記錄觸發的自動化 (取代流程產生器與工作流程規則) |
| 平台 | 流程 | ✅ 具有儲存前執行的記錄觸發流程會在建立記錄之前用於欄位人口 |
| 平台 | 流程 | ✅ 流程會處理決策邏輯、迴圈、API 呼叫、DML 作業和複雜的多步驟協調流程 |
| 平台 | 流程 | ✅ 流程交易控制用於在需要時認可中繼變更 |
| 平台 | 流程 | ✅ 針對流程中的寬鬆錯誤復原實作錯誤處理 |
| 平台 | 流程 | ✅ 反應性畫面流程提供動態使用者體驗 |
| 平台 | 流程 | ✅ 當業務使用者或管理員需要修改邏輯而不需要開發人員參與時,會選擇宣告自動化 |
| 平台 | 流程 | ✅ 變數不參照硬式編碼值 (針對記錄類型、使用者等) |
| 平台 | 流程 | ✅ 在大型資料量內容中將流程視為 Apex |
| 平台 | 流程 | ✅ 子流程用於需要在整個業務中重複使用的流程區段 |
| 平台 | 流程 | ✅ 所有自動啟動流程都使用決策和/或暫停元素來評估輸入條件,並防止對大型資料量執行無限迴圈或執行 |
| 平台 | 流程 | ✅ 僅在無法使用現有系統資料時要求使用者提供資料 |
| 平台 | 流程 | ✅ 流程以包含主要流程和支援子流程的階層結構進行組織 |
| 平台 | 流程 | ✅ 流程內所有使用者輸入都具有明確的目的 |
| 平台 | 流程 | ✅ 每個流程都提供單一特定用途 |
| 平台 | 流程 | ✅ 每個步驟都會執行特定的細微工作 |
| 平台 | 流程 | ✅ 在使用者環境中啟動的所有流程會將摘要系統環境交易移至子流程,並一致地放置在「暫停」元素之後以建立新交易 |
| 平台 | 流程 | ✅ 所有記錄觸發流程都填入觸發順序值 |
| 平台 | 流程 | ✅ 涉及外部系統呼叫或長時間執行程序的流程會使用非同步路徑 |
| 平台 | 流程 | ✅ 使用協調器建立相關資料作業的複雜序列 (而非在單一流程內叫用多個子流程) |
| 平台 | 驗證 | ✅ 使用驗證規則、重複規則和必要欄位,在平台層級強制執行資料完整性 |
| 平台 | 驗證 | ✅ 驗證規則會在儲存前防止輸入無效的資料 (比觸發驗證更有效) |
| 平台 | 批准流程 | ✅ 多步驟批准路由會處理具有委派批准者的並行和序列批准路徑 |
| 平台 | 批准流程 | ✅ 適用於例外狀況的批准結構帳戶 (所有批准者休假,緊急業務需求略過一般批准) |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 流程 | ⚡️ 用於新自動化的流程產生器與工作流程規則 (Flow Builder 是策略方向) |
| 平台 | 流程 | ⚡️ 當業務使用者或管理員需要修改邏輯而不需要開發人員參與時使用的程式設計自動化 |
| 平台 | 流程 | ⚡️ 流程缺少錯誤處理,導致錯誤復原不佳 |
| 平台 | 流程 | ⚡️ 變數具有硬式編碼值 |
| 平台 | 流程 | ⚡️ 必須先手動停用流程,才能大量載入資料 |
| 平台 | 流程 | ⚡️ 流程的部分會在流程之間重複,而非使用子流程 |
| 平台 | 流程 | ⚡️ 流程會觸發「未處理例外」通知 |
| 平台 | 流程 | ⚡️ 即使是簡單的流程也會導致與管理員限制相關的錯誤 |
| 平台 | 流程 | ⚡️ 流程需要額外輸入才能提供內容 |
| 平台 | 流程 | ⚡️ 流程可用於多種用途 |
| 平台 | 流程 | ⚡️ 相關步驟群組包含與其他流程中步驟群組重疊的功能 |
| 平台 | 流程 | ⚡️ 流程在儲存的資料可以改用時要求使用者輸入 |
| 平台 | 流程 | ⚡️ 流程需要未使用資料的輸入 |
| 平台 | 流程 | ⚡️ 使用從畫面元件輸出的集合執行 DML (在從畫面元件輸出集合時,利用「使用記錄或記錄集合中的識別碼和所有欄位值」設定建立、更新或刪除元素) |
| 平台 | 流程 | ⚡️ 記錄觸發流程完全不使用觸發順序屬性,或不一致使用觸發順序值 |
| 平台 | 流程 | ⚡️ 不一致或完全未使用非同步路徑 |
| 平台 | 流程 | ⚡️ 大型單一流程會嘗試協調相關資料作業的複雜序列 (含或不含子流程) |
| 平台 | 批准流程 | ⚡️ 批准結構不會考慮例外狀況 (所有批准者休假、緊急業務需求) |
| 平台 | 驗證 | ⚡️ 僅在觸發程序中強制執行資料完整性,而非驗證規則 (觸發驗證效率較低且更複雜) |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | Apex | ✅ 觸發處理常式架構會強制執行每個物件的單一觸發、大量處理、疑慮分隔和遞迴執行防止 |
| 平台 | Apex | ✅ 觸發處理常式將委派給業務邏輯的服務類別,保持清晰的關注區隔 |
| 平台 | Apex | ✅ 觸發使用靜態標記或專屬遞迴控制類別的遞迴保護 |
| 平台 | Apex | ✅ Future Apex 僅供呼叫或系統物件 DML 使用 |
| 平台 | Apex | ✅ 非同步 Apex 叫用會使用在交易之間的「可排列至鏈結」複雜 DML |
| 平台 | Apex | ✅ 批次 Apex 用於大量資料 (使用每個區塊專屬管理員限制處理大量資料) |
| 平台 | Apex | ✅ 批次工作具有錯誤處理,會記錄失敗的記錄,而不會停止整個批次執行 |
| 平台 | Apex | ✅ 大量 API 僅在必須處理大量資料時使用 (針對較少資料量利用原生 SOAP 和 REST API) |
| 平台 | Apex | ✅ Apex 適用於複雜工作流程協調流程、含重試邏輯的外部呼叫,以及受益於非同步限制的處理 |
| 平台 | Apex | ✅ 排程的 Apex 會對固定排程執行每晚維護、每日報告、定期整合同步和時間型業務規則的處理 |
| 平台 | 設計標準 | ✅ 自動化內同步和非同步作業的使用個案會清楚概述為設計標準的一部分 |
| 平台 | 文件 | ✅ 系統會清楚概述自動化的計畫式與潛在執行路徑 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | Apex | ⚡️ 使用無法預測的執行指示和重疊邏輯,在一個物件上執行多個觸發 |
| 平台 | Apex | ⚡️ 業務邏輯直接內嵌在觸發檔案中,讓測試難以執行 |
| 平台 | Apex | ⚡️ 物件之間沒有觸發處理常式架構或不一致的觸發模式 |
| 平台 | Apex | ⚡️ 批次 Apex 工作範圍大小非常小 (例如範圍大小 = 1) |
| 平台 | Apex | ⚡️ 用於外部呼叫的批次 Apex (使用批次 Apex 將大量 Salesforce 資料推送至外部系統) |
| 平台 | Apex | ⚡️ 任意使用的非同步 Apex 功能 (Future 方法與可排列的 Apex 不一致或互換使用) |
| 平台 | Apex | ⚡️ 極少使用非同步 Apex |
| 平台 | Apex | ⚡️ 資料庫作業沒有明確且一致的邏輯,可在需要時將執行傳送至批次 Apex |
| 平台 | 設計標準 | ⚡️ 未處理同步和非同步作業的使用個案 |
| 平台 | 文件 | ⚡️ 自動化叫用未記錄 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 平台事件 | ✅ 平台事件用於將發行者與訂閱者分離的事件驅動自動化 |
| 平台 | 平台事件 | ✅ 發行者不瞭解訂閱者並發佈 fire-and-forget |
| 平台 | 平台事件 | ✅ 多個訂閱者透過平台事件觸發流程、Apex 觸發或外部整合獨立回應事件 |
| 平台 | 平台事件 | ✅ 重複執行識別碼用於從 72 小時保留期間的任何時間點重新執行錯過的事件 |
| 平台 | 平台事件 | ✅ 平台事件可啟用跨組織通訊、外部系統通知和內部工作流程協調流程 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 平台事件 | ⚡️ 防止可組合自動化的發行者與訂閱者之間直接連接 |
| 平台 | 平台事件 | ⚡️ 帳戶層級升級會直接呼叫一個交易中的機會更新、帳戶小組通知和資料倉庫同步 (緊密的連接會在每次需要新的下游處理時需要對帳戶邏輯進行變更) |
| 平台 | Apex | ⚡️ 臨時使用「立即發佈平台事件」(使用的即時事件,而非「認可後發佈」,無論發佈訂單需求或記錄鎖定風險為何) |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | Apex | ✅ SOQL 陳述式使用正邏輯比較運算子 (INCLUDES、IN) 作為主要或唯一邏輯 |
| 平台 | Apex | ✅ SOQL 會在正面比較運算子之後避免 = NULL、!= NULL 或謹慎使用 |
| 平台 | Apex | ✅ SOQL 不使用 LIMIT 1 陳述式 |
| 平台 | Apex | ✅ SOQL 不使用 ALL ROWS 關鍵字 |
| 平台 | Apex | ✅ SOQL 不會顯示在迴圈內 |
| 平台 | Apex | ✅ 萬用字元條件會顯示在 SOSL 中 (非 SOQL) |
| 平台 | Apex | ✅ SOQL 陳述式會避免 LIKE 比較或部分文字比較 |
| 平台 | Apex | ✅ SOQL 封裝在 try-catch 區塊中 |
| 平台 | Apex | ✅ 變數不參照硬式編碼值 (針對記錄類型、使用者等) |
| 平台 | Apex | ✅ 每個類別都提供單一特定用途 |
| 平台 | Apex | ✅ 每個方法都會執行特定的細微工作 |
| 平台 | Apex | ✅ 所有輸入變數在類別中都有明確的目的 |
| 平台 | Apex | ✅ 程式碼執行需要最少數量的資源 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | Apex | ⚡️ SOQL 陳述式使用 NOT、NOT IN 條件作為主要或唯一比較運算子 (非選擇性) |
| 平台 | Apex | ⚡️ SOQL 陳述式使用 ALL ROWS 關鍵字 (非選擇性) |
| 平台 | Apex | ⚡️ SOQL 陳述式使用 = NULL、!= NULL 條件作為主要或唯一比較運算子 (非選擇性) |
| 平台 | Apex | ⚡️ 變數具有硬式編碼值 |
| 平台 | Apex | ⚡️ SOQL 會顯示在迴圈內 |
| 平台 | Apex | ⚡️ SOQL 陳述式經常使用 LIKE 與萬用字元篩選條件 (非選擇性) |
| 平台 | Apex | ⚡️ SOQL 不包含在 try-catch 區塊中 |
| 平台 | Apex | ⚡️ SOQL 陳述式使用 LIMIT 1 (非選擇性) |
| 平台 | Apex | ⚡️ SOSL 極少或不一致用於萬用字元選取條件 |
| 平台 | Apex | ⚡️ 課程適用於多種用途 |
| 平台 | Apex | ⚡️ 方法執行多個工作,或方法執行不符合其所屬類別所述用途的工作 |
| 平台 | Apex | ⚡️ 輸入變數實際上不會用於方法 |
| 平台 | Apex | ⚡️ 方法不必要地從資料庫或外部系統提取資料 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | Apex | ✅ 自訂例外用於建立進階錯誤傳訊和邏輯 |
| 平台 | Apex | ✅ 程式碼會將所有 DML、SOQL、呼叫和其他重要程序步驟包含在 try-catch 區塊中 |
| 平台 | Apex | ✅ 資料庫類別方法只能用於所有資料作業 (而非 DML) |
| 平台 | Apex | ✅ 在非同步與大量環境中,會使用「資料庫」類別方法而非 DML |
| 平台 | Aura | ✅ JavaScript 會以 try-catch 區塊括住所有資料作業和重要程序步驟 |
| 平台 | Aura | ✅ 在 try-catch 區塊內,會在 throw 陳述式中使用原生 JavaScript Error (不使用 $A.error()) |
| 平台 | Aura | ✅ 所有可復原錯誤邏輯都會顯示在 catch 陳述式中,並提供清楚的使用者訊息 |
| 平台 | 流程 | ✅ 具有資料作業、呼叫和其他重要處理邏輯的流程具有所有關鍵動作的錯誤路徑 |
| 平台 | 流程 | ✅ 畫面流程一律使用錯誤連結向使用者顯示錯誤 |
| 平台 | 流程 | ✅ 系統會針對畫面上顯示的錯誤設定自訂錯誤訊息 |
| 平台 | Lightning Web 元件 (LWC) | ✅ JavaScript 會以 if ()/else if () 區塊括住所有資料作業和重要程序步驟 |
| 平台 | Lightning Web 元件 (LWC) | ✅ 所有 @wire 函數都使用 API 提供的 data 和 error 內容 |
| 平台 | Lightning Web 元件 (LWC) | ✅ 所有 if (error)/else if (error) 陳述式都包含處理錯誤的邏輯,並提供資訊豐富的訊息 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | Apex | ⚡️ DML、SOQL、呼叫或其他重要程序步驟未一致封裝在試用點閱區塊中 |
| 平台 | Apex | ⚡️ 未使用資料庫類別方法 |
| 平台 | Apex | ⚡️ 僅使用 DML 執行的資料作業 |
| 平台 | Apex | ⚡️ System.debug 陳述式會顯示在生產程式碼中 (且不會加上註解) |
| 平台 | Aura | ⚡️ JavaScript 不會一致將資料作業和重要程序步驟包含在 try-catch 區塊中 |
| 平台 | Aura | ⚡️ 元件使用 $A.error() |
| 平台 | Aura | ⚡️ 可復原錯誤邏輯不會一直顯示在 catch 陳述式中,且使用者的錯誤訊息不明確 |
| 平台 | 流程 | ⚡️ 流程不會一直或完全使用錯誤路徑 |
| 平台 | 流程 | ⚡️ 未使用自訂錯誤訊息,因此使用者會看到預設「此流程發生未處理的錯誤」訊息 |
| 平台 | Lightning Web 元件 (LWC) | ⚡️ @wire 函數不使用 API 提供的 data 和 error 內容 (或不一致使用這些內容) |
| 平台 | Lightning Web 元件 (LWC) | ⚡️ 若完全使用,if (error)/else if (error) 陳述式實際上不包含處理錯誤的邏輯,並提供實用的錯誤訊息 |
| 平台 | Lightning Web 元件 (LWC) | ⚡️ JavaScript 不會一律將 if ()/else if () 區塊與資料作業或重要程序步驟搭配使用 |