How to Build a Business Continuity Plan for Salesforce Downtime

When Salesforce becomes unavailable, the biggest operational risk is rarely the error message itself. The real problem is that sales, service, order, marketing, or back-office teams may no longer know where to record work, how to serve customers, or which decisions can safely wait. A useful business continuity plan is therefore not a document that simply says “check Salesforce Trust and wait.” It should keep the most important business processes moving at an acceptable level until normal service returns.

The quality of the plan can be judged by outcomes. During a disruption, people should know what to do, where to record temporary work, who can make decisions, how customers are informed, and how temporary records are reconciled after recovery. The plan should also make clear where continuity stops being safe. Some processes can run manually for hours; others should pause because duplicate transactions, regulatory mistakes, or data inconsistency would create more harm than waiting.

Start with the outcome you need during downtime

A business continuity plan should begin with business impact, not technology. NIST’s Contingency Planning Guide for Federal Information Systems recommends determining contingency requirements and priorities through a business impact analysis. Although the publication is written for federal information systems, the underlying discipline is broadly useful: identify essential functions, understand the effect of disruption, define recovery priorities, and maintain tested contingency procedures.

For Salesforce, that means asking which business activities must continue even when the platform is unavailable. A sales team may need to capture urgent prospect commitments. A support organization may need to receive and triage critical customer incidents. A field team may need access to a small set of customer or asset details. Finance may decide that some transactions should stop completely until Salesforce and connected systems are stable.

A strong continuity objective is specific enough to test. For example, “customer support must remain operational” is vague. “Priority-1 customer incidents can still be received, assigned, acknowledged, and tracked with no lost requests during a four-hour Salesforce outage” is measurable.

Define acceptable degradation, not an unrealistic promise of normal operations

Continuity is not the same as full functionality. The goal is usually to preserve a minimum viable business service until the primary system returns. For each critical Salesforce-dependent process, define what “good enough during an outage” means.

The stop condition is important. A continuity plan that tells people to keep working at any cost can create a second incident: duplicated orders, conflicting case updates, missing approvals, or sensitive information stored in unapproved tools.

Know how Salesforce communicates an incident

Your plan should define an authoritative status source. Salesforce documents the Trust Status site as its source for service availability and performance information. Salesforce also provides Trust notifications through email or SMS for service issues, maintenance, and product releases. The current overview is available in Salesforce Help: Trust Status.

Salesforce’s Incident Trust Communications article explains that the company can use the Trust site, Trust Notifications, informational messages, Help banners, incident alert emails, and live webinars to communicate critical unplanned incidents and remediation progress.

A good continuity plan does not ask every employee to interpret status pages independently. Assign an incident owner or small incident team to verify the affected instance or service, summarize what is known, and publish internal updates on a defined cadence.

Make the plan instance-specific

Salesforce status is not one global binary state. Your organization should know which Salesforce instance or service identifiers matter. Salesforce’s View Instance Information for Your Salesforce Organization guidance, updated August 4, 2026, explains how to find the instance in Setup under Company Information or by using the Salesforce Status site.

Salesforce 也指出，其 Trust 網站會按受影響的實例和服務報告事件和維護事件。 「檢查正在進行的事件或維護」指南顯示，事件記錄包含受影響的實例和服務，以及狀態和時間資訊。

因此，您的連續性運作手冊應記錄生產組織的相關網域和實例詳細信息，以及對您的營運至關重要的任何單獨監控的 Salesforce 產品，例如 Marketing Cloud 或 Commerce 服務。

圍繞受控資料採集設計備用工作流程

最實用的備選方案通常並非替換CRM系統，而是一種可控的方法來保存維持緊急工作所需的最低限度資訊。這可以是已核准的電子表格、服務台佇列、內部表單、協作管道、電話流程，或其他已納入組織安全和保留策略的系統。

備用方法應定義：

• 哪些欄位是必填項目？
• 誰可以建立或修改臨時記錄；
• 每個記錄如何獲得唯一的臨時識別碼；
• 哪些敏感資料絕對不能複製到 Salesforce 外部；
• 如何記錄時間、客戶身分、所有者和操作歷史；
• 在將資料重新輸入 Salesforce 之前，如何偵測重複項。

計劃這一部分運作良好的最佳標誌是，恢復團隊之後能夠回答「Salesforce 不可用期間發生了什麼變化？」這個問題，而無需依賴記憶、聊天記錄或散落在多個團隊中的手寫筆記。

備份有助於恢復，但不能取代業務連續性。

Salesforce建議將常規備份策略作為資料管理和安全的一部分。其2026年4月2日發布的指南《Salesforce資料備份最佳實務》區分了業務資料（例如記錄和文件）和元資料（例如自訂欄位、版面配置、報表、儀表板、Apex和Visualforce）。

Salesforce 列出了多種原生備份方法，包括 Salesforce Backup、資料匯出服務、資料載入器匯出和報表匯出。其「從 Salesforce 匯出備份資料」文件指出，標準資料匯出可以根據版本按週或按月產生基於 CSV 的備份。

然而，備份是一種復原控制措施，而非故障期間的運作模式。備份並不能自動提供可用的 Salesforce 即時替代方案。大型導出資料可能過於陳舊、範圍過廣、過於敏感，或難以安全地用於第一線業務的連續性。請事先確定在故障期間是否確實需要匯出數據，並採取相應的保護措施。

將恢復目標與持續性目標分開

業務連續性目標描述了 Salesforce 不可用時業務如何運作。恢復目標描述如何恢復正常運作以及如何協調臨時工作。

針對每個流程，至少記錄三個實際目標：

• 最大可容忍中斷時間：在業務影響變得不可接受之前，流程可以中斷多久。
• 臨時營運目標：在此期間必須維持的最低服務水準。
• 對帳目標：服務恢復後，臨時記錄必須以多快的速度進行驗證並輸入 Salesforce。

這些目標應該由業務負責人設定，而不是基於通用的IT假設。兩小時的容錯時間對一個部門來說可能合理，但對另一個部門來說則不可接受。

故障發生前分配決策權

如果人們知道任務內容，卻不清楚誰擁有相應的權限，計劃就會進展緩慢。因此，需要為事件聲明、回退方案啟動、客戶溝通、安全性異常處理、供應商升級、恢復驗證以及最終決定是否恢復正常流程等環節定義指定角色或基於角色的所有權。

至少應有一個人能夠啟動業務連續性模式，另一人能夠批准恢復正常服務。對於影響重大的流程，應避免僅由一人負責操作；關鍵職位應指定備用人員。

測試的是業務成果，而不僅僅是文件是否被閱讀。

NIST SP 800-34 Rev. 1 將測試、訓練、演練和計劃維護作為應急計劃的核心要素。因此，Salesforce 連續性測試應模擬實際的存取權中斷情況，並衡量實際效能。

有用的測試標準包括：

• 事件負責人確定正確的 Salesforce 執行個體或服務；
• 關鍵團隊在目標時間內收到啟動訊息；
• 使用者無需單獨詢問 IT 部門即可找到已批准的備用方案；
• 臨時記錄包含必填欄位和所有權資訊；
• 未經批准的敏感資料不會被複製到備用系統中；
• 可以將部分臨時記錄與 Salesforce 進行核對，且不會出現重複項；
• 團隊可以解釋誰有權宣布恢復完成。

如果桌面演練僅確認參與者能夠開啟計劃，則無法證明流程的連續性。更好的演練應該證明人們能夠執行工作流程並順利恢復。

要知道何時需要改變計劃。

不要等到系統真正宕機才發現計畫已經過時。在 Salesforce 架構、關鍵整合、業務流程、合規性要求、團隊所有權、備份策略、呼叫中心路由或客戶溝通管道發生重大變更後，應立即審查計畫。

當測試結果顯示反覆出現的問題時，應改變方法。例如，員工無視官方的備用方案創建不受控制的電子表格；由於臨時記錄缺乏唯一標識符導致恢復時間過長；或者業務團隊發現既定的業務連續性目標不足以滿足實際客戶需求。

一個有效的計劃應該包含版本所有權和審核觸發機制。 「每年審核一次」總比沒有好，但「每年審核一次，並在 Salesforce、整合、所有權或流程發生重大變更時進行審核」則更具彈性。

該計劃無法保證什麼

任何業務連續性計劃都無法保證在每次 Salesforce 服務中斷期間業務都能完全不間斷。某些故障可能同時影響連接的系統、身分提供者、網路、通訊工具或公有雲服務。嚴重或持續時間較長的事件也可能超出手動回退流程的能力範圍。

此外，還存在安全性和資料品質方面的限制。將敏感的 Salesforce 資料移轉到緊急工具可能違反政策或法規。離線操作會導致決策過時、記錄衝突和重複交易。對於某些高風險流程，最安全的連續性選擇是受控暫停，而不是手動繼續運行。

因此，成熟的計劃會明確規定預期運行時間範圍和升級閾值。如果停機時間超出預期、備用佇列過大或資料完整性無法維持，領導階層應從常規的業務連續性程序轉向更廣泛的危機管理決策。

如何判斷您的 Salesforce 業務連續性計劃是否已準備就緒

如果一項現實的演練能夠證明以下四件事，那麼該計劃就進展順利：企業能夠確定哪些事情是重要的，以商定的最低水平繼續開展必要的工作，保留可靠的臨時記錄，並在不丟失或重複重要活動的情況下返回 Salesforce。

使用最終準備檢查：

• 每個依賴 Salesforce 的關鍵流程都有負責人和故障容忍度。
• 生產實例和官方 Salesforce 狀態來源都已記錄在案。
• 備用工具已獲得批准，用戶可以輕鬆存取並理解它們。
• 臨時資料具有已定義的模式、識別碼、存取策略和協調方法。
• 事件處理和客戶溝通責任明確規定。
• 備份被視為復原控制措施，並與運行回退分開進行測試。
• 團隊已經演練了該計劃，並記錄了可衡量的差距。
• 何時放棄手動處理併升級處理，有明確的規則。

Salesforce業務連續性計畫的成功不在於其紙面上的詳盡程度，而在於其在壓力下能夠產生可預測的行為。最有效的計劃應規模適中，便於執行；足夠詳細，可防止不安全的臨時應對；並且經過充分測試，使組織能夠在真正的故障發生之前了解自身的局限性。