# architect 結構良好 (well-architected) - Full Documentation
> [在此](/docs/architect/zh-tw/well-architected/guide/contributors)閱讀我們的更新排程。
## 簡介
「受**信任」**的 Salesforce 解決方案可保護企業和利害關係人。針對「**信任」**而設計良好的解決方案安全、合規且可靠。
**安全**解決方案可控制存取並保護資料。
**符合**法律與道德指導方針的解決方案。
**可靠**的解決方案可有效率且可靠地運作。
建立「**信任的**」解決方案需要謹慎規劃。您需要瞭解解決方案提供的業務和/或行業內容。業務的整體風險容忍度為何?什麼類型的資料會進入和移出系統?Salesforce 會以專門的安全性、合規性或道德考量事項,作為記錄或資料儲存點的系統使用嗎?相關的法規與規範標準為何?是否有額外的公司特定標準?Salesforce 是否為業務關鍵系統?您是否需要考慮流量或系統用量的季節性或情況性高峰?
若要找到「**信任的**」解決方案,您必須與整個業務的利害關係人合作。您必須清楚檢視需要存取解決方案的使用者和系統類型,以及完成工作所需的資料和權限。您需要瞭解法律與行業需求,以及內部原則與標準。您需要與開發和維護小組合作,以確保功能可供存取,並公平地為使用者提供服務。即使發生中斷或快速成長,您仍需要計畫解決方案的可用性和效能。針對結構正確的解決方案,沒有什麼比「**信任」更為重要**。
下列幾節提供更多關於「**信任」**解決方案結構核心考量事項的深入指引。
## 信任的概觀
| 安全 | ||
|---|---|---|
| 安全系統可保護業務、利害關係人和資料。安全結構可確保只有經過批准的使用者才能取得存取權、限制使用者對完成工作所需項目的存取權,並保護系統中的資料免受入侵。 | ||
| 組織安全性 | 工作階段安全性 | 資料安全性 |
| 驗證 授權 |
工作階段管理 裝置存取權 威脅偵測和回應 |
共用與可視性 加密的使用 |
| 符合 | ||
| 符合的解決方案遵循法律與道德指導方針。合規性結構遵循法律法規和產業標準、遵守道德原則,並公平地為所有使用者提供服務。 | ||
| 法律符合度 | 道德標準 | 無障礙 |
| 資料隱私權 本地化 |
公司原則 人工智慧 |
資料項目 瀏覽 |
| 可靠 | ||
| 可靠的解決方案可在各種條件下有效率且可靠地運作。可靠的結構在使用者期望的時間和地點可供使用、一致執行,並與業務一起調整規模。 | ||
| 可用性 | 效能 | 延展性 |
| 風險管理 失敗緩解 |
輸出 延遲性 |
資料建模 資料量 |
| 模式 | 防模式 | |
|---|---|---|
| 應用程式複雜性 | 在您的組織中:
- 應用程式在管理員提供的預設組態中有少於 10 個索引標籤 - 沒有任何應用程式的「停用此應用程式中瀏覽項目的一般使用者個人化」設定為 true |
在您的組織中:
- 應用程式在管理員提供的預設組態中常有 10 個以上的索引標籤 - 許多應用程式的「停用此應用程式中使用者瀏覽項目的個人化」設定為 true,或在組織範圍內停用自訂瀏覽項目的權限 |
| 表單 | 在您的應用程式中:
- 欄位會遵循邏輯分組 - 資料輸入欄位會一起顯示,以五個或更少的群組顯示 - 在使用者離開或提交資料前,資料輸入錯誤會明確且顯示在欄位層級 - 分頁控制會啟用步驟之間的移動 - 資料提交發生一次 - 動作和瀏覽的標籤清楚 - 提供及時且視覺化的回饋意見以確認使用者動作,例如按一下按鈕 - 瀏覽按鈕 (例如「前往」、「下一步」和「返回」) 會一致地放置在整個 UI 中 |
在您的應用程式中:
- 未依邏輯將資料輸入欄位分組,因此使用者填寫表單需要大量內容切換 - 資料輸入錯誤包含僅能由瞭解系統內部運作的人員解譯的密碼資訊 - 只有在按一下表單的提交按鈕時,才會顯示資料輸入錯誤 - 未清楚定義步驟和分組,導致難以瀏覽 - 在整個資料輸入流程中多次發生資料提交 - 動作與瀏覽的標籤會讓不熟悉基本系統功能的使用者感到困惑 - 未提供使用者動作的視覺確認 - 瀏覽按鈕會顯示在整個 UI 中的任意位置 |
| 在您的表單邏輯中:
- 欄位會盡可能預先填入或自動完成 - 使用者不需要等待長時間執行的伺服器端動作完成 - 自訂元件針對不涉及資料作業的伺服器型動作使用 cacheable=true
- 資料作業執行一次 - 在 LWC @wire 轉接器中,處理所有不涉及資料作業的動作 |
在您的表單邏輯中:
- 可預先填入或自動完成的欄位需要手動輸入 - 使用者必須在提交流程期間停止工作,才能等待伺服器端動作完成 - 自訂元件集 cacheable=false |
|
| 尺寸規格 | 在您的組織中:
- Salesforce 提供的 Lightning 頁面範本會用於所有或大多數的頁面 - 在 Aura 元件設計檔案中,自訂 Lightning 頁面範本使用 design:supportedFormFactors 和 design:supportedFormFactor
- 在應用程式產生器中提供的自訂 LWC 或 Aura 元件會在各自的設計檔案中宣告支援的尺寸規格,並實作感知寬度的樣式模式 |
在您的組織中:
- Classic 仍啟用 - 自訂 Lightning 頁面範本在 Aura 元件設計檔案中未統一使用 design:supportedFormFactors 和 design:supportedFormFactor
- 在應用程式產生器中提供的自訂 LWC 或 Aura 元件不會一致在各自的設計檔案中宣告支援的尺寸規格 - 在自訂 LWC 或 Aura 元件中,Salesforce 提供的介面不會實作寬度認知樣式 - 在自訂 LWC 或 Aura 元件中,不同尺寸的樣式完全由硬式編碼的 CSS px 或 % 值所驅動 |
| 桌面版:
- 資料輸入欄位和瀏覽控制項適合畫面,且可以依預期與其互動 - 記錄和應用程式頁面會根據頁面啟用指派規則正確顯示 |
桌面版:
- 資料輸入欄位和瀏覽控制項不會顯示在畫面上的預期位置 - 與資料輸入欄位和瀏覽控制項的互動不符合必要行為 - 缺少頁面啟用指派規則表示所有使用者都會看見相同的記錄和應用程式頁面 |
|
| 在行動裝置與平板電腦上:
- 資料輸入與瀏覽控制會正確顯示 - 使用者可以輕鬆地輸入資料 - 顯示針對較小的尺寸規格最佳化的行動瀏覽功能表 - 精簡版面配置會顯示在記錄層級 |
在行動裝置與平板電腦上:
- 資料輸入與瀏覽控制不會一致或正確地呈現 - 使用者無法輕鬆輸入資料 - 行動瀏覽功能表與桌面瀏覽不同 - 未在記錄層級設定精簡版面配置 |
| 模式 | 防模式 | |
|---|---|---|
| 通知與訊息 | 您的設計標準包括:
- 通知、快顯和通知的已批准使用個案 - 整理變體和通知的設計模式 - 錯誤傳訊的設計模式 |
如果已定義設計標準,則不會解決錯誤與通知 |
| 在您的組織中:
- 通知是主要的傳訊格式 - 快顯訊息使用變體 - 「 模式」設為「貼近」的快顯訊息不存在
- 通知很少使用 (若有) - 生成回應一律可識別使用的資料來源 - 機器人在第一次與使用者互動前清楚識別自己 - 在第一次互動之前,會向使用者顯示與生成式 AI 相關聯風險的免責聲明 - AI 免責聲明為使用者清楚且易懂的語言 |
在您的組織中:
- 電子郵件是主要的傳訊格式 - 對於訊息類型沒有一致的方法 - 快顯訊息不會一直使用變體 - 使用設定為「 粘疊」之 模式的快顯訊息
- 特別使用通知 - 生成回應不會識別使用的資料來源 - 在第一次與使用者互動之前,機器人無法清楚識別自己 - 不會向使用者顯示生成式 AI 風險的免責聲明 - AI 免責聲明不使用使用者易懂的明確語言 |
|
| 在您的應用程式中:
- 沒有直接傳送生成回應給一般使用者,沒有人類參與的點數 |
在您的應用程式中:
- 生成回應會直接傳送給一般使用者,但沒有人類參與的點數 |
|
| 另請參閱:錯誤處理 | ||
| 應用程式內導覽 | 您的設計標準和文件包括:
- 應用程式內導覽的已批准使用個案 - 提示與逐步解說的設計模式 - 清晰的使用者矩陣、應用程式和已啟用的應用程式內導覽 |
如果存在設計標準和文件,則會:
- 請勿處理應用程式內導覽 - 請勿包含顯示使用者、應用程式、已啟用應用程式內導覽的明確矩陣 |
| 在您的組織中:
- 「應用程式內導覽之間延遲」設定使用預設值或比 Salesforce 所提供預設 (24 小時) 期間長的自訂值 - 沒有任何應用程式擁有多個啟用的逐步解說 - 沒有逐步解說具有大於 10 的「顯示時間」設定 - 未針對「任何頁面、任何應用程式」或「此頁面、任何應用程式」啟用提示 |
在您的組織中:
- 「應用程式內導覽之間延遲」設定為短於 Salesforce 所提供預設 (24 小時) 的期間 - 應用程式擁有多個啟用的逐步解說 - 許多逐步解說的「顯示時間」設定大於 10 (有些逐步解說的最大值為 30) - 會臨時啟用提示,許多提示具有「任何頁面、任何應用程式」或「此頁面、任何應用程式」設定 |
|
| 認可與獎勵 | 在您的組織中:
- 應用程式使用內嵌分析向使用者顯示相關的目標進度與生產力統計資料 - 只有在使用者同意的情況下才會啟用路徑慶祝 - 通知與傳訊包含使用者辨識,並反映使用者偏好設定,以設計通知對象及觸發通知的項目 |
在您的組織中:
- 與目標進度和生產力統計資料相關的分析僅適用於報告或經理顯示面板 - 啟用路徑慶祝,而無須檢查使用者同意 - 通知和傳訊不包含任何類型的使用者識別,或不反映使用者的偏好設定,並感到雜訊或煩惱 |
| 工具 | 描述 | 已簡化 | 實用 |
|---|---|---|---|
| 啟用 Lightning 應用程式頁面 | 管理頁面可用性、命名、可視性和定位 | X | |
| 採用顯示面板 | 檢閱登入歷程記錄、功能採用與生產力 | X | X |
| 警示 | 在工作階段中保留警示,並且在沒有使用者起始的情況下顯示警示 | X | |
| 用戶端快取 Apex 方法結果 | 使用快取的用戶端資料評估效能 | X | |
| 動態表單 | 僅向使用者顯示必要欄位和頁面區段 | X | |
| 參與洞察 | 監視最近使用者活動並視需要採取行動 | X | X |
| 應用程式內導覽 | 使用提示和逐步解說進行訓練和上線 | X | |
| 學習路徑 | 個人化使用者學習體驗 | X | |
| Lightning 應用程式產生器 | 無須程式碼即可建立自訂行動和 Lightning 頁面 | X | |
| Lightning 資料服務 | 快取和共用元件之間的資料 | X | |
| VS 程式碼的 Lightning 設計系統驗證程式 | 根據 SLDS 指導方針驗證標記 | X | X |
| Lightning 頁面範本 | 針對不同的尺寸規格建立 Lightning 頁面 | X | |
| 對應篩選 | 篩選對應、主要 - 詳細資料和階層關係的值 | X | |
| 管理多重貨幣 | 在交易中使用多重貨幣 | X | |
| 傳訊 | 傳送 SMS、Facebook Messenger 或 WhatsApp 訊息 | X | |
| Mobile Publisher | 建立 Lightning 應用程式和 Experience Cloud 網站的行動版本 | X | |
| 行動就緒元件 | 建立在行動體驗中表現良好的元件 | X | |
| 多國語言網站 | 建立網站的不同語言版本 | X | X |
| 通知產生器 | 建立自訂通知以呈現資訊 | X | |
| 路徑 | 引導使用者完成業務流程並慶祝成功 | X | X |
| 平台快取 | 快取資料時改善效能與可靠性 | X | |
| 在 Lightning 應用程式產生器中預覽行動應用程式頁面 | 在行動裝置上預覽記錄和應用程式頁面 | X | |
| 提示 | 警示使用者系統相關問題與更新 | X | |
| 認可徽章 | 認可並慶祝使用者成就 | X | |
| 使用 WDC 辨識 | 贊同技能並表示感謝 | X | |
| 記錄類型 | 個人化業務流程、選項清單值和版面配置 | X | X |
| 聲譽概觀 | 認可參與與Knowledge共用 | X | |
| 限制規則 | 防止使用者存取可能包含不必要資料的記錄 | X | |
| 標準頁面元件 | 瞭解標準 Salesforce Lightning 元件 | X | |
| 翻譯 | 管理全域使用者的翻譯 | X | X |
| 驗證規則 | 儲存之前,確認資料符合指定的標準 | X |
| 資源 | 描述 | 已簡化 | 實用 |
|---|---|---|---|
| 建築師建立表單指南 | 評估表單設計考量事項並選取最佳工具 | X | |
| 針對不同的尺寸規格設定元件 | 設定元件以在桌上型電腦和手機中呈現 | X | |
| 自訂說明內容 | 為您的獨特實作量身打造說明內容 | X | |
| 預設欄位值 | 定義預設、動態或靜態欄位值 | X | |
| 設計原則 | 建立符合最佳作法的使用者介面 | X | X |
| 設計標準範本 | 為您的組織建立設計標準 | X | X |
| 設計測試技能 (Trailhead) | 計畫驗證和測試設計的方法 | X | X |
| 應用程式內回饋意見原則 | 檢閱指導方針以從系統收集回饋意見 | X | X |
| Lightning Design System Android 靜態程式庫 | 使用 Lightning 頁面的外觀和操作建立原生 Android 應用程式 | X | |
| Lightning Design System iOS 靜態程式庫 | 使用 Lightning 頁面的外觀和操作建立原生 iOS 應用程式 | X | |
| 傳訊指導方針 | 傳達相關資訊並建立愉快的時刻 | X | |
| 傳訊類型 | 根據使用者互動瞭解不同的傳訊類型 | X | |
| 瀏覽指導方針 | 協助使用者在頁面之間移動,並在應用程式中定位自己 | X | |
| 網頁無障礙測試 (Trailhead) | 使用自動與手動測試來確保無障礙 | X | X |
| 使用者參與指導方針 | 檢閱上線、採用、協助和學習的原則 | X | X |
可組合系統:
## 分離疑慮
軟體工程和系統結構的一個基本概念,*關注分隔*需要在可分割成模組單位的大型系統內識別各種關注。若要在系統內強大區分關注,則需要在整個系統中為應用程式邏輯和功能建立有意義的單位。較小的單位可讓應用程式傳送與維護小組更輕鬆地瞭解如何和何處進行變更,同時對較大系統造成最少的中斷。較小的單位也可讓您更清楚瞭解處理[技術債務時](/docs/architect/zh-tw/well-architected/guide/intentional#技術債務)要專注的工作方式和位置,並為系統的整體[可讀性](/docs/architect/zh-tw/well-architected/guide/intentional#可讀性)做出貢獻。
您可以透過引導業務能力與管理狀態,在 Salesforce 組織中建立更完善的關注分隔。
### 功能單位
針對 Salesforce 系統,區隔疑慮的最佳方法是套用以業務為導向的觀點,以識別和組織系統內的模組化單位 (或功能)。這與以工程為中心的檢視不同,其會根據其技術功能來識別單位。分隔關注的業務導向透視圖需要根據其為公司和業務使用者提供的服務,在系統中組織程式碼和自訂項目。採取此方法並不意味著忽略系統中冗餘或重複技術功能的潛力。相反地,這表示技術服務會明確對應至對業務而言最終為透明的組織原則。
以業務功能為導向,可協助確保業務分析與探索小組與遞送小組之間的轉移盡可能簡單。如果應用程式產生器不知道其工作單位在何處對應至您的可組合結構,則表示您處於混亂狀態,而非可組合應用程式橫向。公司所需的結束狀態與組織內模組化單位之間不清楚的對應也會增加開發小組或廠商將冗餘功能建立到系統中的可能性。
請考量下列事項以將功能單位引導至業務能力:
- **從待完成的工作開始**。專注於使用者和業務本身的待完成工作 (JTBD)。由 Tony Ulwick 領導,JTBD 方法著重於瞭解人員使用產品或服務嘗試完成的「工作」或「真實目的」。這是比使用者角色相關工作或業務流程中個別步驟更高的抽象層級。例如,如重複檢查和地址驗證等工作可能屬於「建立客戶單一檢視」的較高層級功能。在您清楚瞭解這些高階業務功能後,可以開始將系統的部分對應至這些功能。
- **指向功能,而非報告結構**。業務單位的內部階層並非要完成有意義的功能或工作的 Proxy。您業務的內部階層對流程和小組結構 (不包括預算) 具有重大影響。這些是重要的物流考量事項。但業務的功能需求運作的抽象程度高於物流。如果您要建立一個模組來提供報告結構,而非更高階的函數,請注意,您可能必須採取其他步驟來識別該模組與業務功能之間的關係。
- **重複**。從與公司合作開始,以找出哪些功能可以用於最低可行產品 (MVP)。當您識別功能時,請開始建立該 MVP。當您建立時,請識別您正在建立的功能單位中關鍵的程序、中繼資料和 [事件或訊息](/docs/architect/zh-tw/well-architected/guide/composable#傳訊和事件)。識別任何屬於外部相依性的程序、中繼資料和事件或訊息。隨著設計更具功能的單位,請實作 [API 管理](/docs/architect/zh-tw/well-architected/guide/composable#api-管理)和 [相依性管理](/docs/architect/zh-tw/well-architected/guide/composable#相依性管理),以建立相互相容的單位 (而非建立隔離單位)。
以下的[模式與反模式](/docs/architect/zh-tw/well-architected/guide/composable#關注模式與反模式的分隔)清單顯示 Salesforce 解決方案中對業務功能的正確 (和不良) 方向呈現的外觀。您可以使用這些功能在建立之前驗證您的設計,或識別需要重新設計的系統區域。
若要深入瞭解 Salesforce 提供的工具,以協助您進一步掌握業務功能,請參閱與可編輯功能相關的 [工具](/docs/architect/zh-tw/well-architected/guide/composable#與可編譯相關的工具)。
### 州/省管理
州/省管理專注於整個系統在不同時間點的資訊移動。有效的狀態管理可讓應用程式處理複雜的資料流程或互動,其中最少有非預定或未確定成果。在模組化 Salesforce 組織中管理狀態意味著建立單位內和單位之間邏輯流程的明確路徑,以及針對非預定執行行為建立豐富的路徑。州/省管理可讓您從模組化 Salesforce 應用程式單元中建立一致的邏輯串流。在大多數的情況下,這需要可[互通性](/docs/architect/zh-tw/well-architected/guide/composable#互通性)來建構單位之間的資訊流程。
跨寬鬆連接單位管理狀態的困難通常會導致 Salesforce 中的單一應用程式開發。您可以在大型「單一流程」中看見,這是在嘗試在單一流程中協調複雜流程時建立的。另一個範例是大量 Apex 類別,可透過 *Spaghetti 程式碼*協調複雜程序,或一系列長的單一方法。這些類型的應用程式結構會使重新設定和除錯變得難以執行,並增加新小組成員或廠商的上線時間。它們也會降低提供給業務之應用程式的價值,因為功能無法重複使用。
請考量下列事項來管理整個模組化 Salesforce 組織的狀態:
- **決定何時使用狀態模式與無狀態模式**。狀態模式會在整個執行路徑中保留資訊,無狀態模式則不會。在寬鬆連接的系統中,無狀態模式可讓元件更快速地重新產生,並減少副作用。不過,無狀態模式不適用於所有使用個案。如果您要建立資料作業的元件,則狀態模式有助於確保整個系統的資料完整性和一致性。如果您的元件符合下列任一條件,請使用狀態模式:
- 瞭解在較大執行路徑內的放置位置對元件行為至關重要
- 元件的行為必須根據下游動作的結果變更 (例如,它需要根據下游元件的回復/錯誤/成功訊息變更執行)
- 元件需要等待外部或下游系統的回應,才能完成其工作
- **為狀態資訊建立有意義的種類**。*狀態*是一個不明確的詞彙,可套用至 Salesforce 組織內 (及外部) 中如此深厚且廣泛的資訊陣列,這詞彙本身幾乎沒有意義。因此,建立狀態模式的必要第一步是為系統中最重要的狀態執行路徑 (或狀態行為類型) 建立具有*意義的*種類。考量一些種類:
- 瀏覽與表單
- 資料庫作業
- 批次和大量作業
- 錯誤
- **以資料 [庫交易](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#資料庫操作)定義資料相關狀態**。平台的內建行為會限定 Salesforce 中大多數資料的州考量事項。請勿嘗試對此行為進行管理或排除。為其設計與使用。設計最小化或消除散佈交易邏輯的解決方案。(如需詳細資料,請參閱 [資料處理](/docs/architect/zh-tw/well-architected/guide/automated#資料處理))。
- **識別在 (及跨) 功能單位中發生的狀態**。當您將功能單位組合至較大的系統時,請注意當您混合無狀態與狀態元件行為時,並避免組合可能在處理中產生無限迴圈或間隙。
- **定義轉介**。考慮元件會使用哪些[傳訊或撤銷](/docs/architect/zh-tw/well-architected/guide/composable#傳訊和事件)模式將狀態相關資料傳輸至系統的其他部分。確定您正在建立交易認知並在元件中進行[處理](/docs/architect/zh-tw/well-architected/guide/automated#資料處理)。請勿在您的轉送中包含任何散佈的交易邏輯。
- **建立流程圖與狀態之間的對應**。流程圖詳細說明在不同時間點透過系統移動資訊的步驟。狀態圖顯示資訊 (狀態) 中的實際變更。使用「[Salesforce 圖表」](/docs/architect/zh-tw/reference-diagrams/guide/kit-of-parts) 形狀的中繼資料頁尾部分,在流程的每個步驟之內捕捉資訊的變更狀態。如果您將流程圖與狀態圖分開,請務必將其連結。此概念在設計和實作期間,不應混淆於將流程或系統橫向的目前狀態和未來狀態記錄,因為這與系統中移動的資訊無關。
下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/composable#關注模式與反模式的分隔)清單顯示 Salesforce 解決方案內的適當 (與不良) 狀態管理外觀。您可以在建立之前使用這些項目來驗證您的設計,或識別系統中需要重新設計的位置。
若要深入瞭解用於管理狀態的 Salesforce 工具,請參閱與可編譯相關的 [工具](/docs/architect/zh-tw/well-architected/guide/composable#與可編譯相關的工具)。
### 關注模式與反模式的分隔
下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。
✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/adaptable-separation-of-concerns)探索更多關注分隔的模式。
| 模式 | 防模式 | |
|---|---|---|
| 功能單位 | 在您的設計標準中:
- 命名慣例說明如何標記功能單位 - 存在所有目前定義的功能單位清單 (以及相關命名慣例) - 已存在建議功能單位新增或變更的標準 |
在您的設計標準中:
- 設計標準不存在或不處理功能單位和使用個案 |
| 在您的文件中:
- 系統橫向圖清楚顯示組織中的功能單位 - 所有文件和實作圖表都清楚顯示元件的功能單位 - 個別元件的文件包含元件的功能單位對應 - 功能單位內的所有元件皆可搜尋且易於尋找 |
在您的文件中:
- 元件文件不存在 - 元件文件描述元件所屬的功能單位,但它是該功能單位的定義唯一顯示的位置 - 您無法搜尋特定功能單位,且/或搜尋無法識別功能單位內的所有元件 |
|
| 在您的組織中:
- 可快速識別指定中繼資料的功能單位對齊方式 (例如流程、Apex 類別或 Lightning 頁面) - 功能單位以業務易用的詞彙標記 |
在您的組織中:
- 無法識別任何中繼資料的功能單位對齊方式 - 功能單位資訊不一致或不準確 - 功能單位資訊會以針對業務使用者沒有意義的工程專注詞彙標記 |
|
| 州/省管理 | 在您的設計標準中:
- 狀態與無狀態設計的使用個案很明確 - 無狀態通訊的已批准模式存在 - 存在狀態通訊的已批准模式 - 清除狀態存在的種類 |
在您的設計標準中:
- 設計標準不存在或不處理狀態/無狀態模式和使用個案 |
| 在您的文件中:
- 處理狀態和/或無狀態通訊的每個元件都會指出已實作的模式 - 您可以搜尋並尋找已實作特定州/省模式的所有元件 - 流程與互動圖表提供關於狀態種類和處理的詳細資料 |
在您的文件中:
- 元件文件不存在 - 元件文件描述實作的狀態/無狀態模式,但這是定義唯一顯示的位置 - 無法搜尋特定模式,且/或搜尋無法協助識別使用該模式的所有元件 |
|
| 在 Apex 中: - 儲存點與回復行為會用於所有資料作業 |
在 Apex 中: - 不使用 Savepoints 和回復行為 |
|
| 在流程中: - 使用錯誤路徑和「回復記錄」元素 |
在流程中: - 未使用「回復記錄」元素 |
| 模式 | 防模式 | |
|---|---|---|
| 傳訊和事件 | 在您的設計標準中:
- 使用同步模式 (傳訊) 和非同步模式 (事件) 的時機存在明確的標準 - 事件與訊息結構存在明確的標準 |
在您的設計標準中:
- 設計標準不存在,或缺乏同步與非同步模式的明確標準,以及訊息或事件結構的明確標準 |
| 在您的組織中:
- 會清楚標記用於內部系統傳訊的平台事件 - Salesforce 流程工具參照全系統傳訊或事件服務 - 流程和程式碼中會顯示一致的傳訊和事件模式 |
在您的組織中:
- 用於內部系統傳訊的平台事件未清楚標記或不存在 - 傳訊和事件模式的不同策略會顯示在流程和程式碼之間 |
|
| 在 Apex 或 LWC 中:
- 範圍限制自訂事件定義 (系統範圍的事件或訊息不會以程式碼定義) - Apex 中的全系統傳訊或結束服務會以可在 Salesforce 流程工具中使用的方式註釋 |
在 Apex 或 LWC 中:
- 在 Apex 或 JavaScript 中定義全系統訊息和/或事件結構 - 在 Apex 中定義的全系統事件或訊息結構無法在如流程等工具中使用 |
|
| API 管理 | 在您的設計標準中:
- 已存在可供跨元件通訊 (亦即 API) 的明確通訊協定 - 通訊協定/API 概述在邏輯群組中,讓產生器可以搜尋和尋找 - 通訊協定/API 定義變數資料類型、變數名稱、必要或選用項目,並提供使用時機的明確描述 |
在您的設計標準中:
- 設計標準不存在或不定義 API 和使用個案 |
| 在您的文件中:
- 每個元件的文件會清楚列出已實作的 API/通訊通訊協定 - 您可以搜尋特定的 API 或通訊協定,並識別實作的元件 |
在您的文件中:
- 元件文件不存在 - 元件文件描述在元件內實作的 API,但這是 API 定義唯一顯示的位置 - 無法搜尋特定的 API 或通訊協定,且/或搜尋無法識別已實作 API 或通訊協定的元件 |
|
| 在您的組織中:
- 使用自訂中繼資料類型定義內部通訊的 API 訊息格式和變數 - 透過平台事件定義內部通訊的 API 訊息格式和變數 - 程式碼和陳述式自訂項目會參照適當的自訂中繼資料類型 (或平台事件),以傳送或接收資訊 |
在您的組織中:
- 系統元件之間的通訊 (程式碼和陳述性自訂項目) 為臨時 - API 專為 Salesforce 與外部系統之間的通訊而定義 |
無論您選擇的封裝組織模式為何,都有一些絕對值需要記住:
- **請勿在封裝之間重複中繼資料**。多個封裝所需的中繼資料應摘要為宣告為相依性的一或多個封裝。
- **使用 Salesforce Platform 中繼資料** 的內建相依性。針對應用程式產生器,Salesforce Platform 提供的內建服務提供大量可快速設定的功能。許多服務都有內建的相依性,難以抽象化為低層級的功能單位。針對指定的中繼資料類型,您需要瞭解其在內建相依性[範圍](https://developer.salesforce.com/blogs/2018/06/lets-talk-deployment-and-reasons-why-they-succeed-or-fail)中的所在位置,並使用此瞭解來[定義封裝相依性鏈結](https://developer.salesforce.com/blogs/2018/06/working-with-modular-development-and-unlocked-packages-part-2)。請勿透過嘗試強制將寬鬆連接至具有許多內建相依性的標準平台功能來開始封裝採用。當您達到較高層級的功能時,這會增加複雜度 (非值)。這也是落在 [標準與自訂](/docs/architect/zh-tw/well-architected/guide/intentional#標準與自訂功能) [反模式](/docs/architect/zh-tw/well-architected/guide/intentional#維護模式與反模式)中的另一個方法。從底部 (最少相依性) 封裝中繼資料,並隨著時間迭代。
- **監視您的相依性鏈**。避免建立將需要開發人員一次將變更分割成許多不同封裝的封裝相依性鏈。
- **思考來源控制的意義為何**。在來源控制中管理封裝的方式有兩種基本方式。第一個為單一單一封裝,其中封裝在資料夾內隔離。\_\_第二個為具有封裝隔離在自己儲存庫中的多個儲存庫。長期管理每種類型的來源策略都有複雜性。在開發人員上線方面,垂直邊界在多個存放庫範例中更有效率。水平邊界在單一空間中更容易理解。同樣地,您可以隨著結構成熟而混合與比對策略。
下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/composable#封裝性模式與反模式)清單顯示 Salesforce 封裝的正確 (與不良) 相依性管理外觀。您可以使用這些功能在建立之前驗證您的設計,或識別需要重新設計的系統區域。
若要深入瞭解 Salesforce 用於相依性管理的工具,請參閱與可編譯相關的 [工具](/docs/architect/zh-tw/well-architected/guide/composable#與可編譯相關的工具)。
### 封裝性模式與反模式
下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。
✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/adaptable-packageability)探索更多可封裝的模式。
| 模式 | 防模式 | |
|---|---|---|
| 寬連接器 | 在您的設計標準中:
- 命名慣例說明如何標記封裝單位 - 您可以搜尋並尋找所有目前定義的封裝單位清單 (以及相關的命名慣例) - 已存在建議封裝單位新增或變更的標準 - (選用) 自訂設定的所有已批准使用個案都會清楚列出 (若有) |
在您的設計標準中:
- 設計標準不存在或不處理封裝單位和使用個案 |
| 在您的組織中:
- 自訂中繼資料類型提供程式碼和陳述式自訂的動態執行階段資訊 - 沒有任何自訂設定,或有少數自訂設定,且沒有與封裝功能相關的自訂設定 - 沒有任何自訂物件可提供程式碼或陳述式自訂的動態執行階段資訊 |
在您的組織中:
- 使用自訂設定 - 自訂物件存在以提供動態執行階段資訊,以用於程式碼或陳述式自訂 - 未使用 (或未一致使用) 自訂中繼資料類型來提供動態的程式碼和陳述式自訂資訊 |
|
| 在 Apex 中:
- 使用抽象或虛擬 Apex 類別定義通用服務和板碼 - 根據動態、執行階段資訊參照適當自訂中繼資料類型的方法 |
在 Apex 中:
- 一般服務與锅板代碼與其他類別不易區分 - 類別與方法之間的內部參照難以遵循,且在整個程式碼庫中不一致 - 方法不使用一致的方法來存取動態、執行階段資訊,或方法查詢自訂物件以取得執行階段行為資訊,或程式碼參照自訂設定 |
|
| 在來源控制與開發環境中:
- package.xml 檔案只會顯示在早期階段或概念證明專案資訊清單中 |
在來源控制與開發環境中:
- package.xml 檔案用於控制中繼資料部署 |
|
| 在封裝中:
- 組織相依解除鎖定的封裝僅用於早期階段或概念證明實驗 - 在生產或 Sandbox 中未定義未受管理的封裝 |
在封裝中:
- 所有封裝皆為組織相依的已解除鎖定封裝 - 在生產或 Sandbox 中定義未受管理的封裝 |
|
| 相依性管理 | 在您的設計標準中:
- 已存在宣告相依性的標準 - 已存在導入或修改相依性的標準 |
在您的設計標準中:
- 設計標準不存在或不處理如何宣告相依性 |
| 在來源控制:
- 已解除鎖定的封裝版本使用別名符號 ( 最新版本) 以在 sfdx-project.json 資訊清單中宣告相依性
- 開發人員可以從來源控制建立臨時組織並成功部署封裝中繼資料 |
在來源控制:
- 在 sfdx-project.json 資訊清單中明確宣告解除鎖定的封裝版本 (沒有 最新別名)
- 開發人員無法使用來源控制來成功使用臨時組織 |
|
| 在您的封裝中:
- 封裝之間沒有重複的中繼資料 - 針對封裝開發,所有早期階段開發工作都會在臨時組織中發生 |
在您的封裝中:
- 透過在不同封裝中重複中繼資料來略過相依性 - 早期封裝開發會在開發人員 Sandbox 中發生,或早期封裝開發無法在臨時組織中發生 |
|
| 另請參閱:寬連接器 | ||
| 工具 | 描述 | 分離疑慮 | 互通性 | 可封裝性 |
|---|---|---|---|---|
| Apex REST Web 服務 | 透過 REST 向外部應用程式公開您的 Apex 類別和方法 | X | ||
| Apex SOAP Web 服務 | 透過 SOAP 向外部應用程式公開您的 Apex 類別與方法 | X | ||
| 變更資料取取 | 發佈變更至 Salesforce 記錄 | X | ||
| 自訂中繼資料類型 | 定義可重複使用、可自訂、可封裝的功能 | X | ||
| 裝飾 | 以 API 形式公開函數或內容 | X | X | |
| Dev Hub | 管理臨時組織、第二代封裝和 Einstein 功能。 | X | X | X |
| 一般事件 (舊版)* | 傳送未繫結至 Salesforce 資料變更的自訂事件 | X | ||
| Lightning 資料服務 | 快取和共用元件之間的資料 | X | X | |
| 中繼資料 API | 在 Salesforce 環境之間部署自訂項目 | X | ||
| 中繼資料涵蓋範圍報告 | 決定多個管道的支援中繼資料涵蓋範圍 | X | ||
| MuleSoft Composer | 使用點擊而非程式碼建立資料的流程自動化 | X | ||
| 輸出訊息 | 當欄位值更新時,將訊息傳送至外部端點 | X | ||
| 平台事件 | 傳送安全且可調整的訊息,其中包含近乎即時事件資料 | X | ||
| Pub/Sub API | 訂閱平台事件、變更資料擷取或即時事件監視 | X | ||
| PushTopic 事件 (舊版)* | 傳送和接收符合使用者定義 SOQL 查詢的變更通知 | X | ||
| Salesforce CLI | 使用您的 Salesforce 組織時開發和建立自動化 | X | ||
| Salesforce 圖表 | 建立圖表以顯示業務功能與技術詳細資料 | X | ||
| Visual Studio Code 的 Salesforce 擴充功能 (展開型) | Salesforce 開發的正式 VS 程式碼擴充 | X | ||
| 臨時組織 | 將 Salesforce 程式碼與中繼資料部署至可處理組織 | X | ||
| 第二代受管理封裝 | 開發和散佈 AppExchange 的應用程式 | X | ||
| Tooling API | 建立 Lightning 平台應用程式的自訂開發工具或應用程式 | X | ||
| 解除鎖定的封裝 | 組織中繼資料、封裝應用程式或擴充 AppExchange 應用程式 | X | ||
| *Salesforce 將在目前的功能中繼續支援 PushTopic 和一般事件,但不打算進一步投資此技術。 | ||||
| 資源 | 描述 | 分離疑慮 | 互通性 | 可封裝性 |
|---|---|---|---|---|
| 數位整合的原始觀點 | 針對連線概念開發通用語言 | X | ||
| 使用 Salesforce 套用網域驅動的設計 | 讓您的解決方案與業務功能有關 | X | ||
| 第二代封裝的最佳作法 | 瞭解 2GP 封裝模式與作法 | X | ||
| 受管理封裝中可用的元件 | 瞭解受管理封裝中繼資料元件 | X | ||
| 設計標準範本 | 為您的組織建立設計標準 | X | X | X |
| 事件驅動的結構決策指南 | 比較以事件為導向的結構模式與工具 | X | ||
| 事件反模式 | 識別使用事件時要避免的反模式 | X | ||
| 如何設計訊息驅動和事件驅動的 API | 瞭解 MuleSoft 開發指南中的差異 | X | X | |
| 瞭解待完成工作的架構 | 在 Trailhead 上探索 JTBD | X | ||
| 在 B2C Commerce 中管理全域狀態 | 輕鬆在元件之間傳遞資料以維持狀態 | X | ||
| 傳訊指導方針 | 傳達相關資訊並建立愉快的時刻 | X | ||
| 傳訊類型 | 依使用者互動的性質瞭解不同的傳訊類型 | X | ||
| 中繼資料類型 | 瞭解 Salesforce 組織中不同類型的中繼資料 | X | X | |
| 行動應用程式通知類型 | 瞭解 Salesforce 行動應用程式的通知類型 | X | ||
| 最佳化檢視狀態 | 維護 Visualforce 頁面中的狀態 | X | ||
| Salesforce 開發人員體驗 (DX) | 在 Lightning 平台上管理與開發應用程式 | X | X | X |
| 不支援的中繼資料類型 | 識別中繼資料 API 中無法使用的元件 | X |
| 彈性 | ||
|---|---|---|
| 彈性解決方案能順利處理變更。彈性結構可以以可預測的方式快速返回預期的行為和作業。 | ||
| 應用程式週期管理 | 事件回應 | 連續性規劃 |
| 版本管理 環境策略 測試策略 |
復原時間 能夠分級 監視與警示 |
業務連續性 技術持續性 |
| 可組合 | ||
| 可組合解決方案可快速調整且更穩定。可組合結構內建在相互順暢運作的單位中,且可切換為不在服務中。 | ||
| 關注分隔 | 互通性 | 可封裝性 |
| 功能單位 州/省管理 |
傳訊和事件 API 管理 |
寬鬆配對 相依性管理 |
| 觸發分類/類型 | 緩解 |
|---|---|
| 人員 | 原則 |
| 程序 | 手冊、連續性計畫 |
| 技術 | 冗餘 |
| 觸發 | 緩解 | 基本 | 中繼 | 成熟 |
|---|---|---|---|---|
| 新增或離開員工的使用者存取權變更 | 服務層級契約 (SLA) 和佈建或取消佈建使用者的需求 | 根據 SLA 手動佈建和取消佈建使用者以進行手動變更。 | 根據 SLA 的排程變更,透過排程工作處理使用者變更。 | 透過 SSO/IDM 解決方案自動化使用者佈建和取消佈建。 |
| 模式 | 防模式 | |
|---|---|---|
| 風險管理 | 在您的業務中:
- 已建立的風險評估架構正在使用中。 - 風險會分類為人員、流程和技術領域。 |
在您的業務中:
- Salesforce 的風險評估架構為臨時。 - 未清楚識別風險。 |
| 在您的文件中:
- 系統會根據客戶影響來分類和評估風險嚴重性。 - 降低風險和回應計畫的優先順序。 |
在您的文件中:
- 評估風險嚴重性或種類時,不會考量客戶觀點。 - 風險降低和回應計畫會嘗試捕捉所有可想像的風險。 |
|
| 失敗緩解 | 在您的組織中:
- 失敗點觸發及其對應的緩解計畫會依人員、程序和技術分類。 - 緩解控制會立即生效、隨著時間成熟,並盡早納入自動化。 - 為了確保最佳的延展性,在將變更發佈至生產環境之前,會完成全方位測試和最佳化。 - 在業務關鍵事件之前,根據 SLA 執行規模測試和最佳化。 |
在您的組織中:
- 無法分類失敗點數的觸發。緩解措施不存在或僅臨時使用。 - 不會重新檢視或改善緩解控制。 - 自動化未用於緩解問題。 |
| 監視與可觀察性 | 在您的組織中:
- 針對檢查和異常偵測,已啟用「Proactive Monitoring」。 - 為了持續可視性,Proactive Monitoring 警示會與「規模中心」整合。 |
在您的組織中:
- 只會執行手動健康檢查,且不會進行持續監控。 |
| 模式 | 防模式 | |
|---|---|---|
| 輸送量 | 在您的設計標準中:
- 如何使用平台快取的指引遵循 平台快取最佳作法 |
在您的設計標準中:
- 如果有平台快取使用指引,則其不明確或不符合最佳作法。 |
| 在您的組織中:
- 大量化用於資料和系統作業。 - DML 或資料庫方法一律會對應 Apex 中的集合。 - 資料庫中 DML 期間用於較短 elapsedTime 的欄位受到限制。 - 所有萬用字元條件都會用於 SOSL。 - SOQL 陳述式為選擇性。 -- 他們不使用 LIKE 比較或部分文字比較。 -- 比較運算子會使用正數邏輯 (換句話說,INCLUDES 或 IN) 作為其主要邏輯或僅限邏輯。 -- = NULL 和 != NULL 用於使用時,很少一律遵循正比較運算子。 – 為了儘量減少資料載入並發揮最大效能,系統只會在 SOQL 查詢中提取所需的欄位。 -- 未使用 LIMIT 1 陳述式。 -- 不使用「所有列」關鍵字。 - 盡可能偏好非同步處理。 - 已設定平台快取分割。 |
在您的組織中:
- DML 陳述式未大量處理。 - DML 或資料庫方法會對應 Apex 中的單一記錄。 - SOSL 並不常用於萬用字元選取條件。 - SOQL 陳述式為非選擇性: -- 其中包含 LIKE 與萬用字元篩選條件。 -- 使用 !=、NOT 或 NOT IN 條件的比較會作為主要或唯一比較運算子使用。 -- 使用 = NULL 和 != NULL 條件作為主要或唯一比較運算子。 -- 使用 LIMIT 1 陳述式。 -- 使用 ALL ROWS 關鍵字。 - SOQL 會顯示在迴圈內。 - 偏好同步程序。 |
|
| 延遲 | 在您的組織中:
- 報告用於單一特定目的,且包含決策所需的最少列數與欄數。 - 篩選條件使用「equals」和「not equal to」。 - 篩選條件不包含公式欄位。 - 共用模式會盡可能簡化。 - 自訂 UI 元件使用 Lightning Web 元件 (LWC)。 - LWC 使用 Lightning Data Service 進行資料作業。 - 在 JavaScript 的用戶端處理排序和篩選清單資料。 - Salesforce Edge 已啟用。 |
在您的組織中:
- 報告可用於多種用途,或包含決策不需要的額外列與欄。 - 篩選條件使用「contains」和「does not contain」。 - 篩選條件包含公式欄位。 - 共用模式很複雜。 - 自訂 UI 元件使用的架構可能會導致呈現效率低於 LWC (例如 Aura 或 Visualforce)。 - LWC 使用 Apex 進行資料作業。 - 使用 Apex 在伺服器端處理排序和篩選清單資料。 - Salesforce Edge 未啟用。 |
| 模式 | 防模式 | |
|---|---|---|
| 資料建模 | 在您的設計標準中:
- 商業理由保證自訂物件存在的標準和指引。 |
在您的設計標準中:
- 沒有建立自訂物件的標準存在。 |
| 在資料模型中:
- 盡可能使用標準物件。 - ApexGuru 檢查是否有防模式,確認 SOQL 查詢是選擇性的,並避免結構描述使用效率低下。 - 表格會針對刻度反正規化。 |
在資料模型中:
- 您已複製標準物件。 - 表格已正規化以避免冗餘。 |
|
| 在您的業務中:
- 低程式碼產生器會瞭解 Salesforce 支援的不同欄位類型,並在選取欄位資料類型之前評估報告和加密需求。 - 決定在物件之間建立「主要 - 詳細資料」關係之前,請評估該關係的共用與資料誤差影響。 |
在您的業務中:
- 低程式碼產生器會選取資料類型,而無須評估下游報告和加密需求。 - 決定在物件之間建立「主要 - 詳細資料」關係之前,請勿評估該關係的共用與資料誤差影響。 |
|
| 資料量 | 在您的資料中:
- 沒有父系記錄具有超過 10,000 個子系記錄。 - 未將使用者指派給相同物件類型的超過 10,000 個記錄。 - 沒有例項包含指向相同記錄的對應欄位超過 10,000 個記錄。 - 大量資料載入會根據 ParentId 欄位值排序為批次。 - 為了確保批次策略不會同時損毀,規模測試用於驗證生產規模的大量負載模式。 - 大量資料載入至生產環境不會在營業時間高峰期間發生。 - 大量資料載入僅包含業務決策所需的最小資料。 |
在您的資料中:
- 存在超過 10,000 個子系記錄的記錄。 - 系統會將使用者指派給相同類型的超過 10,000 個記錄。 - 存在超過 10,000 筆記錄具有指向相同記錄之對應欄位的例項。 - 大量資料載入不會根據 ParentId 欄位值進行批次排序。 - 大量資料載入至生產環境會在營業時間高峰期間發生。 - 大量資料載入不限於業務決策所需的最少資料。 |
| 在流程與 Apex 中:
- 在資料誤差有疑慮的情況下,邏輯存在於跨多個父系記錄散佈子系記錄數目。 - 當透過整合匯入或複製記錄時,邏輯會將記錄指派給適當的人類使用者。 - 針對 Apex 集合 (例如清單和集),存在處理多個記錄的邏輯,以將查詢最小化並最佳化資料處理。 - 撰寫和部署符合可調整程式碼標準和最佳作法的有效 Apex 程式碼。 |
在流程與 Apex 中:
- 無論已指派的子系記錄數目為何,子系記錄都會隨意指派給父系記錄。 - 透過資料載入或整合建立的記錄會指派給一般「整合使用者」。 - 來自相同物件的多個遞迴 SOQL 查詢在同步交易中,進而造成高堆疊使用量。 - 開發人員撰寫 Apex 程式碼時,會導入效率低下和效能反模式。 |
|
| 在您的業務中:
- 您已記錄並實作資料歸檔和清除策略 |
在您的業務中:
- 您沒有資料歸檔和清除策略,或者您的策略已記錄但未實作 |
| 工具 | 描述 | 可用性 | 績效 | 延展性 |
|---|---|---|---|---|
| 大型物件 | 在平台上儲存及管理大量資料。 | X | ||
| 程式碼掃描器 | 掃描 Apex 程式碼以瞭解效能問題。 | X | ||
| 自訂索引 | 使用自訂索引改善查詢效能。 | X | ||
| 刪除資料 | 移除不需要的資料以改善效能。 | X | X | |
| 分部 | 分割資料以限制查詢和報告中的記錄數。 | X | ||
| 規模測試 | 測試系統效能並解譯結果。部署至生產環境之前,若要驗證延展性和效能,請使用 Playwright 或 JMeter 指令檔模擬大規模的 UI 和 API 工作量。 | X | X | |
| 規模中心 | 取得有關系統效能的自助式服務和即時洞察。尋找長時間執行的交易、例外熱點和輸出瓶頸。在開發週期中稍早診斷規模問題。 | X | X | |
| ApexGuru | 在「刻度中心」中使用此以 GenAI 為基礎的功能,以在執行階段偵測 Apex、SOQL 和測試類別的反模式。透過 ApexGuru 與 Salesforce Code Analyzer 的整合,在開發工作流程中取得 AI 強化的建議和內嵌修正。使用這些建議和修正程式可解決熱點,並改善查詢選擇性、大量處理、快取用量和測試品質。 | X | X | |
| Salesforce 程式碼分析器 | 使用 IDE、CLI 或 CI/CD 掃描程式碼,以確保程式碼符合最佳作法。透過 Salesforce Code Analyzer 與 ApexGuru 的整合,直接在開發人員工作流程中取得效能反模式的相關洞察。 | X | ||
| Salesforce Edge 網路 | 透過 Salesforce Edge 網路路由您的 我的網域,以改善下載時間和使用者體驗。 | X | ||
| Skinny 表格 | 避免在經常使用欄位的表格上加入。 | X | ||
| 主動監視 | 持續監視記錄成長、擁有權偏差和效能迴歸的異常。在規模問題變為嚴重之前警示。 | X | X |
| 資源 | 描述 | 可用性 | 績效 | 延展性 |
|---|---|---|---|---|
| 規模化挑戰需要數百萬美元 — 以下是如何讓業務展望未來 | 探索實作延展性如何促成永續成長和長期成功。 | X | X | |
| 使用「規模中心」建立及部署可調整應用程式 | 瞭解如何主動評估並解決 Salesforce 實作中的效能問題。 | |||
| 分析複雜 Salesforce 應用程式中的效能與規模熱點 | 處理您組織中的效能與延展性問題。 | X | X | |
| 應用程式不應在熱門時段的流量中驚慌 - 準備方式如下 | 瞭解成功規模測試的四個關鍵步驟。 | |||
| 已解釋 ApexGuru AI 引擎 | 瞭解 ApexGuru 如何使用自訂訓練的模型、實際組織遙測和智慧篩選,以提供精確、內容相關且可運作的洞察。 | X | X | |
| 使用 ApexGuru 最佳化應用程式和 Agentforce 的 Apex | 瞭解 ApexGuru 如何協助開發人員偵測和修正效能反模式,包括 SOQL、DML、除錯和測試效率不佳。使用 ApexGuru 作為 AI 技術支援的教練,以擴充應用程式的開發和 Agentforce 的實作。 | X | X | |
| ApexGuru 反模式 | 從 ApexGuru 偵測到的反模式官方文件庫中學習,此文件庫會針對每個主要 Salesforce 版本更新。 | X | X | |
| 使用大量資料進行部署的最佳作法 | 瞭解大量資料的流程影響。 | X | ||
| Salesforce Edge 網路的 考量事項 | 瞭解如何讓您的組織準備好使用 Salesforce Edge 網路。 | X | ||
| 設計標準範本 | 為您的組織建立設計標準。 | X | X | X |
| 資料模型設計考量事項 | 最佳化規模與維護的資料模型。 | X | X | |
| 針對企業規模設計記錄存取權 | 透過組態最佳化存取控制效能。 | X | ||
| 具有大量資料系統的基礎結構 | 瞭解支援大型資料部署之系統效能的功能。 | X | ||
| 批次管理的學習資源 | 瞭解批次管理。 | X | X | |
| Lightning Experience 效能最佳化 | 改善您組織中的 Lightning Experience 以協助您的使用者加速工作。 | X | ||
| 在 Salesforce 中管理對應誤差以避免記錄鎖定例外 | 瞭解如何將對應誤差的影響降到最低。 | X | X | |
| SOQL 與 SOSL 最佳作法 | 針對具有大量資料的部署,遵循 SOQL 與 SOSL 最佳作法。 | X | X | |
| 大規模重新對齊方式的工具 | 有效率地計畫並執行重新對齊。 | X | ||
| 使用遮蔽 | 在不同的應用程式中維護大型資料集。 | X | X |
| 模式 | 防模式 | |
|---|---|---|
| 資料隱私權 | 在您的文件中:
- 您擁有包含欄位層級名稱、描述和分類的最新資料字典 - 您擁有可識別哪些使用者可存取哪些資料的最新安全性矩陣 - 您擁有最新的設計文件,包括針對建立以滿足法規需求的任何自動化的標準和圖表 |
在您的文件中:
- 資料字典不存在或尚未保持最新狀態 - 共用與可視性文件不存在或尚未保持最新狀態 - 針對解決法規需求的自動化設計標準、圖表和文件不存在或尚未保持最新狀態 |
| 在您的組織中:
- 所有包含敏感資訊或受資料隱私權法規約束的物件和欄位都已設定「合規性種類」、「資料擁有者」、「資料敏感度等級」和「欄位用量」 |
在您的組織中:
- 包含敏感資訊或受資料隱私權法規約束的物件和欄位缺少「合規性種類」、「資料擁有者」、「資料敏感度等級」或「欄位用量」的組態 |
|
| 本地化 | 在您的文件中:
- 您擁有概述資料儲存和維護位置的組織策略,以符合所有適用的資料落地需求 - 您擁有整合策略,此策略概述跨境複製資料的可接受案例與流程 - 您擁有概述報告和顯示面板在區域、國家和全球層級可包含的細微性層級分析策略 |
在您的文件中:
- 您沒有組織策略,或者您的組織策略未滿足資料當地語系化與落地需求 - 您沒有整合策略,或者您的整合策略未滿足資料當地語系化與落地需求 - 您沒有分析策略,或者您的分析策略未滿足資料當地語系化與落地需求 |
| 模式 | 防模式 | |
|---|---|---|
| 公司原則 | 在您的設計標準中:
- 標準包含受到公司原則影響之區域的明確指引 |
在您的設計標準中:
- 設計標準不存在或不提供關於受公司原則約束之區域的明確指引 |
| 在您的文件中:
- 組態和自訂的文件包含對支援公司值的參照 |
在您的文件中:
- 組態和自訂的文件未參照公司值或原則 |
|
| 在您的組織中:
- 所有受公司原則相關合規性的物件和欄位都已設定「合規性種類」、「資料擁有者」、「資料敏感度等級」和「欄位用量」 |
在您的組織中:
- 物件及受公司原則相關合規性的物件缺少「合規性種類」、「資料擁有者」、「資料敏感度等級」或「欄位用量」的組態 |
|
| 人工智慧 | 在您的設計標準中:
- AI 應用程式的原則和已批准使用個案清楚且容易找到 - 確保用於 RAG 的資料和文件具有代表性、完整、準確且處於最新狀態。尋找可能存在於資料集或文件中的偏差、有毒和其他有害內容 - 生成回應一律識別 AI 模型所使用的資料來源 - 已記錄可/無法用於提示工程的資料集 - 使用者可以清楚識別機器人和生成式 AI 回應 - 清楚定義生成式 AI 何時及如何使用免責聲明的標準 - 清楚說明如何記錄存在 AI 解決方案設計中人類參與點的需求 - 已存在記錄 AI 解決方案設計中直接與間接回饋意見路徑的標準 - 清楚定義使用者必須識別 AI 的點數 - 管理人類,特別是在受監管或高風險使用個案中 |
在您的設計標準中:
- 設計標準不存在或不包含 AI 應用程式的明確原則和已批准使用個案 - 生成回應不會識別 AI 模型使用的資料來源 - 未記錄用於提示工程的資料集 - 使用者無法識別機器人和生成式 AI 回應 - 遺失有關生成回應的免責聲明 - 不存在記錄 AI 解決方案設計中人類參與點的需求 - 不存在記錄 AI 解決方案設計直接與間接回饋意見路徑的標準 - 設計標準無法指出必須向使用者識別 AI 的點 |
| 在您的文件中:
- 涉及 AI 功能的組態和自訂文件包含所有程序邏輯的完整描述,並儲存在由法律小組或稽核員可存取的集中位置中 - 您建立或帶入 Salesforce 的模型會清楚記錄,包括任何適用的資料區段 - 系統會完整記錄對話邏輯和工作人員對話 - 已有程序可監視您組織的 AI 模型,以瞭解資料漂移、公平性和偏差分數的變更、準確性和穩定性 - 系統會針對用於所有 AI 流程的訓練、評估和測試資料維護描述 - 系統會維護任何 AI 相關資料清除的描述,以及偏差測試、相關聯的結果和效能/準確度分數 (例如 F1 分數) |
在您的文件中:
- 涉及 AI 功能的組態和自訂文件遺失、不完整或儲存在無法存取的位置 - 在您的組織中實作 AI 模型或系統時,沒有其模型的文件 - 在您的組織中實作工作人員,沒有訊息和交談流程的文件 - 不存在或未記錄 AI 監視流程 - 關於所有 AI 流程所使用訓練、評估和測試資料的資訊不明確或無法使用 - 有關 AI 相關資料清除、偏差測試和結果的資訊不明確或無法使用 |
| 模式 | 防模式 | |
|---|---|---|
| 資料項目 | 在您的設計標準中:
- 會列出標準鍵盤與滑鼠以外可用於資料輸入的所有裝置 - 系統會列出文字值及其所有支援語言的翻譯 |
在您的設計標準中:
- 僅列出可用於在標準鍵盤與滑鼠以外輸入資料的部分裝置,或未列出任何裝置 - 系統會列出支援的語言以及要翻譯的 UI 元素 |
| 在測試計畫中:
- 測試步驟包括使用多種類型的輸入裝置來輸入資料 - 測試步驟包含多國語言的資料輸入 |
在測試計畫中:
- 不包含無障礙測試,或針對無障礙資料項目進行臨時測試 |
|
| 在您的組織中:
- 支援語言的翻譯會儲存在翻譯工作台中 |
在您的組織中:
- 翻譯會儲存在自訂標籤中 |
|
| 瀏覽 | 在您的設計標準中:
- 會清楚列出可用於瀏覽的所有裝置 (不只是標準鍵盤與滑鼠) - UI/UX 標準指定所有瀏覽控制項的類型和樣式 - 系統會清楚列出批准傳達意義或狀態的視覺提示類型,且色彩不是主要提示 |
在您的設計標準中:
- 設計標準不存在或不考慮瀏覽控制項的無障礙需求 - 瀏覽的 UI/UX 標準不一致 - 意義或狀態的視覺提示依賴色彩,或者沒有明確的視覺提示清單供產生器使用 |
| 在測試計畫中:
- 測試步驟包括使用多種類型的輸入裝置來瀏覽 - 測試計畫包括使用 UI/UX 測試以確保一致的瀏覽路徑 |
在測試計畫中:
- 不包含無障礙測試,或臨時執行無障礙瀏覽的測試 |
| 工具 | 描述 | 法律符合度 | 道德標準 | 無障礙 |
|---|---|---|---|---|
| Agentforce Analytics | 深入瞭解工作人員的表現 | X | ||
| Agentforce 測試中心 | 執行最多 10 個測試工作,每個測試最多 1,000 個測試個案,因此您可以快速建立和評估多個案例。 | X | ||
| 引文 | 引號可協助您識別產生回應中潛在的錯誤或幻覺,進而提高使用 AI 工具的信心。 | X | ||
| 同意 API | 追蹤客戶同意偏好設定 | X | ||
| 同意事件串流 | 針對同意或連絡人資訊的變更傳送通知 | X | ||
| 同意管理物件 | 管理客戶隱私權與同意偏好設定 | X | ||
| 資料存取與可攜性 | 依要求匯出客戶相關資料 | X | ||
| 資料分類 | 記錄物件欄位的金鑰合規性與稽核資訊 | X | ||
| Data 360 報告 | 監視工作人員指示的符合度 | X | ||
| 資料刪除 | 刪除資料以遵循法律法規 | X | ||
| 資料隱私權偏好設定 | 儲存客戶資料隱私權偏好設定 | X | X | |
| 資料翻譯 | 翻譯呈現給使用者的資料 | X | X | |
| 資料偵測 | 將種類和敏感度層級與實際資料保持一致 | X | ||
| Data 360 探索器 | 管理資料科學家的專案和物件權限 | X | X | |
| Einstein Data Prisma | Salesforce 中生成式 AI 應用程式的奠基解決方案,可改善使用其奠基功能的 AI 解決方案準確度 | X | ||
| Einstein Trust 圖層 | 專為保護資料隱私權、增強 AI 準確性,以及促進在整個 Salesforce 生態系統中負責使用 AI 的功能、流程和原則集合 | X | ||
| 增強型事件記錄 | 事件記錄會在工作人員工作階段中的事件和使用者訊息中,以檢閱「指示符合度」、測試和疑難排解您的工作人員。 | X | ||
| Files Connect | 從 Salesforce 瀏覽、搜尋和共用外部檔案 | X | ||
| Hyperforce | 遵循本機資料儲存空間需求 | X | ||
| 中繼資料翻譯 | 翻譯語言以本地化應用程式 | X | X | |
| 可攜性 API | 編譯可攜性原則中識別的客戶資料 | X | X | |
| 偏好設定中心 | 收集客戶通訊偏好設定 | X | X | |
| 隱私權中心 | 滿足客戶要求與資料隱私權法律 | X | X | |
| 限制資料處理 | 限制個人資料處理方法 | X | X | |
| 被遺忘權 | 根據要求刪除個別客戶資料 | X | ||
| Salesforce 檔案 | 以私人方式共用與儲存檔案 | X | ||
| Security Center | 檢視多個組織的安全性和隱私權設定 | X | ||
| Shield Platform Encryption | 加密靜態與傳輸中的資料 | X | ||
| 翻譯工作台 | 維護中繼資料和資料標籤的已翻譯值 | X | X |
| 資源 | 描述 | 法律符合度 | 道德標準 | 無障礙 |
|---|---|---|---|---|
| 負責任 AI 設計的 5 個原則 | 以道德的方式設計人工智慧 (AI) 功能 | X | ||
| 無障礙基本概念 (Trailhead) | 瞭解無障礙為何重要 | X | ||
| 無障礙合規報告 (ACR) | 瞭解 Salesforce 如何符合無障礙標準 | X | ||
| 無障礙概觀 | 瞭解 Salesforce Lightning 中的無障礙功能 | X | ||
| AI 道德成熟度模型 | 開發藍圖以操作道德原則 | X | ||
| AI Red Teaming:Trust 的測試 | 瞭解 Salesforce 的「道德駭客」如何透過紅色團隊來開發「負責 AI」。 | X | ||
| 自動化對手:為 Red Teaming AI 設計可調整架構 | 瞭解 Salesforce 如何自動化對手提示產生和回應驗證,Fuzzai 可協助保護 AI 互動的安全,同時減少人類對有害內容的曝光。 | X | ||
| 對話設計的最佳作法 | 設計聊天機器人時遵循最佳作法 | X | X | |
| 永續設計的最佳作法 (Trailhead) | 將永續性納入您的設計中 | X | ||
| 同意管理 | 追蹤並遵循同意與選擇退出要求 | X | ||
| Einstein 的資料原則 | 控制 Einstein 功能中的資料使用 | X | X | |
| 設計標準範本 | 為您的組織建立設計標準 | X | X | X |
| 道德黑客作法證明成功建立信任的 AI 產品 | 瞭解 Salesforce 如何使用 紅色團隊作法來透過測試惡意使用、有意的完整性攻擊、良性濫用,以及識別負責的 AI 問題來改善 AI 產品的安全性。 | X | ||
| 道德領導與業務 | 技術、平等與道德的洞察 | X | ||
| 道德使用原則 | 探索有關合乎道德使用產品與服務的 Salesforce 原則 | X | ||
| 依設計的道德 (Trailhead) | 將道德設計納入技術開發 | X | ||
| 探索 Salesforce 的文化與價值 (Trailhead) | 探索 Salesforce 的核心值 | X | X | |
| 遵循無障礙行動設計指導方針 | 遵循最佳作法讓您的設計可供存取 | X | X | |
| 開始使用網路無障礙功能 (Trailhead) | 瞭解如何讓網站和應用程式可供存取的基本概念 | X | ||
| Salesforce 如何建立可複製的 Red Teaming 基礎結構 | 設計、實作和執行敵對測試時建議的四個元件 | X | ||
| 如何執行後續掃描工作坊 | 考量創新時的所有可能成果 | X | ||
| 實作資料保護與隱私權 | 評估資料保護與隱私權需求 | X | ||
| 包容式設計 (Trailhead) | 透過包容式設計原則促進創新 | X | X | |
| KPI 試算表範本 | 設定您組織的主要績效指標 (KPI) | X | ||
| 法律資訊 | 探索 Salesforce 的法律資訊中心 | X | ||
| LWC Cookie 同意模組 | 在 Experience Cloud 網站中控制使用者 Cookie 存取權 | X | X | |
| 隱私概觀 | 依區域和產業瞭解資料隱私權 | X | ||
| 促進負責且有道德的工作人員 | 瞭解如何實作道德紅組和測試策略,並為您的組織開發指導原則和標準。 | X | ||
| 負責工作人員 AI 指導方針 | X | |||
| 負責建立 AI Trailhead 模組 | 瞭解如何從您的資料和演算法中移除偏差,以建立貴公司的道德 AI 系統。 | X | ||
| 負責生成式 AI 指導方針 | 我們建立了我們的信任 AI 原則,並使用一組新的指導方針,專注於負責任開發和實作生成式 AI。 | X | ||
| Salesforce 合規性認證 | 檢閱 Salesforce 的合規性認證和證明 | X | ||
| 永續設計 (Trailhead) | 強化公司與社會之間的關係 | X | ||
| 網頁無障礙測試 (Trailhead) | 使用自動與手動測試來確保無障礙 | X | ||
| 信任的工作人員 AI | 瞭解 Agentforce 如何使用保護措施和負責 AI 原則來建立道德 AI。 | x |
| 模式 | 防模式 | |
|---|---|---|
| 驗證 | 在您的設計標準和文件中:
- 已批准的安全性角色已清楚定義並列出 - 在安全性矩陣中存在的安全性角色與允許的驗證結構描述 (UI、API) 之間的對應 |
如果存在設計標準和文件,則會:
- 不包含安全性角色 - 請勿包含安全性角色和允許驗證方式的安全性矩陣與清楚對應 |
| 在您的組織中:
- 登入組態符合 Salesforce MFA 檢查 - 登入 Salesforce 的使用者與實體之間的關係為 1:1 (無共用使用者) - API 存取控制可防止使用者透過未經授權的連線應用程式進行驗證 - 如果 SSO 已啟用,則批准的管理員使用者擁有直接登入存取權 |
在您的組織中:
- 登入組態不符合 Salesforce MFA 檢查 - 登入 Salesforce 的使用者與實體之間的關係不是 1:1 (共有使用者帳戶) - 如果使用者從防火牆後面存取 Salesforce,防火牆會使用硬式編碼 IP 位址來保護對 Salesforce 的通訊。 - 未啟用「API 存取控制」 - 如果 SSO 已啟用,則沒有任何經批准的管理員使用者擁有直接登入存取權 |
|
| 在 LWC 中,Apex,Aura:
- 執行驗證的方法會使用已命名認證來處理使用者名稱/密碼流程 - 使用者名稱或密碼不會以可讀的程式碼顯示 (沒有硬式編碼值或字串) - 如果存在自訂登入流程,則所有相關的自訂程式碼都會使用適當的 SessionManagement 方法 |
在 LWC 中,Apex,Aura:
- 驗證為臨時處理 - 使用者名稱和密碼會顯示在程式碼中 |
|
| 授權 | 在您的設計標準和文件中:
- 擁有 Salesforce 存取權的每個使用者和系統都會對應至安全性矩陣中的一或多個角色 - 安全性矩陣會清楚列出中繼資料權限和指派的使用者角色 - 會清楚列出授與增強權限的使用個案,包括: -- 修改所有資料權限 -- 檢視所有資料權限 |
如果存在設計標準和文件,則會:
- 不包含安全性矩陣 - 未清楚列出權限 - 請勿清楚列出授與增強權限的使用個案 |
| 在您的組織中:
- 權限集和權限集群組用於控制中繼資料的存取權 - 符合業務功能的權限集和權限集群組 - 指派給使用者遵循安全性矩陣定義的權限 - 設定檔最少使用,僅用於控制登入 IP 範圍和登入時間 - 針對每個整合設定唯一的僅 API 整合使用者 |
在您的組織中:
- 權限集群組未設定為允許根據業務功能存取 - 權限集已臨時設定 - 權限集是冗餘的或重複的;難以瞭解清晰的功能邏輯和設定之間的差異 - 指派給使用者的權限不會遵循安全性矩陣定義 - 設定檔包含中繼資料的存取控制 - 僅 API 使用者未設定或在多個整合之間共用 |
|
| 在 Apex 中:
- 資料庫作業會適當執行欄位和物件級存取檢查,包括: -- DML 與資料庫 DML 陳述式宣告資料作業 AND/OR 的 使用者或系統模式 -- DML 與資料庫 DML 陳述式在資料作業之前使用 stripInaccessible 方法
-- SOQL 和 SOSL 陳述式使用 具有 USER_MODE 和 具有 SYSTEM_MODE 關鍵字 AND/OR
-- stripInaccessible 方法用於篩選查詢和子查詢結果
-- sObject 描述結果方法 (亦即 isAccessible、isCreateable、isUpdateable 和/或 isDeletable) 會很少使用 |
在 Apex 中:
- 在預設系統模式中執行 DML、資料庫類別方法、SOQL 和 SOSL - 資料庫作業無法適當執行存取檢查,包括: -- DML 或資料庫類別方法僅使用 isAccessible、isCreateable、isUpdateable 和/或 isDeletable 檢查以取得 sObject 和欄位級存取權
-- SOQL 查詢只會將 SECURITY_ENFORCED 關鍵字用於存取限制 |
|
| 在流程中(流程設計的安全性考量事項):
- 流程會使用盡可能嚴格的「執行內容」,理想是使用者模式 - 子流程執行安全性敏感或特權資料存取,以將執行內容最小化 - 限制在記錄觸發流程中執行的邏輯 - 驗證流程輸入,以確保只會將允許的裝載傳遞為輸入 |
在流程中:
- 流程會在「系統模式」或「不共用的系統模式」中執行,無論流程執行的動作為何 - 所有流程邏輯都會在單一的大型流程中執行 - 未驗證流程輸入,且會在未驗證的情況下傳送給消費者 |
| 模式 | 防模式 | |
|---|---|---|
| 工作階段管理 | 在您的設計標準和文件中:
- 安全性角色會清楚列出每個角色已批准的工作階段類型與逾時/持續時間設定 - 已指定登入時間 (或識別為非必要) - 需要高度工作階段級安全性或權限的作業會清楚且可探索 - 連線應用程式範圍和權杖管理原則清楚且可探索 |
在您的設計標準和文件中:
- 安全性角色不存在或缺少工作階段類型和逾時/持續時間設定的相關資訊 - 安全性原則不包含連線應用程式範圍或權杖管理的相關資訊 |
| 在您的組織中:
- 工作階段稽核顯示使用者僅透過預期的工作階段類型存取 Salesforce - 有「僅 API 使用者」存取權的明確且已啟用權限集 (且「僅 API」權限集為 TRUE),且已指派所有整合與自動化使用者 - 如果使用者從防火牆後方存取 Salesforce,防火牆會使用所需網域的允許清單,而非 IP 位址,以保護對 Salesforce 的通訊安全。 - 未啟用工作階段逾時間隔不超過預設值 (2 小時) - 已啟用下列所有設定: -- 「設定」頁面的點閱綁架保護 -- 非「設定」Salesforce 頁面的點閱綁架保護 -- 跨網站要求偽造 (CSRF) 保護 -- 跨網站指令檔 (XSS) 保護 -- 啟用內容探查保護 -- 查閱者 URL 保護 -- 在使用者重新導向至 Salesforce 之外之前警告使用者 |
在您的組織中:
- 沒有一般工作階段稽核 - 沒有使用者應擁有的工作階段類型定義 - 「僅 API」權限不明確或缺少於整合與自動化使用者 - 如果使用者從防火牆後面存取 Salesforce,防火牆會使用硬式編碼 IP 位址來保護對 Salesforce 的通訊。 - 未啟用工作階段逾時間隔超出預設值 (2 小時) - 停用下列任一設定: -- 「設定」頁面的點閱綁架保護 -- 非「設定」Salesforce 頁面的點閱綁架保護 -- 跨網站要求偽造 (CSRF) 保護 -- 跨網站指令檔 (XSS) 保護 -- 啟用內容探查保護 -- 查閱者 URL 保護 -- 在使用者重新導向至 Salesforce 之外之前警告使用者 |
|
| 在 LWC 中,Apex,Aura:
- 如果存在自訂登入流程,所有相關的自訂程式碼都會使用適當的 SessionManagement 方法來指派工作階段級安全性 |
在 LWC 中,Apex,Aura:
- 如果存在自訂登入流程,則沒有指派工作階段層級安全性的邏輯 |
|
| 裝置存取權 | 在您的設計標準和文件中:
- 裝置原則清楚且可探索 - 安全性角色會清楚對應至適當的裝置用量與原則 |
在您的設計標準和文件中:
- 安全性原則不存在或不包含裝置存取的相關資訊 |
| 在您的組織中:
- 閒置後,Salesforce 行動連線應用程式組態需要 PIN/密碼解除鎖定 - 如果業務需求需要嚴格控制可存取 Salesforce 行動裝置的使用者,則會啟用「API 存取控制」,並將權限集指派給 Salesforce 行動應用程式的所有使用者 |
在您的組織中:
- 未將 Salesforce 行動連線應用程式設定為需要 PIN/密碼解除鎖定以進行閒置 – 業務需求需要嚴格控制可存取 Salesforce 行動裝置的使用者,但未啟用「API 存取控制」或無法使用權限集來控制對 Salesforce 行動應用程式的存取權 |
|
| 威脅偵測和回應 | 在您的設計標準和文件中:
- 安全性原則包含應觸發回應的事件清單以及適當的回應類型 - 已為資料模型中的所有物件指定稽核層級 - 系統會記錄檢閱 Salesforce 中可用記錄的步驟 - 系統會清楚記錄所有自動回應 |
在您的設計標準和文件中:
- 安全性原則不存在或不包含威脅偵測和警示的相關資訊 - 自動回應的文件不存在或不明確 |
| 在貴公司內:
- 稽核資料可在業務專案關係人可瞭解和存取的報告中使用 - 定期檢閱稽核歷程記錄和報告。 |
在貴公司內:
- 稽核資料僅可透過需要主題專業知識的記錄檔存取與解譯 - 沒有可檢閱稽核資訊的流程 |
|
| 在您的組織中:
- 如果偵測到異常使用狀況,自動化功能已準備就緒,可透過停用使用者帳戶或即時封鎖對資源的存取來回應威脅 - 通知和警示設定為通知適當的使用者有關異常活動 - 欄位歷程記錄追蹤已針對包含私人或敏感資料的所有欄位啟用 |
在您的組織中:
- 沒有自動化功能可回應威脅 - 通知和警示未設定為通知適當的使用者有關異常活動,或者存在與異常活動相關的一些通知和警示,但這些通知是臨時的 - 針對包含私人或敏感資料的欄位,未持續啟用欄位歷程記錄追蹤 |
| 模式 | 防模式 | |
|---|---|---|
| 共用與可視性 | 在您的設計標準和文件中:
- 安全性矩陣概述每個使用者角色獲授權存取的資料 - 外部使用者和內部使用者會使用不同的資料存取標準 (若適用) |
在您的設計標準和文件中:
- 設計標準與文件不存在或不包含安全性矩陣 - 如果安全性矩陣存在,則不會概述使用者角色的資料存取權 |
| 在您的組織中:
- 由於合規性需求,內部使用者的組織範圍預設值 (OWD) 為「公用讀取」,而內部使用者的 OWD 為「專用」, - 外部使用者的 OWD 為專用 - 生成式 AI 僅會在使用者模式中運作,或為系統存取所選取的使用具有明確的業務理由 |
在您的組織中:
- 內部使用者的 OWD 設定為「專用」,但沒有業務理由,或內部使用者的 OWD 設定為「公用讀/寫」 - 外部使用者的 OWD 設定為「專用」以外的任何項目,無須業務理由 - 生成式 AI 在系統模式中運作,沒有業務理由 |
|
| 在 Apex 中:
- 所有程式碼存取資料 (SOQL/SOSL) 或執行資料作業 (DML/資料庫類別方法) 使用 共 用關鍵字 |
在 Apex 中:
- 共用共用關鍵字使用不一致 |
|
| 使用加密 | 在您的設計標準和文件中:
- 在傳輸和 (如有需要) 靜態時使用資料加密的個案明確且可探索 - 已批准的加密通訊協定會清楚列出 - 程式碼文件會清楚指出使用加密的位置以及使用哪些通訊協定 |
在您的設計標準和文件中:
- 批准的加密通訊協定不明確或未列出 - 未記錄程式碼,或文件不清楚在程式碼中使用加密的位置與方式 |
| 在您的組織中:
- 如果偵測到安全性風險需要更高的靜態資料保護,則 Hyperforce 或 Salesforce Shield 會提供靜態加密 |
在您的組織中:
- 業務需求需要更大的靜態資料保護,但不使用 Hyperforce 或 Salesforce Shield |
|
| 在 Apex 中:
- 如果業務需求在傳輸中需要更高的資料保護,則整合涉及的所有程式碼都會使用 Crypto Class 方法執行邏輯,以在傳輸前加密資料,或在接收時解密資料 |
在 Apex 中:
- 業務需求在傳輸時需要更高的資料保護,但整合中涉及的程式碼會執行邏輯,而不會在傳輸前或收到時加密資料,或者會臨時使用「加密類別」方法 |
| 工具 | 描述 | 組織安全性 | 工作階段安全性 | 資料安全性 |
|---|---|---|---|---|
| Apex 加密類別 | 在 Apex 中加密與解密資料 | X | ||
| API 存取控制 | 管理 Salesforce API 和連線的應用程式存取權 | X | X | X |
| API 異常事件 | 追蹤使用者進行 API 呼叫的異常 | X | ||
| 瀏覽器安全性設定 | 保護敏感資料並監視 SSL 憑證 | X | ||
| 以憑證為基礎的驗證 | 使用唯一數位憑證驗證個人 | X | X | |
| 憑證與金鑰 | 從 Salesforce 確認對外部網站的要求 | X | X | |
| 程式碼掃描器 | 掃描 Apex 程式碼以瞭解安全性漏洞 | X | X | |
| 連線的應用程式 | 透過 API 和標準通訊協定整合 | X | X | |
| 認證填充事件 | 追蹤使用竊取使用者認證的嘗試登入 | X | ||
| CSP 信任網站 | 防止程式碼插入式攻擊 (例如跨網站指令檔) | X | ||
| 自訂登入流程 | 控制使用者的登入業務流程 | X | ||
| 客戶身分 | 控制網站和應用程式登入和驗證 | X | ||
| Data Mask | 在 Sandbox 中自動遮罩敏感資料 | X | ||
| 除錯記錄 | 追蹤組織中發生的事件 | X | ||
| 委派管理 | 將有限的管理權限指派給非管理員使用者 | X | X | |
| 裝置啟用 | 驗證來自不受信任瀏覽器、裝置或 IP 範圍的登入 | X | ||
| 增強型交易安全性 | 攔截事件、監視和控制使用者活動 | X | ||
| 欄位存取權 | 在欄位級控制資料存取 | X | ||
| 欄位稽核追蹤 | 定義保留已歸檔欄位歷程記錄資料的原則 | X | ||
| 欄位歷程記錄追蹤 | 追蹤與顯示欄位歷程記錄 | X | ||
| Frontdoor.jsp | 允許存取現有工作階段識別碼和伺服器 URL | X | ||
| Heroku Connect | Heroku 與 Salesforce 之間的雙向同步化 | X | ||
| Heroku Shield | 建立 HIPAA 或 PCI 規範的應用程式 | X | ||
| 高度保證工作階段安全性 | 針對敏感性作業要求額外安全性 | X | ||
| Identity Connect | 將使用者記錄對應至 Active Directory 帳戶 | X | ||
| 身分驗證歷程記錄 | 稽核使用者身分驗證嘗試 | X | ||
| 整合使用者授權 | 僅透過 API 授與資料與功能的存取權。 | X | X | |
| Lightning Login | 避免密碼變弱或忘記及帳戶遭到鎖定 | X | ||
| 登入存取權 | 允許支援使用者以另一位使用者的身分登入 | X | ||
| 登入鑑識 | 識別可能表示身分詐騙的行為 | X | ||
| 登入歷程記錄 | 監視組織和 Experience Cloud 網站登入嘗試 | X | ||
| 行動裝置追蹤 | 追蹤與監視行動裝置對您組織的存取權 | X | ||
| Mobile SDK | 在獨立行動應用程式內連線至 Salesforce Platform | X | X | X |
| 監視使用者權限 (Shield) | 權限集與權限集群組變更 | X | X | |
| 多因素驗證 | 需要兩個以上的驗證方法才能登入 | X | X | |
| 共同驗證 | 強制執行 SSL 或 TLS 共同驗證 | |||
| 我的網域 | 設定登入頁面與原則、SSO 和社交登入 | X | ||
| 已命名認證 | 指定端點 URL 和驗證參數 | X | ||
| OAuth 授權 | 透過權杖交換授權用戶端應用程式存取 | X | ||
| 密碼原則 | 設定密碼歷程記錄、長度和複雜度 | X | ||
| 權限集指派到期 | 設定權限集和權限集群組指派的到期 | X | X | |
| 權限集事件 | 監視對權限集和權限集群組所做的變更 | X | X | |
| 權限集群組 | 配套權限集以支援複雜的存取需求 | X | ||
| 權限集 | 控制使用者存取中繼資料、功能和應用程式的方式 | X | ||
| 私人連線 | 保護 Salesforce 與 Amazon Web Services 之間的安全整合 | X | ||
| 設定檔 | 控制登入 IP 範圍和登入時間 | X | ||
| 即時事件監視 | 在 Salesforce 中監視與偵測標準事件 | X | ||
| 遠端網站設定 | 針對 Apex 或 JavaScript 呼叫註冊外部網站 | X | ||
| 報告異常事件 | 追蹤使用者執行或匯出報告的異常 | X | ||
| 限制規則 | 防止使用者存取不必要的記錄 | X | ||
| Salesforce 程式碼分析器 | 透過 IDE、CLI 或 CI/CD 掃描程式碼,以確保程式碼符合最佳作法 | X | X | |
| 範圍規則 | 控制使用者可以看到的預設記錄 | X | ||
| Security Center | 檢視所有組織的安全性設定,並針對狀態變更設定警示 | X | X | |
| 安全健康檢查 | 識別安全性設定中的漏洞 | X | ||
| 工作階段劫持事件 | 透過竊取的工作階段識別碼識別未經授權的存取 | X | ||
| 工作階段管理類別 | 自訂已啟用工作階段的安全性設定 | X | ||
| 工作階段安全性設定 | 設定工作階段以防範惡意攻擊 | X | ||
| 設定稽核追蹤 | 追蹤管理員最近進行的設定變更 | X | ||
| 共用設定 | 在記錄層級控制資料存取 | X | ||
| Shield Platform Encryption | 加密靜態與傳輸中的敏感資料 | X | ||
| 單一登入 | 透過單一登入提供多個應用程式的存取權 | X | X | |
| 跨網域身分管理系統 (SCIM) | 透過 REST API 管理跨系統的身分 | X | ||
| 威脅偵測 | 使用統計資料和機器學習來偵測威脅 | X | ||
| 信任的 IP 範圍 | 定義不需要額外驗證的 IP 位址 | X | ||
| 使用者存取報告 | 取得使用者物件、記錄和權限存取權的統一檢視 | X | X |
| 資源 | 描述 | 組織安全性 | 工作階段安全性 | 資料安全性 |
|---|---|---|---|---|
| 共用結構指南 | 深入瞭解存取工具、共用模式和使用個案 | X | ||
| 設計標準範本 | 為您的組織建立設計標準 | X | X | X |
| 如何建立使用者安全性模型 | 進一步瞭解使用者安全性模型 | X | X | |
| 如何在 Salesforce 中實作最低權限原則 | 瞭解如何在 Salesforce 中套用 PoLP 資料存取控制 | X | X | |
| 監視使用者工作階段 | 檢閱啟用的工作階段並結束可疑工作階段 | X | ||
| 多因素驗證 | 從 Salesforce 存取正式 MFA 資源 | X | ||
| 權限集群組 (Trailhead) | 使用權限集群組進行操作 | X | X | |
| REST API 結構 | 瞭解 REST API 詞彙與概念 | X | X | X |
| 安全性與 SOAP API | 瞭解 SOAP API 詞彙與概念 | X | X | X |
| API 和內部系統使用者的安全性最佳作法 | 由 API 使用者和安全內部系統使用者安全地存取 Salesforce | X | ||
| 安全性實作指南 | 全方位瞭解 Salesforce 安全性 | X | X | X |
| 安全性原則範本 | 為您的組織設定安全性原則 | X | X | X |
| 工作階段類型 | 識別用於存取您組織的工作階段類型 | X | ||
| 威脅建模基礎知識 (Trailhead) | 瞭解安全性威脅以及如何防止。 | X |
| 臨時組織 | Developer Sandbox | Developer Pro Sandbox | 複製 Sandbox 部分 | 完整 Sandbox | |
|---|---|---|---|---|---|
| 支援 組織形式 | 是 | 否 | 否 | 否 | 否 |
| 支援 來源追蹤 | 是 | 是 | 是 | 否 | 否 |
| 壽命 | 1–30 天 | 手動控制 | 手動控制 | 手動控制 | 手動控制 |
| 重新整理間隔 | 不提供 | 1 天 | 1 天 | 5 天 | 29 天 |
| 版本預覽支援 | 由開發人員控制 | 根據 Sandbox 例項 | 根據 Sandbox 例項 | 根據 Sandbox 例項 | 根據 Sandbox 例項 |
| 佈建時間 | > 5 分鐘 | 小時或天數 | 小時或天數 | 小時或天數 | 小時或天數 |
| 中繼資料決定者 | 來源控制 | 生產 | 生產 | 生產 | 生產 |
| 資料決定者 | 手動資料載入 | 手動資料載入 | 手動資料載入 | Sandbox 範本 | 生產 |
| 資料限制 | 200 MB | 200 MB | 1 GB | 5 GB | 與在生產環境中相同 |
| 工作 | 組織形狀 | 來源追蹤 | 經常重新整理 | 版本預覽支援 | 來自生產的所有中繼資料 | 來自生產的部分中繼資料 | 生產環境中的大型資料集 | 來自生產的部分資料集 | 相容環境 |
|---|---|---|---|---|---|---|---|---|---|
| 原型 | X | X | X | X | X | X | X | 臨時組織、開發人員與開發人員 Pro Sandbox | |
| 新功能調查或概念證明開發 | X | X | X | X | X | X | X | 臨時組織、開發人員與開發人員 Pro Sandbox | |
| 使用者接受度測試 | X | X | X | X | X | X | Developer、Developer Pro 和 Partial Copy Sandbox | ||
| 效能與規模測試 | X | X | X | 完整 Sandbox | |||||
| 使用者訓練 | X | X | X | X | X* | X | Developer Pro、部分複製與*Full Sandbox | ||
| *如果完成特定類型工作的必要項目,請使用資源密集性較低的環境 | |||||||||
| 模式 | 防模式 | |
|---|---|---|
| 發行管理 | 在生產環境中:
- 中繼資料顯示使用穩定版本機制,例如: -- 將中繼資料組織為解除鎖定的封裝 -- DevOps Center 已啟用並安裝 -- 透過使用來源格式的中繼資料 API 進行部署 - 部署記錄在可用歷程記錄內不會顯示失敗的部署。 - 部署歷程記錄會顯示清楚的版本步調,以及版本視窗內相當統一的部署叢集。 |
在生產環境中:
- 中繼資料表示使用以組織為基礎的發行機制,例如: -- 主動使用變更集 -- 透過中繼資料 API 進行的部署使用 package.xml 格式 - 部署記錄會在可用歷程記錄中顯示失敗部署的重複例項。 - 部署沒有可辨識的步調或顯示不平均的部署叢集,這表示有熱修復和臨時回復)。 - DevOps Center 未啟用且未安裝。 |
| 在您的藍圖和文件中:
- 版本名稱清楚。 - 功能會明確繫結至特定已命名版本。 - 版本名稱可搜尋且可探索。 - 小組可以找到並遵循明確的原則來標記具有正確版本名稱的成品、開發項目和其他工作。 - 您可以透過版本名稱來提取版本資料清單的清晰檢視。 - 系統會針對不同的開發階段,定義生成式 AI 應用程式的品質水準。 |
在您的藍圖和文件中:
- 不包含版本名稱。 - 功能未明確繫結至特定版本。 - 版本名稱為特殊使用或不存在。 - 小組以不同的方式參照物件、開發項目和其他工作。 - 無法使用版本名稱來提取版本資料清單的清晰檢視。 - 系統不會定義生成式 AI 應用程式的品質界限,或者如果已定義,則不會定義不同開發階段的品質界限。 | |
| 環境策略 | 在您的組織中:
- 採用來源驅動的開發和版本模型。 - 已針對 Developer 與 Developer Pro Sandbox 啟用來源追蹤。 - 指定環境中的中繼資料獨立於版本成品。 - 環境不會直接對應至釋出路徑。 - 變更的發行路徑取決於變更的類型 (高度風險、中度風險或低度風險)。 - 不存在擁擠的環境。 - 永遠不會直接在生產環境中進行有風險的組態變更。 - 在營業時間高峰期間不會發生發行。 - Data 360 Sandbox 用於適當測試需要 Einstein 資料庫、Knowledge 文章和非結構化資料的代理使用個案 |
在您的組織中:
- 採用以組織為基礎的開發和版本模型。 - 未針對 Developer 與 Developer Pro Sandbox 啟用來源追蹤。 - 指定環境中的中繼資料是版本成品。 - 環境會直接對應至釋出路徑。 - 無論變更類型為何,每個變更的版本路徑皆相同。 - 存在的環境過度擁塞。 - 直接在生產環境中進行有風險的組態變更。 - 發行會在營業時間高峰期間發生。 - 不會使用 Data 360 Sandbox 測試需要 Einstein 資料庫、Knowledge 文章和非結構化資料的 Agentforce 工作人員 |
| 訊號策略 | 在您的組織中:
- 小組可協同合作定義和標準化健康檢查 API 和 SLO。 - 定期審查和精簡訊號策略是死後與營運整備審查的一部分。 在生產環境中: - 會針對所有應用程式實作健康檢查。 - 應用程式會提供有關其健康狀況 (例如載入與功能) 的明確訊號。 - 應用程式的設計目的為在相依性不良時順利降級。 - 載入分割用於防止串聯失敗。 在您的設計中: - 反壓力與負載機制可防止服務遭到流量溢出。 - 系統會假設相依性最終會失敗。訊號處理常式是為了減輕失敗而建立。 |
在您的組織中:
- 小組在孤立作業中,建立不一致且不相容的健康訊號機制。 - 訊號策略是事後考量,只有在事件發生時才會處理。 在生產環境中: - 元件會無訊息表示其健康狀態的情況下無聲失敗。 - 應用程式會無限期重試對不健康服務的要求。 - 所有要求都會以相同的優先順序處理,無論其重要性為何。 - 為了找出問題,運算子僅依賴反應性措施,例如使用者抱怨或重大系統故障。 在您的設計中: - 假設所有相依性一律可供使用,且不會考慮網路分割、延遲高峰或其他常見問題。 - 應用程式接受所有傳入要求,即使應用程式載入過多,進而導致延遲增加且失敗的可能性更高 |
| 測試策略 | 在您的業務中:
- 可用性測試採用各種裝置和輔助技術。 - 模擬器用於複製類似生產的條件,以進行延展性和效能測試。 - 測試會在變更進入來源控制時自動執行。 - 應用程式開發週期中的多個間隔執行耐力、壓力、效能和規模測試,並將其視為進行中的工作。 - 當您擁有 B2C 規模應用程式、大量使用者或大量資料時,您可將刻度測試納入 QA 流程的一部分。 - 您的刻度測試專注於系統的高優先順序層面。 - 您的刻度測試具有已定義的條件。 - 您在完整 Sandbox 中執行規模測試。 - 提示工程包含人類的品質檢閱。 - Agentforce 測試中心用於強大的工作人員測試。 |
在您的業務中:
- 不會執行可用性測試,或者如果是,則會在有限的裝置上執行。 - 不會測試類似生產的使用者要求、API 流量和網路速度變化。 - 測試自動化未準備就緒。 - 耐力、壓力、效能、刻度測試視為開發階段。 - 您不會在 QA 流程中執行刻度測試,且擁有 B2C 刻度應用程式、大量使用者或大量資料。 - 您的刻度測試未排定優先順序。 - 您的刻度測試沒有正確定義的條件。 - 您在 Partial Copy 或 Developer Sandbox 中執行刻度測試。 - 提示工程不包括人類的品質檢閱。 - Agentforce 工作人員未經測試,或僅使用工作人員產生器進行臨時測試。 |
| 在您的組織中:
- 所有測試資料都會清除敏感且可識別的資料。 |
在您的組織中:
- 測試資料與生產資料相同。 | |
| 在 Apex 中:
- 資料工廠模式用於單元測試 - 用於模擬 API 回應的模擬程式與實體。 |
在 Apex 中:
- 單元測試依賴組織資料。 - 未使用粗體及粗體。 | |
| 在您的設計標準和文件中:
- 環境會依其支援的測試類型進行分類。 - 根據風險、使用個案或複雜度指定適當的測試模式。 |
在您的設計標準和文件中:
- 每個環境支援哪些測試類型並不清楚。 - 測試模式不會依風險、使用個案或複雜度分類。 |
| 事件類型 | 外觀觸發 | 復原策略 |
|---|---|---|
| 系統缺勤 | 損毀的登入或帳戶存取權的問題 | 帳戶復原原則 |
| 服務無法使用 | 啟用冗餘的備份服務;手動因應措施 | |
| 生產程式錯誤 | 最近變更 | 先前版本的部署回復或取消部署 |
| 新的無法解釋錯誤 | 手動因應措施、停用非必要功能、升級至 SME |
| 模式 | 防模式 | |
|---|---|---|
| 復原時間 | 在您的業務中:
- 系統會定期實作復原通訊協定。 - 小組瞭解他們在生產環境中擁有且負責的服務。 - 小組瞭解相關工具以支援問題的診斷。 |
在您的業務中:
- 復原通訊協定不存在或未定期執行。 - 不清楚哪些小組在生產環境中擁有並負責不同的服務。 - 小組沒有工具的指引或標準來支援問題的診斷。 |
| 在您的文件中:
- 系統會依事件類型與觸發定義及分類復原策略。 - 事件回應的結束條件包含在 SLO 中且清楚明確。 - 事件期間增加權限的啟用條件和指派邏輯已清楚明確。 - 事件回應權限集與授權會清楚列出。 - 存在疑難排解指南,協助識別和診斷常見問題。 |
在您的文件中:
- 事件回應會臨時執行。 - 不存在事件回應的結束條件。 - 未指派增強權限,或如果是,則會臨時指派權限。 - 事件回應權限集與授權未列出。 |
|
| 在您的組織中:
- 存在以工作階段為基礎的事件回應權限集,且可在復原期間指派給支援人員。 - 「設定稽核追蹤」顯示指定的復原測試人員在協議的時間登入測試環境,並遵循復原測試指令檔。 |
在您的組織中:
- 以工作階段為基礎的權限集不存在於事件回應中,否則支援人員不獲授權使用。 - 「設定稽核追蹤」顯示指定的復原測試人員未登入測試環境或未遵循復原測試指令檔 | |
| 在測試計畫中:
- 復原測試的測試指令檔存在且可重複。 - 系統會清楚列出事件模擬的環境。 |
在測試計畫中:
- 不存在用於復原測試的測試指令檔。 - 未建立事件模擬的環境。 |
|
| 能力分級 | 在您的業務中:
- 在事件發生前,會識別應警示支援複雜問題的中小型企業或利害關係人。 - 交付與支援小組之間的交談是上線的一部分。 - 如有諮詢,Salesforce 結構設計師可快速回應並協助小組專注於復原。 |
在您的業務中:
- 在事件發生之前,不會識別應警示的 SME 或利害關係人。 - 傳送小組與支援小組之間的交談不是版本流程的一部分。 - Salesforce 結構設計師會將事件回應視為其工作範圍外。 |
| 在您的文件中:
- 支援人員可以探索並閱讀指定解決方案中使用的系統和設計模式。 |
在您的文件中:
- 指定解決方案中使用的系統和設計模式無法供支援人員使用。 |
|
| 在您的組織中:
- 記錄和自訂錯誤訊息會納入整個系統的執行路徑。 |
在您的組織中: - 不使用記錄和自訂錯誤訊息。 | |
| 監視與警示 | 在您的組織中:
- 警示僅用於通知使用者需要人力介入的情況;其他失敗會記錄並進行報告。 - 警示會傳送給能夠回應警示的使用者。 - 如果可能,會在可能失敗之前傳送警示。 |
在您的組織中:
- 當發生任何類型的失敗時會傳送警示,無論是否需要後續動作。 - 將需要技術解決方案之問題的警示傳送給業務使用者。 - 警示只會針對已經發生的失敗傳送。 |
| 在您的文件中:
- 系統會根據直接和間接生成式 AI 回饋意見度量定義提示調整警示的項目條件。 |
在您的文件中:
- 沒有針對生成式 AI 應用程式觸發提示調整警示的條件定義。 |
| 模式 | 防模式 | 業務連續性 | 在您的業務中:
- 採用「復原優先」心態,專注於盡快使優先順序最高的業務功能和功能不受影響。 - 有維護排程可供檢閱 BCP 測試計畫。 |
在您的業務中:
- 「修正問題」心態是事件管理的唯一方法。 - 不會定期重新整理 BCP 測試計畫。 |
|---|---|---|
| 在您的文件中:
- 存在 BCP,其中包含在 Salesforce 無法使用時繼續處理或分級資料的步驟、觸發使用 BCP 的事件清單,以及 BCP 測試的步驟和間隔。 - BCP 包含上游和下游系統和相依性。 |
在您的文件中:
- BCP 不存在、不完整或僅包含 Salesforce。 |
|
| 在測試計畫中:
- 系統會考慮與程序和人員相關的 BCP 區域。 |
在測試計畫中:
- 不會考慮與程序和人員相關的 BCP 區域。 | |
| 技術持續性 | 在您的業務中:
- 您已評估是否需要建立有意的冗餘或錯誤系統 - 事件復原策略會盡可能自動化。 |
在您的業務中:
- 您尚未評估有關有意冗餘或停機系統的需求 - 事件復原策略完全為手動。 |
| 在您的文件中:
- BCP 會考慮小組可能需要的額外資源或中斷程序,以有效回應事件。 |
在您的文件中:
- BCP 不包含作業支援需求。 |
|
| 備份與還原 | 在您的文件中:
- 資料與中繼資料皆有備份與還原策略。 |
在您的文件中:
- 備份與還原策略不存在,或者如果存在,則不完整,僅套用至資料或僅套用至中繼資料,而非兩者。 |
| 在貴公司:
- 備份會儲存在僅授權使用者可存取的安全位置。 - 測試計畫和測試記錄顯示資料還原每年至少在完整或部分複製 Sandbox 中進行兩次測試。 |
在貴公司:
- 備份並非人類可讀。 - 備份會儲存在未經授權的業務使用者可存取的位置。 - 沒有資料還原流程,或者資料還原流程未經測試。 |
| 工具 | 描述 | 應用程式週期管理 | 事件回應 | 持續性規劃 |
|---|---|---|---|---|
| Apex 锤子測試 | 瞭解目前和新版本中的 Salesforce Apex 測試。 | X | ||
| Apex Stub API | 建立模擬架構以簡化測試。 | X | ||
| 備份與復原 | 自動產生備份以防止資料遺失。 | X | ||
| 大型物件 | 在平台上儲存及管理大量資料。 | X | ||
| 欄位歷程記錄追蹤 | 追蹤並顯示欄位歷程記錄。 | X | ||
| 取得您組織的採用與安全性洞察新視窗中的開啟連結 | 監視您組織中 Lightning Experience 的採用與使用狀況。 | X | ||
| 管理大量資料載入工作 | 使用「大量 API」建立更新或刪除大量記錄。 | X | ||
| 管理即時事件監視事件 | 管理事件監視串流和儲存空間設定。 | X | ||
| 資料與儲存資源 | 檢視您 Salesforce 組織的儲存空間限制與使用量。 | X | ||
| 監視器除錯記錄 | 監視記錄並設定標記以觸發記錄。 | X | ||
| 使用登入鑑識監視登入活動 | 識別可能表示身分詐騙的行為。 | X | ||
| 使用設定稽核追蹤監視設定變更 | 追蹤管理員最近進行的設定變更。 | X | ||
| 監視訓練歷程記錄 | 檢視使用者已參加的 Salesforce 訓練課程。 | X | ||
| 監視背景工作 | 監視您組織中的背景工作。 | X | ||
| 監視排程的工作 | 檢視報告快照、排程的 Apex 工作和顯示面板重新整理。 | X | ||
| 規模測試 | 測試系統效能並解譯結果。 | X | ||
| 主動監視 | 使用 Salesforce 監視服務將中斷降到最低。 | X | ||
| Salesforce Data Mask | 自動遮罩 Sandbox 中的資料。 | X | ||
| 系統概觀頁面 | 檢視您組織的使用狀況資料與限制。 | X | ||
| 使用 force:lightning:lint | 透過 Salesforce CLI 分析和驗證程式碼。 | X |
| 資源 | 描述 | 應用程式週期管理 | 事件回應 | 持續性規劃 |
|---|---|---|---|---|
| 效能與規模測試中的 7 個防模式 | 避免在效能和規模測試中出現常見的反模式。 | X | ||
| 分析複雜 Salesforce 應用程式中的效能與規模熱點 | 瞭解解決您組織中效能與延展性問題的方法。 | X | ||
| 建立災害復原計畫 (Trailhead) | 建立災害復原計畫。 | X | ||
| 業務連續性不僅僅是備份與還原 | 全方位檢視 BCP。 | X | ||
| 設計標準範本 | 為您的組織建立設計標準。 | X | ||
| Salesforce 中的 診斷與監視工具 | 瞭解如何改善實作的品質與效能。 | X | ||
| 業務持續性規劃的指導原則 | 檢閱有效 BCP 的基礎基本原則。 | X | ||
| 如何在 Salesforce 上規模測試 | 瞭解規模測試生命週期的五個階段。 | X | ||
| 效能測試簡介 | 瞭解如何開發效能測試方法。 | X | ||
| 監視您的組織 | 瞭解自助式服務監視選項。 | X | ||
| 測試策略範本 | 建立和自訂規模和效能測試計畫。 | X | ||
| 測試策略範本 | 確定測試策略已完成。 | X | ||
| 瞭解來源驅動的開發 (Trailhead) | 瞭解封裝開發和臨時組織。 | X |
| 模式 | 防模式 | |
|---|---|---|
| 優先順序 | 在您的文件中:
- 所有新工作項目都有明確的業務價值度量 (例如,收入增加、流程最佳化節省成本等) - 藍圖顯示根據業務值排定工作的優先順序 |
在您的文件中:
- 與工作相關的業務值不明確或不存在 - 藍圖不存在 |
| 在貴公司內:
- 已識別所有工作項目的實作與維護成本 - 系統會根據業務影響、需要提供的新工作量,以及需要維護的工作量,來排定功能要求的優先順序 |
在貴公司內:
- 與實作與維護功能相關聯的成本不明確 - 要求會以臨時或先進/先出為基礎來傳送 |
|
| 路線對應 | 路線圖:
- 為您的受眾量身打造的資訊 (業務或技術) - 以正確的詳細資料層級傳達資訊 - 顯示開始與結束日期 - 顯示先決條件與相依性 |
路線圖 (若存在):
- 作為專案起始材料而非傳送的成品使用 - 不要協助使利害關係人和遞送小組保持一致 - 混合詳細資料層級 (例如,透過在相同的藍圖中包含系統和元件) - 包含未針對受眾量身打造的資訊 (例如,相同藍圖內的業務功能與系統) |
| 在您的業務中:
- 利害關係人瞭解工作項目的「原因」 - 遞送小組瞭解如何根據較長期優先順序評估待處理項目 - 小組瞭解誰要執行哪些動作以及如何管理相依性 - 工作是有意的,即使優先順序必須快速變更 |
在您的業務中:
- 工作從待處理項目中的一切提取,且沒有明確的「原因」 - 小組無法協調相互相依工作,且經常在不瞭解的情況下重複工作 - 工作通常為反應性 - 利害關係人經常對正在完成的動作感到挫折和困惑,並在提供新功能時感到自信 |
|
| 管治 | 在您的業務中:
- 使用者可以輕鬆報告程式錯誤和要求功能 - 工作項目的優先順序流程已記錄並向所有利害關係人透明 - 已清楚記錄環境策略,且開發環境符合文件 - 發行規劃對所有遞送小組成員可預測且透明 - 小組成員瞭解在整個應用程式生命週期負責的項目 - 使用者和傳送/維護小組可以清楚瞭解版本 - 生產支援流程清楚明確,且 hot-fixes 具有生產的明確路徑 - 小組和專案僅使用已批准業務使用的 AI 模型 |
在您的業務中:
- 錯誤報告與功能要求為臨時 - 工作項目沒有明確的優先順序 - 環境為臨時佈建,且可能無法以預測的方式重新整理;開發人員通常沒有所需的環境和存取權 - 傳送小組和使用者無法預期發行版本 - 小組不知道誰負責哪些事項 - 臨時處理熱修復 - 您的待處理項目已成為過時且停滯的「計畫銀行」 - 管治機構會作為協助台來疑難排解支援要求 - 無法輕鬆存取文件 - 小組臨時選取 AI 模型 |
| 模式 | 防模式 | |
|---|---|---|
| 標準與自訂 | 在您的設計標準中:
- 有明確的指導原則可防止解決方案不需要自訂 - 解決方案的指引原則使用下列優先順序:1.使用內建平台服務、2.在建立自訂解決方案前,請先考量 AppExchange 應用程式。在撰寫程式碼前使用低程式碼自訂項目 |
在您的設計標準中:
- 設計標準不存在或沒有避免不需要自訂和程式碼的明確理由 |
| 在您的文件中:
- 當選擇建立或購買解決方案時,決策記錄會顯示近期和長期成本的計算 |
在您的文件中:
- 當選擇建立或購買解決方案時,決策記錄不會同時考量近期與長期成本 |
|
| 在資料模型中:
- 沒有任何物件具有重複標準物件的名稱或功能 - 標準物件不會用於遠超出預期範圍的用途 |
在資料模型中:
- 物件會複製標準物件的名稱和/或功能 - 標準物件用於遠超出預期範圍的用途 |
|
| 在 LWC、Aura 或 Visualforce 中:
- 沒有可覆寫標準頁面檢視機制的程式碼 |
在 LWC、Aura 或 Visualforce 中:
- 存在程式碼來覆寫標準頁面檢視機制,通常是單一頁面應用程式的形式 |
|
| 在 LWC、Aura 或 Apex 中:
- 沒有程式碼嘗試覆寫或略過執行平台順序 |
在 LWC、Aura 或 Apex 中:
- 程式碼嘗試覆寫或略過平台執行順序 |
|
| 技術債務 | 在您的藍圖中:
- 已計畫處理技術債務的工作 - 交付與開始/結束日期清楚 |
在您的藍圖中:
- 未計畫處理技術債務的工作 - 交付項目不明確;開始/結束日期不明確 |
| 在您的決策記錄中:
- 清楚記錄前/後技術補償債務的 KPI - 對動作與未動作的權衡討論,專注於業務成本或益處 |
在您的決策記錄中:
- 技術償還債務沒有可測量的 KPI - 技術債務會以技術或 IT 重點的術語考量,與業務無關 |
|
| 在您的組織中:
- 未啟用任何不支援或舊版技術,包括: -- 所有使用者都在 Lightning Experience 中工作 -- 在 Apex 中沒有或非常少使用 @future (使用 Queueable)
-- 所有第三方 Apex 都屬於 AppExchange 封裝 -- 沒有啟用的工作流程規則 (使用流程) -- 沒有啟用的流程產生器程序 (使用流程) -- PushTopic 事件 (使用「變更資料擷取」) -- 一般事件 (使用平台事件) -- 30.0 版之前的 API 版本 -- Salesforce 組織連線使用 Salesforce Connect 的跨組織轉接器 |
在您的組織中:
- 不支援或舊技術已啟用,包括: -- 在 Salesforce Classic 中工作的使用者 -- Apex 中的 @future usage
-- 來自非 AppExchange 來源的第三方 Apex -- 工作流程規則 -- 流程產生器流程 -- PushTopic 事件 -- 一般事件 -- 30.0 版之前的 API 版本 -- Salesforce 到 Salesforce 連線 |
| 模式 | 防模式 | |
|---|---|---|
| 設計標準 | 在您的組織中:
- 程式碼和陳述式自訂項目具有一致且人類可讀的名稱 - 資料模型具有一致且統一的物件和欄位名稱 - 稽核顯示在報告中一致填寫和參照的欄位等。 |
在您的組織中:
- 程式碼和陳述性自訂項目沒有一致的名稱 - 資料模型名稱不一致,且許多物件和欄位似乎為冗餘 - 稽核會顯示許多未使用的欄位或不同層級的用量,且報告等沒有一致的連結。 |
| 在您的業務中:
- 小組瞭解要使用 (而非使用) 哪些工具來完成工作 - 通過使用個案輕鬆找到並識別批准的設計模式 - 已核准的 AI 模型會清楚識別並包含預期的用途 |
在您的業務中:
- 小組使用許多不同的工具完成類似的工作 - 沒有已批准的設計模式 - 廠商或新進員工需要很多時間才能上線 - 批准的 AI 模型未清楚識別,且其預期用途不明確 |
|
| 文件 | 在您的組織中:
- 程式碼和陳述性自訂項目具有明確的描述 |
在您的組織中:
- 程式碼和陳述式自訂項目沒有描述、具有難以理解的描述,或具有描述,似乎不符合自訂項目實際執行的動作 |
| 在您的業務中:
- 所有解決方案的業務功能圖表和技術實作詳細資料存在 - 金鑰誰/何時/存在的程式碼和陳述式自訂記錄資訊 - 人員可以搜尋並尋找相關文件 |
在您的業務中:
- 難以找到解決方案的什麼/如何/原因,且大多數的小組可能無法使用 - 人員難以瞭解解決方案以及其使用的系統 - 廠商或新進員工需要很多時間才能上線 |
| 工具 | 描述 | 策略 | 永續性 | 可讀性 |
|---|---|---|---|---|
| ApexDoc | 使用靜態 HTML 頁面文件 Apex | X | X | |
| 大量刪除未啟用的選項清單值 | 從選項清單中刪除未啟用的未使用值 | X | ||
| Lightning 設計系統驗證程式 | 驗證標記並瞭解如何改善程式碼 | X | X | |
| 移轉至流程 | 將工作流程規則和流程產生器程序轉換為流程 | X | ||
| Salesforce Labs 的專案管理工具 | 在您的 Salesforce 組織內管理專案 | X | X | |
| Visual Studio Code 的 Salesforce 擴充功能 (展開型) | 使用 Visual Studio 程式碼擴充功能有效率地分析 Salesforce 程式碼 | X | X | |
| 組織檢查 | 快速分析您的組織及其技術債務 | X | ||
| Salesforce 程式碼分析器 | 透過 IDE、CLI 或 CI/CD 掃描程式碼,以確保程式碼符合最佳作法 | X | X | |
| Salesforce 藍圖探索器 | 探索 Salesforce 產品創新 | X | ||
| 設定稽核追蹤 | 追蹤設定變更和稽核歷程記錄 | X | X |
| 資源 | 描述 | 策略 | 永續性 | 可讀性 |
|---|---|---|---|---|
| 改善 Salesforce 組織的 5 個文件策略 | 改善 Salesforce 實作文件 | X | ||
| 選擇命名慣例 (Trailhead) | 瞭解如何套用命名慣例 | X | ||
| 定義、識別和測量技術債務 | 定義、識別和測量技術債務 | X | X | |
| 設計標準範本 | 為您的組織建立設計標準 | X | X | X |
| 開始使用 Salesforce 圖表 | 瞭解如何為您的使用個案建立正確的圖表 | X | ||
| 開始使用程式碼慣例 (Trailhead) | 定義並遵循程式碼慣例 | X | ||
| 如何處理技術債務 (Trailhead) | 在您的 Salesforce 組織中管理技術債務 | X | X | |
| 改善您的 Apex 程式碼 (Trailhead) | 套用以測試為導向開發的基本原則 | X | ||
| 組織對齊方式 (Trailhead) | 瞭解對齊方式的 V2MOM 流程 | X | ||
| 排定優先順序並規劃技術債務退出之路 | 制定減少和移除技術債務的計畫 | X | X | |
| Salesforce 命名慣例範本 | 開始使用命名慣例 | X | X | |
| 技術債務:它是什麼,以及您應該注意的原因? | 瞭解組織中技術債務的影響 | X | ||
| 在企業結構中使用業務模型畫布 | 在業務模型中建立、傳送和查看值 | X |
| 信任 | ||
|---|---|---|
| 受信任的解決方案可保護您的業務和利害關係人。 | ||
| 安全 | 符合 | 可靠 |
| 組織安全性 工作階段安全性 資料安全性 |
法律符合度 道德標準 無障礙 |
可用性 績效 延展性 |
| 簡單 | ||
| 簡單的解決方案可快速提供業務價值。 | ||
| 意圖 | 自動 | 參與 |
| 策略 永續性 可讀性 |
效率 資料完整性 |
已簡化 實用 |
| 可調整 | ||
| 可調整的解決方案會隨著您的業務而發展。 | ||
| 彈性 | 可組合 | |
| 應用程式週期管理 事件回應 持續性規劃 |
分離疑慮 互通性 可封裝性 |
|
| 意圖 | ||
|---|---|---|
| 意圖解決方案會立即與隨著時間提供業務價值。意圖結構會以策略的方式進行規劃和交付、有效地進行維護,且對人類很容易閱讀和理解。 | ||
| 策略 | 永續性 | 可讀性 |
| 優先順序 路線圖 監管 |
標準與自訂 技術債務 |
設計標準 文件 |
| 自動 | ||
| 自動化解決方案可讓企業更快速且大規模完成工作。健康的自動化可減少重複、手動工作或複雜資料項目的時間。 | ||
| 效率 | 資料完整性 | |
| 流程設計 作業邏輯 KPI |
資料處理 錯誤處理 |
|
| 參與 | ||
| 參與解決方案讓使用者開心,並促進採用。參與的結構表示建立直覺式、實用的使用者體驗。 | ||
| 簡化 | 實用 | |
| 應用程式複雜性 表單 尺寸規格 |
通知與傳訊 應用程式內導覽 認可與獎勵 |
|
| 模式 | 防模式 | |
|---|---|---|
| 流程設計 | 在您的組織中:
- 每個流程都提供單一特定用途 - 每個步驟都會執行特定的細微工作 - 流程以包含主要流程和支援子流程的階層結構進行組織 - 流程內所有使用者輸入都具有明確的目的 - 僅在無法使用現有系統資料時要求使用者提供資料 |
在您的組織中:
- 流程可用於多種用途,且需要額外的輸入才能提供內容 - 流程需要未使用資料的輸入 - 相關步驟群組包含與其他流程中步驟群組重疊的功能 - 當可以改用儲存的資料時,流程會要求使用者輸入 |
| 在 Apex 中:
- 每個類別都提供單一特定用途 - 每個方法都會執行特定的細微工作 - 所有輸入變數在類別中都有明確的目的 - 程式碼執行需要最少數量的資源 |
在 Apex 中:
- 類別適用於多種用途 - 方法執行多個工作,或方法執行不符合其所屬類別所述用途的工作 - 輸入變數實際不會用於方法 - 方法不必要地從資料庫或外部系統提取資料 |
|
| 作業邏輯 | 在流程中:
- 沒有變數參照硬式編碼值 (針對記錄類型、使用者等) - 所有自動啟動流程和程序都會使用決策和/或暫停元素來評估輸入條件,並防止對大型資料量執行無限迴圈或執行 - 在大型資料量內容中將流程 (包含程序) 授與 Apex 的邏輯 - 子流程用於需要在整個業務中重複使用的流程區段 |
在流程中:
- 變數具有硬式編碼值 - 必須先手動停用流程 (包含程序),才能大量載入資料 - 流程 (包含程序) 會觸發「未處理例外」通知 - 即使是簡單的流程也會定期造成與管理員限制相關的錯誤 - 流程的部分會在流程之間重複,而非使用子流程 |
| 在 Apex 中:
- 沒有變數參照硬式編碼值 (針對記錄類型、使用者等) - 所有萬用字元條件都會顯示在 SOSL 中 - SOQL 封裝在 試用中
- 迴圈內沒有 SOQL 顯示 - SOQL 陳述式是選擇性的,包括: -- 不使用 LIKE 比較或部分文字比較
-- 比較運算子使用正數邏輯 (亦即 包含, IN) 作為主要或唯一邏輯
-- = NULL、!= NULL 的使用極少見,且/或一律遵循正比較運算子
-- 沒有顯示 LIMIT 1 陳述式
-- 沒有使用 ALL ROWS 關鍵字
| 在 Apex 中:
- 變數具有硬式編碼值 - SOSL 極少或不一致用於萬用字元選取條件 - SOQL 不包含在 試用中
- SOQL 會顯示在迴圈內 - SOQL 陳述式為非選擇性,包括: -- 顯示 LIKE 與萬用字元篩選條件
-- 使用 NOT、NOT IN 條件的比較會作為主要或唯一比較運算子使用
-- = NULL、!= NULL 條件會作為主要或唯一比較運算子使用
-- 顯示 LIMIT 1 陳述式
-- 使用 ALL ROWS 關鍵字
| |
| 在您的設計標準和文件中:
- 系統會清楚概述自動化的計畫式與潛在執行路徑 - 自動化中的同步和非同步作業使用個案會清楚概述為設計標準的一部分 |
在您的設計標準和文件中:
- 自動化叫用未記錄 - 未處理同步和非同步作業的使用個案 |
|
| KPI | 在您的文件中:
- 每個自動化的輸出皆為可測量且繫結時間 - 系統會針對每個 KPI 列出負責的利害關係人 |
在您的文件中:
- KPI 不存在於自動化,或有不明確的測量時間範圍 - KPI 存在於沒有負責的利害關係人的情況下 |
| 在報告與顯示面板中:
- 與 KPI 相關的所有度量都包含在至少一個報告或顯示面板中 |
在報告與顯示面板中:
- KPI 報告不存在,或報告缺少與某些 KPI 相關的度量 |
| 模式 | 防模式 | |
|---|---|---|
| 資料處理 | 在您的資料字典中:
- 存在所有資料來源和資料湖物件的欄位級資料和優先順序邏輯 - 資料湖物件到資料模型物件的欄位對應已存在 |
在您的資料字典中:
- 不包含資料來源和資料湖物件的欄位級資料和優先順序邏輯 - 不包含資料湖物件到資料模型物件的欄位對應 |
| 在您的 Apex 中:
- 在觸發執行內容 之前,會執行所有同步 DML 陳述式或資料庫類別方法 - 非同步 Apex 叫用使用在交易之間的「鏈結」複雜 DML - 批次 Apex 僅用於大量資料 - @future Apex 不會用於呼叫或系統物件 DML |
在您的 Apex 中:
- DML 陳述式會定期顯示在觸發內容 後 要叫用的程式碼中 - 極少使用非同步 Apex - 非同步 Apex 功能會被任意使用,包括: -- Future Methods 與可排列 Apex 不一致或交替使用 -- 資料庫作業沒有明確且一致的邏輯,可在需要時將執行傳送至批次 Apex |
|
| 在流程中:
- 在使用者環境中啟動的所有流程會將所有系統環境交易摘要到子流程 (會一致地放在「暫停」元素之後) 以建立新交易 - 使用協調器建立相關資料作業的複雜序列 (而非在單一流程內叫用多個子流程) - 所有記錄觸發流程均已填入觸發順序值 - 涉及外部系統呼叫或長時間執行程序的流程會使用非同步路徑 |
在流程中:
- 大型單一流程會嘗試協調相關資料作業的複雜序列 (含或不含子流程) - 記錄觸發流程完全不使用觸發順序屬性,或不一致使用觸發順序值 - 非同步路徑不會一直或完全使用 |
|
| 在您的組織中:
- 「身分解析協調規則」遵循資料字典中的優先順序邏輯 |
在您的組織中:
- 身分解析協調規則不遵循資料字典中的優先順序邏輯 |
|
| 錯誤處理 | 在 Apex 中:
- 程式碼會將所有 DML、SOQL、呼叫和其他重要程序步驟包含在 試用抓取區塊中
- 自訂例外用於建立進階錯誤傳訊和邏輯 - 在非同步和大量環境中,會使用 資料庫類別方法,而非使用 DML - 資料庫類別方法只能用於所有資料作業 (而非 DML) |
在 Apex 中:
- DML、SOQL、呼叫或其他重要程序步驟並未一致封裝在 試用區塊中
- System.debug 陳述式會顯示在生產程式碼中 (且不會加上註解)
- 未使用資料庫類別方法 - 資料作業僅使用 DML 進行 |
| 在 Lightning Web 元件 (LWC):
- JavaScript 會將所有資料作業和重要程序步驟包含在 if()/else if() 區塊中
- 所有 @wire 函數都使用 API 提供的 資料和 錯誤內容
- All if (error)/else if (error) 陳述式包含處理錯誤並提供資訊豐富訊息的邏輯 |
在 LWC 中:
- JavaScript 不會持續使用資料作業或重要程序步驟的封鎖 若 ()/其他 if ()
- @wire 函數不使用 API 提供的 資料和 錯誤內容 (或不一致使用這些內容)
- 如果已使用,則陳述式實際上不包含處理錯誤的邏輯,且不提供實用的錯誤訊息, 如果 (錯誤)/其他 (錯誤)陳述式 |
|
| 在 Aura 中:
- JavaScript 會將所有資料作業和重要程序步驟以 試取區塊括住
- 在 試用區塊內,會在 throw 陳述式中使用原生 JavaScript Error (不使用 $A.error())
- 所有可復原錯誤邏輯都會顯示在 抓取陳述式中,並提供清楚的使用者訊息 |
在 Aura 中:
- JavaScript 不會將資料作業和重要程序步驟一致括在 試用區塊中
- 元件使用 $A.error()
- 可復原錯誤邏輯不會一直顯示在 抓取陳述式中,且使用者的錯誤訊息不明確 |
|
| 在流程中:
- 畫面流程會持續使用錯誤連結向使用者顯示錯誤 - 已針對畫面上顯示的錯誤設定自訂錯誤訊息 - 具有資料作業、呼叫和其他重要處理邏輯的流程具有所有關鍵動作的錯誤路徑 |
在流程中:
- 流程不會一直或完全使用錯誤路徑 - 未使用自訂錯誤訊息,因此使用者會看到預設的「在此流程中發生未處理的錯誤」訊息 |
| 工具 | 描述 | 效率 | 資料完整性 | 業務價值 |
|---|---|---|---|---|
| Apex 批次 | 批次記錄並處理為可管理區塊 | X | X | |
| Apex Future 方法 | 在背景中非同步執行 Apex 方法 | X | X | |
| Apex 等級 | 將 Apex 工作新增至某列,並監視這些工作 | X | X | |
| Apex Scheduler | 在指定的時間非同步執行 Apex 類別 | X | X | |
| 批准 | 指定批准記錄的必要步驟 | X | X | |
| 非同步 Apex | 非同步執行 Apex 程式碼 | X | X | |
| 自動化動作 | 在背景中執行欄位更新、電子郵件傳送和其他動作 | X | X | |
| Einstein Next Best Action | 在正確的時間向正確的人員顯示正確的建議 | X | X | |
| 電子郵件警示 | 建立與傳送自動化電子郵件 | X | X | |
| 升級動作 | 指定要對個案升級採取的自動化動作 | X | X | |
| 欄位更新 | 根據自動化更新欄位值 | X | X | |
| Flow Builder | 使用點選介面建立自動化 | X | X | |
| 流程擴充 | 存取儲存的變數作為流程中的元件輸入 | X | ||
| 流程範本庫 | 使用範本設計產業特定的流程 | X | X | |
| 流程觸發 | 自動化複雜的業務流程 | X | ||
| 可叫用動作 | 將 Apex 功能新增至流程 | X | X | |
| 協調流程 | 建立與管理多步驟自動化 | X | X | |
| 輸出訊息 | 透過收據和重試,從自動程序傳送資訊 | X | ||
| 使用流程發佈平台事件 | 透過使用者互動與自動化發佈事件 | X | ||
| 查詢最佳化工具 | 使用選擇性與索引改善查詢、報告和清單檢視效能 | X | X | |
| Salesforce 流程 | 使用 Flow Builder 建立陳述性流程自動化 | X | X | |
| 使用流程傳送通知 | 透過 SMS、WhatsApp 或 Facebook Messenger 傳送訊息 | X | X | |
| 使用程序傳送通知 | 透過 SMS、WhatsApp 或 Facebook Messenger 傳送訊息 | X | X | |
| SOQL FOR UPDATE 修飾詞 | 鎖定記錄以防止比賽條件和執行緒安全問題 | X | ||
| Strategy Builder | 識別要在記錄頁面上顯示的建議 | X | X | |
| 子流程 | 透過重複使用降低流程複雜性 | X | ||
| 使用流程訂閱平台事件 | 接收透過自動化發佈的訊息 | X | ||
| 工作動作 | 決定由自動化提供給使用者的指派詳細資料 | X |
| 資源 | 描述 | 效率 | 資料完整性 | 業務價值 |
|---|---|---|---|---|
| Apex 執行管理員與限制 | 瞭解 Apex 執行階段引擎如何強制執行限制 | X | X | |
| 批次管理資源 | 建立、管理、排程和監視批次工作 | X | X | |
| SOQL 和 SOSL 的最佳作法 | 改善具有大量資料之應用程式的查詢效能 | X | ||
| 設計標準範本 | 為您的組織建立設計標準 | X | X | X |
| 交易中的流程大量處理 | 設計流程以針對集合作業 | X | X | |
| 流程資料考量事項 | 瞭解批次資料的排程觸發流程 | X | X | |
| 流程除錯 | 測試和疑難排解流程 | X | ||
| 要求的處理方式 | 瞭解 Salesforce 如何快速處理工作並將失敗降到最低 | X | X | |
| KPI 試算表範本 | 決定特定度量的業務價值 | X | X | |
| 從可叫用動作對外部系統進行呼叫 | 使用 Apex 從流程呼叫外部系統 | X | ||
| 混合 DML 作業 | 瞭解哪些 sObject 可在相同交易中一起用於 DML | X | X | |
| 執行指示 | 瞭解插入、更新和更新插入的事件順序 | X | X | |
| 查詢計畫常見問題 | 最佳化涉及大量資料的查詢 | X | X | |
| 排程觸發流程考量事項 | 瞭解排程所觸發流程的特殊行為 | X | ||
| 交易控制 | 產生指定目前資料庫狀態的 savepoint | X | X | |
| 流程失敗時會發生什麼事? | 瞭解流程中的錯誤處理 | X | X | |
| 工作流程自動化最佳作法指南 | 開始使用 Salesforce 自動化 | X | X | X |
| 使用非常大的 SOQL 查詢 | 撰寫更有效率的 SOQL 查詢 | X |