Help center

VEID Manager

Overview 

The Release virtual external ID manager is a behind-the-scenes, Prodly-proprietary feature of the cloud-based Prodly service and centrally-controlled deployment architecture. The purpose of the VEID manager is to prevent duplicate record creation as you deploy data between orgs.

Instead of requiring the time-consuming process of adding formal Salesforce external IDs (FEID) to every object you deploy or determining field combinations that create unique Release composite external IDs (Standard Upsert) for every object, simply select Virtual External ID from the Record Matching Method picklist on the data set Element Details tab in the data set editor to use the VEID manager.

The Duplicate Record Prevention Challenge 

When deploying records from a source to a destination org, be it with Release, a data loader, or by any other means besides a full or partial sandbox refresh, Salesforce assigns a unique Salesforce record ID to inserted records, effectively breaking the association between the records in the source and destination orgs. Thus, future changes to and redeployment of the same source records result in duplicate record creation in the destination org. Release solves this dilemma without the use of Salesforce external IDs.

How the VEID Manager Works 

The VEID manager prevents the creation of duplicate records during upsert operations by associating the source and destination record IDs of the records you deploy from your single control org. The Release VEID manager stores the associated IDs in a database in the Prodly cloud. For each record Prodly Release deploys during a deployment, Release executes the following decision flow:

Prodly Release first checks for a record ID match in the destination org, then perform one of the following choices:

  • If a match is found, Release updates the destination record.
  • If a match is not found, Release checks the Release VEID manager database for an entry that shows a previously-associated record ID in the destination org, then performs one of the following choices:
    • If an entry is found, Release updates the associated destination record.
    • If an entry is not found, Release inserts a destination record and adds an entry to the Release VEID manager database to associate the source and destination record IDs.


VEID Decision Flow

This approach allows Release to deploy existing data between source and destination orgs for the following scenarios:

  • Records that exist in both source and destination with the same record ID
  • Records that exist in both source and destination with differing record IDs
  • Records that exist in the source org only

VEID Setup 

Because Salesforce assigns a unique Salesforce record ID on insert, records you deploy from source to destination have differing record IDs whether using a data loader, manual entry, or any third-party tool. At the outset, there is no way for the Release VEID manager to know which data records match in the source and destination orgs because of the differing record IDs. Therefore, the key to the prevention of duplicate records with VEID is to ensure that your source and destination orgs at the start do not contain matching data records with differing IDs.

For data deployment scenarios that start with an empty destination org, by definition, the existence of matching data records with differing IDs is not an issue. The following deployment scenarios start with an empty destination org:

  • Existing full/partial/dev sandbox to empty production org with Release (go-live)
  • Existing production org to new/empty full/partial/dev sandbox with Release (sandbox seeding)
  • Existing full/partial/dev sandbox to new/empty sandbox with Release

Refer to the section on incorporating VEID at the beginning of a development cycle for more information.

For data deployment scenarios that start with data guaranteed to have matching IDs, the existence of matching data records with differing IDs is not an issue. The following deployment scenarios start with data guaranteed to have matching IDs:

  • Existing production org to full/partial sandbox with Salesforce sandbox refresh
  • Existing full/partial/dev sandbox to new sandbox with Salesforce sandbox cloning

Refer to the section on incorporating VEID at the beginning of a development cycle for more information.

The following list contains deployment scenarios that have VEID setup considerations:

  • Existing full/partial/dev sandbox to existing prod with Release
  • Existing production org to existing full/partial/dev sandbox with Release (sandbox seeding)
  • Existing full/partial/dev sandbox to existing sandbox with Release

VEID Setup At Development Cycle Start 

To guarantee no matching data records with differing IDs at the start of a development cycle, start with a destination org that contains no data. If you are developing in a partial or full sandbox, you can also start with a sandbox refresh.

Use this approach to seed a sandbox for the next round of development or for your initial “go live” deployment from sandbox to empty production org.

This diagram shows how the Release VEID manager controls inserts and updates in three successive deployments between a development sandbox and an empty production org. During deployment, the Release VEID manager captures source and destination record IDs, and creates associations between source and destination record IDs in the Release VEID manager database.


Deployment Using VEID

  1. In pass one, Release inserts records from Org Dev X to an empty Org Prod Y using Virtual External ID from the Record Matching Method picklist.
  2. In pass two, Release updates the existing Org Prod Y records and inserts new data records into Org Prod Y.
  3. Pass three depicts Release bringing the sandbox back into alignment at the start of the next development cycle. In pass three, Release updates the existing Org Dev X records and inserts the new data records into Org Dev X.

VEID Setup During A Development Cycle 

When initiating use of VEID during a development cycle, there are several factors to consider.

For one very specific use case that meets all the following criteria, VEID requires no special setup:

  • You are developing in a partial or full sandbox.
  • You started the development cycle with a sandbox refresh.
  • You have not inserted the same data record in both the sandbox and the production org.
  • You have made updates to records only in the sandbox.

In any other scenario where matching data records with differing IDs exist in org A and org B, you must first consolidate the data. To consolidate the data:

  1. Create a new, empty sandbox.
  2. Use VEID to insert the records from org A into the new sandbox, tracking the record IDs in the VEID manager database.
    1. If your scenario involves a sandbox and your production org, org A is your production org. Copy only the records you previously copied to org B.
    2. If your scenario involves two sandboxes, org A is the sandbox that has had more changes. Copy all the records.
  3. For records added to org B, perform one of the following steps:
    1. If you can easily identify the records you’ve added (for example by specifying creation date in a query filter), use VEID to insert the records to the new sandbox, tracking the record IDs in the VEID manager database.
    2. If not, use CEID to insert the records to the new sandbox.
  4. For records updated in org B, use Standard Upsert or manual editing to update the records in the new sandbox.
  5. Verify the new sandbox data to ensure there are no duplicate records.
  6. Use the new sandbox in place of org B going forward.