# architect 決策指南 (decision-guides) - Full Documentation # Data 360 互通性 企業通常會將資料儲存在 Salesforce 和其他外部資料湖中 (例如,_Snowflake_、_Google BigQuery_、_Databricks_、_Redshift_ 或物件儲存空間,例如 _Amazon S3_)。在多個系統之間隔離資料會對想要充分運用其資料價值的公司造成挑戰,以強化 AI 驅動的體驗。Salesforce _Data 360_ 是每個 Agentforce AI 工作人員在正確時間存取正確內容的基礎情報層。 努力將多個資料湖之間的資料整合在一起的結構設計師會面臨關於如何最佳整合該資料的重要結構決策。_Data 360_ 提供資料整合的多個選項,每個選項都有不同的優點與缺點。 ## 指南概觀 本指南提供一個架構來評估哪些模式最適合整合資料時的延遲、成本、可擴展性、管治和複雜性需求,協助您選擇何時使用資料提取、零複製資料聯合或混合式方法。此指南也會協助您在不同方法之間進行選取,這些方法皆滿足不同的需求。 將外部資料湖首頁與 _Data 360_ 整合需要仔細考量資料新鮮度、管治和管道效率之間的權衡。例如,使用「零複製」資料聯合即時查詢可將資料的最新度最大化,但隨著更多資料在網路上移動,可能會降低銷售管道效率。針對大多數的實作,在多重雲端湖家生態系統中結合取用與聯合是最佳的路徑。此混合式方法可確保可調整、受管理、可互通的結構,支援低延遲的作業工作負載 (例如,即時個人化和詐騙偵測) 和分析工作負載 (例如,法規報告和歷程記錄趨勢分析)。本指南可協助您決定如何使用適當的策略來瀏覽這些權衡。 ## 重要道具 - **Data Capture** 會將資料複製到 Salesforce _Data 360,_ 並建立受管理的標準資料模型。這是您需要進行下列動作時的理想選擇: - **建立全方位的 Customer 360**,可讓您將不同的來源統一並轉換為一個信任的設定檔。 - **符合嚴格的法規合規性。**這可讓您建立可稽核的集中複本,以便密切控制資料存取與歷程。 - **Zero Copy Federation** 會即時查詢外部來源,而不會重複,以啟用即時個人化、即時顯示面板和快速來源上線。此方法提供兩個主要選項,但有必須平衡的權衡: - **即時查詢:**請將其用於位於外部資料平台中的互動式分析和即時資料顯示面板 (例如,_Snowflake_、_BigQuery_、_Redshift_ 或 _Databricks_)。這有助於透過將查詢處理推送至來源系統,並僅傳回必要的結果,以避免慢速且高成本的資料重複。此方法針對不常見或臨時的查詢最佳化,其中重新整理十分重要。適用於低 _每秒查詢 (QPS)_ 的工作負載 (查詢成本在高 QPS 時可能大幅高)。 - **快取 (加速查詢):**將此用於不常變更的頻繁資料查詢。加速查詢會維持以可設定的間隔時間 (15 分鐘到 7 天) 更新的本機快取,進而減少重複的來源點擊。此方法會平衡顯示面板效能與成本、區隔和 BI 工作負載,其中略有延遲的結果是可接受的。這不適用於次要決策。 - **檔案聯合:**針對雲端資料湖中的資料 (例如,_S3_ 或 _ADLS_) 進行大規模批次處理和 AI 模型訓練。此方法可透過直接以開放式表格格式查詢檔案,以避免慢速且高成本的採取,進而解鎖大量 ETL 資料集和資料科學工作量。 - **混合式模型**結合了針對 _統一設定檔_採取的注意事項,同時也結合了關聯性,其支援 Omni-Channel 參與、Agentforce 驅動的動作和 AI/ML 訓練。 ### 重要考量事項 - **使用混合結構。**經常需要混合資料取用與聯合。 - 針對標準資料模型和核心控管,在重要資料上使用「_資料取用_」。 - 針對所有其他資料聯合使用「_零複製」,_以保持最新狀態,並將建立和維護資料取用管道的作業負擔降到最低。 - **資料取用頻率很重要**根據業務價值、延遲需求和營運複雜度選擇頻率。 - 將 _即時_用於具有時效性的工作流程 (例如個人化、即時顯示面板和 Agentforce 動作)。 - 針對中度緊急的流程 (例如行銷活動和作業報告) 使用 _近乎即時_。 - 針對歷程記錄或低速資料集使用批次。 - **將聯合模式與延遲和效能比對。**選擇最符合您存取模式與更新性、效能與成本需求的選項。 - 將「_即時查詢」_用於在低延遲十分重要的作業顯示面板和即時個人化。 - 當查詢頻繁且略有延遲的結果可接受時,請使用 _快取 (加速查詢)_,這有助於平衡效能與成本。 - 將 _檔案聯合_用於大規模、輸送量繁多的分析或批次工作負載,這是歷史或較不敏感時間的資料集的理想選擇。 - **將管治與資料落地需求保持一致。** - 當集中化治理十分重要時,請使用 _耗用_。 - 當去中心化治理可接受時,請使用_聯邦_,同時在外部來源強制執行嚴格的監管。 - 針對來源層級原則使用「_零複製」(_例如,_列層級安全性 (RLS)_ 和資料遮蔽)。 - **為高價值工作流程排定採取優先順序。**選擇性地套用至重要流程 (例如身分解析、監管報告和作業啟用)。 - **成本與複雜性驅動決策。**即時採取可能高成本且複雜。這就是為什麼結構設計師必須將上線、儲存和轉換資料的成本對照直接透過 _零複製_查詢資料的成本進行加權。 選擇正確的整合模式 (包括_資料取用_、_零複製_或_混合式_方法) 會直接影響多重雲端平台的延遲、管治、營運效率和成本。此決策會決定如何可靠且大規模地提供即時洞察、AI 驅動的啟用和個人化參與。 ## 產品比較 此表格比較 Salesforce _Data 360_ 中的「_資料取用_」和「_零複製_」模式,專注於功能、權衡和優點,以及企業使用個案和成果。使用此作為設計混合式多雲端資料平台的參考,以平衡效能、成本和合規性。
模式類型 模式/工具 福利 考量事項 成果
資料取用 即時:
  • 透過具有 CDC 支援的「取用 API」來進行子秒延遲。
  • 連續串流銷售管道。
  • 提供立即洞察
  • 包含低延遲作業與個人化使用個案
  • 支援以事件為導向的工作流程
  • 高成本
  • 複雜結構
  • 低延遲來源系統需求
  • 大量來源可能會造成過多的串流,這會導致飽和的銷售管道
  • I/O 密集
  • 選擇性欄位與篩選可能有助於減少超額
 Agentforce:
  • 即時詐騙警示、零售個人化和作業警示
Analytics:
  • 子秒顯示面板與 KPI 監視
合規性:
  • 監管工作流程的連續客戶記錄更新
串流:
  • 每 1–3 分鐘透過原生連接器進行每個 1–3 個批次採取
  • 平衡成本與新鮮度
  • 具有比即時更簡單的結構
  • 支援增量更新
  • 輕微延遲
  • 可能不適用於重要子秒決策
  • 批次大小會影響記憶體/計算
  • 仲裁 I/O
  • 適用於可預測的重複更新模式
  • 視窗彙總可能有助於減少處理負載
 Agentforce:
  • 及時的行銷活動觸發和即時參與
Analytics:
  • 建議引擎與近乎即時的顯示面板
合規性:
  • 含稽核性的頻繁更新
批次:
  • 透過連接器或 API 提供排程的大量負載。
  • 支援物件儲存和 ETL/ELT 銷售管道。
  • 支援高成本效益的大量資料集
  • 功能簡易實作
  • 提供歷程記錄分析的可靠性
  • 資料延遲
  • 不適用於具有時效性的作業
  • 載入期間的 I/O 密集
  • 網路輸送量可能會成為大型檔案的瓶頸
  • 適用於歷程記錄彙總或監管報告工作流程
 Agentforce:
  • IT 支援票證 (Jira/ServiceNow) 和彙總工作流程
Analytics:
  • 歷程記錄分析與趨勢評估
合規性:
  • 法規報告和病患/索賠資料彙總
零複製 即時查詢:
  • 提供外部系統的直接查詢和結構描述讀取,而不需要資料重複
  • 提供最大的新鮮度
  • 功能最低儲存空間負擔
  • 支援即時作業洞察
  • 取決於來源效能
  • 高查詢量可能會影響延遲
  • 適用於含述詞推送和彙總以將 I/O 最小化的查詢
  • 避免在大量資料集中使用未篩選的查詢
 Agentforce:
  • 適用於即時活動的動態工作流程
Analytics:
  • 作業顯示面板與即時報告
合規性:
  • 遵循來源的列層級安全性和遮蔽
加速查詢 (快取):
  • 針對可設定為 15 分鐘到 7 天的聯合查詢,提供快取的本機複本。
  • 提供最佳化查詢執行
  • 減少延遲
  • 功能比重複即時查詢更低的成本
  • 改善頻繁存取模式的效能
  • 需要快取管理
  • 延遲時間取決於快取間隔
  • 適用於高頻率查詢
  • 不適用於次要決策
  • 增量重新整理僅支援更新插入;刪除的記錄不會從快取中移除。
  • 定期需要手動完整重新整理,以使快取與來源保持同步
 Agentforce:
  • 用於快速決策的預先彙總參與度量
Analytics:
  • BI 顯示面板、區隔和分析報告
合規性:
  • 使用稽核記錄持續調控的顯示面板
檔案聯合:
  • 提供物件商店或湖中大型歷史資料集的直接存取權 (例如,S3、Iceberg、Google BigQuery 和 Redshift)。
  • 處理大規模資料集
  • 在 Data 360 中需要最少的儲存空間
  • 支援 AI/ML 工作量
  • 唯讀
  • 查詢效能取決於外部系統輸送量
  • 適用於批次繁重、輸送量密集型工作
  • 不適用於即時顯示面板
 Agentforce:
  • 非典型 (批次繁重)
Analytics:
  • ML/AI 訓練、歷程記錄分析和 petabyte 級報告
合規性:
  • 管理無重複的外部資料集存取權
## Data 360 整合模式 Data 360 有三個主要的整合模式:資料提取、零複製資料聯合,以及混合式方法。 ### 資料匯入 透過「_Data Capture_」,資料會實際複製到 _Data 360_ 並完全受管理,而「_零複製」_則是資料保留在來源處。換句話說,轉換的運算是在 _Data 360_ 內部進行的,其提供集中管理與稽核。 #### 資料取用個案 在 Salesforce _Data 360 中_使用「_資料取用」_來儲存標準、受管理的資料集,以達成合規性和作業控制。當需要完整控制、稽核和可追溯性時,請使用採取。Data Capture 非常適用於受監管或高價值的工作流程,其中集中運算與管治十分重要。 其適用於建立身分解析、法規報告、任務關鍵 AI 驅動工作流程和客戶參與的信任基礎。 資料取用概觀 #### 資料取用方法 根據您使用哪個連接器來取用資料,可能會有不同的 _資料取用_方法。某些連接器提供各式各樣的方法,而其他連接器僅在批次或串流模式中運作。如需 _Data 360_ 連接器和可用方法的完整清單,請查看 [Data 360: 整合和連接器](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5)。 - **即時:** - 使用「_變更資料匯取」(CDC)_ 提供子秒匯取 - 適用於具有時效性的工作流程 (例如詐騙偵測、個人化和作業顯示面板) - 功能在 _Data 360_ 內推送轉換和彙總,這有助於減少下游 I/O 並最佳化運算用量 - 支援使用增量 CDC 將資料混亂降到最低 - **串流:** - 每 1–3 分鐘提供每 1–3 分鐘以小量增量為單位。 - 平衡更新與成本 - 適用於行銷活動協調流程、近乎即時的參與和作業報告 - 支援使用微批次控制 I/O 峰值 - 彙總來源的資料 (如果可以的話) 以減少傳輸量並最佳化儲存空間 - **批次 (已排程載入):** - 提供大型資料集的定期取用 (例如每小時、每日和每週) - 為歷程記錄資料集、法規報告和合規性使用個案提供成本效益與可靠性 - 確保計算地區設定位於與來源儲存空間相同的區域,以提升效能並最佳化成本 #### 結構設計師手冊 - **資料取用個案:** - **產生 Customer 360 統一設定檔。**建立客戶身分與屬性的單一事實來源。 - **維護法規合規性資料集。**強制管理敏感資料、歷程和稽核能力。 - **集中行銷活動協調流程。**確保行銷、銷售和服務皆從一致且信任的資料集中作業。 - **設計作法:** - 針對歷程記錄或低延遲容忍需求 (例如,歸檔報告或定期快照) 容納批次取用。 - 使用 CDC 或串流 API 來維持作業與個人化工作流程的最新狀態,以確保近乎即時更新。 - 透過套用增量負載來最佳化成本和效率來控制儲存和運算成長 (而不是重新載入整個資料集)。 - 透過運算本地性和增量處理來讓取用管道保持一致,以減少網路 I/O。 - 在 _Data 360_ 內套用轉換,以避免不必要地移動原始資料。 - **成本考量事項:** - 針對高價值且具時間敏感性的工作流程 (例如個人化、作業顯示面板或 Agentforce 驅動的動作),**即時接收**的運算與管道成本最高。 - **串流吸收**具有中度的運算和儲存成本,適用於可能容忍輕微延遲的頻繁更新 (例如行銷活動協調流程或營運報告)。 - **批次入院**的計算成本和可預測的儲存空間較低,適用於歷程記錄資料集或低頻率更新。使用特定連接器可免費從 Salesforce 組織中取用批次資料。 - **重新整理模式** 可讓您選取「_增量重新整理」_模式,進而減少整體耗用和計算成本。在 Salesforce,我們建議盡可能使用「_增量重新整理」,_以最佳化所有採取類型的效率。 - **成本**也會受到來源到 _Data 360_ 的 I/O 量影響。最佳化批次大小、分割和區域對齊方式可降低傳輸成本並改善效能。 - **行業案例:** - **財務:**_瞭解客戶 (KYC)_、_反洗錢 (AML)_ 和詐騙偵測 (若可稽核性與合規性為不可協商) 所需的資料集。 - **醫療照護:**針對病患身分解析和 HIPAA 規範的記錄,請針對這些記錄使用採取,以啟用安全且統一的檢視。 - **零售:**將 _銷售點 (POS)_、電子商務和忠誠度計畫資料合併至統一設定檔,以進行區隔和個人化。 - **電信:**使用標準、受管理的訂閱者資料支援流失預防和使用量分析。 #### 資料取用方法決策條件 | 功能 | 即時快取 | 串流捕取 | 批次提取 | | :----------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **延遲與新鮮度** | 使用支援的「_變更資料摘取」(CDC)_,可透過「取用 API」來進行次秒延遲。提供連續串流管道。適用於低延遲作業使用個案。 | 可透過原生連接器每 1–3 分鐘進行一次微批次採取。支援增量更新。預期略有延遲。 | 預期資料延遲。允許排程大量載入。提供定期取用 (每小時、每日和每週)。不適用於具有時效性的作業。 | | **主要使用個案** | 適用於低延遲作業和個人化使用個案的理想選擇。用於具有時效性的工作流程。支援以事件為導向的工作流程。用於即時詐騙警示和作業警示。 | 適用於中度緊急的程序。用於行銷活動協調流程、近乎即時的參與和作業報告。用於及時的行銷活動觸發。 | 針對大量資料集具有成本效益。可靠以進行歷程記錄分析。用於歷程記錄彙總或監管報告工作流程。適用於歷程記錄或低速資料集。 | | **結構複雜性和 I/O** | 包含高成本與複雜結構。需要低延遲來源系統。I/O 密集。大量來源會造成飽和的銷售管道。 | 具有比即時更簡單的結構。I/O 為中。適用於可預測的重複更新模式。批次大小會影響記憶體與計算。 | 實作簡單。載入期間的 I/O 密集。網路輸送量可能會成為大型批次的瓶頸。 | | **成本考量事項** | 包含最高的計算和管道成本。僅適用於高價值且具有時效性的工作流程。 | 包含仲裁運算和儲存成本。提供平衡成本與新鮮性的方法。適用於可承受輕微延遲的頻繁更新。 | 可降低計算成本和可預測的儲存空間。建議用於歷程記錄資料集或低頻率更新。透過 Salesforce 內部銷售管道可免費使用。 | | **設計作法** | 使用增量 CDC 將資料混亂降到最低。篩選並使用選擇性欄位來減少超額。 | 使用微批次控制 I/O 峰值。請考慮使用視窗彙總來減少處理量。 | 用於歸檔報告或定期快照。確定計算地區設定與來源儲存空間所在的區域相同,以進行成本最佳化。 | ### 零複製資料聯合 #### 零複製使用個案 使用「_零複製」_來即時查詢外部系統,而無須資料重複,以啟用對大型或暫時資料集的靈活性、新鮮性和可調整存取權。適用於即時顯示面板、探索分析、AI/ML 模型訓練,以及直接透過 Salesforce _Data 360_ 進行即時客戶參與。 零複製資料聯合概觀 #### 零複製方法 使用「_零複製」時_,結構設計師必須在三個可用的資料聯合方法之間選擇,每個方法都會在更新性、效能和成本之間提供自己的權衡。 - **即時查詢** - 直接針對外部系統 (例如,_Snowflake_、_Google BigQuery_、_Redshift_、_Databricks_ 等) 執行查詢,而不會重複資料。 - 最小化網路上的資料移動,並減少 Salesforce _Data 360_ 計算的 I/O,這在可向下推送述詞和彙總時為最佳。 - 適用於即時洞察和低延遲作業顯示面板。 - 取決於外部系統效能。 - **快取 (加速查詢)** - 暫時將同盟資料的快取複本儲存在 Salesforce _Data 360 中_。 - 透過可設定的持續時間 (分鐘到天) 來減少經常存取資料集的重複查詢成本和延遲。 - 資料不會永久複製或完全管理,因此系統會透過來源的排程重新整理來管理重新整理。 - _增量重新整理_僅支援更新插入。刪除的記錄不會從快取中移除。 - 定期執行完整重新整理,以確保快取與來源保持同步。 - **備註:**_Snowflake_ 連接器支援「_卸載」_功能,其使用 Snowflake 初始的暫存分類來增強加速率。此為預設啟用狀態,但可透過編輯連線來停用。 - **檔案聯合** - 提供物件存放區中大規模資料集的直接唯讀存取權 (例如,_S3_ 和具有 _Iceberg_ 的 _GCS_)。 - 適用於 AI/ML 工作負載、歷程記錄分析和 petabyte 規模報告,無須移動資料。 - 查詢效能取決於物件格式、分割和網路 I/O。如果未最佳化大型掃描,則可能會產生大量 I/O。 #### 結構設計師手冊 - **使用個案** - 隨著客戶行為變更,**即時個人化和自訂工作流程**會提供動態優惠、建議和 Next Best 動作。 - **即時顯示面板和作業分析**會直接從外部倉庫支援業務關鍵顯示面板和 KPI。 - **具有大型外部資料集的 AI/ML 模型訓練**可利用來自資料湖和倉庫的 petabyte 規模資料,而無須透過檔案聯合移動。 - **行業案例** - **零售/媒體:**透過聯合點閱串流或內容互動資料來啟用個人化建議和即時客戶參與。 - **財務:**透過查詢外部倉庫,而不重複敏感資料,以近乎即時執行詐騙偵測和風險評分。 - **技術/企業:**當資料集位於多個系統中時,支援跨雲端報告、IT 服務顯示面板和作業分析。 - **設計作法** - **即時查詢** - 當新鮮度十分重要時,用於高 QPS、低延遲的查詢。 - 將述詞和彙總推送至外部系統,以減少網路上的資料混亂。 - 避免進行不必要掃描大量資料的查詢。 - 請考慮改為裁切分割和篩選。 - **檔案聯合** - 在物件存放區中存取 petabyte 級資料集,而無須取用。 - 將物件儲存空間與 Salesforce 計算保持在相同的雲端區域中,以將延遲和匯出成本降到最低。 - 使用分割的資料欄格式 (Parquet/ORC) 和推送式篩選條件來減少 I/O 和網路傳輸。 - 利用查詢和述詞推送功能來篩選和彙總來源的資料,進而減少資料移動。 - 除非完全必要,否則請避免跨區域資料存取,因為這會增加 I/O、延遲和成本。 - **快取 (加速查詢)** - 快取經常存取的資料集以平衡成本與效能。 - 設定重新整理間隔以平衡更新與查詢成本。 - **合規性:**透過利用 _列層級安全性 (RLS)_ 並直接在聯邦系統內遮蔽原則,強制執行來源的管治。 - 以下是統一 RLS 和跨平台遮蔽的一些最佳作法: - **使用集中化企業識別碼。**將 Salesforce _Data 360_ 中的使用者與實體對應至與外部系統中身分對應的唯一集中企業識別碼。 - **符合安全性原則。**確保聯合系統中的 RLS 和遮蔽原則會根據對應的身分套用。這可在查詢外部資料時保留合規性。 - **標準化身分結構描述。**在所有資料來源之間維護一致的身分屬性 (電子郵件、使用者識別碼、客戶識別碼等),以避免不相符和存取權違規。 - **成本考量事項** - **即時查詢:**在每查詢付款模型中,會產生外部湖家計算的成本,這可能會造成高 QPS 的峰值。這適用於值大於成本變異性的關鍵性使用個案。 - **加速查詢 (快取):**此方法透過減少對來源系統的點擊來降低查詢成本 (相較於 _即時查詢),_不過,這會增加填入和重新整理快取的批次資料取用成本。這適用於頻繁存取的資料集。 - **檔案聯合:**這是「物件商店」中資料的最便宜儲存選項,但查詢成本取決於檔案大小、分割和裁切。這適用於 Petabyte 級的歷程記錄或大量資料。 #### 零複製方法決策條件 | 決策點 | 即時查詢 | 快取 (加速查詢) | 檔案聯合 | | :----------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **資料來源位置** | 外部資料湖首頁 (例如,_Snowflake_、_Google BigQuery_、_Redshift_ 和 _Databricks_) | 外部資料湖首頁 (例如,_Snowflake_、_Google BigQuery_、_Redshift_ 和 _Databricks_) | 物件存放區或雲端資料湖 (例如,_S3_、_ADLS_ 和 _GCS_),通常使用如 _Iceberg_ 等開放式表格式。 | | **用途/使用個案** | 適用於互動式分析與即時顯示面板。適用於即時個人化和動態工作流程。 | 適用於查詢頻繁,但可接受略過時的結果時。適用於 BI 顯示面板與區段。 | 適用於大規模批次處理和 AI/ML 模型訓練。適用於歷程記錄分析和 petabyte 級報告。 | | **新鮮度/延遲性** | 提供最新的方式 直接即時執行查詢。透過有效的述詞推送功能表,針對低延遲查詢最佳化來源系統時,支援次要決策。 | 當略過時的結果可接受時使用。更新程度取決於快取間隔,可設定為 15 分鐘到 7 天。 | 適用於批次繁重、輸送量密集型工作。不適用於即時顯示面板。 | | **存取模式** | 適用於不常見或臨時的查詢,其中清新性十分重要且查詢量較少。成本在高 QPS 時大幅高,因此在查詢頻率高時評估快取 (加速查詢) 很重要。 | 適用於高頻率讀取情況。改善頻繁存取模式的效能。 | 提供 r *ead-only* 存取權。適用於不需要採取的 petabyte 級資料集。 | | **效能驅動因素** | 高度依賴外部來源系統效能。適用於可將述詞和彙總向下推送至來源時。 | 與重複的即時查詢相比,減少延遲。效能取決於快取管理與間隔。 | 效能取決於物件格式、分割和外部系統輸送量。使用分割的資料欄格式 (Parquet/ORC)。 | | **成本影響** | 這是每個查詢的付款模式,因此系統會在外部湖家計算上收取成本。對於不常見的查詢而言,這符合成本效益,但費用可能會因高 QPS 量而高峰。 | 成本低於重複的即時查詢。這會減少重複查詢外部來源的需求,但會增加快取儲存空間和重新整理額外負擔。 | 這是最便宜的儲存空間選項。針對相同區域的相同雲端 AWS 設定 (例如,在 US-East-1 的 _S3_ 與同時在 US-East-1 的 _Data Cloud_ 租戶),系統不會為存取的資料列耗用信用額。跨區域或跨雲端組態 (例如,_Azure_、_GCS_ 或不同的 _AWS_ 區域) 會為存取的資料列產生信用額度耗用。查詢成本也取決於檔案大小、分割和述詞下拉式最佳化。 | | **重要考量事項** | 避免未經篩選的查詢不必要地掃描大量資料。 | 此方法需要快取管理。不適用於次要決策。 | 查詢效能主要依賴透過分割和述詞推送功能表進行最佳化。 | ### 混合式方法 混合式結構可讓結構設計師將重要資料集固定在 _Data 360 中_,以進行集中管理,同時運用聯合查詢以獲得最新狀態、減少重複,並可擴充存取大型外部資料集。此方法會平衡 I/O、計算地區設定、成本和合規性需求。 #### 混合式使用個案 使用混合式方法來結合資料取用和零複製,以提供即時且可採取動作的洞察,以達到平衡的管治、新鮮性和營運效率。針對需要可追蹤性、RLS 和遮蔽的高價值、受監管的資料集,並針對最新性和效能為關鍵的暫時或大量資料集使用同盟。 混合式方法概觀 #### 結構設計師手冊 - **使用個案** - **Omni-Channel 參與:**將歷程記錄客戶資料與即時行為混合在一起,以提供一致且感知內容的體驗。 - **AI/ML 銷售管道:**針對精密設計的標準資料集訓練模型,同時使用來自外部來源的原始或即時訊號來增強模型。 - **混合合規性和靈活性需求:**針對敏感資料套用嚴格的監管,並針對營運靈活性套用聯合。 - **行業案例** - **零售:**針對身分解析和設定檔統一使用 _摘要_,針對即時優惠和個人化使用 _同盟_。 - **醫療照護:**透過使用 IoT 裝置串流和感應器資料的即時內容使用_同盟,以_透過 _摘要_來維護金級病患記錄。 - **金融服務:**使用 _聯邦_ 來進行外部詐騙偵測和風險監視查詢,將受監管的監管資料匯入合規性管理湖。 - **設計作法** - ** 含採取的節點管理:**將高價值或受監管的資料匯入標準模型,以確保 Trust 與合規性。 - **使用聯合提升新鮮度:**允許外部湖家提供即時或大規模的資料存取,而不會重複。 - **平衡成本與績效:**設定工作量以判斷何時使用 _摘要_與_聯邦_,以將不必要的儲存和查詢成本降到最低。 - **套用階層管理:**在利用聯邦系統安全性控制 (例如,RLS 和遮蔽) 時,強制執行已收取資料的集中管理。 - **備註:**設計混合式銷售管道時,務必確保歷程記錄資料集及將彙總或篩選條件推送至聯合來源的漸進式採取,以最佳化 I/O 和運算用量。 - **成本考量事項** - 將合規性或重要資料與必要時的 _同盟_ 結合,以加權總成本與效能。__ - 當混合_取用_和_聯邦_時,請考量 I/O 和運算散佈。若要降低針對來源系統重複查詢的計算成本,請針對高讀取率且經常存取的聯合資料集使用快取 (加速查詢)。 - 使用此規則來引導採取與聯合決策:當資料頻繁存取但變更不頻繁時,_加速查詢_通常更具成本效益。不過,當資料經常變更時 (相對於存取頻率),更適當的是「_即時查詢」_或「_取用_」。以下是一些成本範例: - **加速成交:**從 1 百萬筆記錄建立並每天更新為 ~10,000 次的顯示面板,每天會檢視 20 次。_加速_成本等於大約 ~600 credits/month,相較於 _Live Queries_ 的 ~4,200 credits/month。 - **即時查詢成交:**使用每 30 分鐘變更一次資料,每天發佈 20 次的區段。_即時查詢_的成本約為 ~4,200 credits/month,相較於此重新整理頻率的_加速_成本約為 ~28,800 credits/month。 ## 使用個案決策指南 讓我們進一步瞭解一些常見的原型,說明如何套用此邏輯。 - **「單一事實來源」架構類型:集中與控管** - **案例:**您需要為整個全球企業建立符合、統一的 _Customer 360_ 設定檔。資料來自十幾個不同的系統,必須遵循嚴格的 _GDPR_ 和 _CCPA_ 法規,並且會作為所有行銷和服務互動的事實來源。 - **建議模式:****Data Capture.**此處的優先順序為監管、 Trust 和控制。在「_Data 360_」中將資料提取是建立可完全稽核且與來源系統隔離的標準設定檔的唯一方法。 - **「即時洞察」架構類型:不移動分析** - **案例:**您的資料科學小組需要對 _Snowflake_ 中大量且不斷更新的交易表執行探索查詢。同時,您的管理小組想要由相同資料提供的即時 _BI_ 顯示面板。每天移動 petabyte 的資料速度緩慢且高成本。 - **建議模式:****零複製聯邦.**此處的優先順序是速度、靈活性和大規模成本效益。_「零複製」_ 可讓您利用現有資料倉庫的強大功能進行即時查詢,而不會造成資料重複的負擔和延遲。 - **「混合智慧」架構類型:管理核心、聯合邊緣** - **案例:**您想要使用來自資料湖的即時行為訊號 (例如,點擊網站) 來增強受管理且已採取的客戶設定檔。您需要核心設定檔的穩定性,但需要即時資料的立即性才能提供即時個人化功能。 - **建議模式:****混合式方法。**使用「_Data Capture_」為您的客戶資料建立穩定的受管理核心。使用「_零複製」_ 聯合浮動的即時「邊緣」資料,然後在查詢時間將其聯結在一起,以取得完整且即時的檢視。 ## 前進路徑 企業資料策略不再專注於選擇單一整合模式,而是關於在可互通資料生態系統內架構受控制的彈性。正確的方法會將每個來源系統對應至最適合其更新性、管治、成本和存取需求的模式: - 將關鍵任務且受監管的資料集匯入 Salesforce _Data Cloud_,以達成合規性、身分解析和作業工作流程。 - 透過「_零複製」_聯合資料,以進行即時、探索性和 AI 驅動的分析,而不需要重複儲存空間。 - 當查詢頻率高且資料變更頻率低時,套用 _快取 (加速查詢)_ 可減少來源系統負載和信用額度耗用 _Hyperforce_ 上的 Salesforce _Data 360_ 提供多區域彈性與延展性。其含有 _Iceberg_ 表格的開放式湖頭,可與如 _Snowflake_、_Databricks_ 和 _S3 Iceberg 等平台進行計算分隔和互通,這_ 是真正可互通的多雲資料生態系統的支柱。 隨著資料生態系統的演變,我們必須持續平衡新鮮度、成本、效能和合規性,以維持結構靈活性。這就是為什麼透過使用聯合存取權統一已採取的受管理資料來進一步驗證您的平台十分重要。這可在雲端、區域和業務網域之間啟用即時情報、AI 啟用和企業規模個人化。 請記住,一體適用的解決方案不適合大多數企業。最佳策略會將正確的模式對應至正確的業務驅動因素。 ## 關於作者 **Yugandhar Bora** 是 Salesforce 的軟體工程結構設計師,專門在「資料和情報應用程式」平台內進行資料結構。他負責領導專注於資料管理和統一資料模型的_企業結構審查委員會 (EARB)_ 計畫,同時為自動平台佈建解決方案做出貢獻。 **Jan Fernando** 是 Salesforce _首席結構設計師辦公室 (OCA)_ 的首席結構設計師,他於 2012 年加入 Salesforce。他從入門生態系統中獲得豐富的經驗。在加入 OCA 之前,他曾在 _平台_ 組織工作十多年,在該組織領導了數項關鍵技術轉型。 # Data 360 佈建 Salesforce Data 360 是以 [Hyperforce](https://www.salesforce.com/platform/public-cloud-infrastructure/) 為基礎建立的資料平台,可將 Salesforce 和外部資料整合為每個客戶或帳戶的清晰、完整且值得信賴的全方位檢視。 由於合併和收購、區域營運、功能性分隔或歷史原因,企業經常經營多個 Salesforce 組織。結構設計師可針對 Data 360 進行數項決策,這些都會影響管理、合規性、成本、延遲,以及組織調整 AI 和跨組織平台功能的能力。 ## 指南概觀 本指南提供使用 Data 360 進行佈建決策的架構。這些決策包括: - 選取單一首頁組織與多組織組態 - 佈建多個獨立 Data 360 例項 - 使用 Data Cloud One 在單一例項下統一組織 - 在使用 Data 360 組織之間資料共用的獨立 Data 360 例項之間協同合作 Data 360 會在收到 Data 360 授權的任何生產組織上自動佈建。Data Cloud One 是 Salesforce 的多組織連線結構,允許單一首頁組織主控 Data 360 例項,而其他 Salesforce 組織連線為伴侶組織。選擇哪個組織擁有 Data 360 授權,進而成為 Data 360 首頁組織,是具有長期後果的關鍵結構性決定。 您佈建 Salesforce Data 360 的方式是基礎結構決策。它決定企業如何統一客戶資料、強制執行管治,並啟用關鍵平台功能,尤其是整個組織中的 AI、Agentforce 和分析。將組織叢集固定至單一 Data 360 可提供統一的資料模型、集中管理,並啟用企業範圍 AI 整備。伴隨組織可以存取共用中繼資料與功能,就如同資料在本機一樣。相反地,當法規、規範或自治需求阻止集中化時,多個獨立 Data 360 例項是適當的。Data 360 組織之間的資料共用可在這些例項之間啟用選用的零複製協同合作。 此決策會影響控制資料管理的人員、資料所在位置、平台功能的啟用方式,以及未來整合和 AI 計畫的順利調整。即使對於目前沒有 Data 360 的組織而言,透過開發策略來在未來新增 Data 360 存取權來為其架構進行未來的測試也十分重要。Sales、Service、Marketing、Commerce、Industry 和 Agentforce 的 Salesforce 功能逐漸以 Data 360 為基礎。想要使用這些平台功能的組織必須佈建自己的 Data 360 或連線至共用的 Data 360 作為伴侶組織。 此指南可協助結構設計師設計佈建策略,以平衡簡單性、企業範圍的一致性、合規性和延展性,確保組織可以自信地利用 Data 360 for Customer 360、AI 和跨平台創新。使用此指南判斷哪些組織需要 Data 360,以及是否使用 Data Cloud One 或 Data 360 組織之間的資料共用。此策略為以 Data 360 為中心的未來建立堅實的基礎。 ## 範疇中的產品
Salesforce Platform 標誌 Salesforce Data 360 是 Salesforce 的即時超大規模資料平台,可將來自任何來源 (CRM、網頁、行動或外部資料湖) 的資料協調並統一至可運作的單一客戶設定檔。作為 Customer 360 平台的重要元件,其可強化銷售、服務和行銷的 AI、分析和個人化體驗。
## 接待時間 - **每個組織都應規劃存取 Data 360 例項。**每個組織都必須主控 Data 360 首頁組織,或是透過 Data Cloud One 連線的伴侶組織。 - **思考企業範圍,而不是逐個組織。**避免單獨進行單一的業務線決策。理想情況下,企業結構或資料管理委員會應共同決定佈建策略。一律預期未來 AI 和分析需求,這取決於廣泛且統一的資料集。 - **及早計畫監管與擁有權。**決定要集中管理 Data 360 (傑出中心模式) 還是委派給業務行。定義管理員、安全性小組和合規性商機的角色。避免有不明確的擁有權,因為擁有權不明確可能會造成問題。 - **請記住,佈建與授權相關聯。**購買 Data 360 授權的組織會決定 Data 360 佈建的位置,而該組織的位置會決定區域。 - **瞭解資料來源支援的考量事項。**請特別注意各種公用雲端和零複製資料來源支援的區域。此外,請判斷安全性狀態是否需要「私人連線」才能連線至這些資料來源,以及是否支援區域內或跨區域連線。 - **根據單一組織或多個組織來佈建。**針對單一組織的客戶,請在現有生產組織中佈建 Data 360,以獲得最快的價值轉換時間。針對多組織客戶,請盡可能建立最少數量的 Data 360 例項,最好是使用 Data Cloud One 組態,以將複雜性降到最低。 - **僅在必要時使用** **多個 Data 360 例項。**多個例項僅在合規性、居住權或組織自主權要求時使用。在這些情況下,請使用 Data 360 組織之間的 [資料共用](https://help.salesforce.com/s/articleView?id=data.c360_a_share_data_between_dc_orgs.htm&type=5)來啟用安全的協同合作。 - **設定 Data 360 組織之間的資料共用以進行協同合作,而非針對自訂 ETL 銷售管道。**透過資料共用共用特定物件 (DMO、已計算洞察、區段)。請記住,系統不會共用標記,而耗用量會計入來源組織。 - **避免短期快速鍵。**若沒有長期計畫,請勿執行多個 Data 360 組織的概念證明 (POC)。讓試用版與早期部署符合您企業範圍佈建策略。 ## 決策點 根據這些跨部門考量事項,評估每個佈建選項 (在 Data Cloud One、Data 360 組織之間資料共用或主組織指定之間選擇)。
考量事項 重要原因 範例案例
資料落地與合規性 決定儲存與處理資料的位置。法規規則可能需要特定的區域或多個例項。 全球銀行在位於法蘭克福的 Salesforce 組織上佈建 Data 360 租戶,以遵循 GDPR。他們為其美國分部的維珍尼亞組織佈建另一個租戶。
監管與安全性 識別 Data 360 的管理員和擁有者,包括原則管理和委派策略。 具有強大中央 IT 的跨國公司建立由傑出中心管理的專屬總部組織。
自治與集中 不同的主管可能想要資料的個別擁有權。自主性優先於多個 Data 360 組織。集中化偏好 Data Cloud One。 具有獨立子公司的控股公司可讓每個 BU 執行自己的 Data 360。
延遲與效能 影響查詢速度與體驗,特別是跨區域連線至 Data 360 租戶的伴隨組織。 倫敦的銷售小組查詢來自美國 Data 360 租戶的資料可能會看到較高的延遲。
整合複雜性 更多 Data 360 租戶 = 更多管道、API 和中介軟體。合併可簡化整合。 經銷商透過合併至 Data Cloud One 組態,避免建立 10 個 ETL 管道。
零複製資料來源區域 某些連接器的跨區域存取需求可能會限制 Data 360 組織的區域或位置。 一家公司在 AWS eu-west-1 區域中有 Snowflake 例項。他們可以使用「零複製」將資料聯結至其區域中的 Data 360,但無法使用「零複製」聯結至美國區域中的 Data 360。
私人連線跨區域相容性 「私人連線」支援有時取決於資料來源是否位於與 Data 360 租戶相同的區域。 一家公司在 aws-east-1 區域中有 Snowflake 例項,他們想要透過零複製將其連線至 Data 360。只有在 Data 360 首頁組織位於相同區域時,他們才能建立「私人連線」網路連線。
成本與授權 每個 Data 360 租戶都會增加成本。合併至較少的例項可最佳化支出。 醫療照護提供者透過採用 Data Cloud One 而非多個獨立 Data 360 例項來減少授權成本。
未來延展性 今天佈建的選擇為成長奠定基礎。 SaaS 公司從單一 Data 360 例項開始,但計畫在購買 Salesforce 組織的子公司時擴展至 Data Cloud One。
企業範圍 AI 整備 AI 功能和 Agentforce 在每個組織中都需要連線的 Data 360 租戶。佈建決策會影響 AI 模型在整個企業中訓練和啟用的方式。 一家金融服務公司在 Data Cloud One 中統一資料,讓其 Einstein AI 模型能夠存取企業範圍的客戶資料。
## 使用個案 有三個主要使用個案需要 Data 360 佈建的決定: - 選擇首頁組織 - 套用多組織策略 - 在 Data 360 組織之間共用資料 ### 選擇首頁組織 當您購買 Data 360 授權時,Data 360 例項會佈建在與該授權相關聯的 Salesforce 組織中。此組織稱為 Data 360 首頁組織。首頁組織是 Data 360 例項的安卡。這包括: - Data 360 儲存空間與計算的管理 (在佈建時選取的區域中)。 - 套用管理、管治與安全性原則 - 資料取用、調和、身分解析、區隔和啟用的效能 在多組織案例中,主要組織會管理其他 Salesforce「伴侶」組織的中心 Data 360 例項。 **首頁組織:** - 決定 Data 360 例項的地理位置。 - 決定擁有與管理 Data 360 例項的人員。您 Data 360 首頁組織中的管理員可以存取在 Data 360 中取用的所有資料。 - 控制 Data Cloud One 組態中的伴侶組織連線。 - 設定您企業資料策略的基礎,稍後變更會很困難且具有破壞性。 如需有關 Data 360 首頁組織的詳細資訊,請參閱 [Data 360 整合模式與作法](/docs/architect/zh-tw/fundamentals/guide/data360_integration_patterns_and_practices)。 #### 決策:現有組織或新組織作為主要組織? 第一個重大決定是要在現有生產組織中佈建 Data 360 還是建立新的專屬組織作為主組織。 將現有組織與新組織顯示為主要組織的決策圖 **選項 A:在現有組織中佈建 Data 360** **最適用於:**具有單一 Salesforce 組織的客戶,或已擁有大多數業務流程執行所在主要集中組織的多組織客戶。 顯示現有組織中 Data 360 佈建的圖表 - **優點:** - 最簡單的路徑:Data 360 會佈建您 CRM 資料所在的位置。 - 立即存取本機「銷售」、「服務」和「行銷」資料。 - 不需要額外的整合。 - 管理的授權與環境愈少。 - 加速提早採用、試用版和生產使用個案。 - **選項:** - 可以繼承現有組織的監管或技術債務。 - 如果沒有單一「主要組織」,則選取一個「主要組織」會建立擁有權討論。 - 與組織位置繫結的績效;可能與企業範圍的落地需求不相符。 - 如果多個業務單位使用不同的組織,如果未與 Data Cloud One 配對,則本機佈建可能會導致分割。 **範例:** 具有一個 Salesforce 組織的 SaaS 公司會在該組織中佈建 Data 360,以統一客戶訂閱與支援資料。 **選項 B:在新的專用組織中佈建 Data 360** **最適用於:**具有多個 Salesforce 組織且無法符合單一主要組織的客戶,或具有強大「傑出中心」(CoE) 模式的企業。 顯示新專屬組織中 Data 360 佈建的圖表 - **優點:** - 管理的清除圖表,沒有繼承的組織複雜性。 - 集中控制多個行業。 - 根據合規性需求彈性選擇區域。 - 作為中立的「共用服務」組織,不與一個業務單位繫結。 - 針對未來 Data Cloud One 結構進行設定 (具有多個伴侶組織的主要組織)。 - **選項:** - 客戶必須授權新的 Salesforce 組織來佈建 Data 360。 - 透過 Data Cloud One 伴隨連線將組織連線至 Data 360 所需的其他整合。 - 可新增管理負擔 (使用者管理、安全性、身分)。 - 與現有生產組織中的佈建相比,時間轉換值的速度較慢。 **範例:** 一個跨國金融服務公司建立一個專屬的首頁組織來佈建 Data 360。所有業務單位組織 (零售、財富、商業銀行業務) 都會透過 Data Cloud One 連線為伴侶組織。 **決策條件**
考量事項 現有組織作為首頁組織 (偏好預設值) 將新組織作為首頁組織 (替代)
簡化 建立於現有使用者和資料結構以加速設定。
Data 360 預設會與主要組織整合。		 需要授權與設定新的 Salesforce 組織,以及管理新的額外管理負擔
時間轉價值 立即使用本機 CRM 資料 需要慢速的延展和整合。
監管 繼承現有組織的基本管理模式—現有使用者和權限集 (如果組織已為中心,則可以接受)。 清除監管狀況。適用於 COE 導向的模型。
合規性 與現有組織區域繫結的住所 選取與現有組織無關區域的彈性
績效 本機 CRM 查詢的最佳效能 取決於伴侶組織的連線能力,無論是與其他組織的相同區域或跨區域
未來延展性 與 Data Cloud One 配對時運作良好。如果選擇錯誤的組織,稍後更難進行排班 使用 Data Cloud One 輕鬆調整規模。為了保持中立性而設計。
成本 增量成本降低 來自其他環境的高額負擔
#### 建議 一般原則是,使用現有的主要組織作為您的主要組織,以儘量減少初始工作並加速採用。只有在您的長期管理或合規策略需要時,才能建立新的專屬首頁組織。針對擁有「傑出中心」(COE) 的大型企業,建立新的專屬總部組織是常見的選擇。 **單一組織環境** 在您現有的生產組織中佈建 Data 360。這可最大化簡易性和立即值。這可避免不必要的整合負擔。 **多個組織環境** 您可以選擇其中一個主要組織 (通常是您大多數業務執行所在的組織,或作為集中式 CRM 的組織) 作為主組織。這可減少複雜性、最小化設定工作,並讓您快速實現 Data 360 的價值。使用現有的主要組織也會避免管理新環境的成本和整合工作。 **何時考慮新的專用居家組織** 建立總部組織可提供彈性和中立性,但在這些情況下,時間轉換價值會變慢。 - 如果您的組織擁有強大的傑出中心 (CoE),且想要與業務單位組織分開管理。 - 如果由於合規性或組織限制,沒有單一現有組織適合。 ### 套用多組織策略 #### 多組織挑戰 企業通常會經營多個 Salesforce 組織,這不是極端個案,而是規則。截至 2024 年 2 月,約 19,000 位 Salesforce 客戶已執行一個以上的 Salesforce 組織。 為什麼會發生此情況? - **併購和併購:**新收購的公司有自己的 Salesforce 例項。 - **區域作業:**針對歐盟、北美洲、亞太區等個別組織,通常可滿足資料落地法律。 - **功能分隔:**不同的業務單位 (例如 Retail Banking、Wealth Management、Insurance) 保留自己的組織以保持自主性。 - **法規或安全性隔離:**基於合規性原因,某些產業必須以邏輯方式建立不同的組織。 - **歷史或技術原因:**隨著時間的推移,客戶會自然累積多個組織。 每個原因都個別有意義,但一起建立資料的分割。若沒有統一層,每個組織只會有客戶的部分檢視。 架構挑戰:如何將跨組織的資料統一為單一事實來源,同時遵循合規性、管治與自主性需求? --- #### Data Cloud One Data Cloud One 是 Salesforce 的多組織連線結構,允許多個 Salesforce 組織共用單一 Data 360 例項。這是具有多個 Salesforce 組織的企業建議模式。 在任何 Data Cloud One 叢集中,將一個 Salesforce 組織指定為主組織,主控 Data 360 例項。其他 Salesforce 組織會連線為伴侶組織,從主要組織的 Data 360 中取用統一的資料和中繼資料。 顯示 Data Cloud One 結構的圖表 **Data Cloud One 的運作方式** - **Data Capture and Unification (主要組織)** - 系統只會從主要組織進行所有資料取用組態 (Salesforce CRM、外部來源、串流、批次)。 - 繫結至主要組織的 Data 360 租戶可執行身分解析、調和、建模和統一至信任的客戶設定檔。 - Data 360 管理、管治原則、標記和遮蔽會從主要組織集中套用。 - **資料空間結構** - 從主要組織中,資料會組織成資料空間,這些空間會作為資料、中繼資料和程序的邏輯容器。 - 企業可以為品牌、區域或業務線路建立資料空間。 - 資料空間共用:從主要組織中,特定資料空間會選擇性與伴隨組織共用。這可確保只有相關資料 (以及相關聯的中繼資料) 會流至正確的組織。 - **中繼資料共用** 伴隨組織會從主要組織接收中繼資料定義,包括資料模型物件 (DMO)、統一設定檔結構描述、已計算洞察、區段[等](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5)。這些項目原生顯示在伴隨組織內,就如同是本機資產,但會連結至主要組織。 - **首頁組織與伴侶組織的功能** 首頁與伴隨組織的功能存取權不同。伴隨組織無法採取或統一資料,且依賴主要組織來採取、建模和統一。伴侶組織可以存取 Data 360 資料,以增強 Data 360 技術提供的平台功能,並可在共用的信任資料上建立本機洞察、區段和流程。在未來願景中,他們也可以存取啟用功能。
能力 住家組織 伴侶組織
「連線」 「設定連接器」、「建立資料串流」、「取用或聯合資料」權限 ✅ ❌
協調和統一建立並執行資料轉換和身分解析 ✅ ❌
使用資料空間與權限管理安全資料 ✅ ✅
建立區段、洞察和建立 Einstein Studio 模型 ✅ ✅
「啟用隨處」啟用、資料動作 ✅ ✅
平台功能:提示詞產生器、流程、報告、增強 [等] (https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5) ✅ ✅
Data 360 技術支援的功能:Prospecting Center、Sales 和 Service Cloud 功能、Agentforce 等 ✅ ✅
- **平台功能比對** 從使用者和產生者的角度來看,一旦共用中繼資料,首頁與伴侶組織在使用 Salesforce 平台功能方面會有一些功能差異。支援的功能清單可在「伴隨者組織」的 [Data 360 功能](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5) 中找到。 - 當中繼資料可用時,Salesforce Platform 功能 (例如流程、報告、提示詞產生器、顯示面板和其他平台原生工具) 會同時在首頁與伴侶組織中運作。 - Data 360 技術支援的功能 (例如 Agentforce、Prospecting Center、Sales Cloud Einstein 功能和 Service Cloud AI 功能) 也可在首頁與伴侶組織中順暢運作。某些功能可能正在達到完整相容性的路徑,但整體目標是針對依賴 Data 360 的所有跨雲端功能,讓首頁與伴隨者組織的功能相同。 - **消耗模型** 所有伴侶組織活動 (查詢、區段執行、Data 360 觸發流程、AI 用量、Einstein Trust Layer 記錄等) 都會從主組織中耗用 Data 360 點數。耗用流程只有一種方式:系統會集中化、計費並根據主要組織的信用分配追蹤信用額。不過,您可以逐層細分以查看每個個別組織在 Digital Wallet 中使用的信用額。 - **設計原則:水平建構** Data 360 中的水平建構是基本設計原則,主要透過 Data Cloud One 實作,允許單一 Data Cloud 例項跨多個不同的 Salesforce CRM 組織。目標是讓每個新的發行功能都能在首頁與伴隨組織中運作,而無須進行額外設定。此功能可確保 Data Cloud One 不是資料結構的選擇,而是未來的 Salesforce 平台基礎元素。 --- #### 決策:多個資料組織與共用 Data 360 (Data Cloud One) 具有多個組織的企業必須選擇 Data 360 在其生態系統中的位置和方式。他們想要在每個組織中佈建獨立的 Data 360 組織,還是使用 Data Cloud One 在單一首頁組織之下統一組織? **選項 A:多個獨立 Data 360 組織** 每個 Salesforce 組織都會佈建自己的 Data 360 例項。 **優點:** - **自發:**每個業務單位或區域都控制自己的 Data 360。 - **每個組織中的簡化:**管理、安全性和自訂項目已本地化。 - **法規合規性:**當需要嚴格的法規分隔時很實用 (例如,資料不能跨境)。 **選項:** - **資料孤島:**統一設定檔無法在組織之間達成。 - **成本較高:**每個例項都需要授權、管理與整合。客戶最終會在多個不同組織之間多次採取相同的來源資料。 - **重複工作:**必須在每個 Data 360 例項中重複身分解析、區隔和增強。 **選項 B:一個共用 Data 360 (Data Cloud One 叢集)** 單一 Data 360 會佈建在主組織中,其他的 Salesforce 組織會連線為伴侶組織。 **優點:** - **單一事實來源 (SSOT):**所有組織皆共用統一的資料模型。 - **成本效率:**僅管理一個 Data 360 授權與基礎結構。 - **統一管理:**集中套用的原則、安全性和規範控制。 - **跨組織增強:**存取伴隨組織之間的協調設定檔、洞察和區段。 - **AI 整備:**企業範圍資料集可讓 AI 模型獲得更好的訓練和啟用。 - **未來證明:**新增伴侶組織很簡單,因為不需要新的 Data 360 組織。 **選項:** - **其他準備:**One Data 360 需要規劃組織對首頁組織的連線。 - **延遲考量事項:**不同區域的同伴組織可看見較慢的查詢速度。 - **複雜管理:**如果每個組織有不同的自訂需求,則細微管理可能很複雜。 **選項 C:多個 Data Cloud One 叢集** **有時**,管治、合規或其他業務需求可能會使將每個組織分組在一起變得不實用。這可能會導致需要實作混合式解決方案,其中企業會營運數個 Data 360 組織,每個組織皆為不同的同伴組織叢集的主要組織。 **範例:** 一個跨國公司擁有多個區域的 Salesforce 組織,包括歐洲、美國和亞洲。為了遵循區域資料落地法規,他們為每個個別區域佈建一個 Data 360。 **決策條件**
考量事項 多個獨立 Data 360 組織 一個共用 Data 360 (Data Cloud One)
自治 每個組織或業務單位的高自主性 集中管理,每個組織的自主權降低
合規性 當需要嚴格分隔時很實用 (例如,地區法律) 當落地允許集中化時運作最佳
成本 授權與管理成本愈高 更具成本效益;多個組織的一個授權
監管 分割;各組織的原則不同 組織之間的集中化一致原則
資料孤立 每個組織都有自己的檢視 無 Enterprise 360 統一資料集,無重複
AI/Analytics 限制為每個組織的資料 更準確的企業範圍模型
複雜性 更多可管理的例項、更多整合 更簡單的結構,更少移動組件
績效 最適用於組織內使用個案 具有伴隨組織存取權的延遲可能增加
--- #### 建議 **偏好的模式:Data Cloud One** 若要簡化多組織企業的管治並最佳化成本,請使用具有已連線伴侶組織的單一總部組織。 **使用多個 Data 360 組織的時機:**僅在合規性、居住權或組織自主權嚴格要求時使用多個 Data 360 組織 (例如,如果歐洲營運必須因為法規而保持完全與美國營運分開)。 **如何在 Data Cloud One 中選擇主組織:**從考量其中一個主要組織開始,通常是大多數業務執行的組織。在其中佈建 Data 360 可將複雜性降到最低,並將早期價值最大化。 只有在沒有現有組織適合時,才考慮建立由 COE 小組管理的專屬首頁組織。 **一般原則:** 在多組織環境中,將 Data 360 組織的數量降到最低。將 Data Cloud One 作為預設模式,以減少重複項目、啟用 AI 整備並簡化管治。 ### 在 Data 360 組織之間共用資料 #### 資料共用的需求 雖然 Data Cloud One 是大多數企業的建議方法,但客戶可能必須佈建多個 Data 360 例項,包括: - **區域合規性。**一個跨國零售商在歐盟提供一個 Data 360,在美國提供另一個 Data 360。Data 360 至 Data 360 資料共用可讓公司從本機資料建立洞察,且仍可與美國總部共用洞察。 - **業務單位協同合作。**集團會針對零售和保險執行個別的 Data 360 組織。Data 360 組織之間的資料共用可讓使用者存取單一的權威資料來源,而無須移動或複製。透過 Data 360 組織之間的資料共用,保險組織會收到零售的「高價值客戶」區段,用於鎖定目標的交叉銷售行銷活動。 - **併購。**父系公司取得一個擁有自己 Data 360 的子公司。擁有兩個可管理的例項,保留短期資料孤立區可保留資料安全性和 SSOT 完整性。同時,兩個 Data 360 例項之間共用資料,可在轉換期間進行必要的協同合作。 - **聯邦執行顯示面板。**跨大陸的跨國公司會為每個區域佈建個別 Data 360 組織。主管想要聯合的每季績效檢視。每個區域 Data 360 都會與「執行組織」共用彙總的已計算洞察,以啟用企業範圍報告。 #### 資料共用如何運作 當有多個 Data 360 組織存在時,系統不會自動統一這些組織。Data 360 到 Data 360 資料共用可讓客戶在 Data 360 例項之間共用特定物件,而無須重複或自訂管道。這是專為跨 Data 360 組織協同合作所設計的零複製中繼資料共用機制。 - 每個 Data 360 都佈建在自己的主組織中。 - 管理員可以建立資料共用,即他們想要共用的特定物件分組。 - 所選資料的存取權會與目標組織的 Data 360 共用,其中物件會如同在本機定義一樣顯示。只有共用的存取權,基本資料會保留在來源 Data 360 中。 - 標記未共用。僅原始物件可供使用;目標組織必須視需要重新套用任何監管、作業或 AI 標記。 #### Data Cloud One 的主要差異 - 在 Data Cloud One 中,多個伴侶組織共用單一 Data 360 例項。為了確保一致,如 Agentforce、Prospecting Center 和 Tableau Next 等平台功能會在相同的基本資料上執行。 - 使用 Data 360 組織之間的資料共用時,每個組織都有自己的 Data 360。組織 A 和組織 B 中的 Agentforce 之類的功能會在其本機例項上獨立作業。不會自動進行共用,必須建立有意的資料共用,才能僅針對特定物件協同合作。 #### Data 360 組織之間資料共用的優點與缺點
因素 優點 缺點
資料落地 支援區域分隔,同時啟用協同合作。 不會移除管理多個 Data 360 組織的需求。
資料重複 複製零;無重複物件。 需要刻意選取要包含在每個資料共用的物件。
監管 共用是明確且有意的 (物件級)。 沒有標記或原則流程;目標組織必須重新套用監管。
複雜性 啟用不集中化的選用協同合作。 需要管理多個 Data 360 組織和資料共用。
**AI/Analytics** 可進行區域 AI/分析;洞察可在組織之間共用。 除非有意共用資料,否則不會有企業範圍 AI。
**平台功能** 每個組織的 Data 360 技術支援的功能會獨立執行。 沒有自動共用。若未仔細設計,則會有重複的風險。
成本 可能會減少 ETL 銷售管道的需求。 仍會產生多個 Data 360 組織的成本。耗用資料查詢和資料共用的信用額。
#### 決策條件
考量事項 Data Cloud One (偏好用於多組織) Data 360 組織之間的資料共用
單一事實來源 是,所有組織皆共用資料模型。 否—每個 Data 360 都有自己的資料模型。
合規性 僅在落地允許集中化時才適用。 當住所法禁止集中化時為必要。
監管 集中化,一致。 聯合;有意共用物件層級。
複雜性 移動組件愈少,愈簡單。 更複雜—需要組態資料共用和多個「資料」組織。
AI/Analytics 企業範圍 AI 模型。 區域 AI。選擇性共用洞察。
平台功能 「共用 Data 360」表示所有功能在首頁 + 伴侶之間一致運作。 功能會在每個 Data 360 中獨立執行;共用必須明確。
#### 建議 **如果您的企業有多個 Data 360 組織** - 在 Data 360 組織之間使用資料共用來跨組織協同合作,而不是建立自訂銷售管道或重複資料。 - 透過建立資料共用並將其授與目標組織,共用特定物件 (DMO、已計算洞察、區段)。 - 不會共用標記—接收組織必須重新套用標記,以進行監管、分類或 AI 增強。 **使用 Data 360 組織之間的資料共用** - 符合防止集中化的法規需求。 - 維護業務單位自主性,同時啟用選擇性協同合作。 - 提供跨多個區域的聯合主管顯示面板。 - 橋接無法立即合併的 M&A 案例。 **小心設計** 將 Data 360 至 Data 360 資料共用視為同盟策略,而非 Data Cloud One 的取代。 - 使用物件特定共用。 - 避免過度共用。 - 讓資料共用符合業務與合規性需求。 #### 記住 為 Data 360 佈建規劃資料策略是一個重要的長期結構決策,必須在企業範圍內進行,而非逐一組織進行。此早期策略選擇會決定統一客戶資料的方式、強制執行管治的方式,以及在整個組織中的重要平台功能 (尤其是 AI 和分析) 規模。請提前規劃監管與擁有權模型,並避免短期快速鍵導致後續分散並增加複雜性。 ## 資源 [Customer 360 是什麼?](https://www.salesforce.com/products/what-is-customer-360/) [Data 360 整合模式與作法](/docs/architect/zh-tw/fundamentals/guide/data360_integration_patterns_and_practices) [Data 360 結構](/docs/architect/zh-tw/fundamentals/guide/data-360-architecture) [Data 360 安全性結構](/docs/architect/zh-tw/fundamentals/guide/data360_security_architecture) **關於作者** Kunal Goyal 是 Salesforce 的產品管理部門主管,專注於在 Data 360 內推進多組織結構和擴充性。 自 2017 年起,他負責領導多個專注於跨組織協同合作和多租戶系統設計的計畫和產品。Kunal 是 Data 360 最佳作法結構商機之一,也是 Data Cloud One、設定、佈建和管理員體驗的產品擁有者。 Erin Wagner Tidwell 是 Data 360 的主要技術作者和內容設計師。她從 2013 年開始在 Salesforce 工作。她致力於透過清楚、一致且準確的技術文件和應用程式內通訊,讓 Data 360 更容易理解和使用。 Yugandhar Bora 是 Salesforce 的「軟體工程結構設計師」,專門在「資料和情報應用程式」平台內進行資料結構。他負責領導企業結構審查委員會 (EARB) 計畫,專注於資料管理和統一資料模型,同時為自動平台佈建解決方案做出貢獻。 Samarpan Jain 是 Salesforce 的首席結構設計師,專門處理 Commerce Cloud、平台整合和跨組織結構。他是 Salesforce 最長期的員工之一,負責主要計畫,包括政府客戶的資料落地合規性與 Data 360 用量歸屬系統。 # 非同步處理 使用此指南為每個使用個案選擇正確的 Salesforce 非同步處理方法。 ## 指南概觀 本指南將協助您評估 Salesforce 平台上非同步處理需求的正確方法。它會解釋每個方法,並詳細說明每個方法的優勢與限制。大多數方法與產品功能一致,但某些方法在協調中使用多個功能。此指南包含使用個案來醒目提示每個方法的使用時機。 非同步處理為您的結構提供兩個主要優點。首先,由於非同步程序有較高的管理員限制,因此會增加擴充性。其次,非同步要求會在自己的執行緒中執行,因此使用者可以在非同步工作在背景中執行時執行其他工作。 請注意,本指南專注於在 Salesforce Platform 內選擇非同步處理技術。其他可協助您決策流程的資源會列在「[資源」區段中](#資源)。 ## 此指南範疇中的產品
Salesforce Platform Salesforce Lightning Platform 是一個全方位、 AI 驅動的平台,可將員工、獨立 AI 工作人員、公司資料和應用程式整合到一個可靠的系統中,以提升生產力與客戶體驗。透過連接 Customer 360 應用程式、Data Cloud 和 Slack 來進行端對端自動化,以便建立「真正的企業」。
此文件不涵蓋其他生態系統中的技術,例如 MuleSoft、Informatica、Commerce Cloud、Tableau 和 Marketing Cloud。 ## 接待時間 - **使用非同步處理之前,請確定您的使用個案符合模式。**非同步模式沒有 SLA、受限於多個管理員機制、可根據授權定義產能限制,且可能會因為配置給 Salesforce Platform 中非同步基礎結構的資源有限性而導致處理延遲。在使用者需要系統回應的情況下使用非同步處理時,請考量這些限制,才能繼續進行其工作。 - **使用 Salesforce 進行非同步處理並非滿足無限調整需求的解決方案。**Salesforce Platform 不會無限規模,非同步模式受到限制。非同步處理使用執行緒,其中包含 CPU 執行指示串流所需的內容資訊。討論串可以並列執行。任何 CPU 中可用的執行緒數目受到限制,因此平台已具備機制,以盡可能有效率地使用其可用的執行緒。平台的 [流程控制機制](/docs/architect/zh-tw/fundamentals/guide/async-fundamentals#流程控制)可防止組織耗用太多執行緒,並對其他組織造成負面影響。平台的 [公平使用演算法](/docs/architect/zh-tw/fundamentals/guide/async-fundamentals#公平使用)也控制組織針對每個特定訊息類型可用的執行緒數目。 - **會考量造成極度負載的事件。**當您設計非同步流程時,請確定流程可以預測地管理工作量高峰和閒置。請考慮您的實作如何處理非預期的事件,例如停電,以及設計可減輕資料遺失或功能遺失的安全防護。 ## 產品比較 此表格概述使用 Salesforce 進行非同步處理的可用工具。請參閱此表格,在決策流程期間檢閱每個工具的主要特性。請參閱「[使用個案](#使用個案)」和「[決策點](#決策點)」,以協助為您的結構選擇正確的工具。
方法 描述 所需技能 授權與限制
可排序的 Apex 用於涉及長時間執行資料庫作業或外部 Web 服務呼叫的流程。Apex 提供工作識別碼、支援非原始類型和工作鏈等功能。 專業程式碼 授權數量會增加限制。
批次 Apex 透過分割記錄集並將其處理成可管理區塊,建立複雜且長時間執行流程,其中涉及數百萬筆記錄。 專業程式碼 授權數量會增加限制。
已排程 Apex 在由 Cron 運算式定義的排程時間執行 Apex。雖然透過 Cron 運算式排程 Apex 的動作是非同步的程序,但基本程式碼會在工作開始時同步執行。 專業程式碼 授權數量會增加限制。
Apex 繼續呼叫 從在同步交易內容中執行的 Apex 方法執行呼叫。 專業程式碼 否
非同步路徑 (記錄觸發流程) 執行您要在自己的時間執行的作業。請避免在您更新非觸發流程記錄相關記錄值時發生的混合 DML 錯誤。 低程式碼 授權的數量與類型可增加限制。
排程路徑 (認可流程後) 在觸發事件後動態排程的時間執行,例如建立、更新或刪除記錄時。 低程式碼 授權的數量與類型可增加限制。
已排程流程 在特定時間和重複的頻率 (每日、每週或一次) 在背景中執行流程,以對記錄批次執行動作。 低程式碼 授權的數量與類型可增加限制。
平台事件觸發 寬鬆將 Salesforce 與外部系統配對,並在 Salesforce Platform 內非同步元件之間通訊。 低程式碼 + 專業程式碼 大量平台事件使用個案需要附加元件授權
變更資料取取 認可資料庫交易後,以非同步方式來捕捉和處理變更事件。 專業程式碼 需要附加元件授權,才能將比例大於基準配置。
大量 API 以非同步方式插入、更新、更新插入、查詢或刪除許多記錄,之後再處理結果。 專業程式碼 有一些限制。
Lightning 動作 允許 Lightning 頁面與伺服器互動,而無須強制使用者完全重新整理頁面。 低程式碼 否
## 決策點 此表格包含當您決定要使用哪個非同步工具時要考量的要點概觀。
所需技能 此指南中概述的部分工具需要程式碼,而其他工具則可以宣告的方式進行設定。當您考量您的選項時,請思考小組成員擁有的技能集。請記住,即使開發人員可用於您的初始實作 (例如透過實作合作夥伴),您可能需要在未來修改您的解決方案。如果您的維護小組缺少開發人員,低程式碼選項可能更適合。
強制執行的平台限制類型 決定套用至執行的 限制類型。當您設計解決方案時,請仔細思考交易量和頻率會如何計入每日所選方法的管理員限制。計算每天會發生的執行次數。請確保計算的值在與您所選工具相關聯的限制之內。
延遲 決定處理結果在平台中可用的速度。針對某些方法,變更將近乎立即,而對於其他方法,變更可能為分鐘或小時。
## 使用個案 當您選取用於非同步處理的工具時,請先評估您組織的需求和可用資源。您的目標是選取最小化實作與維護成本的工具,同時確保延展性並將限制違規的可能性降到最低。此目標取決於先前概述的技術考量事項,以及您小組的組成。 請考量 Salesforce 中的非同步訂購流程。儲存訂單時,會觸發外部倉庫管理系統的訊息,其中包含如何包裝和寄送項目的特殊指示。下單的使用者不需要倉庫管理系統的立即回應,因此要求可以非同步傳送。非同步處理可讓使用者繼續工作,而無須等待回應。 針對此使用個案,您可能會考慮使用 Apex 進行實作。只有在您的小組中有可維護 Pro-code 解決方案的 Apex 開發人員時,此方法才會運作。否則,陳述性方法更有意義。此外,請記住,不同工具適用的不同集合的 [限制](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)。 此表格會在最左側欄中列出常見使用個案,後面加上描述。_第一個選項_欄提供用來滿足此類使用個案的最典型方法,以及第一個選項方法的理由。請使用此作為分析的起點,因為「第一個選項」方法可能有不適用於您使用個案的限制。
使用個案 描述 第一個選項方法 理由
高效能批次處理 必須有效率地處理數千筆或數百萬筆記錄的自動化 批次 Apex 批次 Apex 提供豐富的 API,可用於與平台的介面以及原始速度。
資料清除工作 定期執行或隨選執行,可清除資料的工作。範例包括消除重複、地址驗證或資料合併。 批次 Apex 批次 Apex 提供豐富的 API,可用於與平台的介面以及原始速度。
夜間累計工作 在工作日結束時計算累計資料的工作。 批次 Apex 批次 Apex 提供豐富的 API,可用於與平台的介面以及原始速度。
記錄觸發邏輯 執行邏輯以回應記錄更新。 變化 請參閱我們的伴侶決策指南,記錄觸發事件自動化。其中包含非同步使用個案的決策樹狀結構,包括可排列的 Apex、批次 Apex、已排程的流程、非同步路徑流程和變更資料擷取。
透過物件圖表串聯更新 允許使用者的儲存動作快速完成,將串聯更新延後至其他物件以非同步執行。 可排序的 Apex Apex 具有強大的鏈結功能,可讓邏輯將更新鏈結分為一系列非同步交易。
記錄特定排程處理 在未來,記錄特定的動態日期 (例如結束日期前 3 天) 自動化。 含已排程路徑的 流程 已排程路徑為流程提供獨特的優勢,因為當記錄的資料變更時,平台會自動處理這些路徑的排程、取消和重新排程。
並列叫用多個慢速外部服務 在同步執行期間,會並列叫用多個外部服務,以最佳化整體執行時間。 Apex 繼續呼叫 允許多個慢速執行的呼叫並行執行,可將完成工作整體時間最小化。
從外部系統移轉記錄的資料 從外部系統將大量記錄移至 Salesforce Platform。一次性或定期排程的流程。 大量 API 這是資料移轉最有效率且易於限制的方法。
在外部系統上執行其他邏輯 通知平台上事件的外部系統,然後允許該系統非同步處理事件的觸發式模式。 平台事件或 變更資料 發布子模型最適用於此處,並允許外部系統在準備好時處理事件。如需此模式的詳細資料,請參閱「事件驅動結構」。
「使用個案」表格是每個使用個案最合適方法的指引。不過,您需要驗證 First Choice 技術是否符合您使用個案的特定需求。尤其是,判斷所選方法是否可以遵循您組織的管理員限制。 在您為使用個案找出候選方法後,[非同步處理基本概念指南](/docs/architect/zh-tw/fundamentals/guide/async-fundamentals)可協助您完整檢查解決方案。 ## 資源 這些其他資源可協助您的決策流程: - 深入瞭解每個平台非同步技術:[非同步處理基礎知識](/docs/architect/zh-tw/fundamentals/guide/async-fundamentals) - 選擇記錄觸發的 Apex 和流程:[記錄觸發事件自動化](/docs/architect/zh-tw/decision-guides/guide/record-triggered) - 非同步整合模式的相關資訊:[事件驅動的結構](/docs/architect/zh-tw/decision-guides/guide/event-driven) # 針對以事件為導向的結構使用正確的工具和模式 以事件為導向的結構支援事件的有效生產與耗用,其會傳達系統或應用程式狀態變更。這些結構可啟用系統之間的彈性連線,並支援流程,以及跨系統運作的近乎即時更新。雖然事件驅動結構的優點很容易看見,但實作詳細資料並非總是如此明確。您在以事件為導向的結構模式中需要考量哪些功能?這些模式可解決哪些特定問題?解決方案適用的特殊考量事項為何,以及處理解決方案的最佳模式為何? ## 指南概觀 本指南呈現使用 Salesforce 技術時,用來建立最佳事件驅動結構的模式。其中也會討論 Salesforce 提供的撤銷工具,並提供用於選取使用個案的工具建議。如需有關涉及 Salesforce 的資料層級整合資訊,請參閱我們的「[資料整合決策指南](/docs/architect/zh-tw/decision-guides/guide/data-integration)」。 ## 接待時間 - **針對不需要要求同步回應的流程,使用以事件為導向的結構。**本指南概述的模式是針對資料的一致性、可擴展性和重複使用所設計,這有助於隨著您組織的應用程式環境發展將技術債務降至最低。(如需詳細資訊,請參閱 [Well-Architected - 可靠性](/docs/architect/zh-tw/well-architected/guide/reliability.html)。) - **如果 MuleSoft 或其他 Enterprise Service Bus (ESB) 解決方案是您現有的基礎,請盡可能使用它。**這些解決方案是針對支援以事件為導向的結構模式而打造,並具有強大的功能,可讓您在整個企業中重複使用整合。 - **將 Pub/Sub API 用於任何未來的發佈/訂閱模式,而非使用其他 API (包括串流 API) 建立您自己的事件處理常式。**現在 Pub/Sub API 已廣泛可用,請將其用於任何新的發佈/訂閱模式。計畫在可行時使用其他平台 API (例如串流 API 或自訂 Apex 服務) 將現有事件通訊移轉至 Pub/Sub API。 - **平台事件和變更資料取得 (CDC) 是發佈其他系統需要取用的記錄和欄位變更的偏好機制。**我們不建議針對新實作使用 PushTopic 和一般事件。Salesforce 會繼續支援目前功能內的 PushTopic 和一般事件,但不會計畫進一步投資此技術。 ## 範疇中的產品
Salesforce Platform Salesforce Platform 是一個全方位、 AI 驅動的平台,可將員工、自主 AI 工作人員、公司資料和應用程式整合到一個可靠的系統中,以增強生產力與客戶體驗。透過連接 Customer 360 應用程式、Data Cloud 和 Slack 來進行端對端自動化,以便建立「真正的企業」。
MuleSoft MuleSoft 是 Salesforce 領先的整合平台,可讓組織在內部部署和雲端環境之間連線應用程式、資料和裝置。MuleSoft 是一個平台,可讓 IT 平台在系統之間解除鎖定資料、開發可調整整合和自動化架構,並快速建立不同的連線體驗。
## 決策點 針對需要近乎即時通知的情境、分配大量或複雜訊息的處理負載,以及整合如 IoT 和行動裝置等系統,這些情況都建議使用事件驅動結構 (EDA)。然而,EDA 不應針對需要立即同步的人類回應的流程進行實作,因為其設計用於非同步執行。如果來源資料變更的頻率太少,以至於簡單的模式 (例如批次處理) 足夠,則其也不適用。 ### 使用事件驅動結構的時機 以下是一些常見的案例,通常適合以事件為導向的結構:
決策點指引
近乎即時的通知以事件為導向的結構模式 (例如發佈/訂閱、對應和串流) 可能在多個應用程式需要近乎即時地通知狀態變更或記錄更新的情況下運作良好。
平行處理如發佈/訂閱等模式可能在大量資料或高度複雜訊息需要在多個系統之間分配處理負載的情況下運作良好。
大量讀取「傳送的訊息」和「排隊」模式通常用於組織遇到高峰的情況,且產生的訊息量可能超過訂閱者立即處理訊息的能力。
大量寫入在許多情況下,「串流」與「排入排入」模式可以順利運作,其中組織在產生的訊息數量上漲。
將相同資料傳送至不同的系統雖然發佈/訂閱通常是需要將相同資料傳送至多個系統的組織相當常見的解決方案,但此處涵蓋的大多數模式都可處理此問題。請務必仔細檢閱這些項目以找出最合適的項目。
頻繁導入新系統或裝置發佈/訂閱、串流和排入類型模式通常適用於整體橫向傾向為流動的情境,且會定期新增新的系統和裝置。在此情節下,新系統或裝置只需要成為 Event Bus 的訂閱者,或關聯到某個指南,才能開始接收訊息,而不需要自訂點對點整合。
IoT 裝置由於 IoT 裝置通常會提供頻繁的更新,且在某些情況下也會產生一系列訊息,因此當將其整合至 IT 環境時,「串流」與「排隊」模式通常會運作良好。
離線行動裝置與系統行動裝置需要在具有低品質或不存在網際網路存取權的區域中工作,或在傳送訊息時可能為離線的系統,這些裝置將受益於「排隊」模式,其能夠在重新上線後連線至其排隊,並再取回任何相關訊息。
大多數的大型組織擁有複雜的 IT 環境,其系統組合具有不同的功能。您的組織有可能或可能擁有不支援以事件為導向之整合的舊版系統。您可能也會在事件驅動的整合沒有意義的情況下使用個案,即使系統會支援這些個案 (例如,SFTP 檔案從第三方傳輸)。如果您回溯了一步,並查看整個組織的 IT 環境,您可能會使用混合的模式來支援不同的案例,就像其他結構解決方案一樣。當您決定使用以事件為導向的整合方法,請將其視為工具箱中的另一個工具。它可且應用於正確的案例中,但並非要對每個系統強制執行的方法。開發全方位整合策略可協助您判斷本指南中所述模式何時可能或可能不適當。 ### 不使用事件驅動結構的時機 許多案例都需要以事件為導向的結構,在某些案例中,即使以事件為導向的結構並非最適合,它們仍會運作。但在某些情況下,無法使用以事件為導向的結構。以下是一些決策點問題,可協助您識別這些情況:
決策點要詢問的指引/問題
業務需求[使用事件驅動結構時](#使用事件驅動結構的時機) 區段中所述的任何功能是否有真正的業務需求?
技術需求您設計的整合是否符合不同的模式,例如資料虛擬化、批次或要求/回覆?換句話說,您是否正在嘗試將正方形指標置於圓洞中?
需要人類等待回應的流程任何涉及人類從目標系統等待回應的整合不適合以事件為導向的結構,因為其專為非同步執行而設計,且無法保證回應時間。在實作技術解決方案之前,請先考量此類流程是否對您的組織最佳。如需詳細資訊,請參閱 [Well-Architected - Operational Excellence](/docs/architect/zh-tw/well-architected/guide/operational-excellence.html)。
經常變更來源資料如果來源系統中的資料變更不常見,因此有足夠的定期更新,您可能可以使用 [批次模式] (https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_batch_data_sync.htm) 來簡化結構,而非以事件為導向的模式。
實作需求大多數解決方案中涉及的系統是否支援以事件為導向的結構?將以事件為導向的結構與不支援它們的系統 (例如升級、自訂或中介軟體) 搭配使用時,需要什麼?符合這些需求需要付出多少精力?
訊息結構穩定性您的訊息結構需要變更的頻率為何?哪些系統會受到此類變更的影響,以及補救流程會是什麼?
組織管理您是否具備了監管結構,以確保所有利害關係人都瞭解並能夠考量訊息結構、觸發和其他結構和流程相關決策的變更?
必要技能集您的工作人員是否擁有事件驅動結構的經驗,他們會知道如何支援它們嗎?
## 使用個案 各種以事件為導向的結構模式。有些是一般用途模式,可在事件驅動以外沒有任何特殊需求的使用個案中套用;例如,請參閱 [Well-Architected - 可靠性](/docs/architect/zh-tw/well-architected/guide/reliability.html)。其他模式適用於此處討論的特定使用個案,例如涉及大量資料的整合,或需要更長訊息保留的情境。 ### 模式概略 下表比較此文件中所列模式的屬性。當您需要識別指定使用個案的潛在模式時,請將其作為快速參考。
模式近乎即時唯一訊息複製保固交付減少訊息大小轉換資料
發佈 / 訂閱✓✓✓
透鏡圖✓✓✓
傳送的訊息✓✓✓✓
串流✓✓✓
排隊✓✓✓
### 事件驅動結構的工具 Salesforce 提供多種工具來協助您解決以事件為導向的使用個案。此表格包含可用工具的概觀概觀。
工具描述必要技能
MuleSoftAnypoint 平台使用 API 圖層來啟用資料整合的平台。專業程式碼
Salesforce Pub/Sub 連接器適用於 Pub/Sub API 的連接器,此連接器提供發佈和訂閱平台事件、即時事件監視事件和變更資料擷取事件的單一介面。專業程式碼
MuleSoft Anypoint JMS 連接器針對實作 Java 訊息服務 (JMS) 規格的任何訊息服務,此連接器可將訊息傳送與接收至任何訊息服務的列和主題。專業程式碼
MuleSoft Anypoint Apache Kafka 連接器可在 Apache Kafka 與企業應用程式和服務之間移動資料的連接器。專業程式碼
MuleSoft Anypoint Solace 連接器使用 JCSMP Java SDK 的原生 API 整合,適用於 Solace PubSub+ 事件經紀人的連接器專業程式碼
MuleSoft Anypoint MQ 連接器可讓客戶在其應用程式之間執行進階非同步傳訊的多租戶雲端傳訊服務。專業程式碼
MuleSoft Anypoint MQTT 連接器符合通訊協定 v3.x 的 MQTT (Message Queuing Telemetry Transport) MuleSoft 擴充功能。專業程式碼
MuleSoft Anypoint AMQP 連接器此連接器可讓您的應用程式使用 AMQP 0.9.1 相容的經紀人來發佈和取用訊息。專業程式碼
MuleSoft Anypoint 事件驅動 (非同步) API產業無效的語言,透過將以事件為導向的 API 分隔成事件、管道和運輸層級來支援發佈。專業程式碼
MuleSoft Anypoint MQ可讓客戶在應用程式之間執行進階非同步傳訊的多租戶雲端傳訊服務。專業程式碼
MuleSoft Anypoint 資料串流可在 MuleSoft Anypoint 中發佈和訂閱串流資料的架構。專業程式碼
Salesforce PlatformHeroku 上的 Apache Kafka提供 Apache Kafka 作為服務的 Heroku 附加元件,並將完整的平台整合至 Heroku 平台。專業程式碼
變更資料取取變更事件記錄會將變更發佈至 Salesforce 記錄。變更包括建立新記錄、更新現有記錄、刪除記錄,以及取消刪除記錄。低程式碼對 Pro-code
輸出訊息更新 Salesforce 中的欄位值時,傳送 XML 訊息至外部端點的動作。低程式碼
平台事件包含自訂事件資料的安全且可調整訊息。低程式碼對 Pro-code
Pub/Sub API可啟用平台事件訂閱、變更 資料擷取 事件和/或即時事件監視事件的 API。專業程式碼
事件轉送啟用要從 Salesforce 傳送至 Amazon EventBridge 的平台事件和變更資料擷取事件。請注意,事件轉送只會連線至 AWS Eventbridge。低程式碼
### 發佈/訂閱 當重要記錄在核心應用程式內變更狀態時 (例如,訂單的狀態從「正在處理」移至「已出貨」),多個其他系統可能需要近乎即時的通知來執行其各自的工作。當這些變更量很高且訊息很複雜時,會產生特定業務需求,使傳統點對點整合變得繁重且難以維護。為每個相依應用程式建立脆弱且自訂的連線會導致技術負債,並阻礙組織快速擴展。需要強大的整合方法來管理這些頻繁的資料同步化,而無須將來源系統直接連接至每個耗用系統。 #### 發佈/訂閱模式 下圖說明一般發佈/訂閱模式,其中多個發行者和訂閱者透過 Event Bus 共用資料。此基礎模式是可在本指南其餘部分找到的更具體模式基礎。此模式的一些重要特性包括: - 發行者與訂閱者之間沒有直接連線。發行者只需將訊息傳送至 Event Bus,便可將訊息廣播至想要聆聽訊息的任何其他系統。 - 相同的系統可以是發行者與訂閱者。 - 系統可以發佈或訂閱多種類型的事件。 - 如同本指南中所有的模式,發佈/訂閱模式屬於一般整合模式種類,稱為遠端程序叫用 (RPI) 或簡單[「觸發忘記」。](/docs/architect/zh-tw/fundamentals/guide/integration-patterns#遠端流程叫用--觸發與忘記) 此層級 2 圖顯示發佈/訂閱模式的範例,其中包含多個發行者、多個訂閱者,以及透過 Event Bus 中的管道傳送的多個事件。在此模式中,相同的系統可以是發行者和訂閱者,且系統可以訂閱多個事件。 #### 與發佈/訂閱模式相關的工具
事件流程與行為裝載考量事項
可用的工具必要技能發佈透過訂閱透過重複執行期間裝載結構裝載限制
MuleSoftAnypoint 平台專業程式碼APIAPI已設定已定義使用者無
Salesforce Pub/Sub 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint JMS 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint Apache Kafka 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint Solace 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQ 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQTT 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint AMQP 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint 事件驅動 (非同步) API專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQ專業程式碼APIAPI已設定已定義使用者無
Salesforce PlatformHeroku 上的 Apache Kafka專業程式碼API,Heroku Postgres 中的記錄變更無1-6 週已定義使用者已定義使用者
變更資料取取低程式碼對 Pro-code記錄變更Apex、API、Lightning Web 元件 (LWC)3 天預先定義1 MB
輸出訊息*低程式碼流程與工作流程規則無24 小時已定義使用者每則訊息 100 個通知
平台事件低程式碼對 Pro-codeAPI、Apex、流程Apex、API、Flow、LWC3 天已定義使用者1 MB
Pub/Sub API專業程式碼Pub/Sub API 或 API、Apex、流程Pub/Sub API3 天已定義使用者1 MB
事件轉送**低程式碼平台事件、變更資料擷取API3 天已定義使用者1 MB
*Salesforce 會在目前的功能中繼續支援輸出訊息,但不打算進一步投資此技術。**事件轉送僅連線至 AWS Eventbridge
### 透鏡圖 當組織需要將立即更新傳送至大量用戶端應用程式 (例如推送通知或 SMS 訊息) 至行動裝置時,為每個單一收件者建立唯一傳輸的傳統程序會迅速變成可擴充性瓶頸。在此案例中,核心業務需求是將單一資訊 (例如帳戶警示或重要服務變更通知) 快速且高效能地散佈至多個端點應用程式。滿足此需求的簡化方法涉及透過單一路由訊息,這會作為所有耗用系統事件資訊的中心點。此方法可減少管理多個個別訊息複本的需求,藉此改善效能。 #### 透鏡圖 透過「下拉式」模式,訊息會透過單一訊息列傳送至一或多個目的地 (亦即聆聽用戶或訂閱者)。訂閱者會從其自己的唯一複本取用同一則訊息,而不是從其中的同一則訊息。(請注意,雖然這可改善效能,但也會使驗證特定訂閱者是否收到訊息變得更難。) 此層級 3 文件與實作圖表顯示了對外模式的範例。 此圖表描述當透過使用者互動、流程或批次工作修改記錄時,發佈並寫入單一排隊的事件。 訂閱者系統有多個服務會從訊息排隊接收相同的事件。 #### 與顯示模式相關的工具
事件流程與行為裝載考量事項
可用的工具必要技能發佈透過訂閱透過重複執行期間裝載結構裝載限制
MuleSoftMuleSoft Anypoint JMS 連接器專業程式碼APIAPI已設定已定義使用者無
Salesforce Pub/Sub 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint Apache Kafka 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint Solace 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQ 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQTT 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint AMQP 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQ專業程式碼APIAPI已設定已定義使用者無
Salesforce PlatformHeroku 上的 Apache Kafka專業程式碼API,Heroku Postgres 中的記錄變更無1-6 週已定義使用者已定義使用者
變更資料取取低程式碼對 Pro-code記錄變更Apex、API、Lightning Web 元件 (LWC)3 天預先定義1 MB
平台事件低程式碼對 Pro-codeAPI、Apex、流程Apex、API、Flow、LWC3 天已定義使用者1 MB
Pub/Sub API專業程式碼Pub/Sub API 或 Apex、API、流程Pub/Sub API3 天已定義使用者1 MB
事件轉送*低程式碼平台事件、變更資料擷取API3 天已定義使用者1 MB
*事件轉送只會將資料傳送至 AWS Eventbridge
### 傳送的訊息 某些事件案例的特點為訊息量大幅流入,可能會壓倒同步化和轉換程序的容量,或處理和轉換事件資料所需的複雜多步驟邏輯。 某些範例包括: - **季節性量高峰:**線上零售商在其產品的選擇「季節性」時,可能會遇到數量高峰。當大量客戶同時進行購買時,產生的事件數量可能暫時超過同步化和轉換流程的容量。請參閱 [Well-Architected - 可靠性](/docs/architect/zh-tw/well-architected/guide/reliability.html#scalability-and-capacity-planning)以取得詳細資訊。 - **個案或索賠管理:**以服務為基礎的公司在中斷期間,可能會遇到個案或索賠數量的激增。 - **複雜資料轉換:**需要複雜邏輯來轉換訊息的組織通常會擔心事件的產生速度比其轉換的速度快。 #### 傳送的訊息模式 此模式可解決訊息產生速度超過可轉換的挑戰。其可確保可安全地處理大量訊息和必要的資料操作,將串流訊息平台整合到專屬元件中,並將訊息處理邏輯分段。 「傳送的訊息」模式可透過將訊息處理邏輯分段至多個元件來運作: - 一個元件會處理訊息路由,決定必要轉換和最終目的地。 - 個別的元件集會處理訊息轉換的不同層級 (例如,欄位對應、物件關係等)。 - 最後一個元件會撰寫最後修改後的訊息。 此層級 3 文件與實作圖表顯示流程流程範例,適用於傳送訊息模式,其中包含發行者、訂閱者和訊息。 訊息會分割成多個部分,這些部分會個別轉換,然後在傳送給訂閱者前重新組合。 #### 與傳送訊息模式相關的工具
事件流程與行為裝載考量事項
可用的工具必要技能發佈透過訂閱透過重複執行期間裝載結構裝載限制
MuleSoftMuleSoft Anypoint Apache Kafka 連接器專業程式碼APIAPI已設定已定義使用者無
Salesforce Pub/Sub 連接器專業程式碼APIAPI已設定已定義使用者無
Salesforce PlatformHeroku 上的 Apache Kafka專業程式碼API,Heroku Postgres 中的記錄變更無1-6 週已定義使用者已定義使用者
變更資料取取低程式碼對 Pro-code記錄變更Apex、API、Lightning Web 元件 (LWC)3 天預先定義1 MB
平台事件低程式碼對 Pro-codeAPI、Apex、流程Apex、API、Flow、LWC3 天已定義使用者1 MB
Pub/Sub API專業程式碼Pub/Sub API 或 API,Apex 流程Pub/Sub API3 天已定義使用者1 MB
事件轉送*低程式碼平台事件、變更資料擷取API3 天已定義使用者1 MB
*事件轉送只會將資料傳送至 AWS Eventbridge
### 串流 某些產生者會產生連續的事件串流。常見範例為媒體串流,其中涉及自然發生為離散事件的使用者互動。多個系統必須同時回應相同的使用者行為,而不會封鎖核心串流體驗。 請考量音樂串流平台的事件。這些可能包括: - 追蹤已啟動/已暫停/已略過事件 - 聆聽包含時間戳記的工作階段事件 - 播放清單建立/修改事件 - 社交共用事件 - 下載以供離線聆聽 #### 串流模式 在「串流」模式中,訂閱者會存取每個事件串流,並以接收的確切順序處理事件。每個訊息串流的唯一複本會傳送給每個訂閱者,讓您能夠傳送訂閱者特定的內容,並識別哪些訂閱者會收到哪些串流。 此層級 3 文件與實作圖表顯示串流模式的範例,此模式描述正在發佈的事件串流。正在聆聽串流的訂閱者會接收串流並相應地處理。 #### 與串流模式相關的工具
事件流程與行為裝載考量事項
可用的工具必要技能發佈透過訂閱透過重複執行期間裝載結構裝載限制
MuleSoftMuleSoft Anypoint 資料串流專業程式碼APIAPI已設定已定義使用者無
Salesforce Pub/Sub 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint Apache Kafka 連接器專業程式碼APIAPI已設定已定義使用者無
Salesforce PlatformHeroku 上的 Apache Kafka專業程式碼API,Heroku Postgres 中的記錄變更無1-6 週已定義使用者已定義使用者
Pub/Sub API專業程式碼Pub/Sub API 或 API,Apex 流程Pub/Sub API3 天已定義使用者1 MB
#### 串流事件訂單管理 為了讓串流有意義,其所有事件及其相關聯的訊息都必須以正確的順序顯示。如果您在來自不同系統的串流中來源資料,則必須納入其他訂購邏輯作為設計流程的一部分。 ### 排隊 查詢使用個案很普遍。範例包括: - **低品質的網際網路連線:**Field Service 組織或其他組織,其中具有行動裝置的小組需要在品質不佳或間斷網際網路存取權的區域中工作,會受益於將這些裝置上應用程式連線至其中的排隊,並在恢復連線時取回任何相關訊息。 - **訊息緩衝:**當訊息量有時超過訂閱者的處理容量,且延遲增加不會產生額外的問題時,可能會有用於緩衝來儲存過多訊息並避免資料遺失。 - **運輸管理:**需要監視車隊的物流組織可以使用此模式,以近乎即時檢視每部車輛正在使用的路線,並確保司機的效率盡可能高。 - **IoT 裝置:**製造商經常使用產生快速資料串流的系統,而這些串流可能會對其他系統造成下游影響。此模式可用來識別在發生跨多個系統的災難性失敗之前,需要人類介入的事件序列。 #### 列入模式 生產人員會在「排隊」模式中,傳送訊息給排隊,這些排隊會保留訊息,直到訂閱者將訊息提取為止。大多數訊息排列會遵循先進先出 (FIFO) 順序,並在取出訊息之後刪除每則訊息。每個訂閱者都有獨一無二且需要額外的設定步驟,但仍可保證傳送並識別哪些訂閱者接收了哪些訊息。 此層級 3 文件與實作圖表顯示列出模式的範例,此模式描述在修改記錄時發佈的事件,並寫入至列出。訂閱者會從相關聯的列出接收事件的複本,並對自己的記錄進行適當的更新。 #### 與排入模式相關的工具
事件流程與行為裝載考量事項
可用的工具必要技能發佈透過訂閱透過重複執行期間裝載結構裝載限制
MuleSoftMuleSoft Anypoint MQ專業程式碼APIAPI已設定已定義使用者無
Salesforce Pub/Sub 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint Apache Kafka 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQ 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQTT 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint AMQP 連接器專業程式碼APIAPI已設定已定義使用者無
Salesforce PlatformHeroku 上的 Apache Kafka專業程式碼API,Heroku Postgres 中的記錄變更無1-6 週已定義使用者已定義使用者
變更資料取取低程式碼對 Pro-code記錄變更Apex、API、Lightning Web 元件 (LWC)3 天預先定義1 MB
平台事件低程式碼對 Pro-codeAPI、Apex、流程Apex、API、Flow、LWC3 天已定義使用者1 MB
Pub/Sub API專業程式碼Pub/Sub API 或 API、Apex、流程Pub/Sub API3 天已定義使用者1 MB
事件轉送*低程式碼平台事件、變更資料擷取API3 天已定義使用者1 MB
*事件轉送只會將資料傳送至 AWS Eventbridge
#### 記憶體與儲存空間管理 由於「排隊」模式的非同步性質,因此在將訊息新增至排隊與該訊息提取之間可能會有較長的延遲。達號需要記憶體或儲存空間來保留其訊息,因此其無法無限成長,這表示如果在達號中累積足夠的訊息,則無限離線的訂閱者可能會造成失敗。如果訂閱者處理時間過長,則訊息緩衝可能會產生相同的效果,進而導致大量訊息堆積在他們的排隊中。若要減少這些風險,請針對所有訊息排列執行完整的儲存空間需求分析,並視需要設計流程,在未在設定的時間內或當訊息達到預先決定的容量時清除並停用訊息。 ## 非功能考量事項 除了先前章節所列的功能考量事項之外,還有一些非功能考量事項可納入您的決策考量。 ### 從點對點整合移轉 即使您完全相信以事件為導向的結構適合您的組織,您仍可能會從已經擁有大量點對點整合的環境開始。為專案獲得資金來一次取代所有整合可能很困難,甚至可能無法直接將以事件為導向的結構與一些舊版系統搭配使用。在這些案例中,您可以先轉換最關鍵業務的應用程式,然後在其在未來專案中更新或取代時轉換其他系統,以逐步移轉至較寬鬆的架構。此方法可讓您輕鬆將新應用程式新增至 Event Bus,並讓整體 IT 環境在隨著系統持續新增的時間保持可調整和彈性。 ### 寬鬆連接系統中的權衡 身為結構設計師,我們知道每個結構都有權衡。以事件為導向的結構也不例外。雖然充滿寬鬆連接系統的環境可高度調整和彈性,但還需要考量一些權衡因素: - **整體整合策略:**無論您決定要使用的工具和模式為何,請務必從建立策略開始,以瞭解資料如何在組織的各個系統之間共用。此策略應包含您組織的資料目標、資料可共用的方式和使用模式,以及資料來源、目標、結構和擁有權與存取需求。 - **舊版系統的支援:**您的組織可能有舊版系統,只是不支援以事件為導向的結構模式。雖然可能會建立因應措施 (例如,使用透過訂閱事件,然後透過不同的資料傳輸方式將輸出傳送至目標系統作為逐步解說的流程),但您可能想要在此個案中考慮其他整合方法。 - **訊息的結構變更:**一旦發行者與訂閱者之間定義並同意初始訊息結構,可能會難以變更,特別是當訂閱者為外部使用者時。有數種方法可以解決此問題。您可以使用版本化端點,但請確保為每個版本定義並傳達明確的生命週期,以便您的開發人員不必同時維護太多版本。如果 Heroku 上的 Apache Kafka 屬於您的橫向,您也可以考慮使用結構描述登錄或類似工具,但請確保橫向中的其他系統也支援 (並使用)。 - **缺少發行者與訂閱者之間的可視性:**在大多數以事件為導向的結構模式中,發行者不會知道其訂閱者的狀態。因此,如果發行者在所有訂閱者離線時傳送重要訊息,則訊息可能不會傳送。您可以使用重新執行功能來解決此問題,或針對所有重要訊息新增在個別伺服器上執行的冗餘訂閱者。 - **效能瓶頸:**隨著以事件為導向的結構擴展,如果發生過多發行者嘗試同時傳訊太多訂閱者,則 Event Bus 可能會成為訊息傳送的瓶頸。您可以透過增加分配至 Event Bus 的記憶體和處理資源,或使用多個 Event Bus 並列處理不同類型的訊息來解決此問題。 ## 相關最佳作法 除了已提供的指引之外,也請考量下列最佳作法。 ### 實作事件驅動的結構 實作以事件為導向的結構之前,請考量您是否真的需要先使用一個架構。上一節描述適用於每個事件驅動結構模式的常見業務案例。您也可以在 [Well-Architected - 可靠性](/docs/architect/zh-tw/well-architected/guide/reliability.html) 中深入瞭解。檢閱實作以事件為導向的結構時要考量的挑戰,以判斷您考量的模式是否最適合您特定的使用個案。 請注意,雖然本指南涵蓋的大多數案例涉及整合,但以事件為導向的結構也可以用來透過使用平台事件在單一 Salesforce 組織內傳送訊息,例如。設計使用平台事件作為內部傳訊系統的程序時,請務必記住任何適用的[事件分配限制](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)。 ### 避免使用反模式 事件驅動結構的反模式通常來自使用事件作為 Salesforce 組織內內部通訊的因應措施。常見的反模式包括: - **從與相同事件物件相關聯的 Apex 觸發發出事件:**這會導致無限觸發迴圈。 - **在 DML 交易完成前,從 Apex 發佈事件:**如果交易失敗並回復,任何具有「立即發佈」發佈行為的已發佈事件都不會包含在回復行為中。 - **在流程中發佈事件以協調後續的自動化:**在多個自動化之間協調邏輯的最佳方法是使用 [子流程](https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_implementation_guide.meta/salesforce_vpm_implementation_guide/vpm_designer_elements_subflow.htm)或 [Flow Orchestrator](https://help.salesforce.com/s/articleView?id=sf.orchestrator_flow_orchestrator.htm)。 - **建立執行階段相依性:**若未採取適當的[步驟](https://medium.com/salesforce-architects/5-anti-patterns-in-package-dependency-design-and-how-to-avoid-them-87bb50331cb8)去除執行階段相依性,請勿發佈事件以協助封裝之間通訊。 - **不必要的大型裝載:**提出要求時,最好在裝載中傳送及接收盡可能少量的資料。使用者的每個動作都可能產生多個要求,因此有效處理這些要求十分重要。傳送超過必要的資料會造成傳輸速度變慢且處理時間增加。 - **未選擇性處理應用程式事件:**當有多個元件正在聆聽應用程式事件時,開發人員應確保事件處理常式只會在實際需要且實用時執行。例如,在 Lightning 主控台中,未聚焦的索引標籤中包含的元件仍可聆聽,即使它們不可見。開發人員可以使用各種技術,例如使用背景公用程式項目作為唯一接聽者,或呼叫 getEnclosingTabId() 來判斷元件的此例項是否包含在焦點索引標籤內,以確保每個事件僅在預期的時間處理。 - **使用「平台事件」不正確發佈行為:**「平台事件」有兩種發佈行為—「立即發佈」和「認可後發佈」。將即時平台事件用於使用個案 (例如「記錄」) 相當有用,無論交易是否成功與認可,您都會在其中發佈記錄事件。不過,對於即時平台事件,請特別小心使用「立即發佈」。事件可以在相同交易內由訂閱者耗用,並導致列鎖定或其他競爭狀況。 ### 設計有效的事件 實作以事件為導向的結構時,成功的關鍵之一是設定事件本身設計方式的標準。細節會根據您組織的使用個案而有所不同,但以下是一些一般原則: - **決定事件裝載的最佳結構。**較小的訊息大小會減少處理時間,但以大量訊息轟炸訂閱者可能會造成效能瓶頸。您可能需要迭代裝載大小與結構,以找到正確的平衡。MuleSoft 和類似的 ESB 工具能夠在與您的事件相關聯的訊息中設計自訂裝載,這可協助您視覺化資料結構,以改善訂閱者端的效能。(如需詳細資訊,請參閱 [Well-Architected - 可靠性](/docs/architect/zh-tw/well-architected/guide/reliability.html)。) - **考量您的程序端對端。**確定您未建立任何「無限迴圈」案例,這在首展整合後可能難以追蹤。範例為兩個系統在更新記錄時發佈事件,同時聆聽彼此的事件,這兩個系統在處理時會觸發其他已發佈事件。 您可以透過將邏輯新增至兩個系統來修正此類型的反模式,以確保由於耗用事件而進行的變更不會導致發佈新的事件。您也應確保記錄所有事件、其相關聯的觸發,以及可能受影響的下游系統。在設計工作階段期間,請使用此文件作為參考,以協助盡早抓住無盡的迴圈和類似情況。(如需詳細資訊,請參閱 [Well-Architected - Operational Excellence](/docs/architect/zh-tw/well-architected/guide/operational-excellence.html)。) - **在系統之間使用常見命名慣例。**一致的命名慣例是所有軟體開發 (包括以事件為導向的結構) 的最佳作法。花時間記錄事件名稱、結構、相關聯物件和錯誤處理流程的一組標準,以確保系統之間的一致性。(如需詳細資訊,請參閱 [Well-Architected - Operational Excellence](/docs/architect/zh-tw/well-architected/guide/operational-excellence.html)。) ## 資源
模式資源
發佈/訂閱Salesforce 結構良好 - 可靠性
Salesforce 結構良好 - 傑出營運
部落格貼文:使用事件轉送達成結構效率
部落格貼文:公告 Pub/Sub API 廣泛可用
部落格貼文:從 RESTful 移至 Eventful
部落格貼文:以事件為導向的結構與非同步 API 規格
影片:發佈 / 訂閱模式逐步解說
透鏡圖部落格貼文:如何在平台事件傳送限制內工作
影片:透鏡模式逐步解說
傳送的訊息影片:傳送訊息模式逐步解說
串流部落格貼文:針對 Salesforce 中的大量寫入進行設計
影片:串流模式逐步解說
文件:在 Mule 應用程式中串流
排隊部落格貼文:針對 Salesforce 中的大量寫入進行設計
部落格貼文:如何使用事件的 API 設計付款結構
影片:列入模式逐步解說
# 建立表單 在 Agentforce 360 Platform 上建立表單的選項有多種,可跨越從低程式碼到專業程式碼方法的連續。在連續的其中一端,Lightning 應用程式產生器中的「動態表單」和 Flow Builder 中的畫面流程可用於低程式碼解決方案。在另一端,Lightning Web 元件 (LWC) 架構用於專業程式碼解決方案。在連續中,可使用 LWC 擴充的畫面流程和使用 Omnistudio 建立的面向客戶表單,以數種方式混合工具。 ## 指南概觀 本指南提供關於建立 UI 解決方案表單的決策架構與指引。具體而言,它會使用數十個執行階段和非功能決策點,以適當地為指定的使用個案選取最佳技術。 ## 接待時間 - **當您建立 Lightning 頁面的建立/編輯/檢視版面配置時,請使用「動態表單」。**繼續下一步,我們建議在 _Lightning 應用程式產生器_中使用「_動態表單_」來設定記錄詳細資料頁面。 - **如果您需要為一個物件建立、建立或編輯表單,請使用 _Lightning 頁面_ 和 _動態表單_。**這是在 Agentforce 360 Platform 上建立表單的最簡單方法。它也提供其他功能 (例如,欄位可視性控制)。 - **如果您要建立多頁表單或精靈,且沒有嚴格的 UX 或品牌需求,請使用「畫面流程」。**畫面流程提供線性瀏覽架構,可協調多個表單。您可以使用 LWC 建構您自己的架構來在表單之間瀏覽,但我們建議讓「流程」執行工作,讓您可以專注於表單本身,而非專注於表單狀態。 - **如果您需要額外的邏輯或動作來支援表單,請使用「畫面流程」、「Omnistudio」或 LWC。**每個工具都提供不同的方式來增強您的解決方案,方法是允許解決方案在建立或編輯單一記錄以外展開。在此例中,這個詞彙可能會_更_指進階邏輯 (例如分支或迭代),或指與外部系統整合、傳送電子郵件或將通知推送至使用者行動應用程式等動作。 - **如果您有複雜的 UX 需求,或如果您需要動態管理超過 UI 的可視性,請使用 LWC 或 Omniscript。**針對可透過使用主題與以資料欄為基礎的版面配置來達成的需求,您可以直接在低程式碼產生器中建立表單。不過,精確控制表單樣式需要 LWC 的彈性。如果您是 Industries 客戶,且您需要像素完美的品牌標識,或您擁有複雜階層資料,請使用 Omnistudio,這可讓您建立可處理複雜業務邏輯和資料轉換的消費者級表單。 - **如果您需要部署測試自動化,請使用 LWC。**您可以針對任何 LWC 撰寫單元測試,無論您內嵌的位置為何。這可讓您建立更強大的測試策略,其中可能包含使用多個記錄的大量測試,以及負數測試。 - **您不受「或」決策的約束。**您可以結合多個選項來針對您的使用個案找到最佳解決方案 (例如,如果您需要 Flow 的內建瀏覽系統以及 LWC 提供的完整樣式彈性,您可以將其一起使用)。 ## 範圍中的工具 下列工具常用於實作和擴充表單體驗。 ### 工具描述
動態表單 Salesforce Lightning 應用程式產生器中的「動態表單」 會將單一的「記錄詳細資料」元件拆分為個別的可設定的欄位和區段。此功能可讓管理員建立彈性的高效能頁面,方法是將欄位放置在任何位置,並使用可視性規則根據使用者設定檔、裝置或資料顯示或隱藏元件,這有助於減少頁面混亂。
畫面流程 Salesforce 畫面流程是 Flow Builder 中的互動式自動化工具,需要使用者輸入才能完成自訂的逐步業務流程。不同於自動背景流程,「畫面流程」提供類似精靈的使用者介面,無須撰寫程式碼即可收集資料、顯示資訊,或透過 Lightning 頁面、按鈕或自訂應用程式執行動作。
Omnistudio Salesforce Omnistudio 是低程式碼的工具套件,其設計目的為快速建立引導式、產業特有的數位體驗和複雜的業務流程。它可讓開發人員使用拖放元件 (例如 FlexCard 和 Omniscript) 建立像素完美的使用者介面 (例如引導式工作流程和動態顯示面板)。透過 Omnistudio,您可以宣告的方式建立 LWC。
Lightning Web 元件 Salesforce Lightning Web 元件是輕量型、自訂 HTML 元素,使用 HTML、CSS 和現代 JavaScript 建立,並設計為在瀏覽器中原生執行,以獲得卓越的 Salesforce UI 效能。它們可讓開發人員建立與 Aura 元件共存的自訂使用者介面,進而透過產業標準和詳細的元件生態系統來增加開發。
### 工具技能集與授權需求 此表格概述可透過 Salesforce 建立表單的工具,以及其必要技能和授權考量事項。 **備註:**我們將深入瞭解每個工具支援的特定功能、如何在按一下型工具和程式碼型工具之間選擇,以及在稍後區段中何時結合這些工具。
組態 其他授權需求
動態表單 低程式碼 無
畫面流程 低程式碼 無
Omnistudio 低程式碼 + 專業代碼 產業封裝
畫面流程加上 Lightning Web 元件 低程式碼 + 專業代碼 無
Lightning Web 元件 專業代碼 無
## 決策點 當您選擇產品和工具時,有一些決策點需要記住。此表格概述各種決策點,並提供概況指引。
決策點 指引
執行階段使用個案種類
表單範圍與瀏覽 判斷表單上的所有欄位是否會邏輯地符合單一畫面,或使用者是否需要能夠在多個畫面之間瀏覽。
位置 識別您要內嵌表單的位置,可從 Salesforce 應用程式內到行動應用程式及外部網站。
控制項 識別當使用者與您的表單互動時,必須在背景執行的動作或邏輯,包括資料轉換和與外部系統的整合。
驗證 判斷您是否有任何超出 Salesforce 所提供標準系統級驗證的其他輸入驗證需求。
互動設計 識別應在表單中觸發動態回應的互動類型或條件。
樣式 決定所需樣式與 CSS 需求所需的精密層級。
版面配置 識別表單的版面配置需求 (例如,所需的欄數、索引標籤和折疊式) 以及顯示重複資料區塊的能力。
翻譯 決定您的表單是否必須針對其他語言當地語系化。
非功能考量事項
安全性 決定您的表單在執行特定作業前是否應檢查使用者的存取權、您是否要控制可存取表單的人員,以及您是否要控制可內嵌表單的位置。
物件影響 決定您的表單要針對單一物件還是針對多個物件執行。
UI 測試自動化 判斷您的 DevOps 程序是否需要您的表單才能接受自動單元測試或自動端對端測試。
度量 識別您要如何追蹤表單的使用狀況,包括頁面檢視、花費在表單上的時間量、完成率和成功率。
封裝與部署 決定您要如何在建立表單後散佈或部署表單。
**備註:**在後續的決策比較表格中,有一些值與任何工具功能配對相關聯: - **可用:**工具/功能適用於基本考量事項。 - **不可用:**沒有計畫在未來十二個月內新增支援。 - **非理想:**此工具/功能可能適用,但並非最佳工具。 - **不適用:**此工具不適用於特定使用個案。 ## 使用個案 使用這些情況來根據範圍、UX 和作業需求比較工具選擇。 ### 表單範圍與瀏覽 如果您可以從單一畫面表單取得所有使用者輸入,請從「動態表單」開始。請記住,記錄頁面中的「動態表單」可以使用「路徑」功能來支援階段式業務流程。 #### 要詢問的問題 - 您是否需要單一畫面,或使用者需要在多個畫面之間瀏覽才能完成工作? - 您是否要讓您的使用者在填寫表單時看見其在流程中的進度視覺化描述?您的使用者是否需要以特定順序填寫每個畫面上的資訊,或者他們是否可以視需要在畫面之間來回移動? 如果您需要的功能比「動態表單」所提供的更多,則在「流程」、「Omnistudio」和 LWC 之間選擇取決於一些額外的問題: - 在表單底部顯示瀏覽列是否可以?如果「畫面流程」與 Omniscript 瀏覽體驗提供不想要的 UX,請傾向 LWC。 - 表單後面必須發生什麼事?如果您需要管理員可設定的行為,請使用「流程」。針對複雜的多物件關係,請使用 _Omniscript_ 或 _LWC_。
單一畫面 多螢幕表單 進度指標 在步驟/畫面之間跳轉瀏覽
動態表單 可用 不提供 可用 不提供
畫面流程 可用 可用 可用 不提供
Omnistudio 可用 可用 可用 可用
畫面流程 + LWC 可用 可用 可用 可用
LWC 可用 不是理想 不是理想 不是理想
如果您選擇「流程」或「Omnistudio」,您可能還需要建立 LWC 以達成正確的 UX。如果您已建立 LWC 以正確設定表單的樣式,請考慮是否需要在「流程」中[內嵌該元件](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_flow)。 **精靈樣式瀏覽** 另一方面,如果您的解決方案看起來像精靈,使用者可在多個畫面之間瀏覽,請考量「流程」或「Omnistudio」。「流程」與 Omnistudio 具備內建瀏覽模型,因此您無須建立和維護串連的 LWC。瀏覽為線性,具有正向動作、反向動作,以及用來儲存表單的機制以供稍後使用。如果表單符合您的目的,您也可以使用非線性瀏覽來建立表單。 Omnistudio 透過提供標準瀏覽中的進度指標來呈現表單內的步驟,提供重要的瀏覽優勢。步驟檢視會自動顯示使用者在多步驟表單上的位置。不同於「流程」,其可讓使用者在整個表單中按一下各種步驟,在畫面之間跳轉。 無論您要建立單螢幕或多螢幕表單,請務必確保表單簡化,讓使用者能夠輕鬆瀏覽表單。 ### 尺寸規格 如果您將表單內嵌在標準 Lightning 記錄頁面中,我們比較的任何工具都會運作;不過,動態表單目前僅適用於桌上型電腦。如果您想要提供讓使用者從其他位置存取表單的體驗,您可能需要考慮其他選項。 #### 要詢問的問題 - 使用者是否需要透過桌上型電腦、行動裝置或兩者存取表單? - 使用者是否應能夠透過公用程式列從應用程式中的任何位置存取表單? - 您是否要啟用快速動作,讓使用者填寫表單而不必離開目前所在的頁面? - 您的表單是否必須在外部網站上可供使用?
Lightning 記錄頁面 Lightning 首頁或應用程式頁面 Aura Experience Cloud 網站 LWR Experience 雲端網站 內嵌 Snap 公用程式列 物件特定動作 全域動作 Salesforce 行動應用程式* Field Service Mobile Mobile SDK 外部網站與應用程式 自訂 LWC
動態表單 可用 不提供 不提供 不提供 不提供 不提供 不提供 不提供 可用 不提供 不提供 不提供 不提供
畫面流程 可用 可用 可用 可用 可用 可用 可用 不提供 可用 適用** 不提供 不提供 可用
Omnistudio 可用 可用 可用 不提供 不提供 可用 不提供 不提供 可用 不提供 不提供 可用 可用
畫面流程 + LWC 可用 可用 可用 可用 可用 可用 可用 不提供 可用 不提供 不提供 不是理想 可用
LWC 可用 可用 可用 可用 可用 可用 不提供 不提供 可用 不提供 不提供 可用 可用
*Salesforce 行動應用程式支援流程和 LWC,但不支援內嵌「流程」和 LWC 的所有方式 (例如,行動裝置支援物件特定動作,但公用程式列項目不支援)。

**Salesforce Field Service 行動應用程式包含 資料擷取,此為在「流程」引擎上建立的離線優先表單解決方案,並具有專屬的離線執行階段,支援最新的「流程」功能。此應用程式也包含舊版 Field Service Mobile 流程,其在較舊的自訂離線引擎上執行,且不支援許多最新的「流程」功能。
由於需要記錄內容,因此只有 Lightning 記錄頁面支援「動態表單」功能。不過,Experience Cloud 頁面不支援「動態表單」。 您可以建立需要記錄內容的「流程」,或在全域運作的「流程」。換句話說,您可以在各種位置內嵌「流程」。針對記錄內容流程,位置可能包含:Lightning 記錄頁面、Experience Cloud 記錄頁面、物件特定動作或「動作與建議」部署。針對全域流程,位置可包含:公用程式列、其他 Lightning 或體驗產生器頁面、Snap或外部應用程式。目前不支援將「流程」作為全域動作,但您可以將「_流程」_包含在 _Aura_ 元件中作為因應措施。 Omnistudio 可讓您建立可編輯的 FlexCard 和 Omniscript,您可以將這些 FlexCard 和 Omniscript 放置在您可以放置「流程」的_幾乎_任何位置,但當這些 FlexCard 和 Omniscript 可編輯時,便無法進行封裝。 LWC 提供高層級的可重複使用性,用於建立可透過 Salesforce、社群和開放原始碼專案的中繼資料與目標相關聯的元件。您也可以使用 [Lightning Out 2.0](https://developer.salesforce.com/docs/platform/lwc/guide/lightning-out-intro.html) 將 LWC 元件內嵌在您自己的網站中。 Lightning Out on External Sites LWC 元件也可以透過 [Lightning-Flow](https://developer.salesforce.com/docs/component-library/bundle/lightning-flow/documentation) 元件啟動「流程」。 Omnistudio 優於透過 OmniOut 功能向外部網站公開內容。透過 OmniStudio 和 OmniOut,您可以將 OmniScript 表單和 FlexCard 元件編譯為標準元件,然後在第三方網站或應用程式中將其在平台外執行。 目前,Mobile SDK 範本中未正式支援本指南涵蓋的任何形式技術。如果 Mobile SDK 對您的使用個案至關重要,我們建議在行動應用程式中原生建立表單或建立 Visualforce 頁面,同時記住尺寸規格。 ### 邏輯 如果您需要在表單中使用值來建立或更新記錄,則「動態表單」非常適合。您必須針對該範圍以外的功能利用 Flow、Omnistudio 或 LWC,包括建立決策或迭代層,或使用表單中的輸入產生 Slack 貼文或電子郵件。 #### 要詢問的問題 - 背景需要執行的動作或邏輯為何? - 您是否需要使用相關記錄的值? - 您的表單是否需要在單一交易內或跨多個交易完成其作業? - 您是否需要與外部系統整合? - 您對可重複使用性和模組性有何需求?
記錄與動作 階層資料管理 在一個交易內作業 跨多個交易作業 整合 模組設計與重複使用 封裝
動態表單 不提供 不提供 不提供 不提供 不提供 不提供 可用
畫面流程 可用 不提供 可用 可用 可用 可用 可用
Omnistudio 可用 可用 可用 可用 可用 可用 不提供
畫面流程 + LWC 可用 可用 可用 可用 可用 可用 可用
LWC 可用 可用 可用 可用 可用 可用 可用
流程提供標準動作以張貼至 Slack、傳送電子郵件和與 Quip 文件互動,而您不需要撰寫任何這些作業的程式碼。LWC 透過與 [使用者介面 API](https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_get_started.htm) 互動的電線轉接器,提供與單一記錄和相關物件的豐富互動。LWC 也可以使用 [getListInfoByName](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_get_list_info_by_name.html) 的電線與多個記錄互動。 LWC Interaction via Wire Adapters Omnistudio 使用整合程序和「資料對應器」來取得和轉換資料 (外部與 Salesforce 內部)。由於有許多免程式碼函數,因此其在使用各種層級的關係來壓平和擴充資料集方面極為優異。 流程、Omnistudio 和 LWC 皆與 Apex 整合,因此您可以輕鬆地填補您所選擇解決方案中的任何間隙 (例如,如果您需要從 LWC 篩選記錄,您可以使用 Apex 的電線轉接器建立複雜的 SOQL 查詢。如果您因按一下情節而感到困惑,請考慮使用「流程」或「Omnistudio」作為適用於伺服器端需求的 Apex 控制項可行替代方案。 您也應考慮是否要立即認可動作,或將動作延後至表單的特定部分。這特別與您使用多頁表單相關。「流程」可讓您輕鬆地從多個表單 (流程畫面) 結合輸入,並稍後在精靈 (流程) 中使用這些輸入來執行特定作業,這是我們建議設計「流程」的方式。在結尾執行動作 (以防使用者在畫面之間往回跳轉以變更其回答)。 #### 控制作業 交易和 [管理員限制](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)是 Agentforce 360 Platform 的整體。如果您的使用個案相當簡單,則控制特定作業發生的交易並不重要。不過,有一些使用個案會讓您想要將多個作業合併到單一 [交易中](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#交易),而非在多個交易之間執行。 以下是一些範例: - **回復:**假設您的表單在背景建立多個記錄。如果第三個記錄的建立失敗,是否應回復前兩個記錄?如果每個動作彼此獨立,您可以將其作為個別交易執行。不過,如果它們彼此相依 (且您希望其中一個失敗也讓其他項目回復),則應將其實作為單一交易。如果您的表單在「流程」中,您可以使用「錯誤」路徑中的「回復」元素來回復交易並確保資料完整性。 - **對管理員限制的下游影響:**當您的表單建立或更新記錄時,請務必考量該作業的下游影響為何: - 根據建議的記錄變更,可能會觸發哪些程序、工作流程規則、流程觸發、Apex 觸發或儲存訂單中的其他項目? - 這些集合變更如何影響在該交易中耗用的管理員限制? - 如果特定記錄變更可能會導致影響您限制的下游變更,最好考慮在自己的交易中隔離該記錄變更。 - **批次處理:**您可能需要同時批次多個更新 (即使是在 UI 內容中)。假設您的多畫面表單重複處理大量記錄。請等到您收集所有記錄的更新,然後提交一個要求來更新所有記錄,而不是在每個畫面之後認可記錄更新。 當您使用「動態表單」建立或編輯記錄時,您只會執行一個作業,且該作業一律是淨新交易的開始。 當您建立畫面流程時,您可以大幅控制在指定交易中發生的狀況。畫面與本機動作會作為交易之間的邊界。以下是在畫面流程結構中如何管理交易的概況摘要。 1. 一般使用者與畫面互動,然後按一下「**下一步**」。 2. 用戶端會將輸入要求張貼至 API。 3. API 接收要求,並開啟交易和資料庫連線。接著,API 會呼叫流程引擎來叫用要求。 4. 流程引擎會在流程定義中接管並遵循適當的路徑,直到它到達畫面或本機動作節點為止。接著,引擎會將該節點的相關資訊傳回給 API。 5. API 會建立一個回應物件,其中包含要呈現的下個畫面的詳細資料,並將該物件傳回給用戶端。此時會認可資料庫變更 (依據 [儲存訂單執行](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#資料庫操作)),且資料庫連線和交易會關閉。 6. 用戶端使用 API 回應來呈現使用者互動的下一個畫面。 7. 從步驟 1 開始,然後重複此流程。 換句話說,畫面會_破壞_交易。發生此情況時,系統會認可任何待處理動作或 DML、結束先前的交易,並開始新的交易。 multi-screen flow 請記住,特定設計元素 (您將分組至指定交易的作業) 取決於您。 以下是一些範例: screen flow with separate transactions - 開始時,您會看到在多個畫面收集輸入的流程,然後在一個交易中執行數個動作。 - 下一個流程會在個別的交易中執行每個作業。 - 如果單一作業在一系列資料庫作業中失敗,流程也可以使用「回復記錄」來讓您回復整個交易。 Screen Flow with multiple create records 假設您有一個流程建立記錄、更新記錄,然後建立其他記錄 (在下一個流程中說明)。 在此情節下,如果前兩個元素成功,而最後一個元素失敗,則前兩個 DML 作業仍會建立並更新適當的記錄,但第三個元素不會。 Screen Flow with Rollback 透過使用「回復記錄」元素,如果所有三個作業都必須一起進行,您可以確保整個交易已回復 (如最終流程中所示)。 **備註:**如需詳細資料,請查看「[交易中的流程](https://help.salesforce.com/articleView?id=flow_concepts_transaction.htm)」和「[交易中的流程大量處理](https://help.salesforce.com/articleView?id=flow_concepts_bulkification.htm)」。 您從 LWC 控制交易的能力取決於 LWC 用來執行其作業的基本服務。如果您使用 Lightning 記錄格式基本元件,則提交表單時,基本作業 (建立或更新記錄) 會在獨立交易中發生。 一般而言,這些規則適用於: - 每個 UI API 呼叫都會在其自己的交易中隔離。 - 如果您需要在單一交易中執行多個作業,請將輸入傳送至伺服器端技術 (例如,Apex 控制項或流程)。請記住,該技術的一般交易規則仍適用。 #### 外部整合 Flow、Omnistudio 和 LWC 都支援平台事件 (適用於以 [事件為導向的結構](/docs/architect/zh-tw/decision-guides/guide/event-driven)) 和 API 整合。除了自訂 Apex 程式碼外,Flow 和 Omnistudio 也有可與 API 整合的陳述性支援機制。 如果您需要連線至 MuleSoft API 或 RPA 機器人,請使用 MuleSoft Services,因為這會產生「外部服務」。 External integrations via MuleSoft 如果 API 有 OpenAPI 結構描述,請建立「外部服務」。 External Integrations via OpenAPI 針對所有其他例項,請使用「流程」中的 **HTTP 呼叫**功能 (由外部服務提供技術支援) 或 Omnistudio 中的 **HTTP 動作**。 External integrations via HTTP Omnistudio 提供一組豐富的整合功能,可使用整合程序呼叫外部系統,透過資料對應器來轉換資料。 無論您是使用自訂 Apex 程式碼還是外部服務來進行實作,**呼叫**仍是呼叫。 以下是您需要瞭解的事項。 - 呼叫可能需要大量的時間來處理。 - 當同步執行呼叫時,呼叫會在資料庫交易開啟時執行。 - 如果您有任何待處理的資料庫作業,Salesforce 不允許您將資料庫交易保持開啟。 請記住,主要的限制是在執行 **建立**、**更新**或 **刪除**作業,然後在相同交易中執行 **呼叫** 時,造成資料狀態不一致的風險。由於上述第三個考量事項存在,因此不允許使用此模式,因為前兩個考量事項存在。 在「流程」中,您可以透過中斷交易來略過此限制。請記住,畫面與本機動作會重新導入瀏覽器內容。當您使用外部呼叫時,您可以使用畫面和本機動作,但建議在可叫用進階設定中啟用「**交易控制」**。「交易控制」可讓您在進行呼叫前自動結束交易。若要啟用「交易控制」,請在叫用動作的「**進階」**區段中選取「**一律開始新交易**」。 External Integrations via Callouts LWC 可協助簡化呼叫對交易的影響。換句話說,使用 Lightning Data Service (LDS) 執行資料作業,然後使用 Apex 控制項進行外部呼叫。由於 LDS 呼叫在其自己的交易中是隔離的 (與 Apex 呼叫分開),因此可保護您免受產生的資料不一致。 #### 可重複使用性和模組性 「動態表單」不支援重複使用。每個記錄皆繫結至特定物件的特定 Lightning 記錄頁面;不過,您可以將該 Lightning 記錄頁面指派給多個應用程式、設定檔等。 您可以撰寫可在多個元件之間使用的文件庫、公用程式和元件的方式,您也可以在建立流程時透過利用 **子流程**的功能來套用類似的設計模式。若要這麼做,請將您的流程儲存在較小的模組化分類中,然後使用 **子流程** 元素從其他流程呼叫流程。如果您的設計需要流程,您可以建立一個流程,其本身且作為子流程很有用。 Omnistudio 是為了模組化而建立的。「資料對應器」、「Omniscript」、「FlexCard」和「整合程序」皆獨立建立,但也可以互換運作。FlexCard 也可以建立為 LWC 元件,這些元件可內嵌在其他 LWC、Omniscript、記錄頁面和 Experience Cloud 網站中。 畫面流程、Omniscript 和 LWC 皆可建立以重複使用,並內嵌在各種位置中,包括外部網站和 Lightning Out 應用程式。當您設計可組合的解決方案時,您也會獲得適應性和穩定性優點。 ### 驗證 用於建立或更新記錄的所有技術都必須遵循系統層級驗證,無論是傳統驗證規則還是內建在 Apex 觸發中的自訂驗證。無論您使用哪種技術來執行記錄變更,每個變更都必須通過儲存順序。這表示除了驗證規則之外,記錄變更也會由數個儲存前或儲存後流程、前後觸發、升級規則、指派規則等處理。 **備註:**如果您尚未執行此操作,請檢閱並將 Apex [執行順序加入](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)書籤。 #### 要詢問的問題 - 您的表單是否有系統級驗證以外的其他需求? - 您是否需要在表單內動態設定必要或唯讀欄位?
遵循系統層級驗證 此表單特有的自訂欄位級驗證 自訂欄位級驗證
動態表單 可用 不提供 不提供
畫面流程 可用 不提供 不提供
Omnistudio 可用 可用 可用
畫面流程 + LWC 可用 可用 可用
LWC 可用 可用 可用
通常,流程畫面或 Omniscript 步驟上的輸入為未繫結,因此表單本身不會原生遵循與特定物件相關聯的系統級驗證。不過,您用來建立或更新記錄的值會以儲存順序處理,這表示這些值會通過物件的系統級驗證。 **備註:**並非所有「畫面流程」元件都支援輸入驗證。 「動態表單」與版面配置類似,可讓您在頁面層級設定 **必要** 性與 **唯讀** 狀態。請記住,您無法覆寫系統層級設定。 流程提供自訂表單輸入驗證的彈性。系統會在用戶端層級執行多個檢查 (例如,標記遺失的必要欄位和資料類型檢查,以及輸入驗證規則內的相容公式)。作為安全性的額外層級,也會在伺服器上評估輸入驗證。當使用者按一下「**下一步」** 時,流程會將輸入再次傳送至伺服器進行驗證。如果傳回任何無效的輸入,會封鎖瀏覽,並顯示適當的錯誤。 伺服器會透過檢查: - 輸入的 **必要性**設定,或輸入的值是否與基本資料類型相容。 - 輸入的自訂驗證。您需要提供 _布林值_公式運算式,以及錯誤訊息,以在不符合公式運算式時顯示。 - 基本元件的自訂驗證。如果您要為流程建立自訂 LWC,您必須將自己的驗證程式碼新增至 validate() 方法。 您也可以透過「畫面流程」中的「**訊息」** 元件提供可存取的使用者警示,但這不會防止使用者瀏覽至其他頁面,或進入引導式流程中的下一個步驟。**訊息**元件中的「_錯誤_」狀態最適合用於停用瀏覽時透過錯誤路徑觸發的專用錯誤畫面。 Omnistudio 透過「[設定錯誤」](https://help.salesforce.com/s/articleView?id=sf.os_set_errors_in_an_omniscript.htm&type=5) 動作搭配「[條件檢視」](https://help.salesforce.com/s/articleView?id=sf.os_conditionally_display_elements_using_the_conditional_view_property.htm&type=5) 和「[傳訊」](https://help.salesforce.com/s/articleView?id=sf.os_display_messages_in_omniscripts_19551.htm&type=5) 元件,提供強大的錯誤和驗證處理功能。 針對 LWC,大多數基本元件都會執行自己的用戶端驗證 (例如Lightning 遵循系統層級需求,但不遵循頁面層級需求)。針對您的自訂元件,您可以 Build Your Own 驗證機制。 請記住,需要使用者輸入資料的欄位應出現在表單的開頭。提交表單前 (若可能) 驗證用戶端的使用者輸入。 ### 互動設計 靜態表單已過期。今天,重點移至在_特定_時間、在_特定_位置為_特定_使用者動態更新具有正確內容和值的表單。讓我們進一步瞭解可透過 Salesforce 表單建立工具實現的項目。 #### 要詢問的問題 - 哪些類型的互動或條件應在您的表單中觸發動態回應? - 填寫表單時,您是否需要執行螢幕外 (背景) 作業? - 您是否需要將欄位設定為 **可見**、 **必要**、 **唯讀** 或已 **停用**,或者您是否需要根據表單輸入變更格式?
執行螢幕外資料作業 條件值與計算 條件化可視性 條件式必要性 條件式格式化 條件式唯讀狀態 條件式停用狀態
動態表單 不提供 不提供 可用 不提供 可用 不提供 不提供
畫面流程 可用 適用* 可用 可用 不提供 可用 可用
Omnistudio 可用 可用 可用 可用 可用 可用 可用
畫面流程 + LWC 可用 可用 可用 可用 可用 可用 可用
LWC 可用 可用 可用 可用 可用 可用 可用
*限於使用資源選擇器而非靜態核取方塊的元件
**反應性畫面**可啟用「畫面流程」互動性。反應性可讓流程畫面上的個別元件彼此通訊,讓「畫面流程」更強大。 **執行螢幕外資料作業** 「畫面流程」提供透過「**畫面動作」**在相同畫面上提取資料的陳述性方法。「畫面動作」可讓您在畫面中的任何變更或使用者按一下「**動作按鈕**」元件時觸發自動啟動流程。您可以將自動啟動的流程結果對應至相同的畫面,因此不需要使用者瀏覽至其他畫面。 LWC 提供完整的電線轉接器陣列,提供 Salesforce 資料的存取權,以動態填入表單元件中的資料,這可讓開發人員透過 Apex 控制項來**更新**、**刪除**和**建立**記錄。 Lightning Web Components Off-Screen Data Operations **可視性** 您可以在所有表單建立工具中動態控制可視性。「動態表單」、「Flow Builder」和 Omnistudio 使用元件可視性功能來解決此問題。您可以根據表單中的其他值,或使用者是否在行動裝置上完成表單,以宣告的方式**顯示**或**隱藏**欄位。 - 「動態表單」會根據記錄欄位值、對應欄位和尺寸規格控制可視性。 - 透過「流程」,您可以讓可視性規則以其他畫面輸入為基礎,以及在流程前期填入的其他資源 (例如,其他記錄中的公式或值)。 - **以裝置為基礎的規則:**一開始可能並不明顯,但您可以使用公式在使用者在行動裝置上時,**顯示**或**隱藏**特定欄位。撰寫可檢查 **$User.UIThemeDisplayed** 全域變數值的流程公式。如果值為 **Theme4t**,則使用者正在使用 Salesforce 行動應用程式完成表單。 - **評估其他資源:**手動變數和公式參照僅會在伺服器上評估。這表示資源在第一次呈現畫面時所擁有的值是資源在瀏覽至另一個畫面之前所擁有的值。瀏覽期間,流程執行階段會向流程引擎 (伺服器) 提交要求,並傳回最新的手動變數和公式值。如果您預期您的可視性規則會在使用者通過單一畫面時更新 (例如,Onblur),您必須確保您僅參照畫面上其他元件的值。 - 透過 Omnistudio,您可以設定「**條件檢視」** 內容,條件式地**顯示**或**隱藏**元件。不過,您無法為輸入新增多個「條件式檢視」內容。 **條件式輸入狀態** 如果您需要動態控制其他任何內容 (例如,欄位為 **必要**、 **停用**或 **唯讀**),則有一些選項。LWC 提供輸入狀態的完整反應性控制。透過「反應性畫面流程」元件,您可以針對支援的標準元件動態控制元件屬性 (例如**唯讀**、**停用**和 **必要**),而 Omnistudio 支援元件特定屬性的完整範圍。如果您的需求指出您需要「流程」,且元件不支援特定屬性狀態,您可以建立可內嵌 LWC 以達到動態輸入狀態。 如果您需要動態控制其他任何內容 (例如,欄位是**必要**還是為**唯讀**),請在短期內使用 LWC,因為您可以完全控制。這特別適用於您針對如何處理開啟或點擊的自訂需求。 **畫面流程中的反應性 LWC** 如果您要建立可在畫面流程上反應或變更其他元件的 LWC,請查看畫面流程的 [LWC 最佳作法](https://developer.salesforce.com/blogs/2023/02/lwc-best-practices-for-screen-flows)指南,以確保您的元件與流程執行階段引擎整合,並如預期般運作。
標準事件處理 (模糊、焦點) 自訂事件處理
動態表單 不提供 不提供
畫面流程 不提供 不提供
Omnistudio 不提供 適用*
畫面流程 + LWC 可用 可用
LWC 可用 可用
*Omnistudio 標準執行階段不支援 Pub/Sub,但支援 Windows postMessage
針對自訂事件,如果您的某些輸入 (或整個表單) 需要與頁面上的其他元素通訊,則 LWC 是您唯一的選項。 - 若要在相同的 DOM 樹狀結構內通訊,請使用 [CustomEvent 介面](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events)。 - 若要跨 DOM 通訊,請使用 [Lightning 傳訊服務](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel)。 - 如果您的目標容器[不支援](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel_considerations) Lightning 傳訊服務,請使用 pub/sub 模組。 #### 互動設計的其他資源 - 如需詳細資訊,請參閱《_Lightning Web 元件開發指南_》中的 [與事件通訊](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/events)和跨 DOM [通訊](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events_pubsub)。 - 針對 Omnistudio,請查看 [從 Lightning Web 元件與 Omniscript 通訊。](https://help.salesforce.com/s/articleView?id=sf.os_communicate_with_omniscript_from_a_lightning_web_component_18222.htm&type=5) ### 樣式 為了提供最佳的使用者體驗,務必確保表單樣式與內嵌表單的其他應用程式或網站一致。這可能表示使用 Salesforce 提供的標準範本,或建立使用設計中每個像素的自訂 CSS,以提供更明確的外觀和操作。 #### 畫面流程樣式覆寫 管理員可以針對畫面容器或個別元件設定有限的畫面和元件樣式覆寫集 (例如色彩、框線和按鈕外觀)。這些覆寫會套用至主題與品牌標識之後,這可讓產生器進行目標視覺調整,而不會影響其他應用程式。 樣式覆寫適用於本地化的視覺例外狀況 (例如醒目提示確認畫面或強調特定呼叫動作 (CTA);它們並非完整樣式系統。它們不提供 CSS 層級控制,且並非為了在畫面或流程之間重複使用而設計。 從結構角度來看,樣式應遵循此先決順序: 1. **主題與品牌標識:**Lightning 主題、體驗產生器品牌集或 LWR 網站主題 2. **流程樣式覆寫:**目標畫面或元件調整 3. **自訂元件 (LWC):**當需要像素完美控制或可重複使用的設計模式時 使用主題與設計系統有助於確保樣式在一段時間內保持一致、可調整且易於維護。 #### 要詢問的問題 - 您所需的樣式和 CSS 有多複雜? - 您是否需要自訂、像素完美的樣式或標準主題?
直接設定樣式 組織和體驗產生器主題 像素完美樣式
動態表單 不提供 可用 不提供
畫面流程 不提供 可用 適用**
Omnistudio 適用* 不提供 可用
畫面流程 + LWC 不提供 可用 可用
LWC 不提供 可用 可用
*僅限 FlexCard

** 可以為畫面元件設定某些樣式屬性,但無法為 CSS 覆寫。
FlexCard 是本指南中唯一的產品,可讓您以宣告的方式控制您在工具中建立之 UI 的樣式與版面配置 (例如,邊緣與填補、列印、色彩等)。 「動態表單」與「流程」會遵循陳述性主題功能。如果您需要額外的控制 (超出 [Salesforce 主題](https://help.salesforce.com/articleView?id=brand_your_org_in_lightning_experience.htm&mode=1)、[體驗產生器品牌集](https://help.salesforce.com/articleView?id=community_designer_brandsets.htm)或 [LWR Experience Cloud 網站](https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_overview.htm)支援之外),請考慮使用程式設計解決方案。 喜歡使用 CSS 的小組有數個選項: - 流程與 LWC 會繼承 [標準設計權杖](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/tokens_standard.htm)。 - Omniscript 和 FlexCard 包含可透過 [Newport](https://help.salesforce.com/s/articleView?id=sf.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5) 自訂的設計系統支援。 - 透過 LWC,您可以撰寫自己的元件,並完全控制其 HTML 和 CSS。 我們建議盡可能使用主題與設計系統,以確保所有內容的外觀與操作一致。 **備註:**您可以在「流程」中內嵌 Lightning 元件。如果您需要像素完美控制表單的外觀與操作,但您也想要使用「流程」的其他優點 (例如瀏覽模型),您可以擁有這兩個世界的最佳功能!相同的原則也適用於 Omniscript 與 FlexCard。 ### 版面配置 選擇好的版面配置對於設計簡化表單而言至關重要,其可讓資料輸入快速且有效率,並提高資料完整性。 #### 要詢問的問題 - 如何建構版面配置以最佳化使用者體驗? - 如何向使用者呈現現有資料,讓使用者更容易在表單中輸入新資料?
2 欄 4 欄 4 欄以上 重複資料區塊 索引標籤容器 可折疊式容器
動態表單 可用 不提供 不提供 不提供 可用 可用
畫面流程 可用 可用 不提供 可用 不提供 可用
Omnistudio 可用 可用 可用 可用 適用* 可用
畫面流程 + LWC 可用 可用 可用 可用 可用 可用
LWC 可用 可用 可用 可用 可用 可用
*若將資料內嵌在 Omniscript 中的 FlexCard 中,則可使用索引標籤
「動態表單」支援可分成欄位內個別區段的雙欄版面配置。這些區段可放置在元件 (例如索引標籤和可折疊式) 內,以建立有序且易於使用的版面配置。 您也可以使用 **區段**元件呈現流程。您最多可以在流程畫面上新增四個欄和無限數量的區段。區段元件也會回應螢幕寬度,因此它也適用於較小的螢幕。這可讓您將條件化可視性套用至整個區段,讓您更容易將可視性大量套用至區段內的多個欄位。**流程區段**也支援欄標題,並提供類似的折疊式體驗,使用者可按一下標籤來摺疊整個區段。 Omniscript 具備各種版面配置選項,用於顯示欄位與資料。您可以建立包含最多 12 欄的資料區段,包括條件式摺疊式折疊式折疊式。 透過 LWC,您可以使用 Lightning] 格式和支援的 Lightning] 欄位來控制版面配置。唯一的版面配置限制來自 HTML 和 CSS。**Lightning 記錄格式**元件遵循相關聯版面配置中的區段組態 (例如,如果區段在版面配置中為兩欄,則該區段在元件中也是兩欄)。 ### 翻譯 如果您的表單需要可供不同區域的使用者或使用不同語言的使用者存取,您必須確保用於建立表單的工具符合您的本地化需求。 **備註:**特別針對表單,本地化需求通常涉及將文字元素翻譯成其他語言。 #### 要詢問的問題 - 您的表單是否要在一個以上的國家或地區使用? - 表單中的文字是否需要本地化為其他語言?
在產生器中輸入的標籤 程式碼中的標籤
動態表單 適用* 不提供
畫面流程 可用 可用
Omnistudio 可用 可用
畫面流程 + LWC 可用 可用
LWC 不適用 可用
*僅欄位區段標題
如果您本地化自訂欄位,「動態表單」會遵循翻譯的標籤。「動態表單」也會遵循在 Lightning 應用程式產生器中指派給元件標籤和屬性的任何[自訂標籤](https://help.salesforce.com/s/articleView?id=platform.lightning_page_components_use_expressions_for_labels.htm&type=5)。 流程支援透過翻譯工作台翻譯所有標準和自訂畫面元件的使用者面向標籤。 您可以在下列畫面元件上本地化標籤、說明文字和錯誤訊息: - 文字 - 長文字區域 - 數字 - 貨幣 - 核取方塊 - 選項按鈕 - 選項清單 - 多重選擇選項清單 - 核取方塊群組密碼 - 日期 - 日期/時間 無內建翻譯支援立即可用的動作 (例如「傳送電子郵件」或「張貼至 Chatter」),但有因應措施。如果您使用 [自訂標籤](https://help.salesforce.com/articleView?id=cl_about.htm)定義翻譯的標籤,則在 Flow Builder 中進行設定時,您可以在動作或元件中參照該自訂標籤。若要這麼做,您需要建立參照自訂標籤的流程公式,然後在流程內的適當位置參照該公式。 Omniscript 使用自訂標籤進行翻譯。如需詳細資訊,請查看 [此說明文件](https://help.salesforce.com/s/articleView?id=sf.os_create_multi_language_omniscripts.htm),以確保您的 Omniscript 已準備好使用多國語言。 針對 LWC,若某些基本元件在翻譯工作台中設定 (例如 Lightning則會自動繼承相關聯物件欄位、說明文字和驗證訊息的翻譯。 如果您需要在程式碼中導入新的可翻譯標籤,則自訂標籤是最適合的方式。宣告您需要的自訂標籤,然後從 `@salesforce/label` 範圍模組將其匯入元件。 ## 非功能考量事項 使用此區段可在實作前評估安全性、品質和營運限制。 ### 安全性 安全性是一個複雜的主題,建立表單時,有一些考量事項可能不明顯。在基礎層級,您需要確保表單在正確的內容中執行,且使用者擁有使用其基本資料所需的權限。除此之外,您也可能想要採取額外的措施來清除 Rich Text 欄位中潛在的惡意程式碼或 URL、防止特定使用者存取表單,或限制管理員未來可能內嵌表單的位置類型。 選擇工具之前,請務必徹底記錄您的安全性需求。如需此類型文件的其他指引,請查看 Salesforce [Well-Architected 安全性原則範本](/docs/architect/zh-tw/resources/guide/security-policy-template)。 #### 要詢問的問題 - 表單是否應在執行某些作業前檢查使用者的存取權? - 您應該消毒使用者輸入嗎? - 您想要控制可以存取表單的人員嗎? - 您想要控制表單的內嵌位置嗎?
提升使用者權限 控制擁有存取權的人員 限制允許的位置
動態表單 不提供 可用 不提供
畫面流程 可用 可用 不提供
Omnistudio 不提供 可用 不提供**
畫面流程 + LWC 可用 可用 不提供
LWC 適用* 可用 可用
*需要 Apex

**雖然 Omniscript 無法具有指定的目標位置集,但 FlexCard 可以。
#### 提升使用者權限 當程式在 **使用者環境中**執行時,Salesforce 會強制執行一系列的存取檢查,其中包括根據您組織的共用規則驗證欄位級安全性、CRUD 權限和記錄存取權 (例如,只有在使用者能夠更新個案、適當的欄位級安全性,以及對問題記錄的存取權時,使用者才能執行個案更新表單)。 如果您希望使用者能夠在使用您的表單時執行特定作業,但無法透過任何其他表單或互動,會發生什麼事?這就是 **系統內容**的入口! **系統內容**可讓您在工作階段期間提升使用者的權限 (例如,使用者不需要更新「個案」物件的存取權,才能成功完成個案更新表單)。這對於未經驗證的社群特別有用。您可以將表單設定為在系統環境中執行,而不是授與來賓使用者潛在危險的技能。 系統內容只能在絕對必要時使用。當表單在「系統內容」中執行時,每個 CRUD 作業都會略過物件和欄位級安全性和共用元件。此外,「系統內容」不會影響 Salesforce 將誰視為執行動作的 _執行動作使用者_ (您在「**上次修改者」**欄位中看到的名稱)。針對您的表單執行的每個作業 (例如個案更新),_執行動作使用者_是目前的使用者 (即使表單在不同內容中執行)。 **備註:**「動態表單」、「Omniscript」與 LWC」一律在使用者環境中執行,無法覆寫此行為。 「畫面流程」依預設會在使用者環境中執行,但您可以將其設定為在系統環境中執行。您可以決定流程是否應授與對所有資料的存取權,或是否應強制執行記錄級存取權。 - 如果您將 Lightning 元件內嵌在在系統環境中執行的流程中,則流程不會覆寫元件的內容。如果您需要略過使用者存取檢查,請使用流程來執行這些作業,並將適當的資料傳送至 Lightning 元件或傳送出來。某些立即可用的元件 (例如「對應」) 無法在系統環境中作業。 - 如果您的流程呼叫 Apex 動作,則會涉及其他細微差別。 - 如果 Apex 類別設定為 _繼承共_用,則無論流程設定的方式為何,它都會在共用的系統環境中執行。 - 如果類別沒有明確的共用宣告,則無論流程設定的方式為何,類別都會在系統環境中執行,而不會共用。 - 如果類別設定為「_共用或不共用_」,則會覆寫流程的內容。 **使用 Experience Cloud 網站在系統環境中查詢記錄** 如果您在 Experience Cloud 網站上執行「在系統環境中執行流程」(尤其是未經驗證的流程),請僅將特定欄位儲存在「**取得記錄」**元素中。當您使用「流程」並將「**取得記錄」**元素的結果傳遞至「子流程」、「可叫用動作」或 Lightning 元件時,瀏覽器的開發人員工具可能會檢查該物件中的所有欄位。無論您的意圖為何,這都可能會讓 Experience Cloud 使用者可以使用欄位。若要確保只有正確的欄位會在「系統內容」啟用時顯示,請在您的「**取得記錄」**元素中指定這些特定欄位。 **備註:**Omniscript 邏輯會在用戶端執行,這可讓攻擊者修改預期的 Omniscript 執行,並透過瀏覽器的開發人員工具檢視整合程序、資料對應器和 Apex 方法呼叫的回應。當您使用 Omniscript 時,請務必在伺服器端執行業務邏輯 (若可能),並針對透過 [@InvocableMethod 註釋](https://help.salesforce.com/s/articleView?id=sf.os_integration_procedure_invocation_55721.htm&type=5)公開的任何 Apex 方法實作輸入驗證規則。 **消毒輸入物** 若要保護您的組織免受惡意執行動作的影響,請使用輸入消毒。假設您在可公開存取的表單上有輸入,可對應至您組織中的「**Rich Text**」欄位。您可能會想考慮啟用自動化,以刪除可能隱藏惡意 URL 的任何 HTML。 在表單層級實作消毒並不理想,因為您可能有任何數量的來源寫入這些欄位。若要協助解決此問題,請建立「**快速欄位更新流程」(儲存前)**,或使用現有的 **Apex 觸發**程式去除或修改表單中可能輸入的任何潛在 HTML。 #### 最佳作法 - 允許「流程」在其預設內容中執行 (除非您需要針對特定作業提升目前使用者的存取權)。 - 避免針對來賓使用者在系統環境中執行「流程」。建立具有有限欄位存取權的權限集,並將其指派給 Experience Cloud 來賓使用者的設定檔。 - 在 Experience Cloud 網站上查詢「系統內容執行流程」中的記錄時,請僅將您需要的欄位儲存在「**取得記錄」** 元素或「**可叫用動作」中**。 - 如果流程執行各種作業 (所有作業皆不需要增強的存取權),請使用「子流程」來區隔應在「系統內容」內執行的作業。 - 如果您將表單內嵌在外部網頁中,可能需要將其對應至「**Rich Text**」欄位,以協助避免潛在的網路釣魚攻擊。若要這麼做,請使用 **快速欄位更新流程**或 **Apex 觸發**來消毒使用者輸入以移除 HTML。 #### 其他備註 - 依預設,Omniscript、FlexCard 和 LWC 會在使用者環境中執行。 - LWC 依預設會在使用者環境中執行。 - 流程會在使用者環境中執行,但您可以使用 Apex 控制項來覆寫流程。 - 在 UI API 內執行的作業會在使用者環境中執行。 - 使用 Apex 控制項執行的作業取決於特定類別。若要在系統模式中執行這些作業,請設定共用或不共用的 **Apex 類別**。 #### 存取控制 如果您需要控制可以存取表單的人員,請檢閱內嵌表單的容器 (例如,您可以將 Lightning 頁面指派給特定應用程式、記錄類型或設定檔使用)。如果特定輸入是敏感的,請使用可視性規則來進一步控制向人員顯示的內容。此功能適用於「動態表單」與「畫面流程」。 您可以將「流程」[限制為](https://help.salesforce.com/articleView?id=flow_distribute_security.htm)特定設定檔或權限集 (類似於 Apex 類別或 Visualforce 頁面)。依預設,流程不受限制,這表示具有「**執行流程」**使用者權限的任何使用者皆可存取流程。 如果您使用 Omnistudio,您可以設定需要使用者具備從 Omniscript、FlexCard、Classic 卡片或 REST API 管理遠端動作的 Apex 類別明確存取權的 [Apex 類別權限檢查程式](https://help.salesforce.com/s/articleView?id=sf.os_add_an_apex_class_permissions_checker_1.htm&type=5)。 **備註:**Apex 類別權限檢查僅適用於 Apex 類別。也建議為 [整合程序和資料對應器](https://help.salesforce.com/s/articleView?id=sf.os_security_for_dataraptors_and_integration_procedures_48147.htm&type=5)設定設定檔層級權限。 #### 存取控制最佳作法 - 如果您要向來賓使用者公開「流程」,則您僅應將其絕對需要的「流程」設定檔存取權授與來賓使用者。您可以將「**執行流程」**新增至來賓使用者設定檔,但此作法可能具有風險。 - 使用在「系統內容」中作業的「流程」時,請特別小心。您應將這些「流程」限制為特定使用者集,因為這些流程擁有較少的檢查和平衡,以保護您的資料。 - 確保在來賓使用者社群中執行 Apex 的任何 Omniscript 都會列在 Apex 類別定義中**共用**。 - 針對來賓使用者設定檔,請僅指派您要允許來賓使用者呼叫的 Apex 類別。遵循此作法有助於避免不小心向來賓使用者公開其他業務邏輯。 針對 LWC,您可以檢查目前使用者的權限指派,確認其是否具有特定標準或自訂權限。您可以直接在 **JavaScript 中**從 `@salesforce/userPermission` 和 `@salesforce/customPermission` 範圍模組匯入 Salesforce 權限。您也可以使用 Apex 檢查權限。 #### 內嵌控制 LWC 只有在已新增為有效的 [目標](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.reference_configuration_tags) (例如,您可以將元件設定為可在記錄頁面上使用,而無法作為公用程式列項目使用) 之後,才能在指定的位置使用。 啟用「畫面流程」後,該流程便可在支援「畫面流程」的所有位置中使用。Flow Builder 支援具有畫面的多個「流程」類型。最明顯的類型是「**畫面流程**」,但有一些其他專用類型僅限於特定位置 (例如,**Field Service 行動應用程式**僅支援「**Field Service 行動流程」)**。這類似於僅 Experience Cloud 支援的「**連絡要求流程**」。 無論「流程」類型為何,建立「流程」的人員都無法控制「流程」的內嵌位置。流程適用於支援該特定流程類型的每個位置。 如果您使用 Salesforce Industries,則在 Omniscript 方面會有輕微的警告。您無法為 Omniscript 指定目標,但可以為您要內嵌的 FlexCard 指定目標。 ### UI 測試自動化 Salesforce 有數種端對端測試自動化工具 (例如,查看 [Salesforce UTAM](https://developer.salesforce.com/blogs/2022/05/run-end-to-end-tests-with-the-ui-test-automation-model-utam)),可讓您模擬使用者如何與表單互動。您可以撰寫任何標準或自訂 UI 的測試,包括 Lightning 頁面和畫面流程。 **備註:**這些測試類型無法驗證正在執行之方法的輸出。當您設定 UI 測試自動化需求時,請記住這一點。 #### 要詢問的問題 - 您是否需要自動化表單測試? - 您計畫執行的測試類型為何? - 測試自動化所需的細微度層級為何?
單元測試 端對端自動化
動態表單 不提供 適用*
畫面流程 不提供 適用*
Omnistudio 適用* 適用*
畫面流程 + LWC 適用* 適用*
LWC 可用 可用
*需要程式碼
**考量 UI 測試自動化需求** **單元測試**提供與業界標準 CI/CD 系統和工具一致的細微自動化和驗證,測試業務邏輯、JavaScript 控制項和特定元件的輸出。如果您選擇低程式碼方法,您將無法自行撰寫測試;不過 Salesforce 會嚴格測試所有端對端供應項目。 如果元件的方法很複雜,您可以將方法放置在專屬的 JavaScript 檔案中,以個別的方式將方法輸入文字。這可讓您將其匯入至 LWC,然後匯入至 **Jest 測試 (例如,**從 'c/utils'; 匯入 { sort })。 您可以使用 ISV 的無程式碼解決方案、建立自訂測試自動化解決方案,或使用開放程式碼測試架構 (例如 Selenium WebDriver 或 WebdriverIO) 來進行端對端自動化。這些解決方案適用於所有的 Salesforce UI 互動 (例如 Lightning 頁面中的「動態表單」、公用程式列中的「畫面流程」或快速動作流程中的 LWC)。 ### 度量 將表單部署至生產環境後,您必須確保表單有效使用。視您的使用個案而定,這可能表示追蹤表單填寫的次數,以及平均使用者在提交其資訊前花費完成表單的時間。在選擇工具前,請務必識別您的可追蹤 KPI。 #### 要詢問的問題 - 您是否需要追蹤表單用量? - 哪些 KPI 可以判斷表單是否有效使用?
頁面檢視 表單所花費的時間 追蹤表單完成 追蹤成功率
動態表單 適用** 不提供 不提供 不提供
畫面流程 可用 適用* 可用 可用
Omnistudio 可用 適用* 可用 可用
畫面流程 + LWC 可用 適用* 可用 可用
LWC 適用** 適用* 可用 可用
*可在啟用封裝型 Omnistudio 執行階段時使用** 可透過追蹤父系 Lightning 頁面用量
如果您需要追蹤整體表單使用情況與採用情況,請使用低程式碼工具。「動態表單」與「畫面流程」可透過立即可用的自訂報告進行追蹤。不過,「畫面流程」追蹤報告提供額外的細微性。如果您需要追蹤 LWC 使用狀況,立即可用的可用性取決於您使用 LWC 的位置。如果是在 Lightning 頁面上,則所有可用的 Lightning 頁面用量追蹤元素也會套用至您的 LWC。這也適用於內嵌在「流程」中的 LWC。 「動態表單」並非立即可追蹤,但您可以透過 [Lightning 用量物件](https://help.salesforce.com/articleView?id=lex_usage_reports.htm)追蹤父系 Lightning 頁面的用量。若要追蹤標準 Lightning 頁面,請使用「 **依頁面度量使用 Lightning 的使用** 者」自訂報告。針對自訂 Lightning 頁面,請使用「**使用者與 Lightning 使用情況依據 FlexiPage 度量**」自訂報告。 流程可協助您追蹤特定表單的採用狀況。使用 **範例流程報告:畫面流程**可回答下列類型的問題: - 此表單的完成率為何?目前是否正確採用? - 使用者需要多久才能完成此表單? - 使用者花費最多時間完成哪個畫面? - 使用者瀏覽至上一個畫面的頻率為何? - 錯誤的發生頻率為何? 如果標準報告不符合您的需求,您可以使用「**畫面流程」**報告來複製報告並進行變更或從頭開始 Build Your Own 報告。 如果您使用封裝型 Omniscript 執行階段,您也可以使用 [Omnistudio for Vlocity Tracking Service](https://help.salesforce.com/s/articleView?id=sf.os_vlocity_tracking_service.htm&type=5)。此服務會追蹤所有類型的事件 (例如,您可以追蹤在 Omniscript 中完成步驟所需的時間,這有助於識別流程改善方式)。 **備註:**沒有立即可用的選項可追蹤未內嵌在「畫面流程」、「Omniscript」或 Lightning 頁面中的 LWC,但您可以使用 Apex 建立自訂解決方案。 ### 封裝與部署 您可能已熟悉使用變更集或 **DevOps Center** 將解決方案部署至測試環境或生產環境。這些部署選項完全支援「動態表單」、「流程」與 LWC。不過,Omnistudio 需要個別的工具,即 [IDX 工作台](https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5)。 #### 要詢問的問題 - 您打算如何部署表單? - 表單是否必須散佈至多個 Salesforce 組織?
第一代受管理封裝 (1GP) 第二代受管理封裝 (2GP) 解除鎖定的封裝 變更集 DevOps Center
動態表單 可用 可用 可用 可用 可用
畫面流程 可用 可用 可用 可用 可用
Omnistudio 不提供 不提供 不提供 不提供* 不提供*
畫面流程 + LWC 可用 可用 可用 可用 可用
LWC 可用 可用 可用 可用 可用
*使用 IDX 工作台將 Omnistudio 解決方案部署至其他組織。
如果您是 ISV 或計畫在 AppExchange 上封裝解決方案的合作夥伴,請查看「動態表單」、「流程」和「LWC」。請記住,Omnistudio 不支援封裝。 ### 將低程式碼瀏覽至 Pro-Code Continuum 本指南旨在向您顯示「動態表單」、畫面流程、Omnistudio 和 LWC 提供的功能與自訂層級。 Low-Code to Pro-Code Continuum 以下是概況概觀。 - 建立表單時,LWC 是最強大且可自訂的選項,但具有最少的護欄。這就是為什麼建立元件時必須牢記[安全性](/docs/architect/zh-tw/well-architected/guide/trust.html)與可[擴展性](/docs/architect/zh-tw/well-architected/guide/reliability.html#scalability-and-capacity-planning)。 - 「動態表單」是最不彈性的選項,但發生錯誤的機會較少。 - 「流程」與「Omnistudio」在中間略有下降。其功能比「動態表單」更強大,但並未完全符合 LWC 層級。不過,其護欄比「動態表單」較少,且比自訂程式碼更難破壞。 您可能會發現多個符合您需求的工具。如果是,最終的決定取決於最適合您小組的工具。如需考慮其他層面的詳細資訊,請查看這些「[結構設計師決策指南](/docs/architect/zh-tw/decision-guides)」。 #### 要詢問的問題 - 比較工具時,請務必評估您小組對於每個工具擁有的專業知識為何? - 有多少位開發人員熟悉 LWC 或 JavaScript? - 您的小組中是否有 Flow Builder 專家或有興趣深入瞭解的開發人員? 雖然我們不會進一步說明具體的詳細資料,但以下是關於這些特定工具如何與我們目前涵蓋的評估相關的詳細資訊。 **交付委派** 請記住,即使您的某些需求需要 LWC,也不需要使用 LWC 建立整個解決方案。決定如何模組化建立解決方案十分重要。若要這麼做,您需要識別哪些組件需要編碼的 LWC,以及哪些組件不需要。不需要 LWC 的零件應使用低程式碼解決方案建立。 當涉及流程和 LWC 時,有各種元件 (例如反應性畫面元件和畫面流程) 可在相同畫面上彼此同步,以為結構設計師、管理員和開發人員解鎖新工具。開發人員現在可以建立可在整個組織中重複使用的具目的模組化元件,這有助於提升小組生產力。這可讓開發人員使用標準和自訂「流程」元件混合來節省時間,以實現形式動態,讓他們有更多時間專注於解決新挑戰。隨著「流程」中導入反應性元件,建立表單時,從未有更適當的時間來混合「流程」與 LWC。 **長期擁有權與維護能力** 如果您要建立多步驟表單,請從「流程」或「流程與 LWC」的混合開始。如果維護表單的小組為低程式碼小組,請確保解決方案可盡可能針對預期的受眾進行設定和擴充。為了改善穩定性和維護性,將您的解決方案組織為可[組合](/docs/architect/zh-tw/well-architected/guide/resource-and-cost-optimization.html#packaging-and-modularity)單位很重要,無論您選擇的工具為何。 ### 績效 與「動態表單」、「畫面流程」、「Omnistudio」或 LWC 相關的效能考量事項會以技術所在的架構為基礎。以 LWC 為基礎的技術的效能可能高於以 Aura 為基礎的技術。由於有數個原生在 Web 引擎中實作的核心功能 (而非透過架構抽象在 JavaScript 中),因此 LWC 提供增強的效能優點。 因此,我們如何在 Salesforce 中為表單技術運用這些效能優點?讓我們進一步瞭解。 - 「動態表單」(整合在 Lightning 頁面中繼資料內) 以 LWC 堆疊基礎為基礎,可讓我們實作數個期待已久的功能。「動態表單」可作為額外的效能加成,使用漸進式呈現,以改善具有大量欄位之頁面的載入時間。 - 畫面流程以 LWC 為基礎。現在,大多數個別立即可用的元件已轉換為 LWC,但「**檔案上載」**和「**影像」**元件除外。雖然流程小組已將流程執行階段用戶端轉換為 LWC (及其大多數元件),但客戶仍需要將其 Aura 畫面元件轉換為 LWC。請記住,Salesforce 僅支援「畫面流程」中「**反應性元件」** 架構內的 LWC 元件。如需詳細資訊,請查看 [Lightning Web 元件適用於 Aura 開發人員](https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers) Trailhead 模組。如果您計畫為「畫面流程」(或任何其他容器) 建立自訂元件,請選擇 LWC! - 有數種可用的 Omnistudio 版本。如果您是長期客戶,您可能正在使用 **Angular**。我們鼓勵所有新客戶使用 LWC 型 Omniscript 和 FlexCard。我們也鼓勵現有客戶移轉至 Angular。 - LWC 以 LWC 為基礎。 ## 資源
動態表單 - 使用動態表單細分記錄詳細資料
- 取得 Lightning 應用程式產生器的說明
畫面流程 - 使用畫面流程與使用者互動
- 透過流程自動化工作
Omnistudio - Omnistudio
- Omniscript
- IDX 工作台桌面應用程式
- Newport 設計系統
- 使用 Newport Design System 自訂 Omniscript 和 FlexCard
LWC - Lightning Web 元件
- Lightning Aura 元件開發人員指南
- 適用於 Aura 開發人員的 Lightning Web 元件
# 決定工作人員與傳統工作流程自動化 透過 Agentforce,企業現在可以為無法輕鬆縮小為規則的自動化工作解鎖新的模式。這些新功能包括解決非結構化對話中的客戶意圖、協調跨系統的多方流程,以及即時回應營運條件。工作人員工作流程使用自動化,其設計目的為考量成果,而非執行預先定義的步驟。滿足此需求需要跨自動化複雜性的完整範圍作業的平台,以及顯示每個功能適合的架構。 Agentforce 將 Einstein Trust 圖層、推理引擎、工作人員指令檔、流程、Apex 和 Data 360 結合到一個統一的平台中。此組合可處理從簡單的記錄觸發自動化到複雜的語音、視覺、文件和即時遙測的多工作人員協調流程。MuleSoft 透過 MuleSoft 架構、管治和跨系統協調流程,擴充此平台,以連線跨企業的代理工作流程。Agentforce Operations (先前稱為 Agentforce Supply Chain) 將這些功能套用至營運和製造流程的特定需求。 ## 指南概觀 本指南介紹「協調流程密度」架構與原則,以便在整個產品環境中做出明智的決策。此架構為結構設計師提供可重複的方法,使用 Salesforce Platform 上智慧自動化使用個案的密度層級來選取正確的工具和模式。 ## 範疇中的產品 | 產品 | 描述 | | :-------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Agentforce | [Agentforce](https://help.salesforce.com/s/articleView?id=ai.generative_ai.htm&type=5) 是 Salesforce 建立及部署 AI 工作人員的平台。其使用 Atlas 引擎透過 Apex 和 Data 360 觸發即時動態奠基動作。 | | 工作人員指令檔 | [工作人員指令檔](https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html)是陳述性網域特定語言 (DSL),用於在 Agentforce Builder 中為工作人員定義工作流程、業務規則和對話邏輯 | | Agentforce 網格 | [Agentforce Grid](https://help.salesforce.com/s/articleView?id=ai.agentforce_grid.htm&type=5) 是 AI 原生、無程式碼的試算表類似介面,可快速大規模設計和操作 AI 工作流程。 | | Agentforce 作業 | [Agentforce Operations](https://help.salesforce.com/s/articleView?id=platform.automate_agentforce_supply_chain.htm&type=5) (先前稱為 Agentforce Supply Chain) 是 AI 技術支援的協同合作工作流程管理協調流程平台,專為簡化和自動化後端辦公室業務流程而設計。 | | MuleSoft | [MuleSoft](/docs/architect/zh-tw/fundamentals/guide/mulesoft-architecting-agentic-enterprise.html) 是一個全方位、統一且開放的企業整合與代理管理平台。透過 API 導向的連線和 MuleSoft Agent Fabric 和 Agent Broker,其可作為整合架構、管治層和跨系統協調流程基礎,以連接跨企業的代理工作流程 | | 流程與 Apex | [Salesforce 流程](https://help.salesforce.com/s/articleView?language=en_US&id=platform.automate_about.htm&type=5)是一種功能強大的點選自動化工具,可在視覺上建立複雜的業務流程,而不需使用程式碼。[Salesforce Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm) 是 Salesforce 平台的專屬物件導向程式語言,類似於 Java。用於建立自訂業務邏輯、自動化流程,並將核心 CRM 功能延伸至陳述性工具之外。 | ## 接待時間 Agentforce 代表從以規則為基礎的自動化到以推理為基礎的工作流程,在 Salesforce Platform 上工作完成方式的根本變更。為了發揮其潛力,結構設計師必須作出有意義且明智的決定,以瞭解工作人員的適合度、其組成方式,以及其協調的項目。下列原則為工作人員決策提供可重複的原則。 - **針對正確工作使用正確的工具。**根據執行路徑、強制回應組合和目標複雜度使用協調流程密度,以決定最合適的解決方案。 - 將「流程」和 Apex 搭配「**傳統自動化」**使用於以規則為基礎的決定性工作,其中結果可以完全由一組規則範圍來定義。傳統自動化會產生靜態執行路徑,這可保證可預測和可重複的成果,且對於稽核性而言至關重要。針對需要嚴格合規和符合法律的工作選擇傳統自動化。 - 針對低至中協調流程複雜性的大量推斷使用個案,使用 **Agentforce 網格**。此模式使用單次生成性推理來分類、評分或摘要大量 CRM 記錄中的資料,以確保執行高輸出和立即稽核性。 - 針對具有未結束目標的工作使用 **Agentforce with Agent Script**,其中已知所需成果,但無法在設計時指定確切的執行路徑。將此模式套用至需要透過引導決定性推理的需求,以確保可預測且可追蹤的成果。 - 使用「**Agentforce 作業」** 透過為供應鏈工作流程啟用 AI 的管理,簡化和自動化協同合作業務流程。 - **避免將工作人員工作流程套用至低協調密度使用個案**。針對功能與非功能需求,評估傳統自動化與代理自動化之間的權衡。傳統自動化可以為您的使用個案提供所需的規模、可靠性和效能。 - **採用工作人員自動化混合方法**,此方法將 Agentforce 和傳統自動化與「流程」和 Apex 結合在一起,當此協同合作提供的價值高於使用單獨使用代理或傳統自動化時。 ## 決策點 Salesforce sObject 傳統上是記錄自動化的主要進入點。系統會根據規則執行邏輯,從「資料操作語言」(DML) 事件 (例如 insert、update 或 delete) 之後立即開始。為了決定有效率的 [記錄觸發自動化](/docs/architect/zh-tw/decision-guides/guide/record-triggered.html)工具之間,我們引入了「[自動化密度」](/docs/architect/zh-tw/decision-guides/guide/record-triggered#automation-density.html),以測量系統的複雜度,並考慮自動化數量、記錄量和相依性擴展。傳統自動化受到將資料帶入結構化、結構描述相容且以規則為基礎的建構所需的廣泛預先工作限制。 工作人員自動化會使用使用者意圖或非結構化資料升級傳統自動化,作為輸入,可套用推理以達到所需成果。結構設計師必須決定何時為多重模式非結構化資料運用概率邏輯,以及何時強制執行引導式決定性工作流程,以降低無法預測成果的風險。 當需求從執行以規則為基礎的步驟轉移到推理結果時,結構設計師需要標準化架構來評估建議解決方案的推理深度和目標複雜性。 ### 協調流程密度 協調流程密度是工作人員工作流程內的複雜度度量。有三個因素決定協調流程密度:執行路徑、目標複雜性和強制回應組合。自動化密度會測量系統規則和體積的實體複雜度,而協調流程密度會測量工作人員前往目標路徑的推理複雜度。使用複合協調流程密度來評估您的設計需求,並對應至結構標準。 - **執行路徑**:可在設計時完全定義及指定工作流程範圍的程度。完全指定的工作流程表示工作流程會定義每個分支和結果,進而產生預先決定的執行路徑。非可指定的工作流程有一個路徑,可在執行階段期間透過根據內容資料和指示進行推理來出現。 - **目標複雜性**:工作流程在執行階段必須解決的不同成果、決策點和路徑變化數目。低複雜度工作流程會處理具有預先決定的成果的單一包含工作,而高複雜度目標會跨越多個階段,其中具有與設計時無法預期之邊緣個案的競爭或衝突目標。 - **強制回應組合**:工作流程必須處理的輸入類型範圍,以及其必須產生的輸出表單。低強制回應組合會讀取標準 CRM 欄位並產生記錄更新。中型強制回應會耗用結構化 CRM 欄位與靜態、非結構化資料 (例如電子郵件內文或個案文字記錄) 的混合,以產生記錄更新。高強制回應組合會耗用動態即時串流,例如即時音訊或遠程測量,並在多個外部系統之間產生多重模式輸出。 ![顯示執行路徑、目標複雜性和強制回應混合軸的「協調流程密度」架構圖](https://architect.salesforce.com/ns-assets/determining-agentic-automation-orchestration-density-framework.png) ### 因素序列 決定適當的協調流程密度層級需要依序評估執行路徑、目標複雜性和強制回應組合。請先檢查執行路徑。如果路徑完全可指定,請從傳統自動化開始。僅使用工作人員解決方案來協調並執行決定性路徑,而不需要任何推理是反模式。這會導致工作人員展開 (過度、未受管理的 AI 工作人員擴充) 和工作人員斜線 (品質不佳、不必要的 AI 產生的輸出),導致值傳回不佳。 針對部分或不可指定路徑,請繼續評估目標複雜性。如果目標複雜性已正確定義,但路徑的特定節點需要可能性評估,請考慮從流程或 Apex 呼叫工作人員以符合特定本地化需求。相反地,如果執行路徑中的步驟在大型記錄集中需要一或多個 AI 驅動的需求,請考慮 Agentforce 網格。網格透過多個 AI 或工作人員欄支援多步驟、以工作表為基礎的工作流程。最適合大量以列為導向的執行。此方法可確保工作流程保持高效能且可稽核,僅在無法預先定義路徑時叫用概率推理。 當目標的複雜性隨著競爭的維度 (例如判斷保險索賠支出以及詐騙偵測、保單合規性和客戶滿意度) 和無法指定執行路徑而增加時,請考慮使用 Agentforce with Agent Script 來取得自動化中的引導決定性。針對涉及 Salesforce 和第三方系統的跨企業使用個案,請使用 MuleSoft Fabric 和工作人員經紀人。 最後,評估強制回應組合以識別必要的技術功能,例如多重模式連線或專門整合。強制回應組合功能為功能選取器,而非密度計算器。這有助於決定處理解決方案輸入與輸出形式所需的基礎結構,而不變更其基本協調流程邏輯。 ### 密度選取矩陣 使用此矩陣可決定工作人員自動化的結構標準。透過選取解決自動化問題的方法來平衡傳統與代理自動化。 - **傳統自動化 (低協調流程密度):**當流程由記錄變更觸發、資料結構化、邏輯以規則為基礎且預先決定,且成果必須可預測 (例如標準價格計算或自動工作建立) 時,請使用傳統自動化。 - **Agentforce 網格 (低至中協調流程密度):**當必須處理現有記錄之間的大量 AI 工作時,請使用 Agentforce 網格 (例如,摘要此清單中每個帳戶的最後 50 個個案、計算情感分數,並將分數保留在個案欄位中)。 - **混合協調流程 (高階增強型自動化):**當自動化複雜端對端業務流程 (例如,索賠處理或上線) 時,請使用混合式協調流程,這需要 AI 的規劃能力,但需要 Flow 和 Apex 的交易完整性。 - **Agentforce Agent Script (高意圖複雜性):**當進入點非結構化 (例如聊天、電子郵件和語音),且解決方案需要交談或能夠處理不明確的使用者要求時,請使用工作人員指令檔。 | 密度層級 | 執行路徑 | 目標複雜性 | 強制回應組合 | 結構標準 | | :---------------- | :----------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **低** | 完全指定 | **低:**具有預先定義成果的單一包含工作。 | **單一強制回應:**讀取與寫入結構化 Salesforce 物件記錄。 | 記錄觸發自動化。如果使用個案有至少一個推理工作,請在工作流程中使用「工作人員動作」。 | | **低 - 中** | 完全或部分指定 | **低:**包含預先定義成果的一系列步驟。 | **混合強制回應:**輸入或輸出可以混合結構化與非結構化資料。 | 透過工作人員動作,針對跨現有記錄的大量工作使用 Agentforce 網格批次推斷。 | | **中型** | 可完全或部分指定。執行路徑是預先定義的,但中間步驟需要推理。 | **中等:**含變數成果的一系列以 Apex 或流程為基礎的步驟。 | **混合強制回應:**輸入或輸出可以混合少量結構化與非結構化資料。 | 混合式 (Agentforce + Apex/Flow):使用 Agentforce 進行高密度的推理和規劃、使用工作人員指令檔進行引導式決定,以及使用 Apex/Flow 進行協調流程。 | | **高** | 部分或不可指定。目標是預先定義的,但中介步驟需要執行階段內容和使用者意圖。 | **高:**具有嚴重推理需求的多個競爭目標需要決定性成果。 | **混合強制回應:**輸入或輸出可以混合大量即時傳送的結構化與非結構化資料。 | 使用工作人員指令檔以平衡決定性控制與推理。針對複雜的多重工作人員協同合作,針對第三方 MCP 或 A2A 使用 MuleSoft Agent Fabric。 | ## 產品比較 | 能力 | 傳統自動化 (流程/Apex) | Agentforce 網格 | Agentforce | Agentforce 與工作人員指令檔 | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **邏輯類型與決定性** | **決定性:**使用固定 if-then-else 邏輯。根據記錄狀態,執行路徑為 100% 可預測。 | **混合:**透過結構化步驟決定性,而個別 AI 步驟可以是可能性性。 | **可能性:**使用多回合推理來決定達成目標的最佳路徑。 | **引導式決定性:**使用邏輯規劃路徑,並允許對決定性節點路徑執行。 | | **遞送速度** | **建議 (流程):**視覺工具可在無程式碼的情況下快速建立記錄觸發邏輯。 | **建議重複 AI 自動化:**在不建立新流程的情況下,將 AI 邏輯套用至現有記錄集的最快方式。 | **建議:**用於針對特定網域或問題設定「子工作人員」(先前稱為主題)、指示和技能對應。 | **建議:**適用於以州為基礎之圖表和邊緣邏輯的進階對應。 | | **輸入模式** | **建議僅限結構化:**限制為 CRM 欄位和相關記錄集合。 | **建議使用半結構化:**從記錄欄位處理大量文字 (描述、文字記錄)。 | **多強制回應的建議:**處理自然語言、語音和視覺 (非結構化資料)。 | **建議使用高密度:**使用即時系統狀態資料來同步化多重模式輸入。 | | **推理深度 (規劃)** | **不可用:**邏輯是必要的,不能動態地「思考」或規劃步驟。但是,資料可以傳送給工作人員。 | **低:**套用於記錄集的單一步驟推斷 (批次 AI)。 | **中/高:**使用推斷迴圈 (Reason-Act-Observe) 來解決複雜的意圖。 | **受管理:**原因僅限於瀏覽預先定義的業務狀態圖表。 | | **模組化與可重複使用性** | **建議:**預設為透過子流程和 Apex 類別模組化。 | **限制:**邏輯通常與特定網格列繫結。資料欄設定與範本工作流程可在整個資料列集中重複使用。 | **可用:**技能 (流程/Apex) 可在不同的子工作人員 (先前稱為「主題」) 和連線的工作人員之間重複使用。 | **建議:**「工作人員圖表」中的節點是離散且可重複使用的功能單位。 | | **交易與 DML 控制** | **建議 (Apex):**完全控制 Savepoints、結轉和大量處理。 | **可用:**系統會獨立處理每一列,因此執行範圍為每個記錄。 | **限制:**動作會在工作階段中以個別的分離步驟執行。 | **建議:**使用流程/Apex 節點作為所有 DML 的決定點。跨工作人員的分散式交易控制支援受到限制。 | | **不明確處理** | **不可用:**需要預先定義的路徑。非預期輸入會導致失敗或靜態錯誤。 | **限制:**輸出品質取決於提示基礎。工作流程無法以互動方式要求說明。 | **建議:**詢問問題或選取替代技能來處理「未知」狀態。 | **可用:**使用「回復節點」管理推斷失敗或流程逾時。 | | **可視性與管治** | **建議:**流程觸發探索器提供所有記錄觸發邏輯的視覺化地圖。 | **可用:**網格型 UI 可讓您清楚瞭解列層級結果,並支援輸出的稽核性。 | **可用:**「監視記錄」可提供工作人員決策方式的透明度。 | **需要專長:**需要監視「圖表」周遊和 LLM 推斷記錄。 | | **效能與規模** | **建議** 針對大量同步記錄處理最佳化。 | **建議**可有效率地處理大型資料量之間的大量 AI 工作。 | 與推斷時間相依;不適用於高密度大量更新。**** | **中度**適用於複雜的長範圍工作,但額外負擔較高。 | ## 使用個案 此表格提供適用於各種使用個案的一般最佳建議。 | 使用個案 | 描述 | 最適合 | 理由 | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **記錄處理** | 由結構化 Salesforce 物件上的 DML 事件觸發的自動化,其中的每個分支和成果都可以在設計時完全定義。 | 使用記錄觸發流程。這是低密度的傳統自動化。 | 低協調流程密度。單一強制回應 (結構化 CRM 欄位) 和單一包含目標,並具有可預測且可稽核的執行路徑。 | | **具有複雜邏輯的交易控制** | 需要儲存點、回復、部分認可或跨高記錄量大量安全資料操作的自動化。 | 使用 Apex 進行傳統低密度決定性自動化。 | 低協調流程密度。Apex 提供交易完整性的完整控制權、超重耗費的運算和平台層級快取 - 流程中無法使用的功能。 | | **結構化程序內的中度複雜邏輯** | 自動化,其中整體流程以規則為基礎,但個別步驟需要超出陳述性功能的計算或資料操作。 | 將流程與可叫用 Apex 搭配使用,以取得低密度決定性邏輯。 | 低協調流程密度。流程會作為協調流程層;可叫用 Apex 會將高複雜度的作業壓縮為可重複使用且安全的元件。 | | **排程和暫時處理** | 與記錄事件相關的動態計算未來日期必須執行的自動化。 | 針對低密度決定性處理,使用傳統自動化 (記錄觸發流程)。 | 低協調流程密度。如果記錄資料變更,[流程排程路徑](https://help.salesforce.com/s/articleView?id=platform.flow_concepts_trigger_scheduled_path.htm&type=5)會提供自動排程、取消和重新排程 - 原生無法在 Apex 觸發中使用。 | | **大量記錄推斷** | 將單一 AI 推理步驟統一套用至一組大型現有記錄,以產生分類、摘要或分數。 | 使用 Agentforce 網格進行批次推斷,並大規模使用重複的工作人員功能。 | 中等協調流程密度。使用單一強制回應大規模的批次推斷:工作人員會讀取結構化記錄欄位,並將統一輸出寫回每個記錄。具有單一重複推斷模式的低目標複雜度。 | | **非結構化輸入解析度** | 自動化,其中進入點是必須透過推理解譯、分類和解決的自然語言要求、電子郵件或對話。 | 使用 Agentforce 進行中密度、以意圖為導向、非結構化輸入解析。 | 中等協調流程密度。混合強制回應:工作人員會耗用非結構化對話輸入,然後產生文字回應或結構化記錄更新。目標需要解決跨界限成果集的使用者意圖。 | | **可能性流程內的中度複雜邏輯** | 自動化,其中整體流程以規則為基礎,但個別步驟需要 AI 功能,例如摘要或 RAG 提取。 | 針對需要 AI 功能的低密度決定性流程,使用包含可叫用 Apex 和提示範本的流程。 | 中等協調流程密度。流程會作為協調流程層,而「[提示範本」](https://developer.salesforce.com/blogs/2024/04/invoke-prompt-templates-from-flow-apex-or-the-rest-api)、[Agentforce 服務代理程式和 Agentforce 員工代理程式](https://help.salesforce.com/s/articleView?id=ai.agent_custom_invocable_action_flow_apex.htm&type=5)會顯示為「可叫用」動作。 | | **引導式流程協調流程** | 跨多步驟工作流程的自動化,其中一個動作的完成會觸發其他動作 | 針對需要引導式流程協調流程的高密度非指定執行路徑,使用「[工作人員指令檔與動作](https://developer.salesforce.com/sample-apps/agent-script-recipes/action-configuration/action-chaining)」。 | 高協調流程密度 - 輸入與輸出之間的混合模式。無法在設計時完全預期的競爭成果和邊緣個案。「工作人員指令檔」提供引導式決定性。 | | **跨系統流程協調流程** | 在多個後端系統之間協調多步驟業務流程的自動化,其中沒有單一系統擁有端對端流程 | 將 MuleSoft 流程 API 與工作人員經紀人搭配使用,以進行中至高密度的跨系統流程協調流程。 | 高協調流程密度 - 流程 API 會壓縮複雜的多步驟業務邏輯,因此工作人員不需要瞭解訂單處理或庫存檢查等作業背後的協調流程。[工作人員經紀人](https://www.mulesoft.com/ai/agent-broker)會動態地從單一自然語言目標中排列並叫用必要的工作人員和工具。 | | **後端系統抽象** | 工作人員必須與舊版系統、資料庫或缺乏原生 Agentforce 連線的第三方 SaaS 平台互動的協調流程。 | 將 MuleSoft 與 MCP 連接器搭配使用,以包覆舊版系統並提供模型內容。 | 中等協調流程密度。系統 API 為記錄系統提供安全的抽象介面,確保工作人員工作流程與後端複雜性分離。MCP 連接器會將 MuleSoft 應用程式轉換為 MCP 相容的伺服器,以供立即探索和叫用。 | | **大量文件處理與例外處理** | 將輸入結構化和半結構化文件與現有記錄進行大規模讀取、解譯和協調的自動化 - 透過適當的手動介入處理差異、部分相符項目和例外狀況。 | 使用 Agentforce 作業來處理中密度、以意圖為導向的大量文件。 | 具有半結構化輸入強制回應的中型協調流程密度。由每份文件比對規則、例外狀況路徑和批准值所驅動的目標複雜度。需要每個記錄的推理,而非統一單向推斷。 | | **跨廠商的多工作人員協調流程** | 自動化需要在不同平台或廠商上建立的專門工作人員之間協同合作。 | 將 MuleSoft 與「A2A 連接器」和「工作人員紡織」搭配使用,以跨不同系統進行多工作人員協調流程。 | 中至高協調流程密度。無論每個工作人員的建立或託管位置為何,A2A 連接器都能讓企業層級的管理與可靠性實現點對點多工作人員工作流程。 | | **非結構化文件轉換為工作流程** | 自動化,在非結構化來源 (SOP、供應商規則文件或流程圖) 中定義的作業流程必須轉換為可執行的工作流程,而無須手動編碼。 | 使用 Agentforce 作業來轉換高密度、新增非結構化文件至工作流程。 | 輸入高強度混合的高密度。取用 PDF、Word 文件和以影像為基礎的圖表。所選流程的範圍和分支所決定的目標複雜度。無法在設計時指定執行路徑。 | | **多方協調流程** | 跨越外部協調上線的自動化 - 收集必要資料、驗證合規性、管理批准,以及更新許多同時上線追蹤的記錄系統。 | 針對中至高密度、意圖驅動的新增多方協調流程,使用 Agentforce 作業。 | 多個相互相依的驗證與批准步驟必須先依序解決,上線才能完成。強制回應組合包含結構化記錄、非結構化文件和外部對象通訊。 | | **預測資產介入** | 自動化,其中預測引擎會採取即時距離測量以識別即將發生失敗的條件,並觸發協調的多步驟後端辦公室回應。 | 使用 Agentforce Operations 和 Agentforce for Manufacturing 進行高密度預測資產介入。 | Data Cloud 處理高模式 IoT 距離測試和異常偵測。Agentforce Operations 接著會協調中型模式後端辦公室工作流程—管理現場服務記錄、庫存資料和客戶通訊—解決流程端對端。 | | **大規模供應商通訊管理** | 自動化管理跨大型供應商基礎的持續結構化和半結構化通訊,包括訂單確認、遞送日期變更和例外通知。 | 將 Agentforce 作業用於批次推斷用於中密度供應商通訊管理。 | 若通訊在供應商之間是統一的,請使用 Agentforce 網格進行批次處理。若回應需要各供應商關係的內容考量,請使用 Agentforce 作業升級至中度密度。 | | **商機管理 (高速智慧路由)** | 此自動化功能會採取即時行銷回應、使用 AI 評分和 Data Cloud 增強來進行資格,並使用流程來以智慧方式將高品質的商機指派給適當的銷售小組。 | 使用傳統自動化 (流程) + Data Cloud 和 AI 進行中密度高速智慧商機路由。 | 根據 AI 商機評分、工作層級和活動歷程記錄,需要高速 (商機速度 < 1 分鐘) 和複雜且資料驅動的路由。使用「流程」進行快速決定性指派邏輯,並透過可能性 AI 與 Data Cloud 進行擴充以進行商機資格和增強。 | | **商機培養** | 培養低評分商機,直到這些商機準備好進行銷售對話為止。 | 針對中至高密度的自動化,使用「商機培養工作人員」鎖定和改善低品質的商機。 | 傳送以商機資料和客戶成功案例為基礎的個人化多點式電子郵件。它會處理電子郵件回應,並使用「流程」進行轉寄。 | | **輸入商機資格** | 自行資格並培養評分較高的輸入商機。 | 使用「商機培養工作人員」來合格和參與商機。 | 執行多重接觸電子郵件輸出、會議預訂、產品問與答和反對處理。其可在「以銷售人員身分傳送」模式中作業,透過指派的商機擁有者傳送電子郵件。 | ## 使用個案對應 ![使用顯示跨協調密度層級各種自動化案例的個案對應圖](https://architect.salesforce.com/ns-assets/determining-agentic-automation-use-case-mapping.png) ## 非功能考量事項 **延遲** 同步記錄觸發流程會在平台交易中執行,並在毫秒內完成。Agentforce 推斷時間取決於「Atlas 原因引擎」,並依據推斷深度和強制回應複雜度進行調整。Agentforce 不適用於大量同步記錄處理,其中延遲是主要限制。 **成本** 工作人員工作流程的推理成本必須根據成果的業務價值進行推理。針對存在決定性路徑的大量、低協調密度工作,傳統自動化或 Agentforce Grid 可能比端對端代理程式工作流更為經濟。確保設計包含正確的重試模式,並包含明確的重試上限與中斷器。此護欄會限制與大量處理相關聯的複雜成本超額風險。 **管理員限制** 根據非同步執行的每日平台限制來評估大量工作人員工作流程。Agentforce 網格批次作業遵循標準平台交易限制。針對涉及 Salesforce 物件的自動化,請考慮 DML 作業的每日總數,因為 Salesforce 會在多租戶環境中強制執行共用資源管理,並強制執行 [管理員限制](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm?_ga=2.244979463.387753096.1774889755-1655953164.1772207150),以防止流失自動化獨占共用資源。 **稽核與合規性** 傳統自動化透過流程觸發探索器和 Apex 記錄產生可完全稽核的執行追蹤。以 Agentforce 為基礎的端對端或混合式模式會產生推理記錄,以提供工作人員決策的透明度,但其需要專業知識才能解譯。透過「工作人員指令檔」的引導式決定性是受監管產業的建議模式,其中完整執行稽核性是合規性需求。 **升級** 在高密度運作的工作流程應納入明確的人類批准或升級門,以處理具有無法復原後果的動作,例如財務交易、監管提交或供應商承諾。「工作人員指令檔」條件控制項提供在其他工作人員工作流程中決定性強制執行這些門的機制。 ## 相關最佳作法 在協調流程設計中**排定簡化優先順序**。從可達成目標的最小協調流程層級開始、在實際載入中進行驗證,然後重複進行。鏈接中每個額外的工作人員、轉移或相依性都會呈現新的外觀,這可能會產生不一致的行為。 在您可指定的執行路徑中,在需要推理的節點上,開始內嵌工作人員。遵循在 Agentforce 中建立工作人員的最佳作法。請避免包裝大量的子工作人員 (先前稱為「主題」),且切勿膨脹指示。在自動化使用個案中部署的工作人員可以放心使用,因為這些工作人員並非唯一的介面。選擇適合連鎖的原始詞。協調流程 (委派) 模式具有更嚴格的執行順序控制權,並可將子工作委派給專家。避免使用 koreographed (handoff) 模式。如果您必須實作運送設計,請為接收的工作人員提供目標、內容和狀態,讓其能夠在全域最佳化,而非在本機最佳化目標。 **避免動作或工具展開**。動作是實現工作人員邏輯的地方,其設計會決定其是否產生可靠成果或失敗。每個動作都必須傳回結構化且可觀察的回應,以便 AI 工作人員用來計畫下一輪交談。 擁有多個動作 (以及不同的輸出建構) 來執行相同工作會降低工作人員為工作解釋或選擇正確工具的能力。這可能會造成工作人員遺漏細微差別。重疊動作定義會造成分類錯誤的風險。確定您的動作文件庫已稽核、編譯版本並符合「子工作人員」(先前稱為「主題」) 範圍。 **定義可觀察的目標。**將目標定義為可觀察的成果,而不只是程序。模糊的目標會邀請工作人員漂移。使用可指定的執行路徑增強。使用具有混合式推理的「工作人員圖表」將目標建模為具有明確狀態的圖表節點。執行階段會在工作流程中追蹤工作人員目前的位置,並在 tangential 輸入後將其還原;當工作人員在內容視窗中收到其他資訊時,它不會失去目標。 **測試和評估**。實作強大的測試和評估架構,以驗證可能性節點的推理和工作人員自動化的輸出。根據預期的結果路徑驗證執行路徑,以確保模型到達正確的結果。透過判斷執行步驟中的結果,避免工作人員不實報告成功或進入無限或不可復原迴圈時發生無訊息失敗。使用 [工作階段追蹤](https://help.salesforce.com/s/articleView?id=ai.generative_ai_session_trace_about.htm&type=5)來檢查逐一互動、推斷引擎執行、動作、提示和門戶輸入/輸出、錯誤訊息和最終回應。 ## 資源
Agentforce 傳統自動化 整合
**關於作者** Arvind Palaniswamy 是首席結構設計師小組辦公室的軟體工程結構設計師。他喜歡使用第一個原則,以最簡單的形式為複雜系統建立框架。他透過數十年經驗和 MS/MBA(Kellogg) 教育,瞭解工程、營運和業務。 # 與 Salesforce 的資料整合 在 Salesforce 與外部系統之間存取、同步化及共用資料的方式有多種。但並非每個工具都適合您的特定專案。本指南逐步引導您瞭解 Salesforce 提供的資料整合工具。此外也會針對最適合特定使用個案的工具 (或工具組合) 提供建議,以及針對特定情況避免使用之工具的指引。 ## 指南概觀 此決策指南著重於涉及 Salesforce 的資料層級整合。具體而言,它涵蓋下列資料整合使用個案: - Salesforce 至外部系統 - 外部系統對 Salesforce - Salesforce 組織對 Salesforce 組織 這些僅是 Salesforce 結構設計師面對的整合挑戰子集,因此我們計畫新增更多決策指南,專注於事件驅動的整合、使用流程整合建立有效的客戶或員工面向工作流程等。最後,請務必注意,此處描述的許多工具和方法可用來解決整合在整個企業中的挑戰,但此類用途超出本指南的範圍。 ## 接待時間 - **避免不必要的資料複寫。**除非資料絕對需要位於 Salesforce 中,否則請考慮改為使用 Salesforce Connect 虛擬化資料。組織中的資料越多,最終會導致資料量越大,這會對[績效](/docs/architect/zh-tw/well-architected/guide/reliability.html#scalability-and-capacity-planning)造成負面影響,並增加技術負債。如果您的資料已位於 Salesforce 中且您在外部系統中需要資料,請避免將資料複製到外部系統,除非有絕對必要。請改為讓外部系統透過 Salesforce API 存取資料。 - **如果可用,請使用 MuleSoft 或其他 Enterprise Service Bus (ESB) 或 Extract-Transform-Load (ETL) 解決方案,且為您現有的區域範圍的一部分。**由於這些工具是為了協助支援資料移轉和轉換而建立,因此通常具有強大的功能,可讓您在整個企業中重複使用整合、維持更強大的管治,並集中管理整合。在此指南中,無論建議使用 MuleSoft Anypoint 的任何位置,請考量您現有的 ESB/ETL 解決方案是否足夠。 - **使用 Data 360 和 Data Cloud One 協調不同來源的資料。**透過 Customer 360 資料模型、身分解析、資料聯邦和其他功能,Data 360 會將 Salesforce 和其他外部系統的資料合併至您客戶的統一檢視。此外,透過 [Data Cloud One](/docs/architect/zh-tw/fundamentals/guide/data360_integration_patterns_and_practices.html#unified-multi-org-data-platform-with-data-cloud-one),其他 Salesforce 組織中的使用者可以透過資料空間安全地存取從 Data 360 虛擬共用的資料。 - 使用 **Data 360 動作和啟用在組織之間移動資料。**將不同組織的資料從 Data 360 移入後,資料 [動作和啟用](/docs/architect/zh-tw/fundamentals/guide/data360_integration_patterns_and_practices.html#data-activation-patterns--data-outbound)可以將資料同步至其他組織。此方法對於與 Marketing Cloud 組織的整合而言非常有用。 - 使用 **MuleSoft Anypoint.**MuleSoft Anypoint 可用來使用 Connect API 和 Data Graph API 從 Data 360 提取資料,並將其移至另一個 Salesforce 組織。若沒有 Data 360,則當需要在組織之間移動資料而不需要在 Data 360 中複製時,也可使用 MuleSoft Anypoint。 - **如果您選擇使用「輸出傳訊」建立,請特別小心。**Salesforce 會在目前的功能容量內繼續支援「輸出傳訊」,但不會計畫進一步投資此技術。 - **針對所有整合一律建議使用「僅 API」設定檔整合使用者授權。**Salesforce 也建議使用「外部用戶端應用程式」(偏好連線應用程式或 SOAP 登入) 作為所有整合適當允許的 AuthN 和 AuthZ 模式。 ## 選擇資料整合工具的常見考量事項 在深入瞭解可用的資料整合工具之前,選擇工具時,請務必記住幾個常見考量事項。如同結構一般,對於每個業務挑戰沒有指示性回答。如果您在進行整合選擇時說出「這取決於」,則表示您處於正確的位置。
考量區域 常見問題
現有工具與橫向 是否有現有的 ESB 或 ETL 解決方案?相關資料是否具有法規或規範需求?您嘗試整合的系統位於何處 (雲端或內部部署中)?
資料流程 (時間點、預期的使用者體驗、方向性) 資料是否需要同步、非同步移動,還是可批次/排程?資料複寫是否必要?哪個系統應該是事實來源?什麼是資料來源?什麼是目標目的地?使用者互動是否必要?使用者是否需要查看整合的結果?例外狀況處理 (重試、通知、失敗) 的需求為何?系統應如何緊密連接?
實作 非 Salesforce 系統的工作層級為何?哪些小組負責提供整合?他們偏好使用哪些工具?
永續性 哪些小組預期會維護整合?他們目前擁有哪些技能?他們未來需要哪些技能?一段時間內的總擁有成本為何?使用低度或專業程式碼工具測試、除錯、疑難排解的能力有多重要?
資料量 整合中涉及多少資料?您是否要使用 大型資料量 (LDV)?大量變更的發生頻率為何?singleton 更新的影響為何?它們會發生多少次?
限制 資料是否需要進行複雜轉換?資料是否必須從多個來源系統合併?每位使用者整合的發生頻率為何?使用者總數為何?您是否已預先計畫大量資料載入 (範例:新例項的初始資料載入)?
## 產品比較 以下是資料整合可用工具的概觀,以及開始評估每個選項的一些考量事項。下列區段包含深入的使用個案,以及這些工具功能的相關詳細資料。
從 Salesforce 至外部系統 從外部系統到 Salesforce 執行 需要其他授權
Apex 動作 可用 可用 伺服器端 否
變更資料取取 可用 不提供 伺服器端 否*
自訂 Apex (REST 和 SOAP Web 服務) 可用 可用 伺服器端 否
外部服務 可用 不提供 伺服器端 否
Heroku Connect 可用 可用 伺服器端 是
Data 360 可用 可用 伺服器端 是
MuleSoft Anypoint 可用 可用 伺服器端 是
原生 Salesforce API 不提供 可用 伺服器端 否
Omniscript 可用 可用 用戶端*** 是
OmniStudio 整合程序 可用 可用 伺服器端 是
輸出傳訊 不是理想 不提供 伺服器端 否
平台事件 可用 可用 伺服器端 否**
Salesforce Connect/外部物件 可用 可用 伺服器端 是
[\* 大量變更資料摘取事件使用個案需要附加元件](https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm) [\*\*大量平台事件使用個案需要附加元件](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) \*\*\*適用於可在網頁瀏覽器中執行業務邏輯的情況。 資料欄圖例: - **可用**:適用於大多數使用個案 - **非理想**:可能,但請考慮替代工具 - **不可用**:未來 12 個月內沒有支援的計畫 ### 將資料移入和移出 Salesforce 的其他工具 其他工具可能支援資料層整合的某些層面,但不能視為解決整合問題的主要方法。現在讓我們快速查看這些工具。 **Lightning Web 元件**通常用於程序整合,但可以使用 JavaScript 功能進行呼叫,因此資料可能會涉及這些交易。 **Salesforce 流程**可用來使用「外部服務」或「Apex 動作」協調外部呼叫。Salesforce 流程本身並不視為獨立的資料整合工具。 **資料匯入精靈和 Data Loader** 可用來同步化、匯入和移轉資料。雖然 Data Loader 指令也可進行指令檔,以自動匯入和匯出資料,但 [指令行介面](https://developer.salesforce.com/docs/atlas.en-us.dataLoader.meta/dataLoader/command_line_intro.htm)僅適用於 Windows,且這些工具都不為資料整合策略的建議基礎。請改用來補充您的資料管理與維護策略。 [**Salesforce CLI**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm) 資料指令可用來操作您組織中的記錄。指令可協助您使用「大量 API」和「SObject 樹狀結構儲存 API」匯入和匯出資料,並透過 REST API 在個別記錄上執行簡單的 CRUD 作業。Salesforce CLI 本身並不視為獨立的資料整合工具。 **OmniStudio 資料對應工具**可作為陳述性 ETL 工具,在 Salesforce 物件與 JSON 資料結構之間移動資料。雖然會自動為每個「資料對應器」介面建立 REST 介面,提供從外部系統將資料移動至 Salesforce 物件的陳述性方式,但「資料對應器」獨立並非資料整合策略的建議基礎。「資料對應器」動作適用於 OmniStudio 整合程序。 [**Dataloader.io**](http://dataloader.io/) 是 Salesforce 的另一個資料載入工具,由 MuleSoft 的 Anypoint Platform 提供技術支援,可讓您快速安全地匯入、匯出和刪除企業的無限數量資料。Dataloader.io 並非資料整合策略的建議基礎。 ## Salesforce 對外部系統 (輸出整合) 針對 Salesforce 的輸出整合,您可以考量不同類型的工具:低程式碼、Pro-code 或混合式。下列區段提供每個工具類型的指引,並提供範例解決方案。 - [輸出整合的低程式碼工具](#salesforce-中輸出整合的低程式碼工具) - [輸出整合的混合式工具](#適用於-salesforce-輸出整合的混合式工具) - [輸出整合的 Pro-Code 工具](#salesforce-中輸出整合的-pro-code-工具) ### Salesforce 中輸出整合的低程式碼工具
指引 授權 時間 體積與規模 交付與維護 隱私權與安全性
使用時機 額外授權 同步 (要求/回覆) 或非同步 (觸發/忘記) 多物件支援 LDV/大量 測試與部署** 除錯 內建錯誤處理/重試行為 可與靜態加密的資料搭配使用 驗證通訊協定
變更資料取取 當您需要將在 Salesforce 中進行的記錄層級變更發佈至外部系統,且不需要自訂裝載時。 必要 非同步 否 否 是 使用 Pro-Code 工具 是 是 OAuth
外部服務 當您使用流程協調流程時,會使用 OpenAPI 規格描述 Apex、Einstein 機器人或 OmniStudio 和外部系統 API。 不需要 同步化 是 否 是 使用 Pro-Code 工具 否 無 已命名認證
Heroku Connect 當您想要透過雙向同步擴充資料,以在 Heroku 上啟用行動應用程式和其他應用程式,且您想要將資料也複製到 Salesforce 時。 必要 非同步 是 是 否 使用 Pro Code 工具 是 是,透過 Shield Connect OAuth
OmniStudio 整合程序 當您需要在沒有使用者互動的情況下轉換資料,並透過在伺服器處理而非瀏覽器改善效能時。 必要 兩者 是 是 是 宣告式支援 是 是 已命名認證
Salesforce Connect/外部物件 當您想要資料顯示在 Salesforce UI 中,但想要資料儲存在外部系統中時。資料不會複製到 Salesforce。 必要 同步化 否 是* 是 具有 Pro-Code 工具和陳述性追蹤器 否 無 已命名認證
*超過 4.01 版的 Odata 轉接器受限於呼叫限制。如需詳細資料,請參閱 OData 呼叫率限制考量事項。** 測試與部署是指在較低環境中建立並透過 中繼資料 API、封裝或變更集部署至生產的能力。
### 使用個案:使用低程式碼工具的輸出整合 > 當機會成交時,必須在公司的 ERP 系統或訂單管理系統中建立相關產品的訂單。 當「機會」記錄更新時,「變更資料集合」會發佈包含物件更新的變更事件。****變更事件會透過 CometD 連線 (或透過 MuleSoft 連接器) 客戶端耗用,並用於更新客戶的 ERP 或訂單管理系統。變更事件可以加強,以一律包含外部記錄識別碼或物件 (例如區域) 中整合所需的其他資料。可將多個物件的變更事件串流合併為簡化訂閱和串流處理的 _管道_ (因此您可以訂閱和處理一個串流,而非多個串流)。 **外部服務** 如果您的 Web 服務支援 OpenAPI 2.0 或 3.0 規格,您可以在 Salesforce 中將作業和服務公開為外部服務。當機會的階段變更為「成交」時,在使用 Flow Builder 建立的流程中,API 作業 (例如建立順序) 可以稱為可叫用動作。 **Heroku Connect** Heroku Connect 通常用於將 Heroku Postgres 資料庫與 Salesforce 保持同步。如果客戶使用 Heroku Postgres 作為其事實來源交易存放區,則您可以使用 Heroku Connect 將記錄和從 Salesforce 變更同步至 Heroku Postgres。從此處,您可以使用 Heroku 串流連接器將這些變更發佈至 Apache Kafka,並將其作為事件傳送至下游應用程式,包括 ERP 或訂單管理系統。 **OmniStudio 整合程序** 提交訂單時,協調流程的 Omniscript 可以將訂單詳細資料張貼到 ERP 或 MuleSoft 連接器。貼文可以直接由 Omniscript (用戶端) 或間接透過整合程序 (伺服器端) 執行。如果 ERP 系統引發驗證錯誤,Omniscript UI 必須通知使用者,並視需要為使用者翻譯並內容化錯誤。 **Salesforce Connect/外部物件** 您可以在 Salesforce 中建立記錄觸發流程,當機會的階段變更為「成交」時,將記錄插入相關外部物件。由於這是[混合交易](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1),因此為了避免錯誤,請在「機會」更新與相關外部物件插入之間新增零秒的暫停元素,以便您在開始新的交易內容之前關閉一個交易內容。 ### 適用於 Salesforce 輸出整合的混合式工具
指引 授權 時間 體積與規模 交付與維護 隱私權與安全性
使用時機 額外授權 同步 (要求/回覆) 或非同步 (觸發/忘記) 多物件支援 LDV/大量 測試與部署** 除錯 內建錯誤處理/重試行為 可與靜態加密的資料搭配使用 驗證通訊協定
Apex 動作 當您想要透過 Salesforce 流程將呼叫自動化至其他系統時。開發人員可以撰寫流程可叫用的 Apex 類別,或者您可以從 AppExchange 下載預先建立的解決方案。 不需要 兩者 是 否 是 使用 Pro-Code 工具 否 是 多
事件轉送 當您需要從 Salesforce 將平台事件和變更資料擷取事件傳送至 Amazon EventBridge 時。事件轉送僅連線至 AWS Eventbridge 否 非同步 是 否 是 是 是 是 具有 TLS 的 HTTP/1.1
輸出傳訊 當您需要透過 HTTP(S) 將 SOAP 訊息傳送至指定的端點,並在由工作流程規則觸發時保證收到。 不需要 非同步 否 否 是 宣告式支援 是 是 雙向 TLS
平台事件 當您需要自定義的結構化裝載,以在 Salesforce 或外部系統中進行近乎即時的變更時。 不需要* 非同步 是 否 是 使用 Pro-Code 工具 是 是 OAuth
Salesforce Connect/外部物件 (含自訂 Apex 轉接器) 當您想要資料顯示在 Salesforce UI 中,但想要資料儲存在無法使用如 Odata 或 GraphQL 等標準通訊協定的外部系統中時。 必要 兩者 是 是 是 使用 Pro-Code 工具 否 無 多
Data 360 當您想要在一個資料存放區中協調不同來源的資料,或想要將資料複製到其他 Salesforce 組織或其他外部系統時。 必要 兩者 是 是 是 是 是 是 多
需要大量使用個案的 [\* 附加元件](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)。 \*\*測試與部署是指在較低環境中建立並透過 [中繼資料 API](https://developer.salesforce.com/docs/metadata-coverage/)、封裝或變更集部署至生產的能力。 ### 使用個案:使用混合式工具的輸出整合 > 當機會成交時,必須在公司的 ERP 或訂單管理系統中建立相關產品的訂單。 **Apex 動作** 根據機會狀態的記錄觸發流程可以在機會成交時自動觸發。流程會執行可叫用動作,使用外部呼叫將訂單提交至訂單管理系統或 ERP 解決方案。大量提交與多網站訂單是由 Apex 批次與排入排入機制處理。 **輸出傳訊** [設定輸出傳訊後](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_setting_up.htm),您可以定義由機會更新觸發的工作流程規則,以透過 HTTP(S) 將 SOAP 訊息傳送至主控接聽者的指定端點 URL。訊息將包含在建立輸出訊息時指定的欄位。若物件中的資訊在通知排入排隊後變更,但在通知傳送之前變更,則只會傳送更新的資訊,且訊息會保持在排隊中,直到通知成功傳送,或直到訊息已超過 24 小時為止。在 24 小時後,訊息便會遭到排除。如果 ERP 系統需要其他資料,您可以在輸出訊息中傳遞 sessionId,以便外部系統提出回呼要求。 **平台事件** 您可以定義平台事件,其中包含在外部系統中建立記錄所需的自訂裝載資料。由於「平台事件」不會在記錄變更時自動發佈,因此當機會的階段變更為「成交」時,您必須透過 Apex、Salesforce 流程或流程產生器發佈事件。外部服務會使用 CometD (或 MuleSoft 連接器) 聆聽平台事件管道,並在外部系統中建立適當的記錄。 **Salesforce Connect/外部物件 (含自訂 Apex 轉接器)** 以 Salesforce Connect/外部物件為基礎的解決方案不適合僅需要資料同步的使用個案。不過,此解決方案適用於 Salesforce 中的使用者需要查看,並可能與外部系統中的資料互動的個案,且資料無法在 Salesforce 中複製。如果 ERP 或訂單管理系統不支援 Odata 或 GraphQL 通訊協定,則開發小組可以使用 [Apex 連接器架構](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_connector_start.htm)來撰寫處理透過支援通訊協定與外部系統通訊的 Apex 類別。 **Data 360** 以 Data 360 為基礎的解決方案非常適合我們在單一資料存放區中需要來自不同來源之協調資料的使用個案。當我們需要使用 Data 360 作為資料中心,將資料從一個 Salesforce 組織複製到多個 Salesforce 組織,或複製到其他外部系統時,也會使用此功能。當機會在來源組織中成交並更新時,機會資料會同步化至 Data 360,並可在其中使用動作、啟用和 API 等不同機制在其他系統中複製,包括 Salesforce 組織。同樣地,您可以參照機會,而無須使用 Data Cloud One 在其他 Salesforce 組織中複製資料。不過,Data Cloud One 不支援非 Salesforce 平台。 ### Salesforce 中輸出整合的 Pro-Code 工具
指引 授權 時間 體積與規模 交付與維護 隱私權與安全性
使用時機 額外授權 同步 (要求/回覆) 或非同步 (觸發/忘記) 多物件支援 LDV/大量 測試與部署** 除錯 內建錯誤處理/重試行為 可與靜態加密的資料搭配使用 驗證通訊協定
自訂 Apex 當您需要的功能比低程式碼工具所提供的功能多。 不需要 兩者 是 是 是 使用 Pro-Code 工具 否 是* 多
外部服務 使用 OpenAPI 規格說明從程式碼與外部系統 API 整合。 不需要 同步化 是 否 是 使用 Pro-Code 工具 否 無 多
MuleSoft Anypoint 當您需要單一企業級統一解決方案來建立、協調和管理整合時;當您需要取代舊版點對點結構時;或當您需要 API 管理支援時。 必要 兩者 是 是 是 使用 Pro-Code 工具 否 是* 多
\*啟用 Shield Platform Encryption 會變更某些行為,請參閱 [一般 Shield Platform Encryption 考量事項](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5)以取得詳細資料。 \*\*測試與部署是指在較低環境中建立並透過 [中繼資料 API](https://developer.salesforce.com/docs/metadata-coverage/)、封裝或變更集部署至生產的能力。 ### 使用個案:使用 Pro-Code 工具的輸出整合 > 當機會成交時,必須在公司的 ERP 或訂單管理系統中建立相關產品的訂單。 **自訂 Apex** 您可以在機會上建立 Apex 觸發和觸發處理常式,當機會的階段變更為「成交」時,其會對 ERP 或訂單管理系統進行呼叫。請注意,如果您從觸發或執行 DML 作業後進行呼叫,則必須使用註解為 future 或 queueable 的方法。觸發中的呼叫會在呼叫的留存時間內將資料庫連線保持開啟。所有 Apex 程式碼皆受限於「[Apex 管理員」和「API 限制](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_overview.htm)」,這些限制會持續修訂。 **外部服務** 如果透過 OpenAPI 規格定義公司的外部 ERP 或訂單管理系統,則可簡化對未來方法或可排列工作中執行之服務的呼叫。您可以直接從 Apex 呼叫註冊的外部服務,而無須撰寫板碼。在此範例中,可由外部服務處理建立訂單的呼叫。 **MuleSoft Anypoint** MuleSoft Anypoint 提供企業級 API 管理。MuleSoft Anypoint 可以建立 API 來啟用 Salesforce 和許多其他企業系統資料的讀取 (和/或寫入) 存取權。有 [許多預先建置的連接器可用](https://www.mulesoft.com/platform/cloud-connectors)來簡化實作,公司也可以建立和發佈自己的連接器。這些 API 可使用彈性的安全性原則在 Anypoint 中部署,並支援集中管理與管治。交易量沒有任何限制,只要 API 已適當調整其最大利用率的大小 (以 vCores 測量)。 ## 將外部系統資料新增至 Salesforce (輸入整合) 針對 Salesforce 的輸入整合,您可以考量不同類型的工具:低程式碼、Pro-code 或混合式。下列區段提供每個工具類型的指引,並提供範例解決方案。 - [輸入整合的低程式碼工具](#輸入整合至-salesforce-的低程式碼工具) - [輸入整合的混合式工具](#適用於-salesforce-輸入整合的混合式工具) - [輸入整合的 Pro-Code 工具](#輸入整合至-salesforce-的-pro-code-工具) ### 輸入整合至 Salesforce 的低程式碼工具
指引 授權 時間 體積與規模 交付與維護 隱私權與安全性
使用時機 其他授權 同步 (要求/回覆) 或非同步 (觸發/忘記) 多物件支援 LDV/Bulk 測試與部署* 除錯 內建錯誤處理/重複處理行為 可與靜態加密的資料搭配使用 驗證通訊協定
Heroku Connect 當您想要透過雙向同步擴充資料,以在 Heroku 上啟用行動應用程式和其他應用程式,且您想要將資料也複製到 Salesforce 時。 必要 非同步 是 是 否 使用 Pro-Code 工具 是 是,透過 Shield Connect OAuth
OmniStudio 整合程序 當您需要在沒有使用者互動的情況下,從第三方來源匯入和轉換資料時。 必要 兩者 是 是 是 宣告式支援 否 是 已命名認證
Salesforce Connect/外部物件 當您想要資料顯示在 Salesforce UI 中,但想要資料儲存在可使用標準通訊協定 (例如 Odata 或 GraphQL) 的外部系統中時。 必要 同步化 是 是 是 使用 Pro-Code 工具 否 無 多
\*測試與部署是指在較低環境中建立並透過 [中繼資料 API](https://developer.salesforce.com/docs/metadata-coverage/)、封裝或變更集部署至生產的能力。 ### 使用個案:使用低程式碼工具進行輸入整合 > 連絡人會在組織的 ERP 系統中更新。此連絡人資訊必須在 Salesforce 中更新。 **Heroku Connect** Heroku Connect 通常用於將 Heroku Postgres 資料庫與 Salesforce 保持同步。除非 ERP 系統使用 Heroku Postgres 作為其交易存放區,否則此使用個案無法使用。如果使用 Heroku Postgres,則在 Postgres 表格中進行的變更可以使用 Heroku Connect 同步化至 Salesforce 中的物件。 **OmniStudio 整合程序** ERP 系統更新連絡人記錄後,可透過資料對應器產生的 REST API 呼叫包含資料對應器載入動作和回應動作的 OmniStudio 整合程序。首先,資料對應器載入動作會傳送 JSON 或 XML 裝載,用於根據「外部識別碼」欄位或透過「[更新插入金鑰」](https://trailhead.salesforce.com/content/learn/modules/omnistudio-data-tools-and-internal-data/build-an-integration-procedure-with-conditional-dataraptor-loads?trail_id=build-guided-experiences-with-omnistudio)更新插入連絡人記錄。如果 JSON 中的簡單回應僅限預期,則「回應動作」會傳回先前動作中的任何相關資訊,以表示成功或失敗。如果 ERP 系統預期特定回應,則可使用「資料對應器轉換」或「解壓縮動作」產生含額外功能的 JSON 或 XML 回應,以宣告方式包含連絡人記錄更新所產生觸發中的資料。此案例的主要挑戰是並行:多個呼叫同時更新相同的連絡人記錄會造成問題,因為 API 存在於 Salesforce 中。 不建議針對此使用個案使用 **Salesforce Connect/外部物件** Salesforce Connect 和外部物件,因為此情況特別需要在 Salesforce 中複製資料。如果您擁有建立於 ERP 的預先存在 Salesforce Connect 整合,則如果 ERP 支援變更資料資料擷取,您可以設定 Odata 4.0 連接器來支援外部變更資料擷取。此外,您必須在 Salesforce 中設定,以使用 Pub/Sub API 從 ERP 訂閱變更串流。 ### 適用於 Salesforce 輸入整合的混合式工具
指引 授權 時間 體積與規模 交付與維護 隱私權與安全性
使用時機 其他授權 同步 (要求/回覆) 或非同步 (觸發/忘記) 多物件支援 LDV/Bulk 測試與部署** 除錯 內建錯誤處理/重複處理行為 可與靜態加密的資料搭配使用 驗證通訊協定
平台事件 當您需要自定義的結構化裝載,以在 Salesforce 或外部系統中進行近乎即時的變更時。 不需要* 非同步 是 否 是 使用 Pro-Code 工具 是 是 OAuth
Salesforce Connect/外部物件 (含自訂 Apex 轉接器) 當您需要資料顯示在 Salesforce UI 中,但想要資料儲存在無法使用 Odata 2.0/4.0 通訊協定的外部系統中時。 必要 兩者 是 是 是 使用 Pro-Code 工具 否 無 多
Data 360 當您想要在一個資料存放區中協調不同來源的資料,或想要將資料從其他 Salesforce 組織或複製到其他外部系統時。Data 360 也支援某些平台的虛擬化。 必要 兩者 是 是 是 否 是 是 多
\* 大量使用個案需要[附加元件](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)。 \*\*測試與部署是指在較低環境中建立並透過 [中繼資料 API](https://developer.salesforce.com/docs/metadata-coverage/)、封裝或變更集部署至生產的能力。 ### 使用個案:使用混合式工具進行輸入整合 > 連絡人會在組織的 ERP 系統中更新。此連絡人資訊必須在 Salesforce 中更新。 外部系統中的「**平台事件」**自訂程式碼會在 ERP 中更新連絡人記錄時發佈「平台事件」。Salesforce 中的觸發、程序或流程可以訂閱平台事件,並在處理事件時更新對應的 Salesforce 物件。平台事件可能只會作為在客戶 ERP 系統中發生變更而不包含任何資料的訊號運作,或者可能包含更新 Salesforce 物件所需的實際資料。 **Salesforce Connect/外部物件 (含自訂 Apex 轉接器)** 此解決方案不適用於需要資料複製的使用個案。如果您需要 Salesforce 中的使用者查看來自外部系統的資訊,且外部系統不支援如 Odata 或 GraphQL 等標準通訊協定,則此解決方案適用。請參閱 [使用個案:輸出整合使用混合式工具](#使用個案使用混合式工具的輸出整合)作為 Apex 自訂轉接器的範例使用個案。 **Data 360** 當在外部系統 (例如 ERP) 中更新連絡人時,可使用立即可用的連接器,或使用 API 和 Pro-Code 工具 (例如 MuleSoft) 將連絡人更新同步至 Data 360。您也可以使用零複製機制在 Data 360 中參照連絡人 (適用於某些平台)。一旦資料可在 Data 360 中使用,即可使用不同的立即可用整合機制將資料同步至其他 Salesforce 組織。您可以使用 Data Cloud One 透過參照來存取資料。您也可以使用立即可用的連接器來複製資料,或透過如 MuleSoft Anypoint 平台等專業程式碼工具的協助來複製資料。 ### 輸入整合至 Salesforce 的 Pro-Code 工具
指引 授權 時間 體積與規模 交付與維護 隱私權與安全性
使用時機 其他授權 同步 (要求/回覆) 或非同步 (觸發/忘記) 多物件支援 LDV/Bulk 測試與部署**** 除錯 內建錯誤處理/重複處理行為 可與靜態加密的資料搭配使用 驗證通訊協定
自訂 Apex REST 與 SOAP Web 服務 當您需要比原生 API 端點提供更多的功能時,例如跨物件處理或其他複雜邏輯。 不需要 兩者 是 是 是 使用 Pro-Code 工具 否 是*** 多
MuleSoft Anypoint 當您需要單一企業級統一解決方案來建立、協調和管理整合時;當您需要取代舊版點對點結構時;或當您需要 API 管理支援時。 必要 兩者 是 是 是 使用 Pro-Code 工具 否 是*** 多
原生 Salesforce API 當您需要更多控制或擁有專業程式碼技能集,以透過 REST API、SOAP API、大量 API 或 GraphQL API 或 gRPC 建立整合時。 不需要* 兩者 是***** 是 是 使用 Pro-Code 工具 是** 是*** 多
\* 適用「[API 要求上限與配置](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm)」。 \*\*大量 API 有重試行為的層面,而一些 API 透過 allOrNone 設定提供_回復_保護 (例如,請參閱複合與集合要求中的 [allOrNone 參數](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_allornone.htm)) \*\*\*啟用 Shield Platform Encryption 會變更某些行為,請參閱 [一般 Shield Platform Encryption 考量事項](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5)以取得詳細資料。 \*\*\*\*測試與部署是指在較低環境中建立並透過 [中繼資料 API](https://developer.salesforce.com/docs/metadata-coverage/)、封裝或變更集部署至生產的能力。 \*\*\*\*\*複合 API 有多物件支援。 ### 使用個案:使用 Pro-Code 工具進行輸入整合 > 連絡人會在組織的 ERP 系統中更新。此連絡人資訊必須在 Salesforce 中更新。 **自訂 Apex REST 和 SOAP Web 服務** 您可以使用可在「連絡人」物件上執行 CRUD (建立、讀取、更新、刪除) 作業的 Apex 程式碼建立 Web 服務。此服務會透過 SOAP 或 REST 從外部系統 (ERP) 叫用。 **MuleSoft Anypoint** MuleSoft Anypoint 的意圖是提供企業級 API 管理。MuleSoft Anypoint 提供一[組大型預先建置連接器](https://www.mulesoft.com/platform/cloud-connectors),可用來與許多 ERP 系統整合,包括 SAP、Oracle EBS、Oracle ERP 和 NetSuite。您可以建立流程來聆聽這些 ERP 系統中的事件 (在此個案中為建立新連絡人時)。流程開始時,會使用 Salesforce 連接器建立新的「連絡人」記錄 (若連絡人已存在則更新一個)。此外,如果複製交易涉及將連絡人新聞訂閱至其他系統,則可以與其他系統整合。您可以視需要使用對應和轉換語言 (DataWeave) 來執行複雜邏輯和計算,作為跨多個不同系統的資訊流程。針對這些系統的驗證可透過許多不同的驗證機制完成,例如基本驗證和 OAuth。只要流程已適當調整其最大利用率的大小 (以 vCores 測量),交易量就沒有任何限制。 當 ERP 系統中的更新交易完成 (或立即完成後),您可以透過 SOAP API 對「連絡人」物件執行更新插入作業,或對 Salesforce 組織中的 Contact sObjects REST API 執行 [PATCH](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_update_fields.htm) 。**** ## Salesforce 到 Salesforce 整合 Salesforce 到 Salesforce 產品已到期。Salesforce 到 Salesforce 讓合作夥伴可以輕鬆地共同銷售並支援聯合客戶,但 Salesforce 將投資在為其他工具帶來更多創新。繼續進行時,建議使用下列方法在 Salesforce 組織之間共用資料。 ### 在整個 Salesforce 組織之間資料整合的工具
指引 成本 時間 體積與規模 交付與維護 隱私權與安全性 要實作的工具
使用時機 額外授權 同步 (要求/回覆) 或非同步 (觸發/忘記) 多物件支援 LDV/大量 測試與部署* 除錯 內建錯誤處理/重試行為 可與靜態加密的資料搭配使用 驗證通訊協定 低程式碼 → 專業代碼
Heroku Connect 當您想要透過跨 Salesforce 組織的雙向同步擴充資料,同時啟用從 Heroku 上執行的行動應用程式和其他應用程式存取資料時 必要 非同步 是 是 否 使用 Pro-Code 工具 是 是,透過 Shield Connect OAuth 低程式碼
MuleSoft Anypoint 當您需要單一企業級統一解決方案來建立、協調和管理整合時;當您需要取代舊版點對點結構時;或當您需要 API 管理支援時 必要 兩者 是 是 是 使用 Pro-Code 工具 否 是** 多 專業代碼
原生 Salesforce API 當 Salesforce 或 Heroku Connect 不是選項或您需要更複雜的處理時 不需要 兩者 否 是 是 使用 Pro-Code 工具 否 是** 多 專業代碼
變更資料取取 當您需要將在 Salesforce 中進行的記錄層級變更發佈至外部系統,且不需要自訂裝載時。 必要 非同步 否 否 是 使用 Pro-Code 工具 是 是 OAuth
Salesforce Connect 與跨組織轉接器 當您想要一個組織中的使用者檢視或編輯不同組織的記錄時,無須複製資料 必要 非同步 是 是 是 使用 Pro-Code 工具 無 無 多 低程式碼
Data 360 當您想讓一個組織中的使用者檢視或編輯不同組織中具有 Data 360 中所複製資料的記錄時。 必要 兩者 是 是 是 使用 Pro-Code 工具 是 是 多 混合式
\*測試與部署是指在較低環境中建立並透過 [中繼資料 API](https://developer.salesforce.com/docs/metadata-coverage/)、封裝或變更集部署至生產的能力 \*\*啟用 Shield Platform Encryption 會變更某些行為,請參閱 [一般 Shield Platform Encryption 考量事項](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5)以取得詳細資料。 _平台事件不適合將一個 Salesforce 組織的資料整合到另一個組織,因為它們無法在同一個事件的組織之間「聆聽」。自訂 Apex 也不為此類型整合的建議方法。_ ### 使用個案:連線多個 Salesforce 組織 > 大型企業在多個業務單位 (BU) 之間營運。每個 BU 都有自己的 Salesforce 組織。單一客戶處理企業的多個業務單位,因此在多個組織中擁有帳戶和機會資料。企業需要存取單一組織中所有 BU 之間所有「帳戶」和「機會」資料的彙總檢視。 _注意:根據「[Takeaway #1](#接待時間)」,下列所有解決方案都針對最少數量的資料複製設計。_ 您可以使用立即可用的 Salesforce 連接器,將不同 Salesforce 組織的「**Data 360 帳戶」**和機會資料提取至 Data 360。也可以彙總和協調 (若有需要)。在 Data 360 中彙總資料後,即可使用 Data Cloud One 在其他 Salesforce 組織中存取資料,而無須資料複製。 **Heroku Connect** 針對每個 BU 的個別組織,您可以使用 Heroku Connect 將變更從 Salesforce 同步至單一 Heroku Postgres 資料庫。在此情節下,雙向同步化未啟用,只會從 Salesforce 同步化至 Postgres。接著,在 Heroku Connect 中,您可以啟用 Odata 提供者,並選取要在 Salesforce 組織中公開為外部物件的表格,其中您想要彙總檢視。在 Salesforce 中,您可以定義指向 Heroku 中 Odata 提供者的外部資料來源。 **MuleSoft Anypoint** MuleSoft Anypoint 提供企業級 API 管理。MuleSoft Anypoint API 可以設定為使用具有組織多個連線的 Salesforce 連接器來讀取來自多個相關 Salesforce 組織的資訊。MuleSoft 流程可查詢不同的 Salesforce 組織,並視需要傳回增強或增強其他第三方資訊的特定結構。叫用 API 時,會執行所有適當的 Salesforce 組織呼叫 (在此範例中查詢帳戶和機會資訊),以便取用者 (可能為 UI) 可以處理資料。對這些系統的驗證可以透過各種驗證機制完成,包括基本驗證和 OAuth。交易量沒有任何限制,只要流程已適當調整其最大利用率的大小 (以 vCores 或 Core 測量)。 「**原生 Salesforce API」** 查詢作業可以發出給每個感興趣的組織,特別是透過 Salesforce 大量 API 2.0,該 API 非常適合有效地提取數千筆記錄。您可以個別從每個組織中提取查詢結果,並根據客戶需求將其與自訂應用程式或中間程式彙總。 **Salesforce Connect with Cross-Org Adapter** Salesforce Connect Cross-Org 轉接器不適合此情況,因為遠端組織的帳戶或機會將全部顯示在中央組織中,作為 _不同的_物件。例如,無法為所有組織中所有機會的「金額」加總總計。 **選擇性更新跨組織案例:**銷售人員使用 Salesforce 組織 A,需要檢視和更新 Salesforce 組織 B 中的「個案」資料,並在組織 A 中工作時,將個案註解新增至 Salesforce 組織 B 上的父系個案。資料不能複製到組織 A。 **Heroku Connect** 您可以使用上述 _資料彙總案例_中所述的相同方法。不過,您必須透過 Odata 連接器在外部物件上啟用 CRUD,並將變更寫回 Heroku Postgres。 **MuleSoft Anypoint** MuleSoft Anypoint 提供企業級 API 管理。您可以使用上述 _資料彙總情境_中所述的相同方法。 **原生 Salesforce API** 使用已命名認證並叫用原生 Salesforce API 以讀取和更新相關 Salesforce 組織中的資料。元件必須設計為顯示資料。 **Salesforce Connect with Cross-Org Adapter** 透過 [Salesforce 跨組織轉接器](https://help.salesforce.com/articleView?id=sf.xorg_adapter_about.htm&type=5)支援檢視外部物件中的資料 (如果您已在外部物件上啟用 CRUD,則也可以編輯資料)。外部物件之間也支援關係,因此您可以連結至外部物件中的父系個案。然而,建立關係是手動流程,您現在可以將現有資料類型轉換為關係資料類型。此外,在 Service Cloud 中執行的最佳化以更有效率地使用「個案」不會串聯至遠端組織。Salesforce 強烈建議您針對使用個案測試「跨組織轉接器」,並評估使用「外部物件」與「標準物件」的權衡。 **資料同步跨組織**:當組織其中一個業務單位 Salesforce 組織中更新客戶的帳戶時,其他 Salesforce 組織的「帳戶」物件必須更新,才能保持一致的帳戶資訊。 **Data 360** Data 360 可用於從一個組織複製資料至另一個 Salesforce 組織。單一 Salesforce 組織的帳戶資料可使用立即可用的 Salesforce 連接器,以便將這些連接中所輸入的資料匯入至 Data 360。我們也可以使用資料啟用機制,例如批次啟用、近乎即時的資料動作或以 API 為基礎的啟用,將資料從 Data 360 移至 Salesforce 組織。 **Heroku Connect** 您可以使用上述 _資料彙總案例_中所述的相同方法。不過,您必須啟用雙向同步化,且您不再需要啟用 Salesforce Connect,因為雙向同步化會在對 Postgres 表格進行變更時讓所有組織保持在最新狀態。 **MuleSoft Anypoint** MuleSoft Anypoint 提供企業級 API 管理。您可以在 MuleSoft Anypoint 中使用 Flow Designer [設定 Mule 應用程式](https://docs.mulesoft.com/design-center/about-designing-a-mule-application),以聆聽標準和自訂物件事件,以在 Salesforce 中開始自動啟動流程。觸發 Mule 應用程式時,其可以叫用 Anypoint Connector for Salesforce 以與任何數量的 Salesforce 組織通訊。在此使用個案中,當 Salesforce 組織中更新「帳戶」記錄時,Mule 應用程式可以更新相關 Salesforce 組織中的「帳戶」記錄。每個相關的 Salesforce 組織都會擁有內建在 MuleSoft 中整體應用程式流程中的唯一更新步驟。對這些系統的驗證可以透過各種驗證機制完成,包括基本驗證和 OAuth。只要流程已適當調整其最大利用率的大小 (以 vCores 或 Core 測量),交易量就沒有任何限制。 **原生 Salesforce API** [Replication API](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_guidelines_datareplication.htm) (getUpdated、getDeleted 作業) 可用來跨組織同步化資料,但不建議使用此方法。 **Salesforce Connect with Cross-Org Adapter** 您可以使用記錄觸發流程和外部物件,讓 Salesforce 組織之間的部分資料保持同步。例如,更新「組織 A」中的帳戶記錄會觸發流程,然後更新「帳戶」外部物件上的相符記錄,這會將這些更新寫入「組織 B」中的帳戶記錄。這需要正確使用流程語意,以避免進行[混合的 DML 交易](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1)。此外,請記住,「組織 B 中的驗證規則和流程」會以與 REST/SOAP API 進行變更時相同的方式觸發。 ## 結束備註 請記住此指南,並在您規劃涉及 Salesforce 的新資料整合時參閱該指南。最好瞭解您可用的完整選項範圍,以及這些選項如何符合您的特定使用個案。 ### 告訴我們您的想法 協助我們確保我們發佈與您最相關的內容。[參加我們的調查](https://sfdc.co/J0cWb)以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。 # 記錄觸發自動化 Salesforce Platform 持續推進其自動化結構,以滿足複雜業務流程的需求。先前的產生—工作流程規則和流程產生器—提供事件驅動邏輯的初始步驟,擴充事件驅動邏輯的自動化功能,並將範圍延伸至更廣泛的產生器。 此進化為高效能的整合結構,其核心為兩個互補的支柱:記錄觸發流程與 Apex 觸發程序。 ## 指南概觀 此文件提供在設計觸發自動化時做出明智決策的架構與原則。其會將使用個案需求與三個主要決策點進行平衡,這些決策點將引導您為 Salesforce 記錄變更所觸發的自動化選擇正確的方法。 ## 範疇中的產品
流程 Salesforce 流程是一種功能強大的點選自動化工具,可讓使用者使用 Flow Builder 以視覺化方式建立複雜的業務流程、畫面和邏輯,而無須撰寫程式碼。它會自動化資料更新、傳送電子郵件和引導使用者等工作,透過如「畫面流程」(使用者互動) 和「觸發的流程」(記錄/排程事件) 等類型提供彈性。
Apex Salesforce Apex 是 Salesforce 平台的專屬物件導向程式語言,類似於 Java,用於建立自訂業務邏輯、自動化流程,並將核心 CRM 功能延伸至陳述性工具之外。
## 接待時間 在 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 的效能、細微控制,以及物件導向的抽象與多型,更適合管理這些案例的複雜性和規模。
密度層級 自動化數量 資料量 (批次大小) 相依性流程 結構標準
低 < 15
自動化		 標準
使用者驅動的 UI 互動或小型 API 載入 (1–200 筆記錄)		 不定
獨立邏輯。相同物件或相關物件上的 0–1 下游 DML 作業。		 記錄觸發流程
中型 15–30
自動化		 中度
標準批次處理 (具有需要謹慎大量處理的邏輯)		 已配對
「父系/子系」會更新 2–4 個下游 DML 作業。遞迴風險		 混合模式
流程 + 可叫用 Apex
高 > 30
自動化		 高
大量載入 API 的資料量 (2,000 – 10,000+ 筆記錄)		 複雜與遞迴
深度相依性圖表 (5+ 下游 DML 作業)。三角遞迴迴圈的風險		 Apex 觸發中繼資料架構
實際的結構決策需要您加權自動化密度的所有維度。為指定 Salesforce 物件選取自動化機制時,請考量潛在的未來範圍。 此外,請考量每日 DML 作業的總數,因為 Salesforce 會在多租戶環境中強制執行共用資源管理和[管理員限制](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm),以防止流失的自動化對共用資源進行垄断。具有高每日 DML 量之 Salesforce 物件需要謹慎的自動化選取。例如,CPU 時間 (60,000 毫秒) 和堆疊大小 (12 MB) 的非同步限制高於同步限制。此外,非同步執行的全組織 24 小時限制 (計算為 250,000 或使用者授權的 200 倍) 需要將每日 DML 總數納入結構設計中,以避免執行階段例外。 ## 產品比較 「記錄觸發流程」是平台用於記錄觸發自動化的首要陳述性工具。流程的易用性和內建平台保護功能可讓小組輕鬆建立可調整且可靠的解決方案。這是大多數的小組在 Salesforce 平台上建立解決方案的理想選擇。 Apex 是平台專屬、強大類型的物件導向程式語言。針對高度自動化密度的 Salesforce 物件,以及需要高效能、複雜邏輯或對交易進行細微控制的使用個案,使用 Apex。 為協助進行決策流程,此矩陣可提供跨關鍵結構功能的流程與 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 Apex 提供豐富的 API,可用於與平台的介面和原始速度。
複雜資料處理 需要進階資料操作的案例 Apex Apex 提供「流程」中原生無法使用的資料結構,例如「對應」與「集」,這些結構對於撰寫效能高且安全的程式碼而言至關重要。
交易控制 控制如儲存點、結轉和部分認可等機制 Apex Apex 提供如 Database.savepoint 和 Database.rollback 等機制的存取權,並能夠處理部分成功的 DML 作業。
精密的自訂驗證 記錄中多個欄位的資料驗證 Apex 雖然「流程」可以防止使用「CustomError」元素儲存,但並非所有流程類型皆可使用,包含子流程。Apex addError() 方法提供多個欄位特定錯誤訊息,可在觸發處理期間隨時新增至記錄。
簡單程序內的中度複雜邏輯 由標準功能庫簡化,中度複雜度的邏輯與資料操作,作為不複雜流程的一部分發生 流程 + Apex 「記錄觸發流程」會作為協調流程層,而高複雜度的作業會壓縮在「可叫用 Apex」內。
簡單到中度複雜的邏輯 低至中度複雜度的資料操作,其中會觸發主要與相關資料物件的更新 流程 流程通常是執行選項,因為其以陳述性模型為基礎,可供管理員和開發人員存取。
通知與輸出訊息 傳送輸出電子郵件與訊息 流程 流程可讓在記錄變更時傳送電子郵件警示和輸出訊息輕鬆且高度調整。
排程處理 未來動態日期自動化 (例如結束日期前 3 天) 流程 已排程路徑為流程提供獨特的優勢,因為當記錄的資料變更時,平台會自動處理這些路徑的排程、取消和重新排程。
### 可調整處理:深入分析非同步使用個案 設計實作時,延展性是重要的考量事項。當記錄觸發自動化的商業邏輯變得複雜、執行時間長或涉及大量資料時,Salesforce 平台的核心管理員限制會變成結構限制。大量資料更新、複雜的 API 呼叫或繁重計算等作業會增加違反限制的風險,例如總 CPU 時間或單一資料庫交易內的 DML 陳述式數量。由於限制例外,同步觸發失敗會導致使用者的整個儲存交易回復,導致使用者體驗不佳並可能遺失資料。此固有的風險需要結構模式來卸載複雜工作。 非同步自動化在此個案中至關重要。使用非同步機制,結構設計師可以有效地將長時間執行或大量工作與主要同步記錄儲存交易分離。儲存可快速且可靠地完成,而大量處理會委派至稍後執行的個別平台管理交易。分離可改善穩定性、防止交易失敗,對於建立可調整的企業應用程式而言至關重要。此平台為此提供數種專用工具,每種工具皆具有與可靠性、數量和複雜度相關的不同優點和權衡。 ### 流程的非同步路徑 記錄觸發流程中的「非同步執行」路徑提供「觸發忘記」非同步邏輯的最簡單機制。原始記錄儲存交易成功認可至資料庫後,此路徑會在個別交易中執行。 - **理想使用個案**:這適用於不需要立即執行或自訂錯誤處理的工作。範例包括傳送電子郵件通知、建立後續追蹤工作,或對外部系統進行簡單呼叫。 - **限制**:此機制與其他非同步流程訪問共用相同的每日管理員限制。不適用於極大量處理。 ### Change 資料擷取 (CDC) Change 資料擷取 (CDC) 是一種高流量、可調整且彈性的模式,用於處理大量案例中記錄變更所觸發的非同步邏輯。在此模型中,觸發的唯一責任是同步儲存記錄。接著,平台會發佈詳細的事件訊息,其中包含記錄對大量 Event Bus 的變更。個別的專用 Apex 觸發會訂閱此變更事件。它會執行複雜、長時間執行或非同步的工作。 - **益處**:此模式會將非同步流程與初始使用者交易分離。非同步處理失敗不會造成使用者的記錄儲存回復。模式也提供可供多個內部訂閱者或外部系統使用的永久事件串流,且事件最多可重新執行 72 小時,提供強大的彈性。 - **限制**:CDC 事件訊息不包含記錄的先前狀態,亦即等同於 Apex `Trigger.oldMap`。事件裝載包含新的欄位值,但不包含其變更的值。這會使根據特定狀態轉換實作邏輯變得具有挑戰性 (例如,僅在 `Status__c` 從「待處理」變更為「已批准」時執行)。您可以透過在事件訂閱者中查詢物件的欄位歷程記錄來減輕此情況,但這會對流程增加複雜性,且欄位歷程記錄追蹤可能無法用於特定感興趣的欄位。這可能會限制您可以卸載至 CDC 的自動化類型。 依預設,CDC 最多可在五個 Salesforce 物件上啟用。需要更多的組織可以購買附加元件授權,以移除此限制並增加事件傳送配置。 ### 從觸發將 Apex 加以排列 直接從觸發程序執行可排列的 Apex 工作應視為具有風險的模式,僅在需要 Apex 提供的控制時使用 (例如,用於複雜邏輯或自訂重試機制),且 CDC 不是可行的選項。 如果 Apex 需要可排列,則實作必須包含適當的保護措施: - **限制檢查**:程式碼必須在嘗試新增其他工作之前,先檢查已在交易中建立的工作數目。 ``` if (Limits.getQueueableJobs() < Limits.getLimitQueueableJobs()) { ... } ``` - **內容認知**:程式碼必須偵測其是否在非同步環境 (例如批次工作 (`System.isBatch()`) 內執行,並修改其行為,以遵循該環境中更嚴格的一次性交易限制。 ### 限制觸發非同步 Apex 的考量事項 從同步觸發叫用非同步 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](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 流程 作業
# 開始使用 Data 360 決策指南 本節提供關於 Salesforce Data 360 進行關鍵結構決策的實際指引,包括佈建策略、多組織連線和整合模式。使用這些指南設計與實作統一客戶資料並啟用 AI 強化的有效資料結構。 --- ## Data 360 佈建 「[Data 360 佈建」](/docs/architect/zh-tw/decision-guides/guide/data-360-provisioning) 涵蓋佈建 Salesforce Data 360 時的基本決策: - **首頁組織選取**:決定要在現有生產組織中佈建 Data 360 還是建立專屬組織,並考量監管、合規性和時間對價值。 - **多組織策略**:在多個獨立 Data 360 例項之間選擇,或使用 Data Cloud One 統一多個 Salesforce 組織,平衡自主性、合規性和成本。 - **Data Cloud One 結構**:啟用多個「伴隨組織」以透過組織之間的集中管理、中繼資料共用和功能比對來共用單一 Data 360 例項。 - **Data 360 組織之間的資料共用**:針對區域合規性、業務單位協同合作或聯合主管顯示面板,在獨立例項之間使用零複製資料共用。 - **佈建考量事項**:資料落地、管治模型、延遲、整合複雜度、成本和企業範圍部署 AI 整備的因素。 協助結構設計師設計佈建策略,以確保 Customer 360、AI 和跨平台創新的簡化、企業一致性、合規性和延展性。 --- ## Data 360 互通性 [Data 360 互通性](/docs/architect/zh-tw/decision-guides/guide/data-360-interoperability) 提供整合 Data 360 與外部平台和資料湖的架構: - **資料取用模式**:即時、串流和批次採取,以建立適合 Customer 360、合規和集中管理的受管理標準資料集。 - **零複製資料聯合**:即時查詢、加速查詢 (快取) 和檔案聯合方法,以即時存取外部系統而不重複,啟用個人化、顯示面板和 AI/ML 工作量。 - **混合式方法**:使用零複製聯合結合核心資料集的受管理性,以確保最新性和延展性,並支援 Omni-Channel 參與、Agentforce 驅動的動作和企業分析。 - **決策架構**:評估延遲、成本、可擴展性、管治和複雜性的權衡,以選取每個資料來源的正確整合模式。 - **建築師手冊**:針對財務、醫療照護、零售和電信情況的產業特定指引、設計作法和成本考量事項。 引導結構設計師平衡資料更新、管治和管道效率,以建立可調整、可互通且 AI 就緒的資料結構,以支援作業與分析工作量。 # 開始使用平台決策指南 本節提供關於 Salesforce Platform 功能之重要結構決策的實際指引。它涵蓋非同步處理、記錄觸發事件、表單建立、代理程式和傳統工作流程自動化、以事件為導向的結構,以及步驟型非同步架構,以協助結構設計可調整、可維護和高效能平台解決方案。 --- ## 非同步處理 [非同步處理](/docs/architect/zh-tw/decision-guides/guide/async-processing)提供 Salesforce 中非同步作業工具和方法的指引: - **非同步處理工具**:可排列 Apex、排程的 Apex、平台事件觸發、變更資料擷取、排程路徑 (認可流程後) 和非同步路徑 (記錄觸發流程) 的比較,以及適當使用個案的指引。 - **伺服器端非同步處理**:長時間執行資料庫作業、外部呼叫和大量記錄處理的模式。 - **用戶端非同步處理**:如 Apex 繼續呼叫和用戶端非同步處理等技術,可在瀏覽器或行動應用程式中執行。 - **決策架構**:考慮使用個案驗證、可擴充性、瞭解交易何時為真非同步、監視及處理極端負載事件。 - **最佳作法與反模式**:適當使用的指引,包括輸出整合、監視和避免常見的陷阱。 讓結構設計師能夠實作可調整、可靠且可維護的非同步模式,避免可能影響效能的陷阱。 --- ## 建立表單 「[建立表單」](/docs/architect/zh-tw/decision-guides/guide/build-forms) 會引導結構設計師瞭解 Salesforce 表單建立選項: - **表單建立工具**:動態表單、畫面流程、OmniStudio、畫面流程與 Lightning Web 元件 (LWC) 和 LWC 的比較,包括技能和授權考量事項。 - **決策架構**:考量物件影響、表單範圍、瀏覽、位置 (應用程式、行動裝置、網頁)、UX 和測試自動化。 - **工具選取指引**:從簡單的記錄版面配置到多頁精靈和品牌面向客戶表單的建議。 - **組合模式**:結合工具的指引,例如「畫面流程」瀏覽與 LWC 樣式。 - **進階功能**:深入瞭解功能與限制以通知工具選擇。 協助結構設計師為其特定 UX、功能與整合需求選取正確的表單建立方法。 --- ## 決定工作人員與傳統工作流程自動化 [決定工作人員與傳統工作流程自動化](/docs/architect/zh-tw/decision-guides/guide/determining-agentic-vs-traditional-workflow-automation.html)提供使用「協調密度」架構在傳統自動化與 Agentforce 之間選擇的架構: - **協調流程密度架構**:根據執行路徑 (完全可指定與未指定)、目標複雜度 (單一工作與競爭目標),以及強制回應組合 (結構化與多重模式輸入) 來評估自動化複雜度。 - **產品橫向**:不同自動化案例的流程、Apex、Agentforce、工作人員指令檔、Agentforce 網格、Agentforce Operations 和 MuleSoft 比較。 - **密度選取矩陣**:將協調流程密度層級 (低、中、高) 對應至結構標準,從記錄觸發的自動化到混合式協調流程,到使用工作人員指令檔進行引導式決定。 - **決策架構**:序列評估流程—先檢查執行路徑,然後檢查目標複雜度,再檢查強制回應組合—以決定正確的工具。 - **使用個案指引**:傳統自動化 (以規則為基礎、決定性)、Agentforce 網格 (大量 AI 工作)、混合式協調流程 (複雜端對端流程) 和工作人員指令檔 (含考量需求的非結構化進入點) 的特定建議。 讓結構設計師能夠在整個自動化頻譜中做出明智的決策,並平衡考量功能與決定性控制可調整、可稽核和可維護的解決方案。 --- ## 以事件為導向的結構 [以事件為導向的結構](/docs/architect/zh-tw/decision-guides/guide/event-driven)提供 Salesforce 事件工具和模式的全方位指南: - **避免工具**:平台事件的概觀、Change 資料擷取、Pub/Sub API、MuleSoft Anypoint、Streaming API 和整合考量事項。 - **事件驅動模式**:針對各種以事件為導向的使用個案,包含發佈/訂閱、對應、傳送訊息、串流和排列模式。 - **與 MuleSoft 的整合**:針對企業結構使用 Anypoint 連接器 (Pub/Sub、JMS、Kafka、Solace、MQ、MQTT、AMQP)。 - **平台事件和變更資料**:發佈記錄和欄位變更的偏好機制指引,以及從 PushTopic/Generic Events 移轉的指引。 - **實作模式**:擴展性、一致性、錯誤處理和監視的最佳作法。 讓結構設計師設計可調整的近乎即時事件驅動系統,以有效率地連線多個系統。 --- ## 以步驟為基礎的非同步架構 [以步驟為基礎的非同步架構](/docs/architect/zh-tw/decision-guides/guide/step-based-async-framework)提供模組化、可調整的非同步工作處理架構: - **架構結構**:元件包含「可排列 Apex」、「完成者」、「排程流程」、「Apex 游標」、「可叫用動作」和 Slack 整合。 - **以步驟為基礎的處理**:分割為獨立步驟,可透過共用管理與營運可視性來執行、重試和重新啟動。 - **實作指引**:步驟介面、步驟處理器、Apex 可叫用圖層、延遲處理和通知的模式。 - **最佳作法**:適用於 CRM 中大多數資訊、大量工作負載和階層或樹狀目錄記錄處理時的建議;不使用時的指引。 - **企業級功能**:監管、合規性、散佈狀態、進度追蹤、SLA 監視、失敗診斷和稽核層級記錄。 為結構設計師提供單一批次工作和鏈結非同步呼叫的可調整替代方案,以完全的作業透明度支援大量 Salesforce 工作負載。 --- ## 記錄觸發自動化 [記錄觸發自動化](/docs/architect/zh-tw/decision-guides/guide/record-triggered)提供在 Salesforce Platform 上設計記錄觸發自動化的架構: - **工具選取**:何時使用「記錄觸發流程」與 Apex 觸發,以自動化密度 (低、中、高) 和密度選取矩陣為指引。 - **自動化密度**:如何評估自動化數量、記錄量和相依性擴展,以選擇「流程」、「混合式」(使用可叫用 Apex 進行流程) 或 Apex 觸發。 - **進入點與管治**:每個 Salesforce 物件一個進入點;進入條件、遞迴控制和排序執行的指引。 - **非同步叫用**:從記錄觸發流程或 Apex 叫用非同步流程的時間和方式,並謹慎處理錯誤和管理員限制。 - **最佳作法**:大量處理、混合式 Flow–Apex 設計和避免觸發自動化常見陷阱的模式。 讓結構設計師設計可調整、可維護且能效能的記錄觸發自動化,並符合平台標準。 # 開始使用整合決策指南 本節提供為 Salesforce 選擇正確資料整合工具和方法的實際指引。它涵蓋輸出整合、輸入整合和跨組織案例,協助結構設計師設計和實作資料層整合以平衡效能、可維護性和成本。 --- ## 與 Salesforce 的資料整合 [資料與 Salesforce 整合](/docs/architect/zh-tw/decision-guides/guide/data-integration)提供 Salesforce 資料整合工具和最佳作法的全方位概觀: - **整合工具橫向**:Salesforce 資料整合工具的概觀,包括低程式碼、混合式和專業程式碼選項,以及針對特定使用個案選取正確工具的指引。 - **輸出整合**:將資料從 Salesforce 傳送至外部系統的方法,包括 Change 資料擷取、External Services、Heroku Connect、OmniStudio 整合程序、Salesforce Connect、MuleSoft Anypoint 和自訂 Apex 解決方案。 - **輸入整合**:將外部資料帶入 Salesforce 的方法,以及資料複製與虛擬化的指引,以及每個工具的使用時機。 - **跨組織整合**:在 Salesforce 組織之間共用資料的建議方法,包括 MuleSoft Anypoint、Heroku Connect、原生 Salesforce API、使用跨組織轉接器變更 資料擷取 和 Salesforce Connect包括取代舊版 Salesforce 到 Salesforce 實作的指引。 - **決策架構**:選取整合工具的關鍵考量事項,例如現有工具和橫向、資料流程需求 (時間、方向性、預期的使用者體驗)、實作複雜性、可維護性、資料量和平台限制。 讓結構設計師可以為每個案例選擇正確的整合工具和模式,減少不必要的資料複製、利用現有的 ESB/ETL 解決方案,並確保符合企業結構原則的可調整且可維護整合。