You have probably seen a flow sometimes that has no active versions and wondered why it is not active. Should it really not be used or have you just forgotten to activate it?

When, as part of a change, an existing flow needs to be deprecated, it is best to keep track of this change as well.

When you introduce new flows or new versions to existing flows, you will include them in change sets and you should use the flow version’s description to explain what has been changed in comparison to the previous version and why.

However when an existing flow becomes obsolete altogether, you will probably not include it in a change set. If you keep track of your manual deployment steps well, you will add having to deactivate the flow in the target org to your to do list, but that’s probably it.

Just like when you introduce a new flow or flow version, I advise you to describe what has been changed and why. Therefore this is the way of working I use when deprecating flows:

• Save a new version of the flow when you add “DEPRECATED – “ or “DEACTIVATED – “ in front of this flow version’s label
• Use the flow version’s description to log the reason for deprecating the flow

• Activate this version
• Add it to you change set
• After successfully deploying your change set into you target org
  • Activate all new flow versions (you can tell by last modified date or the "is using an older version" checkbox in your flows list view)
  • Then deactivate each flow where you see a label that starts with “DEPRECATED” or “DEACTIVATED”

This way you will have documented properly why a flow is not used anymore across your sandboxes and production org. No more accidentally activating a flow that should remain inactive, just because you do not know why it is inactive.