sfdcmarc.dev
menu
6 min read
salesforce architecture

The Night the Region Went Down: Why Your Org's Resilience Is an Architecture Decision

A practical architecture guide to Salesforce Advanced Cross-Region Continuity, recovery objectives, cost, and regional outage planning.

A regional outage forces an uncomfortable question: does the business need Salesforce to remain operational during the event, or is recovery after the event acceptable? A backup policy does not answer that question.

In a standard recovery event, the org is unavailable while Salesforce restores service. Salesforce does not serve traffic from the backup while the primary is down in most setups, and a warm standby does not continue serving business traffic. The org eventually returns, but the business pauses until then. Your architecture needs to reflect that promise.

What Advanced Cross-Region Continuity provides

ACRC, formerly called Out of Region Disaster Recovery, is a premium Hyperforce product. It maintains a remote copy of the org in a secondary region for events that take every availability zone in the primary region offline.

If that happens, you activate the secondary region to run the business during the disaster, then use it as the source to replicate data back when the primary recovers. This differs from a backup because the ACRC customer can activate an operable org in a different region.

Salesforce chooses the secondary region based on resilience, availability, and performance requirements. The recovery org is an operable copy of the primary rather than a snapshot that you restore later.

How a regional event differs with ACRC

Consider a regional event that takes out every availability zone in the primary Hyperforce region.

Without ACRC: you file a recovery request, and you wait. The org recovers in place - Salesforce restores service and you resume from where the platform could reconstruct. Business continuity during the event is not part of the promise. Your runbook’s honest answer to “how do we keep running?” is “we don’t, until recovery.”

With ACRC: you activate the secondary region. The org - the copy - becomes the operating org. Users work, integrations run, the business keeps moving, from a different region. When the primary recovers, you use the secondary as the source to replicate data back. That’s the difference between a recovery and a continuity story.

That’s why the decision is binary and architectural: do you need to be running during the event, or is recovery acceptable? Everything else is implementation.

EU availability changes the design conversation

EU availability makes this relevant beyond US deployments. Previously, ACRC was primarily an option for US clients. EU clients had to accept a different answer on resilience than their US counterparts - the premium continuity product simply wasn’t available to them.

Summer ‘26 removes that blocker. ACRC is now available in the EU, with faster recovery time objectives across all regions. That change matters. Every architect who’s been deferring this conversation because the EU client couldn’t get the premium option - the blocker’s gone. The conversation, and specifically whether to design for ACRC or accept single-region recovery, can now be had with complete options on the table for EU deployments.

That’s what “Hyperforce expansion” means in practice: the resilience ceiling rises, and your architecture decisions have to catch up.

Start with recovery objectives

The Well-Architected Framework reduces this to two numbers: recovery time objective and recovery point objective. How quickly must the service return, and how much data loss can the business tolerate? Those are business requirements that drive the architecture.

The design decision is whether the org may remain unavailable until recovery or must run from a secondary region during the event. If continuity is required, evaluate ACRC. If recovery is enough, document the single-region trade-off explicitly.

Cost belongs in the architecture decision. ACRC is a premium product, and many orgs do not need it. Single-region recovery is defensible when it matches the business requirement. EU availability matters because architects can now compare both options instead of accepting a geography-based constraint.

What to verify before committing

ACRC is premium, so it’s not something you discover in a sandbox. It’s something you request. Before you commit, verify four things with your account team: that ACRC is available for your org’s Hyperforce region, where the secondary region actually sits, what your recovery time and data replication expectations will be, and what the pricing model looks like for your edition and user count. Get the answers in writing. The product is real and the EU availability is real, but “available” and “available to my org at a price I can defend” are two different statements, and you want the second one confirmed before you put it in an architecture doc.

Prepare the operating runbook

Buying a continuity product without maintaining its runbook creates false confidence.

  1. Document the activation decision. Who flips the secondary region on? What’s the trigger - a regional event that warrants ACRC, versus a normal incident that self-recovers?
  2. Know your recovery expectations. Target for resuming business? Expected data replication behavior during and after the event?
  3. Plan the post-recovery steps. After recovery you can trigger a sandbox clone or refresh to create a sandbox org in the secondary region. Know that flow before you need it, not the morning after.

Rehearse the decision as well as the steps. A tabletop exercise should name the event, the activation threshold, and the person who decides. That rehearsal turns the product into an operating capability.

Make the decision while the region is healthy

A backup policy does not define whether the business can operate during a regional disaster. ACRC provides an operating option in a secondary region, and EU orgs can now evaluate it too. Make the decision while the primary region is healthy. If single-region recovery is sufficient, document that choice and the resulting downtime expectation. An active incident is the worst time to discover what the org can and cannot do.

Sources