Salto for
Salesforce
Articles
SHARE
Doug Gardner
December 23, 2024
4
min read
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’.
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:
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:
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.
Salto for
Salesforce
Salesforce
SHARE
Doug Gardner
December 23, 2024
4
min read
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’.
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:
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:
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.