Skip to main content

Veeva CRM

Medical Information Cloud supports out-of-the-box integration with Veeva CRM. The integration supports two high-level use cases:

  • To receive and synchronize Medical Inquiry Fulfillments (MIRFs) originated within Veeva CRM. This integration allows MIRFs captured within Veeva CRM to be forwarded to Medical Information Cloud for Medical Information teams to properly manage and respond. Once received a corresponding Request is created for each MIRF received. Additionally, updates are then synchronized back to Veeva CRM so that users can access updates across both platforms.

  • To serve as an Account Master data source, facilitating searches for related HCPs and HCOs on inbound requests.

The configuration of the system to support each of the cases above has some overlap to establish connectivity between Medical Information Cloud and Veeva CRM but then diverges to provide the configurability of each use case.

MIRF integration configuration

The native integration connectors will support approximately 400 open medical inquiries at any given point in time. If more than 400 medical inquiries need to remain open, a dedicated integration middleware solution should be considered to ensure the increased volume can be supported.

The steps required to connect and leverage a Veeva CRM instance within Medical Information Cloud are as follows:

  1. Connect Medical Information Cloud and Veeva CRM using named credentials.

  2. Register a Veeva CRM instance.

  3. Define the MIRF field mapping.

  4. Activate and schedule the batch jobs that facilitate the synchronization.

  5. (Optional) Initialize address data.

  6. (Optional) Define a product value mapping.

Step 1 - Connect a Veeva CRM instance

Each remote Veeva CRM instance that is to be integrated with Medical Information Cloud must have a Salesforce org OAuth 2.0 connection configured. This is accomplished using a Salesforce OAuth 2.0 Named Credential. Local Veeva CRM instances do not need any connection.

Note

There are no limitations on the number of Veeva CRM instances supported for MIRF integration. Account Master integration only supports a single instance per segment.

Named credentials

In cases where remote Veeva CRM instances are leveraged, named credentials are required to facilitate the integration. The steps required to be performed are spread across both the Medical Information Cloud instance as well as the remote Veeva CRM instance.

Note

The integration user (remote Veeva CRM) or user scheduling the job (local Veeva CRM) must possess read and update access on the Override Lock field present on the MIRF object in Veeva CRM. This removes the requirement to possess Modify All Data as a profile permission from these users.

#

Environment

Details

1

Veeva CRM

Create a Connected App.

2

Medical Information Cloud

Create an Auth. Provider.

3

Veeva CRM

Edit the Connected App to relax the IP restrictions.

4

Veeva CRM

Manage the Profiles on the Connected App to grant the necessary access.

5

Medical Information Cloud

Create the named credential.

To get help with additional details on individual field values, visit How to Contact Customer Support.

Step 2 - Register a Veeva CRM instance

The Veeva Org custom metadata type houses configuration to be leveraged when communicating with a given Veeva CRM instance. Items contained within an entry include authentication credentials (in cases where the Veeva CRM is in a separate instance from where Medical Information Cloud is installed) in addition to field mappings to receive and route data elements from inbound Veeva CRM MIRFs.

Three available types of entries can be made within the Veeva CRM custom metadata type. The table below provides details on each type:

Type

Description

Default

This is a catch-all configuration against which global configuration can be applied that is to be leveraged across multiple Veeva CRM instances. While not a required entry, having a Default entry saves you time because it defines field and value mappings that are shared across multiple instances. Mappings defined on Default instances can work in conjunction with the other 2 types: local and remote. The mapping used is the sum of the Default mapping plus the applicable local or remote mapping. Default should only contain mappings that apply to all instances as they cannot be overwritten at the local or remote level. It is important to note that Default entries do not contain named credentials. All credentials should be attached to the remote entries.

Local

This is a configuration that applies when Medical Information Cloud is installed in the same Salesforce instance as Veeva CRM. Medical Information Cloud supports 0 or 1 entries of this type. It is important to note that Local entries do not contain named credentials. All credentials should be attached to the remote entries.

Remote

This is a configuration that applies when Medical Information Cloud is installed in a different Salesforce instance than Veeva CRM. A Named Credential that specifies a Named Principal and OAuth 2.0 to connect to the remote Veeva CRM instance is required for this type. For additional information, refer to the Authenticating with Remote Veeva CRM section below.

Note

MasterLabel of Veeva Org entries must be unique as it is used as a unique key to match Inbound Forms to the Veeva Org they came from.

Step 3 - Define Veeva MIRF Field Mapping

Access the Veeva MIRF Field Mapping custom metadata type and review any existing entries that are present, making the necessary changes required to match your integration requirements.

Field mappings can be against the Default Org type, which will apply to all Veeva CRM instances, or a specific org if only certain fields should be mapped to a specific org. The overall mapping set used for any given Veeva CRM instance is the combination of the Default mapping and the specific remote or local instance being connected to. Specific instance mappings will override any overlapping configurations made at the default level.

Use the Value Type fields to specify if the value copied is pulled from a field or is a static value that is used. The supported data types are:

  • Boolean

  • Date

  • Datetime

  • Decimal

  • Integer

  • String

Mappings can also be specified as only inbound (from the Veeva CRM MIRF to the Medical Information Cloud Inbound Form) or outbound (from the Medical Information Cloud Inbound Form to the Veeva CRM MIRF).

Note

When mapping from an Inbound Form, specify the Product Match Strategy to be employed when attempting to match product names to the local product catalog. Product Name (MED_Product_c.name) is the default value and needs to be changed for value maps to be read by MIC Value Mapping.

Step 4 - Schedule integration batch jobs

Remote Veeva CRM Org

Schedule the following two Apex classes. Hourly is recommended.

  • MED_VeevaMIRFPullBatchSched

  • MED_VeevaMIRFUpdateBatchSched

For help scheduling, visit Scheduling Apex jobs.

On-demand run (for testing)

Use the Developer Console to execute the following anonymous Apex:

database.executebatch(new MED_VeevaMIRFPullBatchSched(), 1);
database.executebatch(new MED_VeevaMIRFUpdateBatchSched(), 1);

Local Veeva CRM

Schedule the following two Apex classes. Hourly is recommended.

  • MED_VeevaMIRFPullLocalSched

  • MED_VeevaMIRFUpdateLocalSched

For help scheduling, visit Scheduling Apex jobs.

On-demand run (for testing)

Use the Developer Console to execute the following anonymous Apex

(new MED_VeevaMIRFPullLocalSched()).execute(null);
(new MED_VeevaMIRFUpdateLocalSched()).execute(null);

Step 5 - Initialize address data

If the Medical Information Cloud is being installed in a Veeva CRM Salesforce Org that already has account data, then the address synchronization must be initialized through a batch job. To start the batch job:

  1. Open an Execute Anonymous Window. Visit Salesforce's documentation.

  2. Enter the following code:

    MED_AddressContactInfoSync batchInitialization = new MED_AddressContactInfoSync();
Database.executeBatch(batchInitialization);

  3. Click Execute. A successful log should be displayed in the log panel.

    Execute anonymous log

  4. Confirm execution by reviewing jobs being executed under Setup > Jobs> Apex Jobs. You can abort the job from this screen if necessary.

Step 6 - Define a product value mapping

In addition to the field mappings available to route inbound fields to local fields, there exists the ability to map or convert values within the product field contained on inbound MIRFs. Organizations can swap out the inbound product data with values that align with how the product catalog is structured within Medical Information Cloud. This abstraction allows Administrators to manage the product catalog in the most advantageous manner within Medical Information Cloud without impacting or constraining the ability to integrate with Veeva CRM to process MIRFs. For more information on product value maps, please refer to the Inbound Form documentation.

Customize the Veeva CRM MIRF query

By default, Medical Information Cloud retrieves all open Medical_Inquiry_vod__c records within a Veeva CRM instance that have a Status_vod__c that equals ‘Submitted_vod’ and that has not already been retrieved by Medical Information Cloud. Customers who wish to alter the default query criteria can do so through the use of a developer interface.

To extend Medical Information Cloud to alter the default MIRF query, a developer should perform the following:

  1. Develop a new custom apex class that implements the Salesforce Callable interface.

  2. Implement the logic necessary for the BUILD_VEEVA_MIRF_QUERY action within the new Apex class. The available method arguments are as follows:

    • VEEVA_ORG_NAME <String>: String of the Veeva org connection being processed. This is the MasterLabel of the Veeva Org (MED_Veeva_Org__mdt) custom metadata type. The value is also stamped in the MED_Channel_Details__c field on the Inbound form.

    • FIELD_TO_QUERY <String>: A single string that is a comma-separated list of fields in the Veeva CRM that should be queried according to the MED_Veeva_MIRF_Field_Mapping__mdt custom metadata type settings for the Veeva org.

    • RETURN <String>: The method should return a fully formed SOQL query as a string. The returned query will be used unmodified to query for MIRFs from Veeva CRM.

      Note

      Because this is conducted using the REST API, no query parameters such as :myvar are supported.

    For an example, see the out-of-the-box implementation in the MED_VeevaMIRFQueryProvider class or visit How to Contact Customer Support.

  3. Implement the corresponding unit test code for the new apex class.

  4. Deploy the implementation and test code classes to the target environments.

  5. Register the new Veeva MIRF Query Provider with Medical Information Cloud by populating the API name of the new apex class on the corresponding Veeva Org custom metadata setting record.

  6. Perform the necessary testing to validate that the system is functioning as desired.

Bypass automatic interaction and request creation

The Veeva CRM Integration is based on the standard Inbound Form-based approach to data integration with Medical Information Cloud. As a result, similar to custom integration, Veeva CRM Integrations can take advantage of the Automatic Data Propagation Suppression feature.

To enable this feature:

  1. In Setup, navigate to the MDM Field Mapping (MED_MDM_Field_Mapping__mdt) custom metadata type.

  2. Click Manage MDM Field Mappings.

  3. Click New.

  4. Create a new field mapping entry by selecting Veeva CRM as the MDM Connection and mapping the MED_Suppress_Request_Creation field to a Veeva CRM field that has a value set to true.

Visit the Inbound Form custom object topic for more information.

Account Master integration configuration

As noted above, the native integration connectors for Medical Information Cloud support one configured Veeva CRM instance per segment when being used as an Account Master. For example, it is not possible to search for US-based HCPs in two Veeva CRM orgs, however, you can search for US-based HCPs in one instance and Canada-based HCPs in another.

In the case of Veeva CRM, this allows searches for HCPs and HCOs to be sent to Veeva CRM in the event a customer would like to leverage an instance as a ‘single source of truth’ for HCP and HCO information.

The steps required to connect and leverage a Veeva CRM instance within Medical Information Cloud are as follows:

  1. Connect a Veeva CRM instance. Visit Register a Veeva CRM instance.

  2. Define the MDM Connection.

  3. Configure MDM Settings.

  4. Verify the integration user has the appropriate field-level security configured to support the requisite account and address access.

Step 1 - Connect a Veeva CRM instance

Each remote Veeva CRM instance that is to be integrated with Medical Information Cloud must have a Salesforce org OAuth 2.0 connection configured. This is accomplished using a Salesforce OAuth 2.0 Named Credential. Local Veeva CRM instances do not need any connection.

Note

There are no limitations on the number of Veeva CRM instances supported for MIRF integration. Account Master integration only supports a single instance per segment.

Named Credentials

In cases where remote Veeva CRM instances are leveraged, named credentials are required to facilitate the integration. The steps required to be performed are spread across both the Medical Information Cloud instance as well as the remote Veeva CRM instance.

Note

The Named Credential can be the same one that was used to configure the MIRF integration.

#

Environment

Details

1

Veeva CRM

Created a Connected App.

2

Medical Information Cloud

Create an Auth. Provider.

3

Veeva CRM

Edit the Connect App to relax the IP restrictions.

4

Veeva CRM

Manage the Profiles on the Connected App to grant the necessary access.

5

Medical Information Cloud

Create the named credential.

For additional details on individual field values, visit How to Contact Customer Support.

Step 2 - Define the MDM Connection

The MDM Connection (MED_MDM_Connection__mdt) custom metadata type houses configuration to be leveraged when communicating with a given Veeva CRM instance to search Accounts. Visit Master Data Management for instructions.

Step 3 - Configure MDM settings

Configure the above to point to the generic MDM settings. Review the Master Data Management page for more information.

Step 4 - Verify user security

The Account Master integration capabilities within Medical Information Cloud perform all operations in the context of the configured Salesforce User (that resides within the Veeva CRM instance). As a result, all APIs performed by the integration are subject to the same security considerations as a traditional User within Salesforce. This includes, but is not limited to:

  • Data security - access to the scope of HCP and HCO records required to facilitate an account search.

  • Field security - access to the individual fields that have been called into scope as a result of the field mappings defined above.

In the event the integration is not performing as desired please verify the relevant configurations for the items above to verify things are properly established.