Skip to main content

Eliminate Inactive CPQ Configuration

A guide to identifying, classifying, and cleaning up inactive Salesforce CPQ configuration records using Elements.cloud

Updated this week

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:

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.

  1. Create a custom view and include 'Records' as the only metadata type in scope

  2. Create a custom view with these columns:

    • Parent Object

    • API Name

    • Name

    • Description

    • Active (Status)

    • Last modified date

    • Last modified by

  3. 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

  • 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.

Did this answer your question?