此文字已使用 Salesforce 的自動翻譯系統進行翻譯。參閱我們的 調查以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。
在此閱讀我們的更新排程。
系統會透過讓業務更快速且大規模地達成主要目標來示範自動行為。健康的自動化可讓使用者專注於高價值的工作,並減少對重複、手動工作或複雜資料輸入所花費的時間。
自動化通常是指將業務流程從一個表單轉換為另一個表單:從紙本表單轉換為數位表單,從舊系統轉換為新的系統。每個業務流程翻譯都會帶來轉換的機會。
轉換並非使用新技術為使用者導入中斷和混淆的變更。轉換是關於建立更簡單的方式來完成工作、讓業務不受摩擦地成長,以及讓業務使用者更深入地專注於對利害關係人的真正重要性。從結構角度來看,這涉及識別可以一併去除或自動處理的工作。它需要在技術使用方式與其對業務的可測量影響之間建立明確的連結。
Salesforce 自動化的重要注意事項:可透過各種工具完成,並使用程式設計和陳述性技能集。設計結構正確的自動化,並非選擇只使用一個自動化工具來建立。這是關於使用一致且可預測的方法,並讓小組開發、測試、部署和維護您設計的自動化。您的自動化應盡可能採用最可維持且可讀的形式。
本節涵蓋如何設計和重新產生自動化,讓企業能夠更快速且大規模地達成關鍵目標。您可以專注於效率與資料完整性,以改善 Salesforce 中的自動化結構。
透過 Salesforce 技術,建立自動化效率並非如往常般重建業務。這是關於深入瞭解小組將負責會議或追蹤的關鍵度量和業務成果,以及返回查看您正在自動化工作的內部和整個工作中的功能單位。您可以透過自動化來識別如何建立模式,讓業務更有效率、更快速地進行大規模作業。
有效率的自動化邏輯可讓您的系統:
- 更容易調整且對業務有價值
- 對使用者更有幫助
- 更容易適應並能夠滿足不斷變化的業務需求
您可以透過流程設計和作業邏輯改善自動化效率。
流程設計涉及定義工作完成的方式。建立真正有效率且有效率的流程表示您的設計不只是複製目前的工作方式。識別和移除無效或不明確的步驟至關重要。最佳化的流程應在沒有不必要步驟的情況下建立可測量的業務價值 (請參閱 KPI)。不明確或不必要的步驟可能會造成技術債務,並導致無法維持的自動化。
通常,探索和記錄業務流程的責任會屬於業務分析師或甚至是系統管理員的責任。結構設計師負責與這些小組成員合作,以確保您的流程設計在技術上是健全且結構良好。盡早套用您對 Salesforce 平台的 Knowledge 可協助您的小組找出要透過自動化來簡化的流程,或需要變更的流程,以避免付費自訂。
若要建立 Salesforce 的最佳化流程,請考量:
-
全面定義程序。具有不明確目的或定義不明確的程序在設計時更有可能遭到誤解。這會導致以假設為基礎的錯誤設計,這會導致自動化不正確或效率不佳。確保您要自動化的業務流程符合下列標準:
-
讓流程步驟更清楚。* 雖然新增「未來可能有幫助」的其他步驟有時會很誘人,但這絕對不是一個好方法。自動化中的每個步驟都與整體流程的結果相關。確定每個流程步驟具有下列特性:
下方的 模式與反模式清單顯示 Salesforce 組織中的正確 (和不良) 最佳化外觀。您可以在建立之前使用這些項目來驗證您的自動化設計,或識別需要進一步最佳化的自動化。
若要深入瞭解 Salesforce 提供的流程自動化工具,請參閱與自動化相關的 工具。
作業邏輯會處理從流程的設計轉換為實際實作的效率。無論交易量高峰或執行中的同時例項數量為何,具有強大作業邏輯的自動化都會持續表現良好。邏輯上,有效的自動化可協助企業更輕鬆地調整規模,以滿足更高的需求。在您的自動化中建立強大的作業邏輯,與系統的整體可靠性有直接關係。
未有效運作的自動化提供較差的使用者和客戶體驗,進而導致潛在的收入損失和客戶的 Trust 損失。其維護成本也較高,且可能會變成瓶頸,使相關程序延遲,進而造成整體系統效能問題。
若要在自動化中建立有效的作業邏輯,請考量:
- 確保所有建立自動化的使用者都知道如何執行此操作。使用任何類型的自動化工具可能會產生不良設計選擇。程式碼可能會發生錯誤或實作選項不佳,而非點按型工具。例如,使用硬式編碼參照識別碼是「流程」與程式碼中出現的反模式。按一下式工具不應視為授權,以允許任何人和每個人將自動化釋出至生產環境。建立自動化的每個小組成員都需要知道如何以正確的方式建立自動化。請參閱可讀性與 設計標準,以深入瞭解如何在整個系統中定義及套用有效標準。
- 清楚記錄所有執行路徑。自動化的使用量增加不僅會增加潛在的資料量,也會增加非預定叫用內容。您需要瞭解如何叫用不同的自動化,並確保在具有多個進入點的所有自動化中都會顯示適當的交易控制 (請參閱資料處理)。例如,畫面流程不會在大量資料載入時執行,但 Apex 觸發和觸發 (及自動啟動) 流程可能會執行。清楚記錄自動化的計畫式和潛在執行路徑是瞭解實作期間需要配合的邏輯條件的重要層面。
- 「批次」所有資料作業 (包括 SOQL)。每個資料作業 (插入、更新等) 都應針對集合執行。一律。沒有例外情況。這就是「大量處理」作業的意思。雖然平台可以支援 singleton 資料作業,但您絕不應允許實作 singleton 模式。
- 使用 SOSL 進行搜尋作業。我們錯誤地認為無法針對透過 SOSL 傳回的記錄執行資料作業。事實上,無法直接針對 SOSL 結果叫用 DML,但程式碼可以剖析 SOSL 結果,並建立可在 DML 或資料庫類別方法中參照的集合。SOSL 與 SOQL 之間的關鍵差異是各自的傳回類型,以及其回應廣義或萬用字元搜尋的方式。SOSL 可以針對數種 sObject 類型運作 (這就是傳回類型不同的原因),並能處理與 SOQL 相較的萬用字元和廣義字串搜尋,效能更佳。
- 將 SOQL 視為資料作業。請勿使用 SOQL 尋找記錄,請使用它來限定資料作業。SOQL 和資料作業對 基本關聯式資料庫的效能有非常類似的影響。SOQL 甚至可以傳遞 明確的 DML 指標,該指標會在預期資料作業時鎖定資料庫列。若要建立可調整的自動化,請確保您以類似的盡職調查方式處理 SOQL:不要在沒有非常具體且格式正確的選取條件的情況下使用 SOQL,不要允許外部欄位參照,並要求在
WHERE陳述式邏輯中仔細比對欄位和篩選輸入的資料類型。您的程式碼也應有適當的控制項,以確保查詢永不在非大量處理的環境中執行,或針對空值或空白篩選條件執行。 - 將同步作業專注於即時協助使用者的工作。在您的 流程最佳化期間,識別與使用者即時或近乎即時需要完成的相關邏輯,以及可延後至非同步 (非同步) 交易的項目。請參閱「資料處理」,以取得設計同步化/非同步化作業的詳細考量事項。
下方的 模式與反模式清單顯示 Salesforce 自動化中的正確 (與不良) 作業邏輯外觀。您可以在建立之前使用這些項目來驗證您的自動化設計,或識別需要進一步最佳化的自動化。
若要深入瞭解可協助您計畫規模的 Salesforce 可用工具,請參閱與自動化相關的 工具。
自動化 KPI 測量自動化隨著時間的影響。若沒有自動化功能,您將無法確定自動化是否真正增加業務價值,或為使用者建立非預期的複雜性。您建立的每個自動化都應繫結至一組清楚且可測量的 KPI。
良好 KPI 由可測量的值與相關聯的時間範圍定義。範例包括:
- [X 數] 每個月儲存的工作時數
- 每週手動資料輸入的處理失敗減少 [Y%]
一旦您擁有清楚且可測量的 KPI,您也必須瞭解 Salesforce 中的自動化是否以及如何產生與根據這些 KPI 報告相關的資料。
下方的 模式與反模式清單顯示 Salesforce 自動化時的正確 (與不良) KPI 外觀。您可以使用這些項目來驗證現有的 KPI,或在建立之前找出需要更進一步識別 KPI 的位置。
若要深入瞭解 Salesforce 提供可協助 KPI 的工具,請參閱與自動化相關的 工具。
下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。
✨ 在「模式與反模式探索器」中探索更多效率模式。
| 模式 | 防模式 | |
|---|---|---|
| 流程設計 | 在您的組織中:
- 每個流程都提供單一特定用途 - 每個步驟都會執行特定的細微工作 - 流程以包含主要流程和支援子流程的階層結構進行組織 - 流程內所有使用者輸入都具有明確的目的 - 僅在無法使用現有系統資料時要求使用者提供資料 |
在您的組織中:
- 流程可用於多種用途,且需要額外的輸入才能提供內容 - 流程需要未使用資料的輸入 - 相關步驟群組包含與其他流程中步驟群組重疊的功能 - 當可以改用儲存的資料時,流程會要求使用者輸入 |
| 在 Apex 中:
- 每個類別都提供單一特定用途 - 每個方法都會執行特定的細微工作 - 所有輸入變數在類別中都有明確的目的 - 程式碼執行需要最少數量的資源 |
在 Apex 中:
- 類別適用於多種用途 - 方法執行多個工作,或方法執行不符合其所屬類別所述用途的工作 - 輸入變數實際不會用於方法 - 方法不必要地從資料庫或外部系統提取資料 |
|
| 作業邏輯 | 在流程中:
- 沒有變數參照硬式編碼值 (針對記錄類型、使用者等) - 所有自動啟動流程和程序都會使用決策和/或暫停元素來評估輸入條件,並防止對大型資料量執行無限迴圈或執行 - 在大型資料量內容中將流程 (包含程序) 授與 Apex 的邏輯 - 子流程用於需要在整個業務中重複使用的流程區段 |
在流程中:
- 變數具有硬式編碼值 - 必須先手動停用流程 (包含程序),才能大量載入資料 - 流程 (包含程序) 會觸發「未處理例外」通知 - 即使是簡單的流程也會定期造成與管理員限制相關的錯誤 - 流程的部分會在流程之間重複,而非使用子流程 |
| 在 Apex 中:
- 沒有變數參照硬式編碼值 (針對記錄類型、使用者等) - 所有萬用字元條件都會顯示在 SOSL 中 - SOQL 封裝在 試用中
- 迴圈內沒有 SOQL 顯示 - SOQL 陳述式是選擇性的,包括: -- 不使用 LIKE 比較或部分文字比較
-- 比較運算子使用正數邏輯 (亦即 包含, IN) 作為主要或唯一邏輯
-- = NULL、!= NULL 的使用極少見,且/或一律遵循正比較運算子
-- 沒有顯示 LIMIT 1 陳述式
-- 沒有使用 ALL ROWS 關鍵字
| 在 Apex 中:
- 變數具有硬式編碼值 - SOSL 極少或不一致用於萬用字元選取條件 - SOQL 不包含在 試用中
- SOQL 會顯示在迴圈內 - SOQL 陳述式為非選擇性,包括: -- 顯示 LIKE 與萬用字元篩選條件
-- 使用 NOT、NOT IN 條件的比較會作為主要或唯一比較運算子使用
-- = NULL、!= NULL 條件會作為主要或唯一比較運算子使用
-- 顯示 LIMIT 1 陳述式
-- 使用 ALL ROWS 關鍵字
| |
| 在您的設計標準和文件中:
- 系統會清楚概述自動化的計畫式與潛在執行路徑 - 自動化中的同步和非同步作業使用個案會清楚概述為設計標準的一部分 |
在您的設計標準和文件中:
- 自動化叫用未記錄 - 未處理同步和非同步作業的使用個案 |
|
| KPI | 在您的文件中:
- 每個自動化的輸出皆為可測量且繫結時間 - 系統會針對每個 KPI 列出負責的利害關係人 |
在您的文件中:
- KPI 不存在於自動化,或有不明確的測量時間範圍 - KPI 存在於沒有負責的利害關係人的情況下 |
| 在報告與顯示面板中:
- 與 KPI 相關的所有度量都包含在至少一個報告或顯示面板中 |
在報告與顯示面板中:
- KPI 報告不存在,或報告缺少與某些 KPI 相關的度量 |
資料完整性是指系統維護準確且完整資料的程度。Salesforce Platform 維護強大的 內建處理邏輯,專為保護儲存在個別組織關聯性資料庫中的資料完整性而設計。建立健康自動化的基本概念之一是瞭解 Salesforce 的內建資料完整性行為,並確保所有自動化設計都符合 (並確認) 這些行為。
自動化設計中最大的反模式是因為無法辨識 Salesforce 已經提供的強大資料完整性服務,以及無法使用利用這些服務的標準功能。若要設計可保護及維護資料完整性的自動化,您必須熟悉 Salesforce 作業行為的基本順序。
將資料完整性適當延伸至自訂自動化,表示您的系統可以:
- 無須手動介入即可對抗大量與大型資料量,
- 視需要強制執行使用者安全性原則,並視需要切換至系統內容,
- 在執行階段遇到錯誤,並遵循可預測的復原或失敗路徑。
您可以透過正確的資料處理和錯誤處理,將更佳的資料完整性建立在 Salesforce 自動化中。
設計 Salesforce 中正確資料處理的第一步是瞭解多重租戶平台如何處理交易。這包括瞭解 Salesforce Platform 用來在記錄層級資料作業期間確保資料完整性的內建執行行為順序。如需有關此行為影響的詳細資訊,請參閱 Salesforce 結構基本概念中的 資料庫操作。
自動化中的資料處理不佳,可能是最難識別和完全修復的反模式之一。平台執行順序的遞迴性與重疊性質可能會導致難以瞭解問題的起源。將致命錯誤或超過管理員限制的程式碼或流程特定區段可能不是基本資料處理問題的根本原因。
交易認知是建立可靠且大規模執行 Salesforce 之自動化的關鍵。這意味著確保自動化中的每個步驟都經過設計,並瞭解其與平台控制的執行順序相關的 Knowledge,可以正確執行其功能,並將資訊正確傳遞至下一個步驟。
無論您使用的自動化工具為何,適當的交易感知會遵循類似的模式,且需要一般考量事項:
- 假設系統會要求您針對大量資料執行所有自動化,且不會在任何時間通知。自動化應具有允許批次或大量執行的路徑 (請參閱「延展性」)。
- 請勿在相同的交易中混合系統和使用者內容資料作業。
- 將同步化資料作業保留在 前後 環境 中,並針對所有內容 後 動作使用非同步化作業。
- 使用 傳訊與通知可避免建立應用程式內體驗,這會要求使用者根據非同步作業的結果等待資料。
除了交易認知之外,資料處理還有第二個維度:瞭解何時在不同執行內容中執行邏輯。將自動化拆分為不同執行內容的常見原因包括:
- 大量和/或複雜的資料作業
- 大量處理作業並不保證自動化將正確處理大量資料。如果自動化中的資料作業量超過每個交易限制,您將需要使用大型資料量特有的功能 (例如透過批次 Apex 或 大量 2.0 API) 來執行資料作業。這些項目有不同的交易限制,適用於大量資料。
- 當大量執行時,需要在記錄之間周遊複雜關係階層或執行複雜重新計算 (不包括公式欄位) 的資料作業可以輕鬆超過每個交易限制。考量某個記錄更新的「雜訊」程度,以完成系統中後續動作所需的相關資料作業或 SOQL 為準。
- 自動化整個鏈中涉及的 sObject 類型可能需要您將資料作業分割成個別的交易,以避免發生「混合 DML」錯誤。
- 需要在使用者或系統環境中執行的邏輯
- 需要以非同步方式執行的邏輯
下方的 模式與反模式清單顯示 Salesforce 自動化中的正確 (與不良) 資料處理。您可以使用這些功能在建立之前驗證您的自動化設計,或識別需要重新設定以改善資料處理的自動化。
若要深入瞭解 Salesforce 可用於自動化中資料處理的工具,請參閱與自動化相關的 工具。
錯誤處理對於資料完整性而言至關重要。強大的錯誤處理也可協助您的系統調整規模並使其更具彈性。
自動化中的錯誤處理可能會導致:
- 記錄不一致和其他資料完整性問題
- 傳送不準確的通知給使用者和其他系統
- 浪費時間與資源以手動或重複處理
- 整體缺乏系統的 Trust
自動化中的錯誤處理需要授與任何執行中的程序剖析資訊錯誤的功能、根據錯誤資訊存取後續步驟應如何的邏輯,然後遵循正確的路徑。這些功能不需要在每個自動化中重複建立 (這是最佳化反模式)。相反地,系統中的每個自動化都應能夠連線至相關的錯誤處理 元件。
若要在您的自動化中建立適當的錯誤處理控制項,請詢問以下問題:
- 什麼是「致命」錯誤?
- 什麼是「可復原」錯誤?
- 針對由使用者動作觸發的自動化,自動化如何在嘗試認可變更前找出錯誤並通知使用者?
決定如何處理這些錯誤後,您可以開始在自動化中建立有效的錯誤處理。下方的 模式與防模式清單顯示 Salesforce 自動化中的正確 (與不良) 錯誤處理。您可以在建立之前使用這些項目來驗證您的自動化設計,或識別需要重新設定以改善錯誤處理的自動化。
若要深入瞭解 Salesforce 可用於錯誤處理的工具,請參閱與自動化相關的 工具。
下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。
✨ 在「模式與反模式探索器」中探索更多資料完整性的模式。
| 模式 | 防模式 | |
|---|---|---|
| 資料處理 | 在您的資料字典中:
- 存在所有資料來源和資料湖物件的欄位級資料和優先順序邏輯 - 資料湖物件到資料模型物件的欄位對應已存在 |
在您的資料字典中:
- 不包含資料來源和資料湖物件的欄位級資料和優先順序邏輯 - 不包含資料湖物件到資料模型物件的欄位對應 |
| 在您的 Apex 中:
- 在觸發執行內容 之前,會執行所有同步 DML 陳述式或資料庫類別方法 - 非同步 Apex 叫用使用在交易之間的「鏈結」複雜 DML - 批次 Apex 僅用於大量資料 - @future Apex 不會用於呼叫或系統物件 DML |
在您的 Apex 中:
- DML 陳述式會定期顯示在觸發內容 後 要叫用的程式碼中 - 極少使用非同步 Apex - 非同步 Apex 功能會被任意使用,包括: -- Future Methods 與可排列 Apex 不一致或交替使用 -- 資料庫作業沒有明確且一致的邏輯,可在需要時將執行傳送至批次 Apex |
|
| 在流程中:
- 在使用者環境中啟動的所有流程會將所有系統環境交易摘要到子流程 (會一致地放在「暫停」元素之後) 以建立新交易 - 使用協調器建立相關資料作業的複雜序列 (而非在單一流程內叫用多個子流程) - 所有記錄觸發流程均已填入觸發順序值 - 涉及外部系統呼叫或長時間執行程序的流程會使用非同步路徑 |
在流程中:
- 大型單一流程會嘗試協調相關資料作業的複雜序列 (含或不含子流程) - 記錄觸發流程完全不使用觸發順序屬性,或不一致使用觸發順序值 - 非同步路徑不會一直或完全使用 |
|
| 在您的組織中:
- 「身分解析協調規則」遵循資料字典中的優先順序邏輯 |
在您的組織中:
- 身分解析協調規則不遵循資料字典中的優先順序邏輯 |
|
| 錯誤處理 | 在 Apex 中:
- 程式碼會將所有 DML、SOQL、呼叫和其他重要程序步驟包含在 試用抓取區塊中
- 自訂例外用於建立進階錯誤傳訊和邏輯 - 在非同步和大量環境中,會使用 資料庫類別方法,而非使用 DML - 資料庫類別方法只能用於所有資料作業 (而非 DML) |
在 Apex 中:
- DML、SOQL、呼叫或其他重要程序步驟並未一致封裝在 試用區塊中
- System.debug 陳述式會顯示在生產程式碼中 (且不會加上註解)
- 未使用資料庫類別方法 - 資料作業僅使用 DML 進行 |
| 在 Lightning Web 元件 (LWC):
- JavaScript 會將所有資料作業和重要程序步驟包含在 if()/else if() 區塊中
- 所有 @wire 函數都使用 API 提供的 資料和 錯誤內容
- All if (error)/else if (error) 陳述式包含處理錯誤並提供資訊豐富訊息的邏輯 |
在 LWC 中:
- JavaScript 不會持續使用資料作業或重要程序步驟的封鎖 若 ()/其他 if ()
- @wire 函數不使用 API 提供的 資料和 錯誤內容 (或不一致使用這些內容)
- 如果已使用,則陳述式實際上不包含處理錯誤的邏輯,且不提供實用的錯誤訊息, 如果 (錯誤)/其他 (錯誤)陳述式 |
|
| 在 Aura 中:
- JavaScript 會將所有資料作業和重要程序步驟以 試取區塊括住
- 在 試用區塊內,會在 throw 陳述式中使用原生 JavaScript Error (不使用 $A.error())
- 所有可復原錯誤邏輯都會顯示在 抓取陳述式中,並提供清楚的使用者訊息 |
在 Aura 中:
- JavaScript 不會將資料作業和重要程序步驟一致括在 試用區塊中
- 元件使用 $A.error()
- 可復原錯誤邏輯不會一直顯示在 抓取陳述式中,且使用者的錯誤訊息不明確 |
|
| 在流程中:
- 畫面流程會持續使用錯誤連結向使用者顯示錯誤 - 已針對畫面上顯示的錯誤設定自訂錯誤訊息 - 具有資料作業、呼叫和其他重要處理邏輯的流程具有所有關鍵動作的錯誤路徑 |
在流程中:
- 流程不會一直或完全使用錯誤路徑 - 未使用自訂錯誤訊息,因此使用者會看到預設的「在此流程中發生未處理的錯誤」訊息 |
在自動化方面,業務價值的概念是關於流程如何對業務專案關係人產生可測量的正面影響。理想情況下,流程自動化可讓使用者更少花費時間處理重複的低價值工作。它也會透過去除可能產生錯誤的手動處理活動來協助提升資料完整性。與 流程設計類似,識別並提供將推動實際業務價值的自動化需要超出基本探索和業務分析的工作。
有時,將價值提供給業務的最佳方法似乎就是簡單地將業務使用者要求的每個流程自動化,無論其出現在待處理項目 (或票證排行榜) 中的順序,或根據您組織中的政治因素。這可能會導致兩個相關問題:以子最佳順序建立自動化,以及建立錯誤的自動化。第一個問題,即優先順序不佳,會讓高價值流程無法在應用時進行實作,進而降低成長速度。第二個問題,建立錯誤的自動化,不僅會延遲高價值的自動化傳遞,也會導致錯誤的時間、不必要的成本,以及傳送小組的挫折度增加。
您可以透過專注於 KPI 和排定優先順序來提供更大的業務價值。
| 工具 | 描述 | 效率 | 資料完整性 | 業務價值 |
|---|---|---|---|---|
| Apex 批次 | 批次記錄並處理為可管理區塊 | X | X | |
| Apex Future 方法 | 在背景中非同步執行 Apex 方法 | X | X | |
| Apex 等級 | 將 Apex 工作新增至某列,並監視這些工作 | X | X | |
| Apex Scheduler | 在指定的時間非同步執行 Apex 類別 | X | X | |
| 批准 | 指定批准記錄的必要步驟 | X | X | |
| 非同步 Apex | 非同步執行 Apex 程式碼 | X | X | |
| 自動化動作 | 在背景中執行欄位更新、電子郵件傳送和其他動作 | X | X | |
| Einstein Next Best Action | 在正確的時間向正確的人員顯示正確的建議 | X | X | |
| 電子郵件警示 | 建立與傳送自動化電子郵件 | X | X | |
| 升級動作 | 指定要對個案升級採取的自動化動作 | X | X | |
| 欄位更新 | 根據自動化更新欄位值 | X | X | |
| Flow Builder | 使用點選介面建立自動化 | X | X | |
| 流程擴充 | 存取儲存的變數作為流程中的元件輸入 | X | ||
| 流程範本庫 | 使用範本設計產業特定的流程 | X | X | |
| 流程觸發 | 自動化複雜的業務流程 | X | ||
| 可叫用動作 | 將 Apex 功能新增至流程 | X | X | |
| 協調流程 | 建立與管理多步驟自動化 | X | X | |
| 輸出訊息 | 透過收據和重試,從自動程序傳送資訊 | X | ||
| 使用流程發佈平台事件 | 透過使用者互動與自動化發佈事件 | X | ||
| 查詢最佳化工具 | 使用選擇性與索引改善查詢、報告和清單檢視效能 | X | X | |
| Salesforce 流程 | 使用 Flow Builder 建立陳述性流程自動化 | X | X | |
| 使用流程傳送通知 | 透過 SMS、WhatsApp 或 Facebook Messenger 傳送訊息 | X | X | |
| 使用程序傳送通知 | 透過 SMS、WhatsApp 或 Facebook Messenger 傳送訊息 | X | X | |
| SOQL FOR UPDATE 修飾詞 | 鎖定記錄以防止比賽條件和執行緒安全問題 | X | ||
| Strategy Builder | 識別要在記錄頁面上顯示的建議 | X | X | |
| 子流程 | 透過重複使用降低流程複雜性 | X | ||
| 使用流程訂閱平台事件 | 接收透過自動化發佈的訊息 | X | ||
| 工作動作 | 決定由自動化提供給使用者的指派詳細資料 | X |
| 資源 | 描述 | 效率 | 資料完整性 | 業務價值 |
|---|---|---|---|---|
| Apex 執行管理員與限制 | 瞭解 Apex 執行階段引擎如何強制執行限制 | X | X | |
| 批次管理資源 | 建立、管理、排程和監視批次工作 | X | X | |
| SOQL 和 SOSL 的最佳作法 | 改善具有大量資料之應用程式的查詢效能 | X | ||
| 設計標準範本 | 為您的組織建立設計標準 | X | X | X |
| 交易中的流程大量處理 | 設計流程以針對集合作業 | X | X | |
| 流程資料考量事項 | 瞭解批次資料的排程觸發流程 | X | X | |
| 流程除錯 | 測試和疑難排解流程 | X | ||
| 要求的處理方式 | 瞭解 Salesforce 如何快速處理工作並將失敗降到最低 | X | X | |
| KPI 試算表範本 | 決定特定度量的業務價值 | X | X | |
| 從可叫用動作對外部系統進行呼叫 | 使用 Apex 從流程呼叫外部系統 | X | ||
| 混合 DML 作業 | 瞭解哪些 sObject 可在相同交易中一起用於 DML | X | X | |
| 執行指示 | 瞭解插入、更新和更新插入的事件順序 | X | X | |
| 查詢計畫常見問題 | 最佳化涉及大量資料的查詢 | X | X | |
| 排程觸發流程考量事項 | 瞭解排程所觸發流程的特殊行為 | X | ||
| 交易控制 | 產生指定目前資料庫狀態的 savepoint | X | X | |
| 流程失敗時會發生什麼事? | 瞭解流程中的錯誤處理 | X | X | |
| 工作流程自動化最佳作法指南 | 開始使用 Salesforce 自動化 | X | X | X |
| 使用非常大的 SOQL 查詢 | 撰寫更有效率的 SOQL 查詢 | X |
協助我們讓 Salesforce Well-Architected 與您相關;進行我們的調查以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。