Why remove inactive metadata?
It is a popular practice to deactivate or hide, as opposed to remove, unneeded metadata components in Salesforce Orgs. It is faster. But is it good?
Even though some automations might be inactive because they aren't ready for deployment or were temporarily deactivated due to errors, many deactivated components are simply forgotten.
These forgotten assets in your Org eventually lead to:
Slower impact assessments: Dependencies on inactive metadata add unnecessary complexity to change management.
UI clutter: Inactive metadata fills the UI, making it harder to navigate active components.
Missed opportunities: Components that may have been deactivated for a valid reason can still be repurposed or improved if analyzed properly.
By finding and either re-enabling or removing inactive metadata, you streamline your Org, reduce confusion, and improve the overall health of your platform.
When to Find and Remove Inactive Metadata?
You should perform this activity when:
Technical debt is accumulating: You notice a high volume of inactive metadata causing clutter and slower performance.
Preparing for major updates or Org optimization: When planning large projects or cleanups, removing inactive components helps reduce complexity.
Errors caused deactivations: Investigating components that were disabled due to errors may reveal easy fixes or insights for future use.
Avoid removing inactive metadata if it is only temporarily deactivated for testing or troubleshooting purposes.
Prerequisites
In order to follow this guide you need:
Salesforce Metadata Management license
Synced Salesforce Org into Metadata Dictionary
Perform Inactive Metadata Removal
To clean up inactive metadata efficiently, you can leverage Elements.cloud's Analytics 360, Custom Views, and Metafields features. Let's discuss how to use them in sequence:
Step 1: Use Analytics 360 to Identify Inactive Metadata
In Elements.cloud, open the Technical Debt dashboard using the Analytics 360 feature. Using 'Inactive Metadata' chart, identify the total volume of inactive metadata components across your Org by different metadata types.
The dashboard gives a high-level overview of how much inactive automation is present, allowing you to assess the scale of the cleanup needed.
Step 2: Create a Custom View to Locate Inactive Components
In the Metadata Dictionary, create a custom view to focus on the specific metadata types that can be active or inactive:
apex trigger,
approval process,
assignment rule,
business processes,
duplicate rule,
escalation rule,
flow,
matching rule,
process builder workflow,
report type,
record type,
workflow rule,
validation rule
Include following attributes to be displayed as columns:
API name
Metadata type
Active
Last modified date
Last modified by
Description
Set a filter where the "Active" field equals "Inactive". This will list all metadata of the specified types that are currently deactivated.
Tip: You can further refine this view by sorting inactive components by metadata type or last modified date to focus on inactive metadata in specific cohorts.
Step 3: Define MetaFields to Classify Inactive Metadata for Action
Before proceeding, define your MetaFields.
MetaFields allows you to define custom fields you can add to different metadata types in your metadata dictionary for further analysis.
Proposed MetaField definitions
Proposed MetaField definitions
MetaFields applied to metadata types:
apex trigger,
approval process,
assignment rule,
business processes,
duplicate rule,
escalation rule,
flow,
matching rule,
process builder workflow,
report type,
record type,
workflow rule,
validation rule
Action Needed on Inactive Metadata:
Field type: Picklist
Values:
Delete
Re-Enable
Undecided
Purpose: Classifies the future state of inactive components.
Deactivation Reason:
Field type: Text field
Purpose: Captures the justification for deactivation. Enter reasons such as “Error-prone,” “Outdated,” or “Not needed.”
Review Date:
Field type: Date Field
Purpose: Specifies when the component should be revisited.
Step 4: Review Inactive Components
Using the Custom View, review information about the inactive components:
Use the 'Last modified date' to determine when the component was deactivated or last touched. Components that have been inactive for over a year are likely forgotten assets that are candidates for deletion.
Review 'Description' (which stores Salesforce description) to determine the business purpose behind creating the component in the first place.
Inactive component that have no description and have been last modified a long time ago could potentially be safely deleted from the Org as forgotten assets. However, you might want to do a deeper analysis, like:
Review change logs to understand evolution of the metadata definition over time
Consult with whoever is listed as 'Last modified by' on why the component was deactivated.
Once you have identified why component was deactivated, you can document that information, alongside action you plan to take, by updating MetaFields.
You can either change that one-by-one in the right panel for a selected component, or perform bulk operations:
Step 5: Document action
From the custom view, bulk-select the metadata components that are inactive and you have decided to either delete completely or re-enable (apply a filter to only display one or the other!)
Then bulk-create user stories from the selected components to capture the work required.
Assign captured stories to the appropriate team members and link them to Jira if needed, using Elements.cloud's integration capabilities. You can then pick up those stories for development from your backlog and deliver it when there is capacity.
