Disaster Recovery for Power Platform: Backups, Environment Restores, and Runbooks

Introduction

It's 2:47 AM on a Tuesday when your phone lights up. A junior admin, trying to fix a broken environment variable, accidentally deleted the wrong solution in production. With it went three months of flow customizations, seventeen active approval workflows currently sitting mid-execution, and the connection references that tied everything to your Azure Key Vault integration. By 8 AM, your finance team will start their month-end close process — a fully automated 90-step orchestration built on Power Automate. The clock is ticking, and you have no written runbook.

This scenario is not hypothetical. It happens to mature organizations with experienced teams. Power Platform's low-code nature makes it deceptively easy to change things in production, and its interconnected architecture — environments, solutions, Dataverse, connection references, environment variables, flows — means that a single wrong action can cascade across a surprisingly large surface area. Disaster recovery for Power Platform is not just about backups. It's about knowing what to restore, in what order, and how to verify that you actually got there. It's about having a document someone can execute at 3 AM without calling you.

By the end of this lesson, you will be able to design and implement a complete DR strategy for Power Platform: understanding what Microsoft backs up automatically (and where it falls short), performing environment restores through both the Admin Center and PowerShell, building recovery plans for flows, connection references, and environment variables, and authoring an operational runbook that your team can actually execute under pressure.

What you'll learn:

• How Power Platform's automatic backup system works, including retention windows, what's included, and the critical gaps you need to fill manually
• How to trigger an environment restore from the Power Platform Admin Center and the Power Platform CLI, including the restore-to-new-environment pattern for non-disruptive recovery
• How to recover solution components — flows, connection references, environment variables, and custom connectors — after a restore, including the steps most documentation skips
• How to design and version a runbook that covers failure scenarios from accidental deletion to full environment corruption
• How to integrate DR testing into your ALM pipeline so you know your recovery procedures work before you need them

Prerequisites

You should be comfortable with Power Platform environment management and the ALM concepts covered in Deploying and Managing Power Automate Solutions Across Environments: ALM Pipelines, Solution-Aware Flows, and Environment Variables for Enterprise-Scale Delivery. Familiarity with the Power Platform Admin Center is assumed. Experience with PowerShell and the Power Platform CLI will help for the automation sections, but the admin center steps are documented in enough detail to follow without it.

---

Understanding What Microsoft Actually Backs Up

Before you design your DR strategy, you need to know exactly what automatic protections exist — and where they end. Microsoft's documentation is accurate but optimistic. It lists what's backed up. It does not always make clear what the restore experience will feel like at 3 AM.

Automatic Environment Backups

Power Platform automatically backs up environments on a rolling basis. The retention window depends on your environment type and licensing:

• Production environments with Dataverse: 28-day rolling backup, taken continuously (system backups happen approximately every day, but the platform retains the ability to restore to any point within that window for Dataverse)
• Sandbox environments: 7-day rolling backup
• Developer environments: No automatic backup guarantee; treat them as ephemeral

The backup mechanism is tied to Dataverse, not to the Power Automate service independently. What this means in practice:

Component	Included in Auto Backup?
Dataverse tables, rows, relationships	✅ Yes
Power Apps (canvas, model-driven)	✅ Yes (as Dataverse solutions)
Power Automate flows (solution-aware)	✅ Yes, if in a Dataverse solution
Power Automate flows (non-solution-aware)	❌ No
Environment variables (values)	✅ Definition yes, current value maybe
Connection references (metadata)	✅ Definition, not credentials
Custom connector definitions	✅ Yes
Active connections and credentials	❌ No — ever
On-premises gateway configuration	❌ No
DLP policy assignments	❌ No (managed at tenant level)

The most dangerous gap is the last column pattern: anything that represents a live, stateful relationship to an external system — credentials, gateway bindings, active connections — does not survive a restore in a form you can just switch on. You will always need to re-establish those relationships after a restore. This is the part that bites teams who test their backup but never practice the full restore.

What "Restore" Actually Means

A Power Platform environment restore replaces the Dataverse database with the state captured at the backup point. It does not:

• Restore in-flight flow runs (runs executing at the time of the backup point are gone)
• Restore SharePoint lists or external systems that your flows wrote to
• Re-establish connections to Azure services, even if those services still have the same configuration
• Automatically re-enable flows that were off at backup time

A restore brings back the definitions of your automation. Turning that automation back on, reconnecting it, and verifying it's behaving correctly is operational work that must be planned and documented.

---

The Restore-to-New-Environment Pattern

The most important architectural decision in your DR strategy is whether you restore in place (overwriting the current environment) or restore to a new environment and then cut traffic over. For most production scenarios, restore-to-new is dramatically safer and should be your default.

Why In-Place Restore Is Dangerous

An in-place restore to a production environment:

1. Takes the environment offline for the duration of the restore (potentially hours)
2. Is irreversible — if the restored state is wrong, you cannot "undo" back to your pre-restore state
3. Loses any changes made between the backup point and the restore trigger (sometimes this is what you want; often it isn't)
4. Means any flows that ran after the incident but before you restored have their effects orphaned in the environment but their execution records gone

If a dev accidentally deleted a solution at 10 PM and you don't discover it until 2 AM, four hours of flow runs happened in between. Those runs may have created Dataverse records. Restoring in place to 9:59 PM drops those records too. That's potentially a data integrity problem that's worse than the original incident.

Restore to a New Environment: The Procedure

The safer pattern: restore the backup into a new (sandbox) environment, validate that the restored state is correct, migrate any gap data from the production environment if needed, then promote the restored environment (or extract and re-deploy the solution) into production.

Here's the detailed procedure using the Power Platform Admin Center:

Step 1: Create the restore target

Navigate to Power Platform Admin Center (admin.powerplatform.microsoft.com). Go to Environments and select the production environment you want to recover from. Select Backups in the top action bar, then Restore or manage. This opens the backup timeline viewer.

You'll see a calendar with available restore points. Select the timestamp you want to restore to — choose a point before the incident occurred. The interface shows "system backups" as distinct points, but for environments with continuous backup capability, you can type a specific timestamp.

Click Restore. The dialog asks where to restore to. Select To a different environment and provide a name for the target environment. Do not restore to the production environment itself at this stage.

Step 2: Monitor the restore operation

Restores take between 20 minutes and several hours depending on database size. The Admin Center shows a progress indicator on the target environment. You can also monitor via PowerShell:

# Install the Power Platform admin module if needed
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -Force

# Authenticate
Add-PowerAppsAccount

# List environments to get environment IDs
Get-AdminPowerAppEnvironment | Select-Object DisplayName, EnvironmentName

# Check the environment state — "Restoring" will appear during the operation
Get-AdminPowerAppEnvironment -EnvironmentName "your-target-env-id" | 
    Select-Object DisplayName, CommonDataServiceDatabaseProvisioningState

Step 3: Validate the restored environment

Once the restore completes, the target environment is in a raw state. Before you trust it, verify:

# Using Power Platform CLI (pac)
pac auth create --environment "https://your-restored-env.crm.dynamics.com"

# List solutions to confirm they're present
pac solution list

# Export a solution to verify its contents are intact
pac solution export --name "YourProductionSolution" --path "./verify-export" --managed false

Open the restored environment in the maker portal (make.powerapps.com), switch to the restored environment, and navigate to Solutions. Check that your solution is present with the expected version number and that the flows within it are visible. Do not turn them on yet.

Step 4: Reconnect connection references

This is the step most tutorials skip. After a restore, connection references exist as definitions but their underlying connections are broken. You must re-establish them.

Navigate to the restored environment in the maker portal. Go to Solutions, open your main solution, and find Connection References. For each connection reference:

1. Click the connection reference to open its detail panel
2. If it shows "No connection," select an existing connection from the dropdown or create a new one
3. Verify the connection authenticates successfully before moving on

For connections backed by managed identities or Azure Key Vault secrets, this process integrates with your identity infrastructure. If your team followed good practices as described in Integrating Power Automate with Azure Key Vault and Managed Identities: Complete Guide to Secrets Management and Zero-Trust Authentication, the secret values themselves are still in the vault — you're just re-establishing the connection's permission to reach them.

Step 5: Set environment variable values

Environment variables restore their definitions (the schema), but the current values may be from the backup point rather than production. More importantly, any values that differ between environments (API endpoint URLs, queue names, feature flags) need to be set explicitly.

# Using PAC CLI to set environment variable values
pac env update-variable --name "OrderProcessingQueueName" --value "orders-prod-v2"
pac env update-variable --name "NotificationApiBaseUrl" --value "https://api.contoso.com/v3"

Alternatively, use the Power Platform REST API directly from a flow or script:

# Get the environment variable definition ID first
$headers = @{
    "Authorization" = "Bearer $accessToken"
    "Content-Type" = "application/json"
}

$response = Invoke-RestMethod `
    -Uri "https://your-org.crm.dynamics.com/api/data/v9.2/environmentvariabledefinitions?`$filter=schemaname eq 'contoso_OrderProcessingQueueName'&`$select=environmentvariabledefinitionid,defaultvalue" `
    -Headers $headers

$definitionId = $response.value[0].environmentvariabledefinitionid

# Set the current value
$body = @{
    "EnvironmentVariableDefinitionId@odata.bind" = "/environmentvariabledefinitions($definitionId)"
    "value" = "orders-prod-v2"
} | ConvertTo-Json

Invoke-RestMethod `
    -Uri "https://your-org.crm.dynamics.com/api/data/v9.2/environmentvariablevalues" `
    -Method POST `
    -Headers $headers `
    -Body $body

---

Manually Backing Up What Microsoft Doesn't

Your automatic backup strategy has gaps. Close them with a structured manual backup process integrated into your ALM pipeline.

Exporting Solution Packages as Artifacts

Every deployment pipeline should produce and retain solution exports as build artifacts. If you're running CI/CD through Azure DevOps or GitHub Actions, add a post-deploy step that exports the managed solution from production and stores it as a versioned artifact.

# Azure DevOps pipeline step — add after your deploy step
- task: PowerPlatformExportSolution@2
  displayName: 'Export Production Backup — Managed'
  inputs:
    authenticationType: 'PowerPlatformSPN'
    PowerPlatformSPN: 'prod-spn-connection'
    SolutionName: 'ContosoOrderManagement'
    SolutionOutputFile: '$(Build.ArtifactStagingDirectory)/ContosoOrderManagement_managed_$(Build.BuildId).zip'
    Managed: true
    Environment: '$(ProductionEnvironmentUrl)'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Solution Export'
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'production-solution-backups'
    publishLocation: 'Container'

Retain these artifacts for at least 30 days with versioning. In an incident, a three-week-old artifact might be your lifeline if the Dataverse backup is somehow corrupted or unavailable.

Backing Up Non-Solution-Aware Flows

If you have flows outside solutions (and you likely do if you've been in Power Automate for more than six months), they have no backup whatsoever. Find them and address this before they become a problem.

# List all flows in an environment, including non-solution flows
Get-AdminFlow -EnvironmentName "your-env-id" | 
    Where-Object { $_.Internal.properties.definition -ne $null } |
    Select-Object DisplayName, FlowName, 
                  @{N='IsInSolution'; E={$_.Internal.properties.isInSolution}} |
    Where-Object { $_.IsInSolution -eq $false } |
    Export-Csv -Path "./non-solution-flows-$(Get-Date -Format 'yyyyMMdd').csv"

For each non-solution flow you find, either migrate it into a solution (the right long-term fix) or export its definition as a JSON backup:

# Export a flow definition
$flowId = "your-flow-guid-here"
$envId = "your-env-guid-here"

$flow = Get-AdminFlow -FlowName $flowId -EnvironmentName $envId
$flow.Internal.properties.definition | ConvertTo-Json -Depth 20 | 
    Out-File -FilePath "./flow-backup-$flowId-$(Get-Date -Format 'yyyyMMdd').json"

Documenting Connection Reference Ownership

One of the most painful parts of DR is discovering that a critical connection reference was owned by an employee who left six months ago. Their connection is now invalid, and the flow tied to it fails silently.

Build and maintain a connection reference registry. This is a simple Dataverse table or SharePoint list that maps each connection reference to its owning service account, the type of credential it uses, where those credentials are stored, and who is responsible for rotating/renewing them. If you're using the CoE Toolkit as part of your governance strategy, this data already exists in your tenant — you just need to maintain a process for keeping it current and reviewing it quarterly.

---

Building Your DR Runbook

A runbook is a decision tree and procedure guide combined. It answers: "Given that X has happened, execute steps 1 through N in order to restore service." A good runbook can be executed by a competent person who has never seen the system before. Aim for that standard.

Runbook Structure

Every runbook should have five sections:

1. Incident Classification

Define the failure scenarios this runbook covers and which procedures apply to each. Be specific. "Flow not working" is not a scenario. These are:

Scenario	Severity	Primary Procedure
Single flow deleted or corrupted	P2	Restore from solution artifact
Solution deleted from environment	P1	Environment restore to new + redeploy
Environment corrupted (Dataverse errors)	P1	Environment restore to new + cutover
Environment fully deleted	P1	Restore from backup to new env + full config
Credential/connection failure (not data loss)	P2	Reconnect references, no restore needed
Environment variable misconfiguration	P3	Update variable values directly
Gateway failure	P2	Failover to cluster node, see gateway runbook

2. Pre-Conditions Checklist

Before executing any recovery procedure, verify:

[ ] Incident scope confirmed — what exactly is broken?
[ ] Root cause identified or contained — is the problem still actively occurring?
[ ] Stakeholders notified — finance, ops, IT leadership as appropriate
[ ] Backup point identified — which timestamp represents the last known good state?
[ ] Recovery environment target identified — new environment name, region
[ ] Service account credentials confirmed available — can you log in as the deployment SP?
[ ] Environment variable values documented — do you have the current production values?

3. Step-by-Step Procedure

Write each procedure as numbered steps with specific UI paths and commands. Here's an example for the "Solution deleted from environment" scenario:

---

Procedure: P1-A — Recover Deleted Solution via Environment Restore

Estimated time: 2–4 hours. Execute only after completing the Pre-Conditions Checklist.

1. Log into Power Platform Admin Center as a tenant administrator or environment administrator
2. Navigate to Environments → select the affected production environment → Backups → Restore or manage
3. On the backup timeline, select the timestamp 30 minutes before the incident occurred (buffer for system backup lag)
4. Select Restore to a different environment. Name the new environment: PROD-RECOVERY-[YYYYMMDD]
5. Select the same region as production. Select the same security group if applicable
6. Click Restore and record the start time in the incident log
7. Monitor the environment list — the new environment shows "Restoring" status
8. While restore is running, collect environment variable values from the runbook appendix (see Section 6)
9. When restore completes (status changes to "Ready"), navigate to the new environment in the maker portal
10. Open Solutions — verify ContosoOrderManagement is present at version [current version from runbook appendix]
11. Navigate to Connection References in the solution. For each reference:
    • cr_AzureServiceBusMain → Connect to service account svc-automate-prod@contoso.com
    • cr_SharePointDocLibrary → Connect to service account svc-automate-prod@contoso.com
    • cr_KeyVaultReader → Connect using managed identity (see Key Vault procedure in Appendix B)
12. Set environment variable values from Appendix A
13. Run smoke test suite from Appendix C
14. If smoke tests pass: proceed to cutover procedure P1-B
15. If smoke tests fail: do not cut over; escalate to [senior engineer contact]

---

4. Cutover Procedure

The cutover procedure for the restore-to-new pattern involves deciding whether to swap the environment (change configuration to point at the new environment) or redeploy the recovered solution into the original environment. Each approach has trade-offs:

Option A: Promote the recovered environment to production

This requires updating any external references (Azure API Management policies, app registrations, webhook URLs) to point at the new environment's URL. It's faster but requires broader config changes.

Option B: Extract solution from recovered environment, redeploy to original

# Export the solution from the recovered environment
pac auth create --environment "https://prod-recovery-20241203.crm.dynamics.com"
pac solution export --name "ContosoOrderManagement" --path "./recovery-export" --managed true

# Switch auth to original production environment
pac auth create --environment "https://contoso-prod.crm.dynamics.com"

# Import the recovered solution
pac solution import --path "./recovery-export/ContosoOrderManagement_1_2_0_managed.zip" --force-overwrite

Option B is usually preferable because it keeps external references stable, but it requires that the original environment's Dataverse layer is still functional (which is true in most scenarios except full database corruption).

5. Verification and Sign-Off

The runbook is not complete until verification is documented. Define your smoke test suite explicitly:

Smoke Test Suite: ContosoOrderManagement
Executed by: [name]
Date/Time: [timestamp]

[ ] Test 1: Trigger OrderCreated flow manually with test payload → verify Dataverse record created
[ ] Test 2: Trigger InvoiceApproval flow → verify approval email received by test@contoso.com
[ ] Test 3: Verify ServiceBus trigger flow picks up test message from orders-test queue
[ ] Test 4: Verify scheduled ReconciliationReport flow runs to completion
[ ] Test 5: Check Application Insights for error rate in first 15 minutes of operation
[ ] Test 6: Finance team representative confirms month-end close system accessible

Pass criteria: All 6 tests pass
Fail criteria: Any single test fails

---

Flow-Level Recovery Without a Full Restore

Not every incident requires restoring an entire environment. For cases where a single flow was deleted, modified, or corrupted, you have faster options.

Recovering a Single Flow from a Solution Export

If your deployment pipeline exports solution artifacts on every release, you can recover an individual flow by importing a previous version of the solution:

# Import with upgrade — this will restore the flow to its previous state
# without affecting other components in the solution
pac solution import \
  --path "./artifacts/ContosoOrderManagement_1_1_5_managed.zip" \
  --force-overwrite \
  --publish-changes

The --force-overwrite flag on a managed solution import will overwrite flow definitions, including restoring deleted flows. This is your fastest path for single-component recovery and should be your first response before triggering a full environment restore.

Using Flow Run History for Forensics

Before you decide which backup point to restore to, understand what actually happened. Power Automate's run history gives you a forensic record:

# Get run history for a specific flow
Get-AdminFlowRun -EnvironmentName $envId -FlowName $flowId | 
    Select-Object FlowRunId, StartTime, Status, TriggerType |
    Sort-Object StartTime -Descending |
    Select-Object -First 50

This helps you answer: "What was the last successful run? What happened after the incident started? Are there runs that processed real business data I need to account for?" Your restore point selection depends on this analysis.

Recovering Mid-Execution Approval Flows

Approval flows are among the trickiest to recover because they have human-held state. If an approval email was sent and a manager has a pending action in their Outlook or Teams, what happens to that pending action after a restore?

The answer is: it depends. The approval record in Dataverse (the approvals table) will be restored to its backup-point state. If the manager approves via the email link after the restore, the flow that receives that approval may or may not still be running — flow runs in progress at restore time are gone.

The practical approach:

1. Query the Dataverse approvals table in the restored environment to identify approvals that were in-flight
2. Notify managers with pending approvals that they need to re-approve via the Teams Approvals app (not the old email link)
3. If the approval flow itself is gone, you may need to manually re-trigger it for affected records

This is ugly and there's no clean platform solution for it. The mitigation is designing your approval flows to be idempotent — built so that re-triggering them for a record that already has a decision in some state doesn't cause double-processing.

---

Integrating DR Testing into Your ALM Pipeline

A DR runbook you've never tested is a fiction. The only way to know your recovery procedure works is to execute it — not in a crisis, but on a scheduled basis as part of your operations cadence.

Quarterly DR Drills

Schedule a quarterly DR drill where your team executes the runbook against a non-production target. The procedure:

1. On a scheduled date, designate a sandbox environment as the "victim"
2. Take the environment name and note the current solution version
3. Deliberately corrupt the environment — delete a flow, drop a solution, or use an older backup point
4. Execute the recovery runbook as written
5. Time each step
6. Note where the runbook was unclear or wrong

The output is a post-drill report with specific runbook amendments. Over four quarters, your runbook becomes genuinely reliable because it's been executed and revised multiple times.

Automated Backup Verification

Build a scheduled flow (or Azure DevOps pipeline) that runs monthly and verifies your backup posture:

# Azure DevOps scheduled pipeline — runs first of each month
trigger: none
schedules:
  - cron: "0 6 1 * *"
    displayName: Monthly DR Verification
    branches:
      include: [main]

jobs:
  - job: VerifyBackups
    pool:
      vmImage: ubuntu-latest
    steps:
      - task: PowerPlatformToolInstaller@2
        inputs:
          DefaultVersion: true

      - task: PowerShell@2
        displayName: 'Export Production Solution for Backup Verification'
        inputs:
          targetType: 'inline'
          script: |
            pac auth create --applicationId $(SPN_CLIENT_ID) \
                            --clientSecret $(SPN_CLIENT_SECRET) \
                            --tenant $(TENANT_ID) \
                            --environment $(PROD_ENV_URL)
            
            pac solution export \
                --name "ContosoOrderManagement" \
                --path "$(Build.ArtifactStagingDirectory)/monthly-dr-backup" \
                --managed true
            
            # Verify the export is non-empty
            $exportFile = Get-Item "$(Build.ArtifactStagingDirectory)/monthly-dr-backup/*.zip"
            if ($exportFile.Length -lt 100000) {
              Write-Error "Export file is suspiciously small — possible export failure"
              exit 1
            }
            Write-Host "Backup verification passed. File size: $($exportFile.Length) bytes"

      - task: PublishBuildArtifacts@1
        inputs:
          PathtoPublish: '$(Build.ArtifactStagingDirectory)/monthly-dr-backup'
          ArtifactName: 'monthly-dr-backup-$(Build.BuildNumber)'

Combine this with a monitoring and alerting flow that triggers if the pipeline fails — you want to know immediately if your automated backup verification stops working, not discover it during an incident.

Environment Promotion as DR Rehearsal

Every time you promote a solution through your environment pipeline (dev → test → production), you're practicing a subset of your DR procedure. Structure your environment strategy so that the promotion process touches all the same components as a recovery:

• Connection reference re-binding (each environment has its own service account connections)
• Environment variable value injection (values differ by environment by design)
• Post-deployment smoke test execution
• Rollback procedure if smoke tests fail

If your team can execute a promotion smoothly in ten minutes, they'll be able to execute a recovery in an hour rather than four. The muscle memory transfers.

---

Advanced Topics: Multi-Environment Failover and Cross-Tenant Recovery

Geographic Failover

For organizations with strict RTO/RPO requirements, consider a warm-standby environment in a secondary Azure region. Power Platform environments are tied to a specific geo (US, Europe, Asia, etc.), and Microsoft does not automatically fail over between geos. If your primary region has an outage, your environment is unavailable.

The mitigation is to maintain a secondary environment in a different geo that receives periodic solution deployments. Your deployment pipeline deploys to both primary and secondary. In a regional outage, you redirect traffic (API Management policies, SharePoint site configurations, etc.) to the secondary.

This pattern integrates well with Azure Service Bus-based flow architectures: because the queue is in Azure (which has regional redundancy independent of Power Platform), messages survive a Power Platform regional outage. Your secondary environment's flows pick up the queue when primary is restored or when you cut over.

Cross-Tenant Migration During DR

In a severe scenario — tenant corruption, tenant deletion in error, acquisition where the tenant is being wound down — you may need to recover flows into a completely different tenant. This is the most complex recovery scenario and involves:

1. Exporting managed solutions from any available backup (artifact storage, a secondary environment in a third-party tenant, etc.)
2. Creating a new environment in the target tenant
3. Importing the solution — which will create new GUIDs for all components
4. Re-establishing all external integrations (Azure app registrations, SharePoint site connections, Dataverse foreign keys pointing to external systems)

The full procedure is covered in Migrating Flows Between Tenants: Solution Export, Connection Remapping, and Cutover. For DR planning purposes, the key takeaway is that cross-tenant recovery requires significantly more preparation than same-tenant recovery. If this is in your risk surface, you need a separate, more detailed runbook section and explicit DR drills that cross the tenant boundary.

Managed Environments and Enhanced Governance

If your production environment is configured as a Managed Environment, you have access to additional governance features that help with DR preparedness. Weekly digests can surface ownership gaps. Sharing limits prevent flows from accumulating organic owners who don't appear in your registry. These features, covered in detail in Managed Environments in Power Platform, reduce the organizational entropy that makes DR harder — you know who owns what, credentials are centralized, and the blast radius of any single person's credentials expiring is contained.

---

Hands-On Exercise

This exercise takes approximately 90 minutes and requires access to a Power Platform tenant with the ability to create sandbox environments.

Scenario: You are the automation engineer for Contoso Finance. The production environment runs three critical flows: InvoiceIngestion, ApprovalOrchestrator, and GLPostingSync. A junior team member accidentally deleted the ContosoFinanceAutomation solution from production at 14:00 today. It is now 14:45. You must recover service.

Part 1: Identify the backup point (15 minutes)

1. Navigate to the Power Platform Admin Center and open your sandbox environment (use a sandbox you have admin access to as the "production" stand-in)
2. Navigate to Backups → Restore or manage
3. Identify the available backup points for your environment
4. Determine which timestamp you would restore to given the 14:00 incident time
5. Document your reasoning: why that specific point, and what is the risk of choosing a point too close to 14:00?

Part 2: Execute a restore to a new environment (30 minutes)

1. Trigger a restore of your sandbox to a new environment named SANDBOX-RECOVERY-[YOURNAME]
2. Monitor the restore progress
3. When complete, navigate to the new environment and verify the solution list

Part 3: Reconnect and configure (30 minutes)

1. In the recovered environment, navigate to the solution's Connection References
2. Attempt to connect each reference (even if you only have one real connection available, document the steps for the others)
3. Set at least two environment variable values via the maker portal
4. Set one environment variable value via PowerShell or the Dataverse REST API

Part 4: Document your runbook entry (15 minutes)

1. Write the pre-conditions checklist for this scenario
2. Write 10 numbered steps for the recovery procedure based on what you just executed
3. Define three smoke tests that would confirm recovery is complete
4. Note one step that took longer than expected and how you would improve it

Cleanup: Delete the SANDBOX-RECOVERY-[YOURNAME] environment from the Admin Center when done, to avoid consuming capacity.

---

Common Mistakes & Troubleshooting

Mistake 1: Restoring without identifying the root cause

If you restore before understanding what caused the incident, you may restore directly into conditions that will re-trigger the problem. A flow that corrupted data because of a bad environment variable will corrupt it again after restore if you don't fix the variable first. Always contain the cause before executing recovery.

Mistake 2: Confusing "restore complete" with "service restored"

The platform restore completes. The environment shows "Ready." You close the incident. Two hours later, finance calls because the flows aren't processing. The restore gave you a working database — the flows still need to be turned on, connections re-established, and environment variables set. Recovery is not complete until smoke tests pass.

Mistake 3: Restoring to the wrong timestamp

Backup timelines in the Admin Center show system backup points, but the continuous backup capability allows point-in-time restore to arbitrary timestamps. Teams often restore to the nearest system backup before the incident, which may be further back than necessary. Check whether your environment supports point-in-time restore — if it does, you can restore to one minute before the incident.

Mistake 4: Forgetting in-flight Dataverse transactions

Flows that use Dataverse change tracking or delta sync patterns maintain a "last sync position" (change version) in an environment variable or Dataverse record. After a restore, this position may be ahead of the restored state, causing your delta sync to miss records that were created between the backup point and now. Always reset delta sync positions as part of your recovery procedure.

Mistake 5: The runbook exists only as a Word document

Runbooks stored as Word documents in someone's OneDrive are discovered during incidents to be the wrong version, missing critical steps, or simply unavailable because the person who owns them isn't reachable. Store runbooks in version-controlled repositories (the same repo as your deployment pipelines), formatted as Markdown. Link to them from your team's incident management system. Review and version them with every major production change.

Troubleshooting: Import Fails After Restore

Symptom: You try to import a solution into the recovered environment and get a "dependency not met" error.

Cause: The restored environment is missing a base solution that your target solution depends on — often a Microsoft first-party solution or a connector that was installed separately.

Resolution: Check the solution's dependency list. Install missing base solutions first. If the dependency is a Microsoft-managed solution, find its solution name in the working production environment and install it in the recovery environment via the Admin Center (Settings → Solutions → Install).

Troubleshooting: Connection References Won't Connect

Symptom: You attempt to assign a connection to a connection reference and receive an authentication error or "connection not available."

Cause: One of three things: (a) the connection was created by a user who no longer exists, (b) the OAuth token for the connection is expired and can't be renewed automatically, or (c) the target service (SharePoint, Azure) has DLP policies that block the connection type in this environment.

Resolution: Create a fresh connection from the service account. If DLP is blocking it, check whether the recovered environment has the same DLP policy assignments as production — a restored environment inherits its own DLP policy from the restore, but DLP policies are administered at the tenant level and may need to be re-applied.

---

Summary & Next Steps

Disaster recovery for Power Platform is not a single technology — it's a system of preparation, documented procedure, and practiced execution. The automatic backup system gives you Dataverse continuity, but it doesn't give you a path to operational service on its own. You close that gap with manual backup artifacts from your deployment pipeline, a structured runbook that covers both the restore mechanics and the post-restore reconnection work, and quarterly DR drills that prove your procedures before an incident proves otherwise.

The key architectural principle is restore-to-new. Never overwrite production with a restore unless you have exhausted other options. Instead, restore to a recovery environment, validate, reconnect, test, and cut over. This pattern gives you a reversible path at every stage and protects against restore errors compounding the original incident.

The runbook is the deliverable that matters most. A team that understands the platform deeply but has no written procedure will take four hours to recover. A team with a tested, versioned runbook will take one. Write it now, test it quarterly, and update it every time production changes significantly.

What to do next:

• Audit your current production environment for non-solution-aware flows and migrate them into solutions. This is your single highest-impact DR improvement.
• Add a solution export step to your deployment pipeline and verify artifacts are being retained for at least 30 days.
• Schedule your first DR drill for next quarter. Even a two-hour exercise against a sandbox will reveal gaps you didn't know existed.
• If you haven't already, review your governance and compliance posture — the connection reference registry and ownership tracking it surfaces are prerequisites for fast, confident recovery.
• Ensure your monitoring infrastructure is in place before you need DR. A monitoring and alerting system that detects failures in the first minutes after a restore gives you early confirmation that recovery is working — or early warning that it isn't.