MIRF Integration

The MIRF Integration synchronizes Medical Inquiry Records (MIRFs) between Veeva Vault CRM and Medical Information Cloud. It supports both inbound synchronization (Vault CRM to Medical Information Cloud) and outbound synchronization (Medical Information Cloud back to Vault CRM), so medical inquiries can be managed across both platforms while staying in sync.

How it works

Pull (inbound)

1. A scheduled batch job builds a VQL query for new and updated MIRFs in Vault CRM.
2. The connector runs the query and receives the matching MIRF records.
3. Each Vault MIRF is transformed into an MED_Inbound_Form__c record and upserted into Medical Information Cloud using external-ID matching.
4. Medical Information Cloud creates the corresponding Interactions and Requests from the inbound forms.

Push (outbound)

1. Medical Information Cloud marks Requests whose changes need to be sent back to Vault CRM.
2. A scheduled batch job sends the relevant updates to the matching Medical Inquiry records in Vault CRM.
3. The connector marks the Requests as pushed.

Configuration

Vault CRM integration user

The MIRF batch jobs run as the scheduled user. That user must have:

• Read access to address__v, account__v, and medical_inquiry__v.
• Write access to medical_inquiry__v.

External Credential and Named Credential

The MIRF Integration uses the same External Credential and Named Credential as Account Search. Make sure the scheduled user is also assigned the permission set that grants External Credential Principal Access for the Vault CRM principal.

Register the Vault CRM instance

Create a KLAB_VaultCRM_Org__mdt record for each Vault CRM instance you integrate with. The fields are:

Field	Description
KLAB_Type__c	Org type used to filter configuration: Default stores common data, Remote syncs MIRFs and inbound forms, Local applies when Medical Information Cloud and Vault CRM share an org. Defaults to Remote.
KLAB_Named_Credential__c	The developer name of the Named Credential used to connect to the Vault CRM instance.
KLAB_Timeout__c	Callout timeout in milliseconds. Defaults to 120000.
KLAB_Where_Condition__c	Additional criteria appended to the WHERE clause when pulling MIRFs (for example, medical_inquiry_status__v = 'submitted__v').
Active__c	Whether this org record is active.

Define MIRF field mappings

Create KLAB_VaultCRM_MIRF_Field_Mapping__mdt records to control how MIRF fields move between the two systems. Each record links to a KLAB_VaultCRM_Org__mdt record through the Vault Org lookup. The fields are:

Field	Description
KLAB_Local_Value__c	The Medical Information Cloud field API name (or constant).
KLAB_Local_Value_Type__c	Field (read from a field) or Constant.
KLAB_Remote_Value__c	The Vault CRM field API name, or a VQL wrapper for long or rich text.
KLAB_Remote_Value_Type__c	Field (read from a Vault field) or Constant.
KLAB_Inbound_Copy__c	Copy this field during the inbound pull.
KLAB_Outbound_Copy__c	Copy this field during the outbound push.

The connector ships a default set of mappings you can modify to suit your organization.

note

Long-text and rich-text Vault fields must be queried with VQL functions. Use LONGTEXT(field__v) or RICHTEXT(field__v) in KLAB_Remote_Value__c.

Handling value differences

Unlike Account Search, the field mappings themselves do not translate values between Vault CRM and Medical Information Cloud — they copy values as-is. When a Vault CRM value does not match the expected Medical Information Cloud value, you transform it with a Salesforce Flow.

The default configuration ships two record-triggered Flows on the inbound form — VaultCRM MIRF Value Mapping In (inbound) and VaultCRM MIRF Value Mapping Out (outbound) — that you can customize to match your Vault CRM instance and picklist values. There are two patterns:

• Standard fields that need transformation — map the Vault CRM value directly to the existing Medical Information Cloud field, then let the Flow transform the value in place. For example, the default Product mapping writes to MED_Product__c, and the inbound Flow strips the __c suffix on the same field. No additional field is required.
• Restricted picklist fields — fields such as MED_Status__c, MED_Delivery_Method__c, and MED_Requester_Gender__c are a special case. Because a restricted picklist rejects any value that is not already in its value set, the raw Vault CRM value cannot be written to it directly. For these, the default configuration maps the Vault CRM value into a dedicated custom staging field (for example, KLAB_Status_Custom__c, KLAB_Delivery_Method_Custom__c, KLAB_Requester_Gender_Custom__c), and the Flow translates that staging value into the restricted picklist. These custom staging fields are included in the default configuration.

Run the batch jobs

On demand

To run the jobs once (for example, while testing), execute the following in the Developer Console:

Database.executeBatch(new KLAB_VaultCRMPullBatch(), 1);
Database.executeBatch(new KLAB_VaultCRMPushBatch(), 1);

On a schedule

To synchronize continuously, schedule the jobs. Hourly is a common cadence. Run the following in the Developer Console:

System.schedule('Vault CRM MIRF Pull', '0 0 * * * ?', new KLAB_VaultCRMPullBatch());
System.schedule('Vault CRM MIRF Push', '0 10 * * * ?', new KLAB_VaultCRMPushBatch());