This article assumes that the Gearset external ID exists and has been added to the CPQ and related objects. See our getting started guide for how to correct align the record IDs using the setup wizard in conjunction with our recommended full copy sandbox refresh approach.
Introduction
Gearset's external ID setup wizard adds the Gearset external ID field to the necessary CPQ and related objects, whilst also populating the external ID for existing records with our own record ID (based off of the existing Salesforce record ID).
So, what happens when it comes to deploying new CPQ records that have been created after the setup process has been run? This article explains how Gearset automatically handles the comparison and deployment of new records - even when they don't have a Gearset record ID when first created.
Creating and deploying new records after setup
Take the following scenario whereby:
The existing CPQ configuration between your orgs are perfectly in sync (we recommend using a full copy refresh approach to align your existing CPQ configuration perfectly).
You then create a new product record ('USB Cable') in your Dev Sandbox
You want to deploy it to your Full copy sandbox and finally to your Production org
The new USB Cable product record will have a Salesforce record ID when created in your Developer Sandbox (e.g. Salesforce record ID: 'CVWEmv1MA'), but will not yet have a Gearset record ID
So, what happens when it comes to comparing and deploying this new record?
tldr; if no Gearset record ID exists, we automatically fall back to using the reverse of the record's existing Salesforce record ID as part of our real-time comparison and deployment logic. If a Gearset record ID does exist - we use it during comparisons and deployments. As long as you use Gearset for all comparisons and deployments - we'll handle the rest.
Gearset can tell that since our external ID field exists, but there's no Gearset record ID populated, this org is where the new record was created (i.e. originates from).
Since the Gearset record ID is blank, and Gearset simply bases its own external record ID off of the existing Salesforce record ID, this specific record would have a Gearset record ID value of: 'aM1vmEWVC' (i.e. the reverse of the Salesforce record ID CVWEmv1MA).
When the comparison starts, Gearset automatically resorts to using its version for the record ID to compare against records in the target in lieu of no ID being actually present
At deployment time, Gearset handles the deployment of that new Gearset record ID value 'aM1vmEWVC' to the chosen target org(s)
It's the same process when comparing between orgs ('empty' values are handled in real time by simply looking at the existing Salesforce record ID and reversing it during comparison).
Deploying from Developer Sandbox to Full copy to Production
If I then deploy from my Full Copy Sandbox to Production org, we'd deploy the Gearset record ID that exists as a result of the previous deployment
I now have a consistent Gearset record ID between all 3 environments
Two of those being the result of deployments and one we determine in real time during comparisons and deployments by falling back to what our record ID would be, if it were present
