Overview
This rule flags Salesforce Flows that exist in your org but are currently inactive. Flows are Salesforce's strategic low-code automation tool. However, even Flows can become "stale" or "dead code" if they are deactivated and left in the system without proper cleanup.
Inactive Flows, while not actively executing, still contribute to system clutter, can cause confusion for admins and developers, and often indicate automation that has been superseded or is no longer needed but hasn't been properly removed.
Code reviews classifies this as a Warning because inactive Flows don't impact runtime performance, but they significantly reduce clarity, increase maintenance overhead, and complicate auditing and troubleshooting efforts in the long term.
Why This Matters
Keeping inactive Flows:
Clutters your automation layer: Makes it harder to navigate, understand, and manage the live automation within your Salesforce org, especially as the number of Flows grows.
Slows down audits and reviews: When reviewing automation, it requires extra effort to distinguish between active, relevant Flows and inactive, potentially obsolete ones.
Introduces risk of accidental reactivation: An inactive Flow could be mistakenly reactivated, potentially causing unintended business process execution or data corruption.
Increases maintenance complexity: While inactive, these Flows still need to be considered during org upgrades, package installations, or when analyzing system behavior, adding unnecessary cognitive load.
Creates onboarding challenges: New team members might spend time trying to understand or debug inactive Flows, assuming they are part of the active business logic.
Obscures the current state of automation: It becomes difficult to get an accurate picture of what automations are truly running in the org.
A clean, lean automation structure ensures that only necessary and current logic exists, promoting efficiency and reducing technical debt.
Deleting Salesforce Flows
Deleting a Salesforce Flow isn't always straightforward. Several conditions must be met to ensure a clean removal:
All versions of the Flow must be deactivated.
All references to the Flow (e.g., from custom buttons, processes, or Apex) must be removed.
If it's a managed-installed Flow, you'll need to uninstall its managed package first.
In short, a Flow can only be deleted if it's a custom Flow (not managed-installed), inactive, and has no remaining dependencies. It's a systematic process of untangling its connections before it can be fully removed.
What Triggers This Rule
Code reviews flags Flows that:
Are currently saved with a "Inactive" status.
Have not been deleted or versioned out of active consideration despite their inactive status.
Recommended Approach
Proactively audit and clean up inactive Flows:
Review ownership and confirm irrelevance: Determine who created or last modified the Flow and confirm with stakeholders that its logic is truly no longer needed or has been fully replaced by a current, active automation.
Document replacements: If the Flow was replaced, clearly document which active Flow (or Apex, or other automation) now handles the original logic. This is crucial for future reference and understanding the automation landscape.
Delete or archive unnecessary Flows:
If a Flow is completely obsolete and has a clear replacement or is no longer needed, delete it. This is the cleanest option.
If there's a slight chance it might be needed in the distant future, or if historical context is critical, consider documenting its details externally (e.g., in a version control system, Confluence, or a dedicated "Archived Flows" custom object if your org has one) before deleting it from the org to reduce clutter.
Version Management: When making significant changes to a Flow, activate a new version rather than constantly deactivating and reactivating the same version. This creates a clear history. Once a new version is active, old inactive versions should be reviewed for deletion if they are no longer required for rollback purposes.
Summary
Inactive Flows, while benign in execution, create unnecessary clutter and complexity in your Salesforce automation environment. They hinder clarity, increase maintenance efforts, and pose risks if accidentally reactivated. Code reviews flags these as Warnings to encourage proactive cleanup, ensure a well-organized and efficient automation framework, and maintain a clear understanding of your live business processes.