Skip to main content

Data change requests

Data change requests (DCRs) represent a requested change to a managed Account or Contact Information record within Medical Information Cloud. While typically used in conjunction with a Master Data Management solution, Medical Information Cloud supports the generation of DCR records absent of a third-party Master Data Management solution.

You can use either Medical Information Cloud's native DCR handler or a custom DCR handler to process requested changes. Both native and custom DCR handlers can be called in the following scenarios:

  • The Account record is created via the New Account modal, which users can access when searching for Accounts.

  • The Account record is updated.

  • The Contact Information record is created.

  • The Contact Information record is updated.

Native DCR process

Note

This section only applies to Medical Information Cloud's native DCR functionality, not custom DCR handlers. Your instance uses Medical Information Cloud's native functionality if the value of MED_Global_Setting__mdt.MED_DCR_Create_Handler_Class__c is MED_DCRCreateHdlr.

The Data Change Request object stores information about requested changes to managed Account and Contact Information records and is on the master side of a master-detail relationship with the Data Change Request Line object, which captures the old and new values for change requests.

Every time a data change is submitted and invokes the native DCR handler, the DCR handler creates a Data Change Request record that has a record type of Account and that looks up to the relevant Account record. The DCR handler also creates any additional Data Change Request records and Data Change Request Line records that are needed to process the requested change or group of changes that were submitted together. See Native DCR data model.

A single Data Change Request record cannot capture more than one change request. This means that each Data Change Request record should only ever have one of these lookup fields populated at a time: MED_Account__c, MED_Contact_Information__c, or MED_Parent_Account__c. When multiple Data Change Request records are created in a single step, the Account Data Change Request record is always the parent, and the other Data Change Request records that were created in the same step are linked to the parent record via the MED_Parent_Data_Change_Request__c field.

Data Change Request records that have a Status of Pending are sent to Veeva Network, the Master Data Management source, for a data steward to process. Once sent, the Status is set to Submitted, and after a data steward processes the change request, the Status is changed to Processed, the appropriate Data Change Request and Data Change Request fields are updated, and any necessary merge work occurs.

Account merge work prevents duplicate Account records from being created. When the Data Change Request's Type field is set to New and the Status field is set to Processed, Medical Information Cloud verifies that an Account with an External ID matches the value of MED_Data_Change_Request__c.MED_Account_External_ID__c does not already exist in the product. If an existing Account record has an External ID that matches, the existing record and new record are merged using Salesforce's native merge feature. Metadata from the existing record is kept if the existing and new records have conflicting data.

Medical Information Cloud also verifies that a new Contact Information record is not a duplicate by looking at the External ID field on existing Contact Information records to see if the value matches the value of MED_Data_Change_Request__c.MED_Address_External_ID__c . If an existing Contact Information record has an External ID that matches, Medical Information Cloud repoints MED_Data_Change_Request__c.MED_Contact_Information__c from the new Contact Information record to the existing Contact Information record and then deletes the new Contact Information record.

Upon completion of any necessary merge work or if no merge work is required, a Medical Information Cloud trigger updates the External ID field on the related Account or Contact Information record.

Enable native and custom DCRs

To enable DCR generation:

  1. Navigate to the appropriate Global Setting custom metadata record, and click Edit.

  2. Set the DCR Globally Active field to true.

  3. Enter a value into the DCR Create Handler Class field.

    • To use native DCR functionality, enter MED_DCRCreateHdlr.

    • To override default functionality and use a custom DCR handler, enter the Apex class name that implements MED_DCRCreateIntf. When a change event occurs, this handler class is sent the full record and, if applicable, the old record and contact information to create DCR records as you would like.

  4. Click Save.

Configure native DCR functionality

Note

This section only applies to Medical Information Cloud's native DCR functionality. Your instance uses Medical Information Cloud's native functionality if the value of MED_Global_Setting__mdt.MED_DCR_Create_Handler_Class__c is MED_DCRCreateHdlr.

After DCRs are enabled, you can configure native DCR functionality to specify when to generate DCRs and which users should not trigger DCRs. You can also integrate Veeva Network with your Medical Information Cloud instance and use it as your Master Data Management source.

Configure DCR change events

To configure the DCR creation behavior, leverage the Account Field Setting custom metadata type to ensure the correct fields are monitored for the appropriate change events and included within the corresponding DCR records. To include a field within the DCR scope, populate the Include in DCR field with the appropriate change event for a given object (e.g. Account and Contact Information), field, country, and record type (e.g. HCP).

Opt-out users

You can configure the DCR feature to exclude updates from specific individuals. This can be helpful in cases where you want to bypass the DCR generation for a particular user, such as an integration user, data steward, or administrator. To exclude a user from DCR consideration:

  1. Locate the MIC Feature Flag custom setting within the Salesforce administrative user interface.

  2. Create a MIC Feature Flag custom setting record for each profile and/or user that should be excluded from the DCR process. Be sure to check the Bypass DCR field when creating the records.

    MIC Feature Flags Edit

Configuration considerations

Important points to consider when leveraging DCRs are as follows:

  • Only new Accounts (inserts) that are created via the New Account modal, which users can access when searching for Accounts, are considered for a DCR.

  • Only updated Accounts that are sourced from an Account Master are considered for a DCR. If an account has a value present within the MED_External_Id__c field, it is deemed to have been sourced from an Account Master.

  • DCRs are generated based on the underlying configuration which may include fields from both Accounts as well as related Contact Information.

  • DCR configuration supports separate configurations for Inserts and Updates.

  • When merging Accounts, there may be a delay from the time the DCR status is processed to when the Account is fully merged because the DCR status update and Account merge processes are asynchronous.

  • When merging Accounts, triggers, and workflows will not fire on child objects that are re-parented to the new Account.

Native DCR data model

Note

This section only applies to Medical Information Cloud's native DCR functionality. Your instance uses Medical Information Cloud's native functionality if the value of MED_Global_Setting__mdt.MED_DCR_Create_Handler_Class__c is MED_DCRCreateHdlr.

The DCR entity relationship diagram depicts the change request data model and field requirements for native DCR functionality. Data Change Request and Data Change Request Line fields listed on the entity relationship diagram are required.

DCR entity relationship diagram

The native DCR data model relies on Data Change Request record types. Data Change Request object record types include:

  • Account - utilized when the associated Account record is either (1) new or modified or (2) the parent Account of other modified records.

    A Data Change Request record with the Account record type must exist for every change request. This record is at the top of the DCR data model and must look up to the Account record that is new or modified or that is related to the Institution or Contact Information record that is new or modified. Depending on the change request, the Data Change Request record may not have any Data Change Request Line records associated.

  • Address - utilized when the associated Contact Information record is new or has been modified.

    The Data Change Request record for the Address record type must look up to the Contact Information record that is new or modified, must look up to the Data Change Request record for the Account record type, and must have at least one Data Change Request Line record associated.

  • Parent - utilized when the associated Institution Account record is new or has been modified.

    The Data Change Request record for the Parent record type must look up to the relevant Account record for the Institution that was created or modified, must look up to the Data Change Request record for the Account record type, and must have at least one Data Change Request Line record associated.

DCR objects

The Data Change Request object stores information about requested changes to managed Account and Contact Information records and is on the master side of a master-detail relationship with the Data Change Request Line object, which captures the old and new values for change requests.