To be able to effectively trial Gearset for CPQ, the first step is to set up the Gearset External IDs in several environments. This will allow Gearset to identify the same piece of CPQ configuration using a custom Gearset External ID field (based off the Salesforce ID) to highlight configuration changes that exist for you to migrate.
There are several ways to achieve this set up based on your circumstances:
Full copy sandbox refresh
You can set up your CPQ trial by using the full copy sandbox refresh approach. It's the easiest solution and our recommended approach to make sure your full copy sandbox and production org CPQ configuration is perfectly in sync.
For this process, run the Gearset External ID setup on your Production Org and THEN refreshing your lower Orgs from Prod, copying the newly created Gearset External ID to these lower environments.
We do understand however, that due to Salesforce restrictions, timing within your Dev cycle or concerns about making changes to your Prod Org, you may not be able to refresh your environments from Prod but still want to trial Gearset for CPQ.
Alternative scenario
You can still achieve this by running the external ID wizard on the Orgs that you want to test Gearset for CPQ with. We'll detail below how best to set up your Orgs so that you can best trial Gearset for CPQ.
Full/Partial Copy Sandboxes
For full or partial copy sandboxes, you don't need to newly refresh these from Prod to be able to get the Gearset external IDs to match. You can manually run the external ID setup firstly on Production and then on the full or partial copy sandbox.
Because of the relationship between the sandbox and Production, you will find the following:
Any items that were already in Prod when you did the refresh of the sandbox should match (the Salesforce IDs and therefore the Gearset IDs will be the same).
Any CPQ configurations you create NOW in the sandbox and deploy to your Prod Org will match (Gearset will default to creating our ID during the compare and deploy process - our support document goes into more detail on this).
You may see some mismatches (where the Gearset External IDs don't match between two environments) if you have created configurations in the sandbox and deployed them to Prod SINCE the refresh. We detail how to resolve mismatches below.
Non-copy environments (eg. Dev sandbox)
These lower environments are different to sandboxes that are copies of Production because the non-copy environments won't copy the Salesforce IDs of Production Orgs and therefore Gearset's External IDs won't match.
The process for setting up these Orgs would be to run the External ID on Production first and THEN seed the non-copy environment.
If you seed the Dev Sandbox (for example) from Production before running the External ID setup in either Production or the Dev Sandbox, you will see that none of the IDs will match and if you run a comparison between this Dev sandbox and Production, you will see many mismatches.
What if I don't want to alter Production to test Gearset for CPQ?
We understand that if you're only testing Gearset for CPQ, you may not be comfortable with Gearset adding a new custom field into your Production environment.
You can still perform the CPQ External ID setup on your full or partial copy sandboxes and Dev sandboxes without needing to include your Production environment.
To achieve this, you would need to run the external ID setup on your full or partial copy sandbox/s. If you were looking to include a non-copy environment into the scope of your test, then you should seed this Dev sandbox (for example) from one of the full/partial copy sandboxes using a CPQ for Gearset deployment, moving this configuration to your non-copy environment.
Manually solving mismatches
Mismatches occur when the Salesforce IDs of a certain piece of CPQ configuration are different between two environments, which leads to differences in the Gearset External ID values.
This means that when you run a comparison between two Orgs where the External IDs are different, you will see two entries for a single piece of configuration.
For example, if I create two CPQ Dev Orgs and ran the External ID setup in both, the External IDs won't match. This means in the comparison, Gearset is trying to match by External ID but can't, so you'll see two entries in the comparison for the same piece of configuration.
The manual resolution for this is to go into the Org itself and edit the value of the Gearset External ID field to match the external ID value of the other Org - this will then mean that Gearset will match those values in the comparison.
To do this, you'll need to make sure that you have permission to edit the Gearset External ID field, which requires permission to edit the Product2.ProductCode field.
You can also solve the mismatches with our data seeding tool, as explained here.
With the above, you can now set up the Gearset External ID on any number of Orgs you want to test Gearset for CPQ.