Tag Archives: data migration

A digital bull's eye representing data accuracy

Salesforce Record IDs: When Do They Change?

Deploying relational data between Salesforce orgs can be challenging when you’re navigating how and when Salesforce record IDs change. If you’re not careful, you may end up with duplicate records… and a lot of extra work.

In this blog, we discuss when record IDs are different and when they remain the same. We also explain how to prevent duplicate data records with Prodly.

Salesforce Record IDs Are Different After Data Migration

Salesforce assigns a unique record ID to each record when you import it into an org. It doesn’t matter whether you import it using manual entry, a simple single-object data loader, or a sophisticated data migration tool like Prodly. 

Salesforce breaks the association between orgs. When you move a data set from one org to another, Salesforce assigns a new record ID to each record in the data set. Think, for example, of when you move data from sandbox to production or from production to sandbox.

Salesforce Record IDs Remain the Same After a Refresh

During a full or partial sandbox refresh, Salesforce copies Salesforce record IDs from production to the sandbox. Because it copies the record IDs, they remain the same. 

Salesforce also copies record IDs when you refresh a Developer or Developer Pro sandbox for standard objects like Products, Price Books, Price Book Entries. It also copies them when you clone a sandbox.

Even when it copies record IDs, Salesforce still breaks the association of the records between orgs. Because the orgs aren’t synced, changes in one org after the refresh will not be reflected in the other.

When you move updated data from a sandbox to your production org, Salesforce assigns a new record ID to each record. If you haven’t taken any precautions against duplication, Salesforce inserts the data set from the sandbox without updating any of the old records in production.

How to Solve the Duplicate Data Problem Manually

Many Salesforce admins get frustrated with the process of deploying data between orgs without creating duplicate records.

Oftentimes, they assign external IDs to each object in a data set to associate the object with a parent object outside Salesforce. If you’ve used this technique before, you know it’s laborious, time consuming, and prone to error.

Prodly Prevents Duplicate Data With Automation

Prodly eliminates this time-consuming manual task with its exclusive automatch feature. When you migrate data, the automatch manager automatically creates an association between source and destination org Salesforce record IDs. It then stores this information in the Prodly app. 

This eliminates the need to manually create and maintain formal external IDs on every record. And that saves you a lot of time and work.

A digital bull's eye representing data accuracy

When you deploy data between orgs, Prodly first checks to see if the source records have a matching record with the same Salesforce record ID in the destination org.

If there isn’t a match, Prodly checks its automatch database to see if the records are the same but the IDs are different. If Prodly doesn’t find a match, it creates a new record. This prevents duplicates during a data deployment.

It’s best to set up the automatch manager when you move data from an existing org to an empty one, from a sandbox to a production org, or after a sandbox refresh.

However, you can still set up automatch during a development cycle. This involves a few extra steps to consolidate data and ensure the automatch manager accounts for all the matching records.

Learn more about setting up the automatch manager and about automatch in general on our help site.

Successful relational data deployment starts with understanding when Salesforce record IDs change and when they’re copied.

Prodly takes matching and changing Salesforce record IDs into account when you deploy relational data with the automatch manager. This solves the problem of duplicate data records without extensive use of external IDs.

Simplify Salesforce data migration

Simplifying Salesforce CPQ Implementations for Coastal Cloud

Coastal Cloud leverages Prodly to facilitate faster, more accurate Salesforce CPQ implementations.

Salesforce CPQ Implementations Are Smoother With Prodly

Coastal Cloud is a Salesforce™ Platinum Partner based in Florida, with additional development centers in Kentucky and Colorado. They help clients leverage Salesforce Revenue Cloud (Salesforce CPQ and Billing) to improve business results and deliver a superior customer experience.

Q2C implementations can be a time-consuming process due to the complexities of relational data migration. Coastal Cloud has overcome this challenge by employing Prodly.

This Q&A with Mike Ackerman of Coastal Cloud discusses how his team uses Prodly to enable efficient Salesforce CPQ implementations.

Simplify Salesforce data migration

Q: Mike, what is your role at Coastal Cloud?

I’m a senior technical architect at Coastal Cloud. I help our client implementation teams during the design, build, and deployment phases. I promote best practices and best-in-class tools so our consulting teams can deliver projects consistently and efficiently.

Q: Can you describe Coastal Cloud’s experience with Salesforce CPQ and Billing implementations?

We’re a leading implementation partner of Salesforce Revenue Cloud, which includes Salesforce CPQ and Salesforce Billing. We’ve implemented some of the largest and most complex quote-to-cash deployments to date.

Coastal Cloud is on a shortlist of partners with deep experience in both CPQ and Billing. We’re a long-standing partner. We worked with SteelBrick, which was founded by Prodly’s CEO, before it was acquired by Salesforce and became Salesforce CPQ. We’re happy to say that relationship continues today.

We’ve performed many Salesforce CPQ and Billing deployments with complex configurations of products, pricing, availability, discounting, billing, and revenue recognition rules.

Our quote-to-cash projects range in complexity. We’ve completed simple Salesforce CPQ implementations for midsize companies and highly complex implementations for large enterprises. With quote-to-cash playing a central business role, we often integrate with ERP and other systems.

Q: Why is quote-to-cash, and CPQ in particular, so challenging from a relational data migration perspective?

The real power of Salesforce CPQ is the flexibility and configurability. You need the ability to make product catalog reference data changes quickly and easily to leverage that power.

However, there’s a complex reference model working behind the scenes to enable this configurability in Salesforce CPQ. Implementation teams need to treat this reference data as another important artifact to be appropriately managed across environments.

When it comes to disciplined configuration management, you need to treat reference data as a first-class citizen. This is alongside the programmatic and declarative deliverables necessary to build and deliver the project.

Q: Why is relational data migration such a challenge?

Before we discovered Prodly, our teams executed a very labor-intensive process. It involved exporting configuration data changes to spreadsheets and meticulously loading them back into the target environments.

Salesforce’s internal IDs and lookup relationships are very complicated. So that load process had to account for the re-keying of relationship data. We needed to carefully load the parent and child rows in the correct order. Then we have to re-key the child rows to point to the newly imported parent.

This is a concern with related objects, as well as with rows within the same object that have a recursive relationship. You need to ensure that you’re loading the rows within the same object in the right order. Plus, you need to re-key those child rows before you can load them.

When you deliver changes to an existing target of reference objects, you identify each row with a unique external key. That way, you know if a row is being updated, inserted or deleted.

As you can imagine, using export spreadsheets with Data Loader can be a very labor-intensive and error-prone process.

After we discovered Prodly, this became a much more automated process. It saves us significant effort and reduces the risk of error.

Q: How long did it take to migrate reference data without Prodly?

Many factors impact the complexity of the Salesforce CPQ and Salesforce Billing model. Think of how many products are in the catalog, as well as the number of options and features you have. In addition, consider the complexity of the pricing and discounting rules.

All these factors influence the migration effort. However, it can easily take a full day to do one load without effective tools. This isn’t a scalable process when you’re following an agile development model.

Q: How do you integrate Prodly into your Salesforce CPQ implementation process?

In an agile development environment with two-week sprints, you want to set up and shut down feature development environments frequently.

To make your developers productive, provide them a full copy of the product catalog from which to develop and test. And you need to reduce that full-day migration process to execute refreshes reliably and frequently.

Let’s say we have three developers working on a two-week sprint. We start the sprint by setting up three empty DevPro orgs . Then we use Prodly to instantly populate these empty orgs with current product catalog reference data. Later, we’ll migrate that reference data to a fourth environment to support testing activities.

We also use Prodly for quick, ongoing deliveries of incremental data changes for bug fixes. When a fix is ready for production, we save time and reduce risk by delivering the final reference data using Prodly.

Note that we reduce our users’ outage window significantly by using Prodly during the production migration.

Q: How do you avoid duplicates when you migrate relational data?

You’ve got to ensure you have a unique surrogate identifying key on each of the rows of the product reference objects.

Prodly uses this key to identify whether it’s an insert, update, or delete action when copying the data. Hopefully, a surrogate key exists in your data set already, but a lot of times we find one does not.

For instance, you might assume the product SKU is surrogate, but in reality there may be business meaning in that SKU. Perhaps those first two letters of the SKU indicate the line of business.

Perhaps the business team decides somewhere down the line that they want to change that SKU during a rebranding effort. Where you thought something was a surrogate unique identifier, it may in fact change in the future. That could break your deployment process.

Ideally, you want to start the project by identifying truly unique surrogate IDs for each row. You want the developers to set a surrogate ID once—and know it is never going to change.

IDs should have no business meaning and must reliably identify the uniqueness of a row as it moves across environments.

As Salesforce developers know, we can’t use the Salesforce ID for a surrogate key. The ID is not updatable and it changes as it moves from org to org. Surrogate IDs are an important success factor in making the reference data management process reliable.

Q: How exactly do you configure Prodly data sets to migrate CPQ reference data?

Today, this is part of the startup steps for getting a Salesforce CPQ implementation project up and running. We install Prodly in the client’s org. Then we the data set or template for the objects we’re going to ask Prodly to move back and forth.

The data set represents the configuration, or instructions, on how the data will be moved. We define this initially in production to prepare for the copy of data from production to our development and test orgs.

When you’ve made changes in the development org, it becomes the new source. Those changes can be copied to test and later to production. To re-use the data set configuration we already defined in production, we copy it to the development org. That way, it can also facilitate that org’s new role as being the source for changes.

Currently, Prodly must be installed in any org that acts as a source for copying data. We can also use Prodly to push its own data set configurations to and from various source orgs. That way, we don’t need to re-define the data set from scratch. We’re essentially creating our own template.

With Prodly’s centralized deployment architecture, pushing data sets and installing Prodly in the various source orgs will no longer be necessary. Instead, we’ll be able to manage deployments from a central org. This will be another big time saver.

The centralized deployment console can potentially offer smaller clients a shared reference data management service based on Prodly.

Q: How do you hand off the reference data update process to a client once you finish your Salesforce CPQ implementation?

Our standard methods and tools now include the use of Prodly for managing complex reference data migrations.

During our discovery phase, we identify if these challenges are present. Our teams identify this risk early and ensure the project is scoped to include the appropriate tools to mitigate this risk. This helps to ensure our clients and delivery teams are set up for success.

Prodly is a key part of our risk mitigation tool set.

Ideally, we want our clients to procure their own Prodly licenses. That way, once we’ve successfully delivered our project, the client’s Salesforce support team can continue to smoothly execute the process.

We ensure the process is well documented and train the client’s administrators on how to use the tools. We have a very robust configuration and release management process that’s well documented and repeatable.

Some clients opt to engage us for long-term Salesforce support. In those cases, which we continue to leverage Prodly for highly efficient reference data management.

Q: Any final thoughts?

Using Prodly, we’ve been able to dramatically improve the efficiency and quality of managing our Salesforce quote-to-cash data. We’ve taken a day-long reference data process and now execute it reliably in mere minutes. Prodly has drastically improved the way we operate and increased the ROI for our Salesforce quote-to-cash clients.

Do these Salesforce CPQ data migration challenges sound familiar to you? 

Schedule a free demo now to see how Prodly can help !