At 9:10 a.m., the sales team at Northstar Office Supply tries to open Salesforce and receives a service error. New orders are arriving by email, customer-service agents cannot see account histories, and an integration that sends order updates to the warehouse is retrying in the background. Nobody yet knows whether the disruption will last five minutes or the rest of the day.
Illustrative scenario: Northstar Office Supply is a fictional company used throughout this article. It is not a customer testimonial, incident report, or test result. The example shows how a real organization could turn business continuity concepts into an operating plan.
A useful Salesforce downtime plan does not promise that every process will continue normally. It defines which work must continue, which work can wait, how people will communicate, how integrations will be controlled, and how records will be reconciled after recovery. This guide uses current Salesforce documentation checked on September 16, 2026, plus NIST contingency-planning guidance. Product names, features, availability, contracts, and service commitments can change, so validate your own Salesforce edition and agreements.
Salesforce’s current resilience documentation makes an important distinction between the provider’s continuity program and the customer’s own business continuity plan. Salesforce’s Enterprise Resilience/BCP Summary, updated July 23, 2026, describes provider-level programs for risk management, business continuity, crisis management, third-party risk, cyber resilience, incident response, and disaster recovery. It does not replace a customer plan for staffing, manual work, customer communications, integrations, or data reconciliation.
Another current change is the September 9, 2026 Salesforce Help page for Advanced Cross-Region Continuity (ACRC). Salesforce says ACRC is a premium Hyperforce offering for extraordinary regional disasters, and that it was renamed from Out of Region Disaster Recovery. The page lists RTO and RPO targets of 12 hours and 4 hours for ACRC, notes that some services are not yet supported, and states that sandbox orgs are not covered. Those details may matter if an older runbook refers to the former product name or assumes that a paid recovery option protects every org and feature.
For most businesses, the practical starting point remains a customer-owned plan that works during an ordinary Salesforce service disruption, a planned maintenance window, an identity failure, a network problem, or an integration outage. A provider recovery capability can reduce risk; it cannot decide your business priorities for you.
Write the outcome in operational terms. Northstar’s goal might be: “During a Salesforce outage, keep urgent customer requests, order commitments, and warehouse handoffs moving; prevent duplicate fulfillment; communicate status every 30 minutes; and reconcile every temporary record after service returns.” That statement is more useful than “maintain Salesforce availability,” because the latter is mostly outside the customer’s control.
A continuity plan should let the team answer five questions quickly:
NIST describes contingency planning as a coordinated strategy of plans, procedures, and technical measures for recovering information systems, operations, and data after a disruption. Its guidance emphasizes evaluating systems and operations to determine requirements and priorities. Use that idea as the planning frame, but tailor the controls to your Salesforce products, processes, contracts, and risk tolerance.
Start with a business impact analysis, not with a list of Salesforce objects. Interview process owners from sales, service, finance, fulfillment, compliance, and IT. Ask what stops if Salesforce is unavailable, what can be performed from an existing source, and what becomes dangerous if entered later without a control.
For Northstar, the first inventory could look like this:
| Process | Impact during downtime | Temporary method | Recovery evidence |
|---|---|---|---|
| Urgent customer cases | Service commitments and escalations may be missed | Approved phone queue and restricted offline form | Case number, owner, timestamp, priority, and follow-up status |
| New orders | Orders may be delayed or duplicated | Controlled order register with unique temporary IDs | Customer confirmation, item list, price approval, and fulfillment result |
| Warehouse handoff | Shipments may lack an authoritative request | Manual release approval from an authorized manager | Temporary ID matched to the final Salesforce order |
| Sales activity | Pipeline visibility becomes stale | Existing meeting notes and a small approved intake sheet | Last contact, next step, owner, and source timestamp |
| Scheduled integrations | Retries can create duplicates or overload endpoints | Pause, quarantine, or rate-limit according to the runbook | Queue depth, status, replay decision, and reconciliation report |
Do not put sensitive customer data into an improvised personal spreadsheet or chat thread. Define an approved temporary store, access list, retention period, and deletion procedure. If a manual form is unavoidable, collect the minimum data required to keep the critical process moving.
Give each critical process a Recovery Time Objective (RTO) and Recovery Point Objective (RPO). RTO is how quickly the process needs a usable workaround or restored service. RPO is how much recent data the business can afford to lose or re-create. These are business decisions, not guesses about how quickly Salesforce will resolve an incident.
Northstar might set a one-hour RTO for urgent customer cases, a four-hour RTO for warehouse handoffs, and a one-business-day RTO for routine pipeline updates. It might set an RPO of zero for a payment authorization decision, while accepting that routine sales notes must be re-entered from a timestamped temporary log. The numbers are fictional examples; your finance, legal, and operations owners must approve the targets.
Document the assumption behind each target. A one-hour RTO may require a staffed phone queue, a trained duty manager, and a pre-approved form. If those resources are not available on weekends, the target is not a plan—it is an aspiration.
Define a short activation procedure so employees do not improvise different responses. The first person who notices the issue should record the UTC time, affected users, affected products, error message, and business process. An incident lead then checks whether the problem is broad or local.
Salesforce’s Trust site provides real-time and historical information about availability and performance for products and instances. Its current help guidance explains how to identify an instance through Setup > Company Information or by searching a My Domain prefix, and how to interpret status colors: green for Available, yellow for Service Degradation, purple for Maintenance, and red for Service Disruption. Salesforce also recommends Trust notifications and says to contact Support when a core issue has exceeded 10 minutes without appearing on the site.
Trust is essential evidence, but a clear status page does not prove that your own network, identity provider, browser, API credentials, or integration endpoint is healthy. Northstar should test a second user, a second network, and a low-risk read-only action where policy allows. If only one office is affected, activating a company-wide manual process may create unnecessary work.
Наречете заобиколното решение именуван режим, например „Salesforce degraded operations“ (Операции с влошени характеристики на Salesforce) и дефинирайте критериите му за влизане и излизане. Служителите трябва да знаят къде да намерят текущия формуляр, кой одобрява изключенията и кои действия са забранени. Доброто заобиколно решение е умишлено по-тясно от нормалните операции.
За Northstar, влошените операции могат да позволят спешни случаи, одобрени поръчки и задържане на доставки, като същевременно се паузират отстъпки, сливания на акаунти, групови актуализации и импортиране на несъществени данни. Планът трябва да присвои временен идентификатор на всяка ръчна транзакция. Полезен идентификатор може да включва дата, код на екипа и пореден номер, но точният формат трябва да бъде избран от организацията и проверен за колизии.
Използвайте разделяне на задълженията за действия с голямо въздействие. Лицето, получаващо поръчка, не трябва да е единственото лице, което одобрява пратка с висока стойност. Изисквайте втора проверка за възстановяване на суми, промени в банкови данни или решения, свързани с самоличността на клиента. Записвайте одобренията с час, име и причина. Тези контроли може да изглеждат по-бавни, но намаляват риска от превръщане на кратко прекъсване в измама, инцидент, свързан с поверителността или изпълнението на поръчките.
Направете интеграциите част от плана за непрекъснатост, а не приложение, собственост само на разработчиците. Избройте всеки входящ и изходящ поток, неговия тригер, собственик на данните, поведение при опашка или повторен опит, риск от дублиране и бизнес последици. Включете планирани задачи, уеб кукички, междинен софтуер, потоци от събития, доставчици на идентичност, извлечения от отчети и качвания от хора.
По време на прекъсване на Salesforce, автоматичните повторни опити могат да бъдат полезни или вредни. Ако дестинацията не е налична, ограничените повторни опити с backoff може да са подходящи. Ако източникът приема съобщения, но Salesforce не, поставете съобщенията в опашка с траен времеви печат и ключ за идемпотентност. Ако нито една от страните не може да потвърди дали записът е бил успешен, спрете повторното възпроизвеждане, докато състоянието не стане известно. Никога не приемайте, че изчакването означава, че транзакцията не е била извършена.
Наръчникът с инструкции на Northstar може да инструктира собственика на интеграцията да постави на пауза изходящите задачи след три неуспешни опита, да запази оригиналния полезен товар, да запише последния потвърден времеви отпечатък на Salesforce и да предотврати ръчно повторно влизане, докато опашката не бъде класифицирана. Точният праг е измислен пример. Задайте го въз основа на наблюдавано поведение, насоки от доставчика и бизнес риск.
Осигуряването на непрекъснатост и архивирането решават свързани, но различни проблеми. Процедурата за осигуряване на непрекъснатост поддържа бизнеса в експлоатация по време на прекъсване. Архивирането помага за възстановяване на данни след изтриване, повреда или друго събитие, водещо до загуба. Архивирането не осигурява автоматично живо заместване на приложението Salesforce, неговите разрешения, автоматизации или интеграции.
Ръководството за архивиране на данни на Salesforce описва резервните копия като копия, съхранявани отделно за възстановяване, и препоръчва редовно архивиране, множество местоположения и тествано възстановяване. Решете кои записи, метаданни, файлове и одитна информация бизнесът трябва да възстанови, колко дълго трябва да се съхраняват и кой може да разреши възстановяване. Тествайте дали възстановените данни могат да бъдат съпоставени с временните записи, създадени по време на престой.
Ако вашата организация обмисля Advanced Cross-Region Continuity, прочетете внимателно текущите ЧЗВ на Salesforce. Salesforce съобщава, че предлагането е ограничено до Hyperforce, някои услуги все още не се поддържат и събитие за възстановяване прави организацията недостъпна, докато се извършват операции за възстановяване след бедствие. Също така се казва, че ангажиментите за съхранение на данни на ниво държава може да бъдат засегнати, когато основните и вторичните региони са в различни държави. Това са ограничения за планиране, а не бележки под линия.
Назначете един ръководител за инциденти, един технически ръководител, един ръководител за бизнес операции и един отговорник за комуникациите. Определете резервни копия за всяка роля. Поддържайте съобщението фактическо: какво е засегнато, кога е започнало, какво трябва да правят потребителите, какво не трябва да правят, кога ще пристигне следващата актуализация и къде се намират одобрените инструкции.
Не обявявайте време за възстановяване, което Salesforce не е потвърдил. Не изисквайте от клиентите да изпращат информация многократно, ако първоначалната заявка може вече да е в опашка. За Northstar съобщението до клиента може да гласи, че приемането на поръчки се извършва чрез временен канал, че клиентите трябва да използват един определен метод за контакт и че следващата актуализация на състоянието ще бъде издадена в определено време.
Включете вътрешни прагове за ескалация. Например, критичен процес, който влияе върху клиента, може незабавно да изпрати сигнал до потенциалния клиент за инцидент, докато остарял отчет може да изчака следващия планиран преглед. Свържете плана с текущите известия на Salesforce Trust и правата за поддръжка на организацията. Телефонно дърво, което вече не съответства на работната сила, не е комуникационен план.
Започнете с упражнение на маса. Дайте на екипа на Northstar измислена задача, например: „В 9:10 ч. Salesforce не е на разположение за екипите за обслужване и продажби; задачите за интеграция на складове показват повтарящи се повреди; Trust съобщава за прекъсване на услугата.“ Помолете всяка роля да изпълни първите 30 минути от плана, използвайки само документираните материали.
Измерете наблюдаемите резултати:
След теста, проведете контролиран технически тест в среда с пясъчник или непроизводствена среда, където сценарият е безопасен и поддържан. Не твърдете, че упражнение в пясъчник доказва превключване на производствения срив. Документацията на ACRC на Salesforce изрично посочва, че организациите с пясъчник не са обхванати от ACRC, което е напомняне да се тества действителният обхват на възстановяване, а не да се прави извод за него от по-ниска среда.
Възстановяването започва, когато потенциалният клиент при инцидента има надеждни доказателства, че засегнатата услуга на Salesforce е използваема, а не само когато потребителят може да зареди страницата за вход. Потвърдете страницата за състоянието, тествайте с малко оторизирано действие, проверете интеграциите и обявете контролирано връщане към нормални операции.
Съгласувайте в последователност, която защитава системата за водене на записи:
Планът не може да принуди Salesforce да се възстанови по-бързо, да гарантира, че записът за интеграция е завършен, или да накара неподдържан продукт да се държи като поддържан. Той не може да замести договорния преглед, анализа на поверителността, тестването на резервни копия или реагирането на инциденти със сигурността. Ръчното решение може също да доведе до грешки при транскрипцията, проблеми с контрола на достъпа, забавено признаване на приходи и объркване на клиентите.
Следователно планът трябва да включва решение за спиране. Ако екипът не може да провери самоличността на клиента, целостта на платежната инструкция, статуса на пратката или местоназначението на трансфера на данни, действието се задържа за оторизиран преглед. Непрекъснатостта не е същото като продължаване на всяка транзакция на всяка цена.
За Northstar успехът не е „Salesforce никога не спира“. Успехът е екипът да разпознае прекъсването, да защити критичната работа, да избегне опасна импровизация, да поддържа проследим запис на временните действия и да се връща към нормални операции без скрити дубликати или липсващи ангажименти. Това е стандартът, на който трябва да отговаря един практичен план за непрекъснатост на бизнеса на Salesforce.
Прегледайте забележителните прекъсвания на Salesforce през 2025 г., какви са били неуспешните действия, колко дълго са продължили избрани инциденти и практическите уроци за устойчивост, които екипите могат да приложат.
Build a practical Salesforce downtime continuity plan with impact analysis, RTO/RPO targets, manual workarounds, integration controls, and recovery checks.
Learn how to contact Salesforce Support during a major outage: check Trust Status, choose the right channel, open a strong case, and track recovery.
Отстраняване на неизправности при влизане в Salesforce Workbench, REST Explorer, изчакване, 503, версия на API и ограничаване на грешките по време на престой с практичен диагностичен контролен списък.
StoreForce issues can disrupt scheduling, timekeeping, and employee workflows. Learn how to assess impact, keep stores operating, verify recovery, and know when to escalate.
Разберете основните причини за широко разпространените прекъсвания на работата в облака, как се натрупват повреди, какво да проверите първо и как да проектирате по-устойчив план за възстановяване.
Ако Datorama или Marketing Cloud Intelligence изглеждат неработещи, използвайте този контролен списък, базиран на доказателства, за да проверите прекъсването, да защитите качеството на отчитането и да разберете кога данните отново са надеждни.
A practical look at how Heroku outages can affect deployed apps, dynos, routing, databases, deploys, Heroku Connect, logs, and recovery.
Understand how Salesforce and AWS connect through Hyperforce, integrations, networking, data residency, outages, and shared operational responsibilities.
Прекъсването на AWS не означава автоматично, че Salesforce не работи. Научете как Hyperforce, регионите, инстанциите и Salesforce Trust определят дали вашата организация е засегната.
