Why eliminate inactive CPQ configuration?
In Salesforce CPQ environments, it's common practice to deactivate configuration records—such as price rules, product rules, and approval conditions—when they become outdated, buggy, or temporarily unnecessary. However, these inactive components often become forgotten assets over time, cluttering the system and introducing hidden risks:
Technical debt: Accumulation of obsolete metadata complicates future enhancements.
Confusion for administrators: Distinguishing between temporarily and permanently deactivated records becomes difficult.
Risk of accidental reactivation or duplication: Forgotten rules might be unintentionally reused, causing unpredictable behavior.
Regularly reviewing and classifying inactive components ensures your CPQ configuration remains clean, maintainable, and aligned with business needs.
When to eliminate inactive CPQ configurations?
You should conduct this review:
During quarterly technical debt assessments.
After major product or pricing changes.
When preparing for CPQ system upgrades or refactoring.
As part of post-implementation cleanups after large projects.
Avoid large-scale deletions without proper review and stakeholder input to prevent unintended consequences.
Prerequisites
Before proceeding, ensure you have:
Access to the Elements.cloud platform with a connected Salesforce Org.
Revenue Cloud (SBQQ) Add-on license
Space admin permission to create MetaFields
Perform the Cleanup of Inactive CPQ Configuration
Step 1: Identify inactive configuration records
In the Salesforce Metadata Dictionary, create a custom view to focus on the records that can be active or inactive.
Create a custom view and include 'Records' as the only metadata type in scope
Create a custom view with these columns:
Parent Object
API Name
Name
Description
Active (Status)
Last modified date
Last modified by
Apply filter: Active is equal to Inactive to list all inactive CPQ-related records. This will include:
Price rules, price actions, price conditions
Configuration rules, product rules
Approval rules, approval conditions
Billing, revenue recognition, tax, and GL rules and treatments
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 2: Define MetaFields to classify inactive CPQ configuration records
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
Action Needed (Picklist)
Values:
Delete
Re-Enable
Undecided
Purpose: Defines the intended future state.
Deactivation Reason (Text field)
Purpose: Captures why the component was deactivated. Examples: “Error-prone”, “Outdated”, "Not needed”
Review Date (Date field)
Purpose: Sets a future date to reassess the component’s relevance.
Step 3: Review inactive records
Using the Custom View, review information about the inactive records:
Use the 'Last modified date' to determine when the record was deactivated or last touched. Records 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 record in the first place.
Inactive record 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 record definition over time
Consult with whoever is listed as 'Last modified by' on why the record was deactivated.
Once you have identified why record 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 4: Raise user stories based on classifications
From the custom view, bulk-select the records that are inactive and you have decided to either delete completely or re-enable.
You can change your custom view to include MetaFields and filter CPQ records based on their values, for instance Action Needed = Delete or Re-Enable.
Then bulk-create user stories from the selected records to capture the work required for the backlog.
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.