Skip to main content

Agentforce Revenue Management (ARM) External ID Wizard - FAQs

Frequently asked questions on using the External ID wizard before deploying ARM (Formerly RCA - Revenue Cloud Advanced) configuration.

Written by Jacob Joshua
Updated over 2 months ago

Before you can compare and deploy any Agentforce Revenue Management (ARM) configuration with Gearset, both the source and target org ARM components and related objects must have the unique Gearset external ID field.

Before running the External ID Wizard to automatically add the external ID field, check which of the below scenarios applies to you.

Scenario 1 - You have created ARM configuration in a sandbox and need to deploy it to Production

Note: this is the most common scenario if you are implementing ARM and have not made your first deployment yet.

  1. Run the external ID wizard on your Production org. (details here)

  2. Run the external ID wizard on your sandbox(es).

  3. Use the ARM deployment feature in Gearset to deploy configuration (source is the sandbox, target is Production).

The records will have external IDs created from Sandbox Salesforce IDs.

Scenario 2 - ARM configuration is in the Production org, but not yet in your sandboxes

Note: unless you're building directly in Production this is unlikely for a new ARM implementation.

Option 1 - (details here):

  1. Run the external ID wizard on your Production org.

  2. Refresh the sandbox(es) to automatically migrate the new external ID field (metadata) and ARM records (data) and bring your sandboxes in sync.

Option 2 - (details here)

  1. Run the external ID wizard on your Production org.

  2. Run the external ID wizard on your sandbox.

  3. Use the ARM deployment feature in Gearset to deploy configuration (source is Production, target is the sandbox).

The records will have external IDs created from Production Salesforce IDs

Scenario 3 - The same ARM configuration exists in more than one sandbox, neither have an external ID.

Note: This is a likely scenario if you have been making deployments without using our ARM deployment feature.

  1. Run the external ID wizard on your Production org (details here).

  2. Run the external ID wizard on your sandboxes.

  3. If the same record is present both in multiple sandboxes (in the above example; CPU and Keyboard) there is a very high possibility that they have different Salesforce IDs, and therefore different Gearset External IDs:

    1. if the record was created manually in both Orgs, or if it was previously deployed from one Org to the other, the Salesforce IDs will be different.

    2. if the record was created in the Sandbox with a refresh from Prod, the Salesforce ID will be the same (less likely for a new ARM implementation).

  4. If a deployment with Gearset is attempted in this situation, some records will be duplicated if deployed โš ๏ธ

  5. Use the data deployment tool to overwrite the Gearset External ID fields, picking either one org as source of the deployment. This fix will be possible only if there are other fields that can be used for matching the records (i.e. another external ID).

  6. After fixing the Gearset External IDs, it will be possible to move records over with the ARM deployment feature.

Scenario 4 - Some ARM configuration was created in the Sandbox, some in Production, but the same record is never in both environments

  1. Run the external ID wizard on your Production org (details here).

  2. Run the external ID wizard on your sandbox.

  3. Use the ARM deployment feature to move records over (the deployment can safely go in both directions: Production to sandbox, then sandbox to Production).

Some records will have external IDs created from Sandbox Salesforce IDs, some records will have External IDs created from Production Salesforce IDs. The ID will be picked from the org where the record was created. Records will be deployed without duplicates.

Did this answer your question?