Data migration
May 31, 2022
The problem with CPQ configuration data
Why is it so difficult to deploy?
.jpeg){kind=avatar}
In this blog, we’ll examine the issue with deploying Salesforce configuration data and discuss why deploying metadata is easier. We’ll explain why Salesforce managed packages use configuration data in the first place—plus, we’ll mention how to streamline Salesforce CPQ configuration data deployment.
Configuration data, or reference data, achieves a specific functionality in a Salesforce app. It’s like metadata in that it describes how the system behaves. However, it’s stored as transactional data in Salesforce’s databases. Because Salesforce doesn’t have tools to manage reference data, it’s critical for Salesforce CPQ users to understand why it exists and how it works. It becomes particularly challenging when you need to promote many changes with complex relational data from a sandbox to production. You can’t use change sets, because they only work for actual metadata types. You can use Data Loader—but that can be a laborious, lengthy, and painstaking process. Especially when you have a high volume of complex relational data, like in Salesforce CPQ, you can spend hours mapping objects. And that’s before mistakes and do-overs.
In Salesforce, metadata is native to the platform. Salesforce can create new types of metadata when needed and has hundreds of types of metadata to power its applications. For example, Salesforce created Einstein bots—with dialog as a new custom metadata type within the platform. Once the dialog was added as a metadata type, customers could develop their own bots in a sandbox. Then they could define the bots’ interactions with end-users based on the dialog metadata provided. Now, when they wanted to deploy those bots from a sandbox to production, they could simply use change sets. Why? Because the metadata types are already included in org migration tools that the platform provides.
If deploying metadata is relatively easy, why do some Salesforce apps use configuration data? The answer is simple. Many apps are made by Salesforce App Partners (otherwise known as ISVs) who don’t have the ability to create new types of metadata. So when they want to specify behaviors in their applications, they need a solution. That’s where configuration data comes in.
Configuration data are records that serve as the code used by managed packages to produce some type of application behavior for applications built on Salesforce. For example, Salesforce CPQ is an AppExchange product originally created by Salesforce App Partner, Steelbrick. Even after Salesforce acquired Steelbrick, you still need to install the CPQ managed packages in your org to gain access to its many powerful features and functionalities.
One of these functionalities is Price Rules—conditions and actions that update prices. However, when Steelbrick developed Price Rules, it wasn’t an option to create a new type of metadata like with our Einstein dialog example. So they needed a different solution. Instead, they developed Price Rules as a custom Object made with configuration data. However, when you, the user, make changes to Price Rules, you can’t use change sets to promote those changes to production. Because they’re configuration data, you need to promote them as data.
Read Prodly accelerates Salesforce CPQ data deployment to discover how to do this quickly and easily.
In this blog, we’ll examine the issue with deploying Salesforce configuration data and discuss why deploying metadata is easier. We’ll explain why Salesforce managed packages use configuration data in the first place—plus, we’ll mention how to streamline Salesforce CPQ configuration data deployment.
Configuration data, or reference data, achieves a specific functionality in a Salesforce app. It’s like metadata in that it describes how the system behaves. However, it’s stored as transactional data in Salesforce’s databases. Because Salesforce doesn’t have tools to manage reference data, it’s critical for Salesforce CPQ users to understand why it exists and how it works. It becomes particularly challenging when you need to promote many changes with complex relational data from a sandbox to production. You can’t use change sets, because they only work for actual metadata types. You can use Data Loader—but that can be a laborious, lengthy, and painstaking process. Especially when you have a high volume of complex relational data, like in Salesforce CPQ, you can spend hours mapping objects. And that’s before mistakes and do-overs.
In Salesforce, metadata is native to the platform. Salesforce can create new types of metadata when needed and has hundreds of types of metadata to power its applications. For example, Salesforce created Einstein bots—with dialog as a new custom metadata type within the platform. Once the dialog was added as a metadata type, customers could develop their own bots in a sandbox. Then they could define the bots’ interactions with end-users based on the dialog metadata provided. Now, when they wanted to deploy those bots from a sandbox to production, they could simply use change sets. Why? Because the metadata types are already included in org migration tools that the platform provides.
If deploying metadata is relatively easy, why do some Salesforce apps use configuration data? The answer is simple. Many apps are made by Salesforce App Partners (otherwise known as ISVs) who don’t have the ability to create new types of metadata. So when they want to specify behaviors in their applications, they need a solution. That’s where configuration data comes in.
Configuration data are records that serve as the code used by managed packages to produce some type of application behavior for applications built on Salesforce. For example, Salesforce CPQ is an AppExchange product originally created by Salesforce App Partner, Steelbrick. Even after Salesforce acquired Steelbrick, you still need to install the CPQ managed packages in your org to gain access to its many powerful features and functionalities.
One of these functionalities is Price Rules—conditions and actions that update prices. However, when Steelbrick developed Price Rules, it wasn’t an option to create a new type of metadata like with our Einstein dialog example. So they needed a different solution. Instead, they developed Price Rules as a custom Object made with configuration data. However, when you, the user, make changes to Price Rules, you can’t use change sets to promote those changes to production. Because they’re configuration data, you need to promote them as data.
Read Prodly accelerates Salesforce CPQ data deployment to discover how to do this quickly and easily.
.png)