Flow activation state after change set deployment
Key Takeaway
A flow deployed by change set arrives inactive by default, so an admin activates it by hand. To have processes and autolaunched flows arrive active, enable "Deploy processes and flows as active" in the production org's Process Automation Settings and enter a flow test coverage percentage.
When you move a flow from a sandbox to production with a change set, the flow arrives inactive by default, even if it was active in the sandbox. You have two ways to make it active. You can activate the correct version by hand after deployment. Or you can enable a production-only setting that lets processes and autolaunched flows deploy as active when the org meets its flow test coverage requirement. Activation isn't the only step after deployment, so you also debug and check the flow in production.
What happens when a change set deploys a flow
By default, an active process or flow in a change set is deployed to the destination org as inactive. After deployment, an admin must manually activate the new version.
A change set can include only one version of a flow. If the flow has no active version when you upload the outbound change set, the latest inactive version is used.
Each deployment or redeployment of a flow with a change set creates a new version of that flow in the destination org, so a flow in production can build up several versions over time.
Dana builds a flow called Renewal Reminder in a sandbox and activates it there. She adds the flow to an outbound change set and deploys the change set to production, which uses the default settings. In production, Renewal Reminder arrives as a new inactive version, so Dana must activate it by hand. A month later, she fixes a bug in the sandbox and deploys the flow again. Production now has another new version of Renewal Reminder, so Dana has more than one version to choose from when she activates.