Sort by Topics, Resources
Clear
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Salto for

Salesforce

Articles

SHARE

The power of sandbox seeding from a CPQ view

Doug Gardner

December 23, 2024

4

min read

Intro

Having worked with many customers and in many companies that change and alter their systems, I have seen many different DevOps approaches. These approaches have varied from the vilified ‘just do it in Prod’, to a 9-level sign-off structure with multiple sandboxes at each level. I actually remember the first time I started using sandboxes when connecting eBay to Magento and the freedom it gave, even if we then had to duplicate the completed work into Production. There is no question in today's tech world that sandboxes should be used for any changes and that an organisation-wide approach to deployments is required. It is also true that in today's world, that “data is king” meaning that when building, you have to consider data, not just config. 

So, do Sandboxes and Data play well together? We will consider this using the example of Salesforce CPQ. Salesforce CPQ is a Salesforce product implemented via a managed package that uses records for configuration, i.e. the package checks records (data) rather than system-level config (meta-data) when making decisions. This means that you have to get the data into Sandboxes to work on the product. This process is called ‘seeding’. 

Experience the Ease & Confidence of NetSuite Customizations with Salto

Automate the way you migrate Jira configurations from sandbox to production

STAY UP TO DATE

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

How do you seed?

The easiest way to seed a Salesforce Sandbox is by choosing the right type of Sandbox. To help explain this, it is worth knowing that a sandbox is a non-production copy of another software instance, usually Production. A general guide to when different types of Sandbox are available can be found in this help document, but here is a rough guide to the types of Sandbox available:

  1. Full - a full copy of all config and data although it does have slightly different limits. 
  2. Partial - a full copy of config and up to 10,000 records for each object in the configured mapping. 
  3. Developer Pro - A full copy of the configuration and improved usage limits.
  4. Developer - A full copy of the configuration and basic usage limits.

To move information between Sandboxes, you need to carry out deployments. There are multiple tools for carrying out deployment, such as the internal Change Set tool or more advanced tools like Salto.io. In essence, these tools enable you to move information from one instance to another; this information could be configuration, code, or, with some tools, data.

The way that Salto.io does this is really quite genius. When moving records, it translates them into metadata and then moves them over. This improves predictability and removes the need for cumbersome text fields showing Id’s. From my experience using tools and creating these reference fields, it doesn’t take long for them to get out of sync and restricts the use of practices like a ‘Quick Fix’ sandbox. This also allows better checking of changes and reduces the likelihood of duplication caused by deployment. 

Moving this information and the testing required is at the core of DevOps. Good DevOps will involve building in one environment and testing in a copy of Production before deploying into Production. This can get complicated, but a basic model for DevOps looks something like this:


For this reason, a Full copy sandbox is typically used at the ‘UAT’ sandbox shown above, which can be refreshed frequently without losing work. The Partial sandbox is often used for QA as well if included in the model and available, and this means that the Developer Sandboxes need to be populated with records before any work can take place. This takes us back to seeding. 

Historically, seeding has occurred through tools, or a manual process in which records such as Price Rules are exported from Production and imported into the Developer Sandbox. Due to the relationships, this has to occur in a set order and takes a lot of time, sometimes days. Some custom fields need to be created for reference points from Salesforce ID’s. In my nine years of CPQ experience, this occurs infrequently across only a few environments. This profoundly influences the businesses involved, as there are many advantages to having properly seeded sandboxes. Here is a list of the main advantages of having a properly seeded CPQ Sandbox’s always available and easy/quick to spin up: 

  1. CPQ is always available to be considered in all builds. It is sometimes hard to realise how far its tentacles can reach.
  2. The speed of case resolution is improved massively. I have seen examples where resolution has gone from weeks to less than a day. 
  3. Issues can be worked on in the exact situation in which they occurred; this enables trusted replication, leading to better quality solutions without requiring a UAT refresh.
  4. Freer investigation can take place by multiple teams in multiple places as it becomes reasonable to use multiple sandboxes for multiple teams. 
  5. CPQ error messages are notorious for being hard to read. If it is simple to replicate the error, you can go for a ‘delete till it stops’ approach if required. This can save a dramatic amount of time.
  6. You can quickly provide individual environments to train people. Don’t underestimate the power of this!

STAY UP TO DATE

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

The advantages to the business can be huge from each of these examples, and there are often more to be found which are specific to the company. For this reason, seeding should be an integral part of a healthy DevOps solution, especially if you use tools, like Salesforce CPQ, which use records for their configuration.

WRITTEN BY OUR EXPERT

Doug Gardner

Founder and Consultant at Drivechain

Doug has worked with Salesforce for over 14 years and CPQ for 9 years. In that time, he worked as an end user and consultant chairing round tables for CPQ thought leaders, speaking at Londons Calling, running Revenue Cloud demonstrations for Salesforce, and predominantly working as a CPQ architect. Dougs' aim is to help end users get the most out of Revenue Cloud through human-centered-design and solid, future-focused architecture.

Sort by Topics, Resources
Clear
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Salto for

Salesforce

Salesforce

SHARE

The power of sandbox seeding from a CPQ view

Doug Gardner

December 23, 2024

4

min read

Intro

Having worked with many customers and in many companies that change and alter their systems, I have seen many different DevOps approaches. These approaches have varied from the vilified ‘just do it in Prod’, to a 9-level sign-off structure with multiple sandboxes at each level. I actually remember the first time I started using sandboxes when connecting eBay to Magento and the freedom it gave, even if we then had to duplicate the completed work into Production. There is no question in today's tech world that sandboxes should be used for any changes and that an organisation-wide approach to deployments is required. It is also true that in today's world, that “data is king” meaning that when building, you have to consider data, not just config. 

So, do Sandboxes and Data play well together? We will consider this using the example of Salesforce CPQ. Salesforce CPQ is a Salesforce product implemented via a managed package that uses records for configuration, i.e. the package checks records (data) rather than system-level config (meta-data) when making decisions. This means that you have to get the data into Sandboxes to work on the product. This process is called ‘seeding’. 

What if Zendesk was 4x less work?

Request a Demo Get started with Salto

How do you seed?

The easiest way to seed a Salesforce Sandbox is by choosing the right type of Sandbox. To help explain this, it is worth knowing that a sandbox is a non-production copy of another software instance, usually Production. A general guide to when different types of Sandbox are available can be found in this help document, but here is a rough guide to the types of Sandbox available:

  1. Full - a full copy of all config and data although it does have slightly different limits. 
  2. Partial - a full copy of config and up to 10,000 records for each object in the configured mapping. 
  3. Developer Pro - A full copy of the configuration and improved usage limits.
  4. Developer - A full copy of the configuration and basic usage limits.

To move information between Sandboxes, you need to carry out deployments. There are multiple tools for carrying out deployment, such as the internal Change Set tool or more advanced tools like Salto.io. In essence, these tools enable you to move information from one instance to another; this information could be configuration, code, or, with some tools, data.

The way that Salto.io does this is really quite genius. When moving records, it translates them into metadata and then moves them over. This improves predictability and removes the need for cumbersome text fields showing Id’s. From my experience using tools and creating these reference fields, it doesn’t take long for them to get out of sync and restricts the use of practices like a ‘Quick Fix’ sandbox. This also allows better checking of changes and reduces the likelihood of duplication caused by deployment. 

Moving this information and the testing required is at the core of DevOps. Good DevOps will involve building in one environment and testing in a copy of Production before deploying into Production. This can get complicated, but a basic model for DevOps looks something like this:


For this reason, a Full copy sandbox is typically used at the ‘UAT’ sandbox shown above, which can be refreshed frequently without losing work. The Partial sandbox is often used for QA as well if included in the model and available, and this means that the Developer Sandboxes need to be populated with records before any work can take place. This takes us back to seeding. 

Historically, seeding has occurred through tools, or a manual process in which records such as Price Rules are exported from Production and imported into the Developer Sandbox. Due to the relationships, this has to occur in a set order and takes a lot of time, sometimes days. Some custom fields need to be created for reference points from Salesforce ID’s. In my nine years of CPQ experience, this occurs infrequently across only a few environments. This profoundly influences the businesses involved, as there are many advantages to having properly seeded sandboxes. Here is a list of the main advantages of having a properly seeded CPQ Sandbox’s always available and easy/quick to spin up: 

  1. CPQ is always available to be considered in all builds. It is sometimes hard to realise how far its tentacles can reach.
  2. The speed of case resolution is improved massively. I have seen examples where resolution has gone from weeks to less than a day. 
  3. Issues can be worked on in the exact situation in which they occurred; this enables trusted replication, leading to better quality solutions without requiring a UAT refresh.
  4. Freer investigation can take place by multiple teams in multiple places as it becomes reasonable to use multiple sandboxes for multiple teams. 
  5. CPQ error messages are notorious for being hard to read. If it is simple to replicate the error, you can go for a ‘delete till it stops’ approach if required. This can save a dramatic amount of time.
  6. You can quickly provide individual environments to train people. Don’t underestimate the power of this!

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

The advantages to the business can be huge from each of these examples, and there are often more to be found which are specific to the company. For this reason, seeding should be an integral part of a healthy DevOps solution, especially if you use tools, like Salesforce CPQ, which use records for their configuration.

WRITTEN BY OUR EXPERT

Doug Gardner

Founder and Consultant at Drivechain

Doug has worked with Salesforce for over 14 years and CPQ for 9 years. In that time, he worked as an end user and consultant chairing round tables for CPQ thought leaders, speaking at Londons Calling, running Revenue Cloud demonstrations for Salesforce, and predominantly working as a CPQ architect. Dougs' aim is to help end users get the most out of Revenue Cloud through human-centered-design and solid, future-focused architecture.