Help center

VEID Manager

Overview 

The AppOps Release virtual external ID manager is a behind-the-scenes, Prodly-proprietary feature of the cloud-based Prodly AppOps 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 AppOps Release composite external IDs (CEID) 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 AppOps 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. AppOps 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 AppOps Release VEID manager stores the associated IDs in a database in the Prodly cloud. For each record AppOps Release deploys during a deployment, AppOps Release executes the following decision flow:

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

  • If a match is found, AppOps Release updates the destination record.
  • If a match is not found, AppOps Release checks the AppOps 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, AppOps Release updates the associated destination record.
    • If an entry is not found, AppOps Release inserts a destination record and adds an entry to the AppOps Release VEID manager database to associate the source and destination record IDs.


VEID Decision Flow

This approach allows AppOps 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 AppOps 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 AppOps Release (go-live)
  • Existing production org to new/empty full/partial/dev sandbox with AppOps Release (sandbox seeding)
  • Existing full/partial/dev sandbox to new/empty sandbox with AppOps 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 AppOps Release
  • Existing production org to existing full/partial/dev sandbox with AppOps Release (sandbox seeding)
  • Existing full/partial/dev sandbox to existing sandbox with AppOps 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 AppOps Release VEID manager controls inserts and updates in three successive deployments between a development sandbox and an empty production org. During deployment, the AppOps Release VEID manager captures source and destination record IDs, and creates associations between source and destination record IDs in the AppOps Release VEID manager database.


Deployment Using VEID

  1. In pass one, AppOps 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, AppOps Release updates the existing Org Prod Y records and inserts new data records into Org Prod Y.
  3. Pass three depicts AppOps Release bringing the sandbox back into alignment at the start of the next development cycle. In pass three, AppOps 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 CEID 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.