Klokken 9:10 forsøger salgsteamet hos Northstar Office Supply at åbne Salesforce og modtager en servicefejl. Nye ordrer ankommer via e-mail, kundeservicemedarbejdere kan ikke se kontohistorik, og en integration, der sender ordreopdateringer til lageret, forsøger at køre igen i baggrunden. Ingen ved endnu, om afbrydelsen vil vare fem minutter eller resten af dagen.
Illustrativt scenario: Northstar Office Supply er en fiktiv virksomhed, der bruges i hele denne artikel. Det er ikke en kundeudtalelse, en hændelsesrapport eller et testresultat. Eksemplet viser, hvordan en virkelig organisation kan omdanne forretningskontinuitetskoncepter til en driftsplan.
En nyttig nedetidsplan for Salesforce garanterer ikke, at alle processer vil fortsætte normalt. Den definerer, hvilket arbejde der skal fortsættes, hvilket arbejde der kan vente, hvordan folk vil kommunikere, hvordan integrationer vil blive kontrolleret, og hvordan poster vil blive afstemt efter genoprettelse. Denne vejledning bruger den aktuelle Salesforce-dokumentation, der blev kontrolleret den 16. september 2026, plus NIST-vejledning til beredskabsplanlægning. Produktnavne, funktioner, tilgængelighed, kontrakter og serviceforpligtelser kan ændres, så valider din egen Salesforce-udgave og aftaler.
Salesforces nuværende dokumentation for robusthed skelner vigtigst mellem udbyderens kontinuitetsprogram og kundens egen plan for forretningskontinuitet. Salesforces Enterprise Resilience/BCP Summary, opdateret 23. juli 2026, beskriver programmer på udbyderniveau for risikostyring, forretningskontinuitet, krisestyring, tredjepartsrisiko, cyberrobusthed, hændelsesrespons og katastrofeberedskab. Den erstatter ikke en kundeplan for bemanding, manuelt arbejde, kundekommunikation, integrationer eller dataafstemning.
En anden aktuel ændring er Salesforce-hjælpesiden for Advanced Cross-Region Continuity (ACRC) fra 9. september 2026. Salesforce oplyser, at ACRC er et premium Hyperforce-tilbud til ekstraordinære regionale katastrofer, og at det blev omdøbt fra Out of Region Disaster Recovery. Siden viser RTO- og RPO-mål på 12 timer og 4 timer for ACRC, bemærker, at nogle tjenester endnu ikke understøttes, og angiver, at sandbox-organisationer ikke er dækket. Disse oplysninger kan have betydning, hvis en ældre runbook refererer til det tidligere produktnavn eller antager, at en betalt gendannelsesmulighed beskytter alle organisationer og funktioner.
For de fleste virksomheder forbliver det praktiske udgangspunkt en kundeejet plan, der fungerer under en almindelig Salesforce-tjenesteafbrydelse, et planlagt vedligeholdelsesvindue, en identitetsfejl, et netværksproblem eller et integrationsafbrydelse. En udbydergendannelsesfunktion kan reducere risikoen; den kan ikke bestemme dine forretningsprioriteter for dig.
Skriv resultatet i operationelle termer. Northstars mål kunne være: "Under et Salesforce-nedbrud skal du holde hastende kundeanmodninger, ordreforpligtelser og lageroverdragelser i gang; forhindre dobbeltopfyldelse; kommunikere status hvert 30. minut; og afstemme alle midlertidige poster efter servicereturneringer." Denne udtalelse er mere nyttig end "opretholde Salesforce-tilgængelighed", fordi sidstnævnte for det meste er uden for kundens kontrol.
En kontinuitetsplan bør give teamet mulighed for hurtigt at besvare fem spørgsmål:
NIST beskriver beredskabsplanlægning som en koordineret strategi med planer, procedurer og tekniske foranstaltninger til genoprettelse af informationssystemer, operationer og data efter en afbrydelse. Dens vejledning understreger evaluering af systemer og operationer for at bestemme krav og prioriteter. Brug denne idé som planlægningsramme, men skræddersy kontrollerne til dine Salesforce-produkter, processer, kontrakter og risikotolerance.
Start med en analyse af forretningsmæssige konsekvenser, ikke med en liste over Salesforce-objekter. Interview procesejere fra salg, service, økonomi, ordrebehandling, compliance og IT. Spørg, hvad der stopper, hvis Salesforce ikke er tilgængeligt, hvad der kan udføres fra en eksisterende kilde, og hvad der bliver farligt, hvis det indtastes senere uden en kontrol.
For Northstar kunne den første opgørelse se sådan ud:
| Behandle | Påvirkning under nedetid | Midlertidig metode | Beviser for inddrivelse |
|---|---|---|---|
| Hastefulde kundesager | Serviceforpligtelser og eskaleringer kan blive overset | Godkendt telefonkø og begrænset offlineformular | Sagsnummer, ejer, tidsstempel, prioritet og opfølgningsstatus |
| Nye ordrer | Ordrer kan blive forsinket eller duplikeret | Kontrolleret ordreregister med unikke midlertidige ID'er | Kundebekræftelse, vareliste, prisgodkendelse og opfyldelsesresultat |
| Overdragelse af lager | Forsendelser mangler muligvis en autoritativ anmodning | Manuel godkendelse af frigivelse fra en autoriseret leder | Midlertidigt ID matchet med den endelige Salesforce-ordre |
| Salgsaktivitet | Synligheden af pipelinen bliver forældet | Eksisterende mødenotater og et lille godkendt intake-ark | Sidste kontakt, næste trin, ejer og kildetidsstempel |
| Planlagte integrationer | Genforsøg kan skabe dubletter eller overbelaste slutpunkter | Pause, karantæne eller hastighedsgrænse i henhold til runbooken | Kødybde, status, afspilningsbeslutning og afstemningsrapport |
Placer ikke følsomme kundedata i et improviseret personligt regneark eller en chattråd. Definer en godkendt midlertidig lagring, adgangsliste, opbevaringsperiode og sletningsprocedure. Hvis en manuel formular er uundgåelig, skal du indsamle de minimumsdata, der kræves for at holde den kritiske proces i gang.
Giv hver kritisk proces et Recovery Time Objective (RTO) og et Recovery Point Objective (RPO). RTO angiver, hvor hurtigt processen har brug for en brugbar løsning eller gendannet tjeneste. RPO angiver, hvor mange nye data virksomheden har råd til at miste eller genskabe. Dette er forretningsbeslutninger, ikke gæt om, hvor hurtigt Salesforce vil løse en hændelse.
Northstar kan muligvis sætte en RTO på én time for hastende kundesager, en RTO på fire timer for overdragelser til lageret og en RTO på én hverdag for rutinemæssige pipelineopdateringer. De kan sætte en RPO på nul for en beslutning om betalingsgodkendelse, samtidig med at de accepterer, at rutinemæssige salgsnotaer skal genindtastes fra en tidsstemplet midlertidig log. Tallene er fiktive eksempler; dine økonomi-, juridiske og driftsmæssige ejere skal godkende målene.
Dokumentér antagelsen bag hvert mål. En times vagthavende vagthavende kan kræve en bemandet telefonkø, en uddannet vagthavende leder og en forhåndsgodkendt formular. Hvis disse ressourcer ikke er tilgængelige i weekenderne, er målet ikke en plan – det er en ambition.
Definer en kort aktiveringsprocedure, så medarbejderne ikke improviserer forskellige reaktioner. Den første person, der bemærker problemet, bør registrere UTC-tiden, berørte brugere, berørte produkter, fejlmeddelelse og forretningsproces. En hændelsesleder kontrollerer derefter, om problemet er bredt eller lokalt.
Salesforces Trust-websted giver oplysninger i realtid og historisk information om tilgængelighed og ydeevne for produkter og instanser. Den nuværende hjælpevejledning forklarer, hvordan man identificerer en instans via Opsætning > Virksomhedsoplysninger eller ved at søge efter et præfiks "Mit domæne", og hvordan man fortolker statusfarver: grøn for Tilgængelig, gul for Serviceforringelse, lilla for Vedligeholdelse og rød for Serviceafbrydelse. Salesforce anbefaler også Trust-meddelelser og siger, at man skal kontakte support, når et kerneproblem har overskredet 10 minutter uden at blive vist på webstedet.
Tillid er et vigtigt bevis, men en tydelig statusside beviser ikke, at dit eget netværk, din identitetsudbyder, din browser, dine API-legitimationsoplysninger eller dit integrationsslutpunkt er i orden. Northstar bør teste en anden bruger, et andet netværk og en skrivebeskyttet handling med lav risiko, hvor politikken tillader det. Hvis kun ét kontor er berørt, kan aktivering af en virksomhedsomfattende manuel proces skabe unødvendigt arbejde.
Kald løsningen en navngiven tilstand, f.eks. "Salesforce-degraderede operationer", og definer dens start- og slutkriterier. Medarbejdere skal vide, hvor de kan finde den aktuelle formular, hvem der godkender undtagelser, og hvilke handlinger der er forbudte. En god løsning er bevidst mere snæver end normale operationer.
For Northstar kan forringede operationer muliggøre hastesager, godkendte ordrer og forsendelsesholdninger, samtidig med at rabatter, kontofletninger, masseopdateringer og ikke-essentielle dataimporter sættes på pause. Planen bør tildele en midlertidig identifikator til hver manuel transaktion. En nyttig identifikator kan omfatte dato, teamkode og sekvensnummer, men det nøjagtige format bør vælges af organisationen og kontrolleres for kollisioner.
Brug funktionsadskillelse ved handlinger med stor indflydelse. Den person, der modtager en ordre, bør ikke være den eneste person, der godkender en forsendelse af høj værdi. Kræv en ekstra kontrol for refusioner, ændringer af bankoplysninger eller beslutninger om kundeidentitet. Registrer godkendelser med tidspunkt, navn og årsag. Disse kontroller kan føles langsommere, men de reducerer risikoen for at forvandle et kortvarigt afbrydelse til en hændelse vedrørende svindel, privatlivets fred eller opfyldelse.
Gør integrationer til en del af kontinuitetsplanen, ikke et bilag, der kun ejes af udviklere. Angiv alle indgående og udgående flow, dets trigger, dataejer, kø- eller gentagelsesadfærd, duplikatrisiko og forretningsmæssige konsekvenser. Inkluder planlagte job, webhooks, middleware, event streams, identitetsudbydere, rapportudtræk og menneskelige uploads.
Under et Salesforce-nedbrud kan automatiske genforsøg være nyttige eller skadelige. Hvis destinationen ikke er tilgængelig, kan begrænsede genforsøg med backoff være passende. Hvis kilden accepterer meddelelser, men Salesforce ikke gør, skal meddelelserne sættes i kø med et varigt tidsstempel og en idempotensnøgle. Hvis ingen af siderne kan bekræfte, om en skrivning lykkedes, skal afspilningen stoppes, indtil status er kendt. Antag aldrig, at en timeout betyder, at en transaktion ikke blev committet.
Northstars runbook kan instruere integrationsejeren i at sætte udgående job på pause efter tre mislykkede forsøg, bevare den oprindelige nyttelast, registrere det sidst bekræftede Salesforce-tidsstempel og forhindre manuel genindtastning, indtil køen er klassificeret. Den nøjagtige tærskel er et fiktivt eksempel. Indstil den ud fra observeret adfærd, udbydervejledning og forretningsrisiko.
Kontinuitet og backup løser relaterede, men forskellige problemer. En kontinuitetsprocedure holder virksomheden kørende under en afbrydelse. En backup hjælper med at gendanne data efter sletning, beskadigelse eller en anden tabshændelse. En backup giver ikke automatisk en live erstatning for Salesforce-applikationen, dens tilladelser, dens automatiseringer eller dens integrationer.
Salesforces vejledning til databackup beskriver backups som kopier, der er gemt separat med henblik på gendannelse, og anbefaler regelmæssige backups, flere placeringer og testet gendannelse. Beslut, hvilke poster, metadata, filer og revisionsoplysninger virksomheden skal gendanne, hvor længe de skal opbevares, og hvem der kan godkende en gendannelse. Test, om de gendannede data kan matches med de midlertidige poster, der er oprettet under nedetid.
Hvis din organisation overvejer Advanced Cross-Region Continuity, skal du læse de aktuelle Salesforce FAQ omhyggeligt. Salesforce oplyser, at tilbuddet er begrænset til Hyperforce, at nogle tjenester endnu ikke understøttes, og at en genoprettelseshændelse gør organisationen utilgængelig, mens der finder nødberedskabsoperationer sted. Det oplyses også, at datalagringsforpligtelser på landeniveau kan blive påvirket, når primære og sekundære regioner er i forskellige lande. Dette er planlægningsbegrænsninger, ikke fodnoter.
Tildel én incident lead, én teknisk lead, én forretningsdrifts lead og én kommunikationsejer. Definer sikkerhedskopier for hver rolle. Hold budskabet faktuelt: hvad er berørt, hvornår det startede, hvad brugerne skal gøre, hvad de ikke må gøre, hvornår den næste opdatering kommer, og hvor godkendte instruktioner findes.
Angiv ikke en gendannelsestid, som Salesforce ikke har bekræftet. Bed ikke kunder om at sende oplysninger gentagne gange, hvis den oprindelige anmodning muligvis allerede er i kø. For Northstar kan kundebeskeden angive, at ordreindgangen foregår via en midlertidig kanal, at kunderne skal bruge én bestemt kontaktmetode, og at den næste statusopdatering vil blive udsendt på et defineret tidspunkt.
Inkluder interne eskaleringstærskler. For eksempel kan en kritisk proces, der påvirker kunden, straks sende hændelseskunden til en kunde, mens en forældet rapport kan vente til den næste planlagte gennemgang. Link planen til aktuelle Salesforce Trust-notifikationer og organisationens supportberettigelse. Et telefontræ, der ikke længere matcher arbejdsstyrken, er ikke en kommunikationsplan.
Start med en bordøvelse. Giv Northstars team en fiktiv prompt som: "Kl. 9:10 er Salesforce ikke tilgængelig for service- og salgsteams; lagerintegrationsjob viser gentagne fejl; Trust rapporterer en serviceafbrydelse." Bed hver rolle om at udføre de første 30 minutter af planen ved kun at bruge de dokumenterede materialer.
Mål observerbare resultater:
Efter tabletop-testen skal du køre en kontrolleret teknisk test i et sandkasse- eller ikke-produktionsmiljø, hvor scenariet er sikkert og understøttet. Du må ikke påstå, at en sandkasseøvelse beviser produktionsfailover. Salesforces ACRC-dokumentation angiver eksplicit, at sandkasseorganisationer ikke er dækket af ACRC, hvilket er en påmindelse om at teste det faktiske gendannelsesomfang i stedet for at udlede det fra et lavere miljø.
Genoprettelsen begynder, når den potentielle hændelse har pålideligt bevis for, at den berørte Salesforce-tjeneste er brugbar – ikke blot når en bruger kan indlæse loginsiden. Bekræft statussiden, test med en lille autoriseret handling, tjek integrationer, og annoncer en kontrolleret tilbagevenden til normal drift.
Afstem i en rækkefølge, der beskytter registreringssystemet:
En plan kan ikke tvinge Salesforce til at gendanne hurtigere, garantere, at en integrationsskrivning er fuldført, eller få et ikke-understøttet produkt til at opføre sig som et understøttet produkt. Den kan ikke erstatte kontraktuel gennemgang, privatlivsanalyse, backuptestning eller sikkerhedshændelsesrespons. En manuel løsning kan også medføre transskriptionsfejl, problemer med adgangskontrol, forsinket indtægtsføring og kundeforvirring.
Planen bør derfor indeholde en beslutning om at stoppe. Hvis teamet ikke kan verificere en kundes identitet, integriteten af en betalingsinstruktion, status for en forsendelse eller destinationen for en dataoverførsel, skal handlingen tilbageholdes til en autoriseret gennemgang. Kontinuitet er ikke det samme som at fortsætte enhver transaktion for enhver pris.
For Northstar er succes ikke "Salesforce går aldrig ned". Succes er, at teamet genkender forstyrrelsen, beskytter kritisk arbejde, undgår usikker improvisation, fører en sporbar registrering af midlertidige handlinger og vender tilbage til normal drift uden skjulte dubletter eller manglende forpligtelser. Det er den standard, en praktisk Salesforce-forretningskontinuitetsplan bør opfylde.
Gennemgå bemærkelsesværdige Salesforce-nedbrud i 2025, hvad der fejlede, hvor længe udvalgte hændelser varede, og de praktiske erfaringer om modstandsdygtighed, som teams kan anvende.
Byg en praktisk Salesforce-plan for kontinuitet i nedetid med konsekvensanalyse, RTO/RPO-mål, manuelle løsninger, integrationskontroller og genoprettelsestjek.
Lær, hvordan du kontakter Salesforce Support under et større nedbrud: Tjek tillidsstatus, vælg den rigtige kanal, åbn en stærk sag, og spor gendannelse.
Fejlfind Salesforce Workbench login, REST Explorer, timeout, 503, API-version og begræns fejl under nedetid med en praktisk diagnostisk tjekliste.
StoreForce issues can disrupt scheduling, timekeeping, and employee workflows. Learn how to assess impact, keep stores operating, verify recovery, and know when to escalate.
Forstå de vigtigste årsager til udbredt nedetid i skyen, hvordan fejl opstår i flere omgange, hvad man skal kontrollere først, og hvordan man designer en mere robust genopretningsplan.
Hvis Datorama eller Marketing Cloud Intelligence ser ud til at være nede, kan du bruge denne evidensbaserede tjekliste til at verificere nedbruddet, beskytte rapporteringskvaliteten og vide, hvornår data er troværdige igen.
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.
Et AWS-nedbrud betyder ikke automatisk, at Salesforce er nede. Lær, hvordan Hyperforce, regioner, instanser og Salesforce Trust afgør, om din organisation er berørt.
