Klokken 09:10 prøver salgsteamet hos Northstar Office Supply å åpne Salesforce, men får en servicefeil. Nye bestillinger kommer inn på e-post, kundeservicemedarbeidere kan ikke se kontohistorikk, og en integrasjon som sender bestillingsoppdateringer til lageret prøver på nytt i bakgrunnen. Ingen vet ennå om avbruddet vil vare i fem minutter eller resten av dagen.
Illustrativt scenario: Northstar Office Supply er et fiktivt selskap som brukes gjennom hele denne artikkelen. Det er ikke en kundevurdering, hendelsesrapport eller testresultat. Eksemplet viser hvordan en ekte organisasjon kan gjøre forretningskontinuitetskonsepter om til en driftsplan.
En nyttig nedetidsplan for Salesforce garanterer ikke at alle prosesser vil fortsette normalt. Den definerer hvilket arbeid som må fortsette, hvilket arbeid som kan vente, hvordan folk skal kommunisere, hvordan integrasjoner skal kontrolleres og hvordan poster skal avstemmes etter gjenoppretting. Denne veiledningen bruker gjeldende Salesforce-dokumentasjon kontrollert 16. september 2026, pluss NIST-veiledning for beredskapsplanlegging. Produktnavn, funksjoner, tilgjengelighet, kontrakter og tjenesteforpliktelser kan endres, så valider din egen Salesforce-utgave og avtaler.
Salesforces nåværende dokumentasjon for robusthet skiller viktig mellom leverandørens kontinuitetsprogram og kundens egen plan for forretningskontinuitet. Salesforces Enterprise Resilience/BCP Summary, oppdatert 23. juli 2026, beskriver programmer på leverandørnivå for risikostyring, forretningskontinuitet, krisehåndtering, tredjepartsrisiko, cyberrobusthet, hendelsesrespons og katastrofegjenoppretting. Den erstatter ikke en kundeplan for bemanning, manuelt arbeid, kundekommunikasjon, integrasjoner eller dataavstemming.
En annen aktuell endring er Salesforce-hjelpesiden for Advanced Cross-Region Continuity (ACRC) fra 9. september 2026. Salesforce sier at ACRC er et premium Hyperforce-tilbud for ekstraordinære regionale katastrofer, og at det ble omdøpt fra Out of Region Disaster Recovery. Siden viser RTO- og RPO-mål på 12 timer og 4 timer for ACRC, bemerker at noen tjenester ikke støttes ennå, og oppgir at sandkasseorganisasjoner ikke dekkes. Disse detaljene kan ha betydning hvis en eldre runbook refererer til det tidligere produktnavnet eller antar at et betalt gjenopprettingsalternativ beskytter alle organisasjoner og funksjoner.
For de fleste bedrifter er det praktiske utgangspunktet fortsatt en kundeeid plan som fungerer under et vanlig avbrudd i Salesforce-tjenesten, et planlagt vedlikeholdsvindu, en identitetsfeil, et nettverksproblem eller et integrasjonsavbrudd. En gjenopprettingsfunksjon for leverandøren kan redusere risikoen; den kan ikke bestemme forretningsprioriteringene dine for deg.
Skriv resultatet i operative termer. Northstars mål kan være: «Under et Salesforce-avbrudd, hold haster fra kundeforespørsler, ordreforpliktelser og lageroverleveringer i gang; forhindre duplisering; kommuniser status hvert 30. minutt; og avstem alle midlertidige poster etter at tjenesten er returnert.» Denne uttalelsen er mer nyttig enn «opprettholde Salesforce-tilgjengelighet», fordi sistnevnte stort sett er utenfor kundens kontroll.
En kontinuitetsplan bør la teamet svare raskt på fem spørsmål:
NIST beskriver beredskapsplanlegging som en koordinert strategi med planer, prosedyrer og tekniske tiltak for å gjenopprette informasjonssystemer, drift og data etter en avbrudd. Veiledningen legger vekt på å evaluere systemer og drift for å bestemme krav og prioriteringer. Bruk denne ideen som planleggingsramme, men skreddersy kontrollene til Salesforce-produktene, prosessene, kontraktene og risikotoleransen din.
Start med en analyse av forretningsmessige konsekvenser, ikke med en liste over Salesforce-objekter. Intervju prosesseiere fra salg, service, finans, oppfyllelse, samsvar og IT. Spør hva som stopper hvis Salesforce ikke er tilgjengelig, hva som kan utføres fra en eksisterende kilde, og hva som blir farlig hvis det legges inn senere uten en kontroll.
For Northstar kan den første beholdningen se slik ut:
| Behandle | Påvirkning under nedetid | Midlertidig metode | Bevis for gjenoppretting |
|---|---|---|---|
| Hastesaker fra kunder | Serviceforpliktelser og eskaleringer kan bli oversett | Godkjent telefonkø og begrenset frakoblet skjema | Saksnummer, eier, tidsstempel, prioritet og oppfølgingsstatus |
| Nye bestillinger | Bestillinger kan bli forsinket eller duplisert | Kontrollert ordreregister med unike midlertidige ID-er | Kundebekreftelse, vareliste, prisgodkjenning og resultat av oppfylling |
| Overlevering av lager | Forsendelser kan mangle en autoritativ forespørsel | Manuell godkjenning av utgivelse fra en autorisert leder | Midlertidig ID samsvarer med den endelige Salesforce-bestillingen |
| Salgsaktivitet | Synligheten i rørledningen blir foreldet | Eksisterende møtenotater og et lite godkjent inntaksskjema | Siste kontakt, neste trinn, eier og kildetidsstempel |
| Planlagte integrasjoner | Nye forsøk kan opprette duplikater eller overbelaste endepunkter | Pause, karantene eller hastighetsgrense i henhold til runbooken | Kødybde, status, avspillingsbeslutning og avstemmingsrapport |
Ikke legg sensitive kundedata inn i et improvisert personlig regneark eller en chattråd. Definer en godkjent midlertidig lagring, tilgangsliste, oppbevaringsperiode og slettingsprosedyre. Hvis et manuelt skjema er uunngåelig, samle inn minimumsdataene som kreves for å holde den kritiske prosessen i gang.
Gi hver kritiske prosess et gjenopprettingstidsmål (RTO) og et gjenopprettingspunktsmål (RPO). RTO er hvor raskt prosessen trenger en brukbar løsning eller gjenopprettet tjeneste. RPO er hvor mye nyere data bedriften har råd til å miste eller gjenskape. Dette er forretningsavgjørelser, ikke gjetninger om hvor raskt Salesforce vil løse en hendelse.
Northstar kan sette en RTO på én time for hastesaker hos kunder, en RTO på fire timer for overleveringer til lageret og en RTO på én virkedag for rutinemessige oppdateringer av pipelines. De kan sette en RPO på null for en betalingsautorisasjonsbeslutning, samtidig som de aksepterer at rutinemessige salgssedler må registreres på nytt fra en tidsstemplet midlertidig logg. Tallene er fiktive eksempler; dine økonomi-, juridiske og driftsansvarlige må godkjenne målene.
Dokumenter antagelsen bak hvert mål. En times RTO kan kreve en bemannet telefonkø, en trent vakthavende leder og et forhåndsgodkjent skjema. Hvis disse ressursene ikke er tilgjengelige i helgene, er ikke målet en plan – det er en ambisjon.
Definer en kort aktiveringsprosedyre slik at ansatte ikke improviserer forskjellige svar. Den første personen som legger merke til problemet, bør registrere UTC-tid, berørte brukere, berørte produkter, feilmelding og forretningsprosess. En hendelsesleder sjekker deretter om problemet er bredt eller lokalt.
Salesforces Trust-nettsted gir sanntids- og historisk informasjon om tilgjengelighet og ytelse for produkter og forekomster. Den nåværende hjelpeveiledningen forklarer hvordan du identifiserer en forekomst via Oppsett > Firmainformasjon eller ved å søke etter et Mitt domene-prefiks, og hvordan du tolker statusfarger: grønn for Tilgjengelig, gul for Tjenestedegradering, lilla for Vedlikehold og rød for Tjenesteavbrudd. Salesforce anbefaler også Trust-varsler og ber om å kontakte kundestøtte når et kjerneproblem har overskredet 10 minutter uten å vises på nettstedet.
Tillit er viktig bevis, men en tydelig statusside beviser ikke at ditt eget nettverk, identitetsleverandør, nettleser, API-legitimasjon eller integrasjonsendepunkt er i orden. Northstar bør teste en annen bruker, et andre nettverk og en skrivebeskyttet handling med lav risiko der retningslinjene tillater det. Hvis bare ett kontor er berørt, kan aktivering av en manuell prosess for hele selskapet skape unødvendig arbeid.
Kall løsningen en navngitt modus, for eksempel «Salesforce degraderte operasjoner», og definer dens start- og sluttkriterier. Ansatte bør vite hvor de finner det gjeldende skjemaet, hvem som godkjenner unntak og hvilke handlinger som er forbudt. En god løsning er bevisst snevrere enn vanlige operasjoner.
For Northstar kan degraderte operasjoner tillate hastesaker, godkjente bestillinger og forsendelsesholdinger, samtidig som rabatter, kontosammenslåinger, masseoppdateringer og unødvendige dataimporter settes på pause. Planen bør tilordne en midlertidig identifikator til hver manuelle transaksjon. En nyttig identifikator kan inkludere dato, teamkode og sekvensnummer, men det nøyaktige formatet bør velges av organisasjonen og kontrolleres for kollisjoner.
Bruk ansvarsdeling for handlinger med stor innvirkning. Personen som mottar en bestilling bør ikke være den eneste som godkjenner en forsendelse med høy verdi. Krev en ny sjekk for refusjoner, endringer i bankopplysninger eller beslutninger om kundeidentitet. Registrer godkjenninger med tidspunkt, navn og årsak. Disse kontrollene kan føles tregere, men de reduserer risikoen for at et kortvarig avbrudd blir til en hendelse knyttet til svindel, personvern eller levering.
Gjør integrasjoner til en del av kontinuitetsplanen, ikke et tillegg som kun eies av utviklere. List opp alle innkommende og utgående flyter, utløser, dataeier, kø- eller nytt forsøk, duplikatrisiko og forretningsmessige konsekvenser. Inkluder planlagte jobber, webhooks, mellomvare, hendelsesstrømmer, identitetsleverandører, rapportutdrag og menneskelige opplastinger.
Under et Salesforce-avbrudd kan automatiske nye forsøk være nyttige eller skadelige. Hvis destinasjonen ikke er tilgjengelig, kan begrensede nye forsøk med reserve være passende. Hvis kilden godtar meldinger, men Salesforce ikke gjør det, sett meldingene i kø med et varig tidsstempel og en idempotensnøkkel. Hvis ingen av sidene kan bekrefte om en skriving var vellykket, stopp avspillingen til statusen er kjent. Anta aldri at en tidsavbrudd betyr at en transaksjon ikke ble fullført.
Northstars runbook kan instruere integrasjonseieren om å sette utgående jobber på pause etter tre mislykkede forsøk, bevare den opprinnelige nyttelasten, registrere det siste bekreftede Salesforce-tidsstemplet og forhindre manuell gjeninnføring før køen er klassifisert. Den nøyaktige terskelen er et fiktivt eksempel. Sett den ut fra observert atferd, leverandørveiledning og forretningsrisiko.
Kontinuitet og sikkerhetskopiering løser relaterte, men forskjellige problemer. En kontinuitetsprosedyre holder virksomheten i gang under et avbrudd. En sikkerhetskopiering hjelper med å gjenopprette data etter sletting, korrupsjon eller annen tapshendelse. En sikkerhetskopiering gir ikke automatisk en live erstatning for Salesforce-applikasjonen, dens tillatelser, automatiseringer eller integrasjoner.
Salesforces veiledning for sikkerhetskopiering av data beskriver sikkerhetskopier som kopier som er lagret separat for gjenoppretting, og anbefaler regelmessige sikkerhetskopier, flere steder og testet gjenoppretting. Bestem hvilke poster, metadata, filer og revisjonsinformasjon bedriften trenger å gjenopprette, hvor lenge de må oppbevares, og hvem som kan autorisere en gjenoppretting. Test om de gjenopprettede dataene kan matches med de midlertidige postene som ble opprettet under nedetid.
Hvis organisasjonen din vurderer avansert tverrregionskontinuitet, bør du lese den nåværende vanlige spørsmålen om Salesforce nøye. Salesforce sier at tilbudet er begrenset til Hyperforce, at noen tjenester ikke støttes ennå, og at en gjenopprettingshendelse gjør organisasjonen utilgjengelig mens katastrofegjenopprettingsoperasjoner pågår. Det står også at forpliktelser til datalagring på landsnivå kan bli påvirket når primære og sekundære regioner er i forskjellige land. Dette er planleggingsbegrensninger, ikke fotnoter.
Tildel én hendelsesleder, én teknisk leder, én driftsleder og én kommunikasjonseier. Definer sikkerhetskopier for hver rolle. Hold budskapet faktabasert: hva som er berørt, når det startet, hva brukere bør gjøre, hva de ikke må gjøre, når neste oppdatering kommer og hvor godkjente instruksjoner finnes.
Ikke annonser en gjenopprettingstid som Salesforce ikke har bekreftet. Ikke be kunder om å sende informasjon på nytt gjentatte ganger hvis den opprinnelige forespørselen allerede er i kø. For Northstar kan kundemeldingen si at ordreinntaket opererer gjennom en midlertidig kanal, at kunder bør bruke én spesifisert kontaktmetode, og at neste statusoppdatering vil bli utstedt på et definert tidspunkt.
Inkluder interne eskaleringsterskler. For eksempel kan en kritisk prosess som påvirker kunden, sende hendelseslederen umiddelbart, mens en foreldet rapport kan vente til neste planlagte gjennomgang. Koble planen til gjeldende Salesforce Trust-varsler og organisasjonens støtteberettigelse. Et telefontre som ikke lenger samsvarer med arbeidsstyrken, er ikke en kommunikasjonsplan.
Begynn med en bordøvelse. Gi Northstars team en fiktiv oppgave, for eksempel: «Klokken 09:10 er Salesforce ikke tilgjengelig for service- og salgsteamene; lagerintegrasjonsjobber viser gjentatte feil; Trust rapporterer et tjenesteavbrudd.» Be hver rolle om å utføre de første 30 minuttene av planen ved kun å bruke det dokumenterte materialet.
Mål observerbare resultater:
Etter tabelltesten, kjør en kontrollert teknisk test i et sandkasse- eller ikke-produksjonsmiljø der scenariet er trygt og støttet. Ikke påstå at en sandkasseøvelse beviser produksjonsfailover. Salesforces ACRC-dokumentasjon sier eksplisitt at sandkasseorganisasjoner ikke dekkes av ACRC, noe som er en påminnelse om å teste det faktiske gjenopprettingsomfanget i stedet for å utlede det fra et lavere miljø.
Gjenopprettingen starter når hendelseslederen har pålitelig bevis på at den berørte Salesforce-tjenesten er brukbar – ikke bare når en bruker kan laste innloggingssiden. Bekreft statussiden, test med en liten autorisert handling, sjekk integrasjoner og kunngjør en kontrollert tilbakeføring til normal drift.
Avstemm i en sekvens som beskytter registreringssystemet:
En plan kan ikke tvinge Salesforce til å gjenopprette raskere, garantere at en integrasjonsskriving er fullført, eller få et ikke-støttet produkt til å oppføre seg som et støttet produkt. Den kan ikke erstatte kontraktsmessig gjennomgang, personvernanalyse, sikkerhetskopieringstesting eller respons på sikkerhetshendelser. En manuell løsning kan også introdusere transkripsjonsfeil, problemer med tilgangskontroll, forsinket inntektsføring og forvirring hos kundene.
Planen bør derfor inkludere en beslutning om å stoppe. Hvis teamet ikke kan bekrefte en kundes identitet, integriteten til en betalingsinstruksjon, statusen til en forsendelse eller destinasjonen til en dataoverføring, må handlingen holdes tilbake for en autorisert gjennomgang. Kontinuitet er ikke det samme som å fortsette hver transaksjon for enhver pris.
For Northstar er ikke suksess at «Salesforce aldri går ned». Suksess er at teamet gjenkjenner forstyrrelsen, beskytter kritisk arbeid, unngår usikker improvisasjon, fører en sporbar oversikt over midlertidige handlinger og går tilbake til normal drift uten skjulte duplikater eller manglende forpliktelser. Det er standarden en praktisk Salesforce-kontinuitetsplan bør oppfylle.
Gjennomgå bemerkelsesverdige Salesforce-avbrudd i 2025, hva som feilet, hvor lenge utvalgte hendelser varte, og de praktiske lærdommene om robusthet teamene kan bruke.
Bygg en praktisk kontinuitetsplan for nedetid i Salesforce med konsekvensanalyse, RTO/RPO-mål, manuelle løsninger, integrasjonskontroller og gjenopprettingskontroller.
Learn how to contact Salesforce Support during a major outage: check Trust Status, choose the right channel, open a strong case, and track recovery.
Feilsøk Salesforce Workbench-innlogging, REST Explorer, timeout, 503, API-versjon og begrens feil under nedetid med en praktisk diagnostisk sjekkliste.
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å hovedårsakene til utbredt nedetid i skyen, hvordan feil oppstår, hva du bør sjekke først og hvordan du kan utforme en mer robust gjenopprettingsplan.
Hvis Datorama eller Marketing Cloud Intelligence ser ut til å være nede, bruk denne evidensbaserte sjekklisten for å bekrefte driftsstansen, beskytte rapporteringskvaliteten og vite når dataene er pålitelige igjen.
Et praktisk blikk på hvordan Heroku-avbrudd kan påvirke distribuerte apper, dynamoer, ruting, databaser, distribusjoner, Heroku Connect, logger og gjenoppretting.
En praktisk tilbakeblikk på store Salesforce-avbrudd i 2025, inkludert årsaker, tidslinjer, berørte tjenester, lærdommer og kontinuitetstrinn for administratorer.
Et AWS-avbrudd betyr ikke automatisk at Salesforce er nede. Lær hvordan Hyperforce, regioner, instanser og Salesforce Trust avgjør om organisasjonen din er berørt.
