When choosing a CPQ tool, its ongoing administration is often overlooked. I find this surprising, as I believe this is one of the most important topics to discuss before a CPQ implementation even starts. If you cannot maintain your tool over time, the value it is providing will be lost.
Salesforce prides itself on being a tool which uses “clicks, not code” and Salesforce native CPQ solutions come with the same allure, making them attractive choices for an organisation with a team of Salesforce admins.
Beware Salesforce admins! There’s a dangerous assumption that maintaining Salesforce CPQ is similar to core Salesforce products. While there are some similarities, the differences far outweigh those. Failing to understand the level of expertise required to maintain a CPQ tool can lead to costly consequences, such as paying external consultants for longer than expected while the search continues to employ a qualified specialist (possibly another unaccounted for expense!)
I’ve seen firsthand how failing to properly prepare can impact organisations, in my role as a solution architect (currently managing a CPQ tool in an ever changing environment), and from my past life as a CPQ implementation consultant. Trust me, things can quickly get out of hand.
In this post, I will share my top tips for successfully preparing for CPQ deployments – a “what I wish I knew’. Let’s start by answering the burning question: “why are CPQ deployments so complex?”
Why are CPQ Deployments so Complex?
The number of data relationships between CPQ objects makes it difficult to deploy changes between environments. In a nutshell, you will be working with CPQ object data across multiple orgs, each record with their own unique CRM ID per org.
All Salesforce admins will know the difference between metadata (objects, fields, workflows, etc.) and data (records within an object).
Metadata can be moved relatively easily between environments using tools like Change Sets for basic environments, or more robust Release Management tools for complex environments.
Data records containing relationships, however, are not so easily moved between environments.
This is because Salesforce allocates a unique 15/18 digit ID to each record. When a record is created in an environment, it’s allocated a 15/18 digit ID. This means there is no way to maintain relationships between records when migrating data through multiple development environments and then finally, to Production (and vice versa to seed development environments).
Example: to create a single Product or Price Rule in Salesforce CPQ, you will have a minimum of two (2) records created on two (2) different objects, the rule “container” record and at least 1 action, provided there are no conditions to take into account.
You can see from the above graphic that creating a single price rule can create multiple records in multiple objects and the relationships must be maintained during deployments. For reference, Summary variables are examples of records which are not child objects of Price Action or Price Conditions, but are their own entity and can be used as tested variables on Price Actions & Price Conditions.
Now it’s time to go into my six tips for managing CPQ deployments that, hopefully, will leave you with many things to consider.
Tip 1: Invest in a Deployment tool
One of the most common ways to alleviate some of the pain CPQ deployments can cause is to invest in a paid tool which will assist in your deployments. There are a few tools on the market which can make the process much faster, however some tools have potential drawbacks which should be considered, depending on your business, before purchasing.
See Tip 2 & 4 for points to consider when purchasing a deployment tool.
Tip 2: Evaluate your DevOps Process
On the topic of paid deployment tools, some can also help to deploy your metadata components along with your data deployments.
For example, if you want to use the field “Status” in a Price Condition, you will need to manually add the API field name to the “Field” picklist on the Price Condition object. Once you do this, you will need to ensure this picklist field is updated in your destination org prior to deploying the Price Condition record which references this field.
Having your data deployment tool make this field update for you before it creates the data record which references it might sound like a huge timesaver, (no more adding custom fields one at a time to change sets, hurrah!). However, depending on your existing (or future) DevOps process, this feature may be of little value to you.
An organisation which uses Change Sets or the Force.com Migration tool may be able to utilise this feature as the purpose of these tools is to move metadata changes between environments to keep environments in sync. What these tools do not do, is commit metadata changes to a code repository.
If you are using a DevOps model which involves committing metadata changes to a code repository, tools which create metadata for you in the background bypass this process, and therefore cannot usually be utilised.
Tip 3: Don’t rely on external IDs to maintain relationships
One possible way to handle the issue caused by unique record IDs, is by assigning each record with an auto-generated External ID. These will never change from Org to Org as they are connected to the record itself.
The caveat here is that your CPQ Admin will need to be a VLOOKUP wizard in Excel and devote many hours to doing multiple extracts and uploads throughout your development environments. As this means a human is responsible for the relationships being maintained, the chance of error is high.
This can also quickly turn into a tedious task (I can tell you from experience!) I was once told by a Salesforce CPQ implementation consultant that one of their customers refused to purchase a deployment tool and doing manual deployments using Excel took three (3) business days to complete. Depending on how often you expect to do changes to your CPQ configuration, this could become a full time job in itself. And don’t forget, each time you need to seed a sandbox, you will need to do a full deployment from Production, increasing both the time and resources required.
The External ID route could be viable for an organisation with an established product base, or one which rarely changes how products are sold (e.g. configuration/pricing rules are set in stone) and has an experienced Salesforce CPQ specialist.
If you do choose this route, estimate how many records you will need to process each month. If you exceed 10,000 records/per month/org, invest in a paid license from dataloader.io due to its enhanced features (e.g. being able to relate records by referencing the Price Rule name vs the 15/18 digit ID) as opposed to Salesforce Data Loader.
Tip 4: Schedule Your Release in Advance
As with any deployment, scheduling a release in advance and deploying during your org’s quiet time can be a good idea, especially when releasing new functionality. This allows proper time to test functionality post-deployment. Salesforce, of course, does this before each release, usually on a weekend and they notify users in advance.
The same principle applies with CPQ data deployments. Try to alert your users that there will be a deployment happening and they may find some services are interrupted during this time.
Another consideration when looking to invest in a paid tool is that some require package level settings to be disabled during the deployment. This could impact your org as certain functionality may be temporarily inactive.
Finding a quiet time where the org is not in use is key. For global organisations with users spread across different time zones, this requires extra planning around each deployment.
Tip 5: Seed sandboxes with every sandbox refresh
Don’t forget to seed sandboxes with your CPQ configuration data when you refresh or spin a new development environment (sandox).
If your data migration took you 5 days to get from sandbox to Production, expect to spend about the same amount of time to seed your sandbox just to make your changes! This is where an investment in a paid tool can make all the difference.
Tip 6: Fix Critical Issues Directly in Production
You’re probably reading this “tip” thinking “fixing issues directly in Production – she can’t be serious?!” For the most part you would be correct. I would normally never advocate to do such a thing, BUT sometimes there are cases where a fix is needed there and then, and because CPQ records are data vs metadata, you can make the change direct in Production, without breaking your dev ops process (in most cases).
However, this is not advisable as a long term solution and should be done in only the most rare of cases.
If you do make any changes in Production, ensure you update your development environment manually or by using your deployment tool so that when you go to deploy in the future, you do not overwrite your manual change.
Summary
CPQ deployments are complex and should be thought about as much as the functional solution itself if you want to have a successful and highly adopted solution.
Paid solutions can be a great way to speed up deployments, but should be evaluated thoroughly. Ensure you come prepared with questions as to how the solutions will work based on your devops model and how your business operates to ensure no loss of functionality as described in tips 2&4, respectively.
Comments: