flow-deployment-activation-ordering

name	flow-deployment-activation-ordering
description	Use when deploying Flow metadata across environments and worrying about activation order: which flow version becomes active, how paused interviews survive deploys, and how to avoid the 'two active versions for a moment' race. Covers SFDX / Metadata API deploy flags, 'Deploy as Active', rollback, and paused-interview safety. Does NOT cover Flow authoring best practices (see flow-bulkification) or general release management.
category	devops
salesforce-version	Spring '25+
well-architected-pillars	["Reliability","Operational Excellence","Security"]
triggers	["flow deployment activation order","sfdx deploy flow activate","paused interview after flow deploy","flow rollback after deploy","multiple flow versions active"]
tags	["devops","flow","deployment","activation","release"]
inputs	["Target environment + branching strategy","Flows changing in this release","Paused interviews / scheduled interviews in flight","Rollback SLA"]
outputs	["Pre-deploy inspection (which flow versions, paused interviews)","Deploy procedure (activation order, guards)","Rollback plan","Post-deploy verification"]
dependencies	[]
version	1.0.0
author	Pranav Nagrecha
updated	2026-04-23T00:00:00.000Z

Flow Deployment & Activation Ordering

Purpose

Flow deployments are deceptively tricky. Unlike Apex, Flow preserves previous versions in the org; the "active" version is a pointer. A deploy can inadvertently deactivate the currently-running flow, leave two flows active in sequence, or break paused interviews that refer to the old version. The team hits production incidents: "the approval flow stopped triggering," "paused interviews threw after deploy," "rollback just deactivated everything." This skill codifies the sequence, guards, and verification to make Flow deploys boring.

When To Use

• Planning a release that changes any Record-Triggered, Screen, or Scheduled Flow.
• Debugging paused interview failures after a deploy.
• Writing a Flow rollback runbook.
• Standardizing Flow CI/CD.

Recommended Workflow

1. Inventory changes. Which flows changed? Which have paused interviews or scheduled runs currently in progress?
2. Check active versions in target org. sf data query against FlowDefinition and Flow to confirm what is active today.
3. Pick activation mode. Deploy as active (default) vs deploy as inactive then activate via FlowDefinition update. Inactive-first is safer for risky flows.
4. Plan the order. If Flow A calls Subflow B, deploy B first (active before A switches).
5. Communicate pause windows. If paused interviews exist on the changing flow, delay deploy or accept that paused interviews may fail on resume.
6. Deploy. Use --test-level RunSpecifiedTests when Apex callers exist; Flow itself has no test framework parity.
7. Verify. Re-query active versions post-deploy; run a smoke Flow interview; check for spikes in Flow error emails.
8. Rollback plan. Keep prior active version id; rollback = flip pointer on FlowDefinition, not redeploy.

Active vs Inactive Deploy

• Default SFDX behavior: deploys a new flow VERSION; activation depends on flags.
• --ignore-warnings can mask inactive deploys silently activating.
• For risky flows, explicitly deploy as inactive, then flip activation in a separate step once verified.

Paused Interview Risk

Paused interviews reference a specific version. If that version is deactivated or deleted, resume fails. Mitigations:

• Do not delete prior versions for N days (retain for paused interview survival).