Inbound Forms
The Medical Information Cloud Inquiry Management module supports the receipt of Medical Inquiries via data integration to streamline business processes within an organization. The primary manner in which this is supported is through the Inbound Form object (MED_Inbound_Form__c), made available within Medical Information Cloud Inquiry Management. This object serves as an integration staging table of sorts. When Inbound Form instances are created within Medical Information Cloud Inquiry Management, there exists functionality behind the scenes to propagate this information into the appropriate locations within Medical Information Cloud Inquiry Management such that a User can begin working on the Medical Inquiry as they would normally.
This propagation is facilitated via two main components:
A series of field and value mappings are made available within the administrative interfaces of Medical Information Cloud Inquiry Management. These configurations instruct the system on how to map fields in addition to any value transformations that should be performed before the creation of the corresponding Interaction and Request.
Apex triggers to perform the custom processing upon receipt of a new Inbound Form record to read the available configuration and create the corresponding Interaction and Request.
For organizations looking to develop custom integrations with Medical Information Cloud Inquiry Management to transfer Medical Inquiries to Medical Information Cloud Inquiry Management, the Inbound Form is the primary option made available. For information on the APIs available to create records within a Salesforce environment programmatically please refer to the Salesforce Developer Site.
Inbound Form groups
Each Inbound Form record has a 1:1 relationship with the Request (MED_Request__c) object within Medical Information Cloud Inquiry Management. Inbound Forms have a Many:1 relationship with Interactions. Should several Inbound Forms share the same Group Identifier (MED_Group_Identifier__c) and Channel Details (MED_Channel_Details__c) they will all be housed under a single Interaction record, each with their corresponding Request record.
Inbound Form field mappings
The table below details how fields present on the Inbound Form object are mapped and propagated in the course of the automated Interaction and Request creation.
Inbound Form (Source) Field | Case Field | Notes |
|---|---|---|
MED_Address_Line_1__c | Case.MED_Address_Line_1__c | |
MED_Address_Line_2__c | Case.MED_Address_Line_2__c | |
MED_Channel__c | Case.Origin | |
MED_Channel_Details__c | Case.MED_Channel_Details__c, Case.MED_Incoming_Inquiry_Group_Identifier__c | Case.MED_Incoming_Inquiry_Group_Identifier__c is a compound value comprised of MED_Inbound_Form__c.MED_Channel_Details__c + ‘::’ + MED_Inbound_Form__c.MED_Group_Identifier__c |
MED_City__c | Case.MED_City__c | |
MED_Country__c | Case.MED_Country__c | |
MED_Email__c | Case.MED_Email__c | |
MED_Fax_Number__c | Case.MED_Fax__c | |
MED_Group_Identifier__c | Case.MED_Incoming_Inquiry_Group_Identifier__c | Case.MED_Incoming_Inquiry_Group_Identifier__c is a compound value comprised of MED_Inbound_Form__c.MED_Channel_Details__c + ‘::’ + MED_Inbound_Form__c.MED_Group_Identifier__c |
MED_Interaction_Notes__c | Case.MED_Case_Notes__c | Available only in Medical Information Cloud Inquiry Management Classic |
MED_Phone_Number__c | Case.MED_Phone__c | |
MED_Postal_Code__c | Case.MED_Postal_Code__c | |
MED_Referred_By_Email__c | Case.MED_Referred_By_Email__c | |
MED_State__c | Case.MED_State__c |
Request field mappings
Inbound Form (Source) Field | Request Field | Notes |
|---|---|---|
MED_Country__c | MED_Request__c.MED_Country__c | |
Id | MED_Request__c.MED_Inbound_Form__c | |
MED_Delivery_Method__c | MED_Request__c.MED_Preferred_Delivery_Method__c | |
MED_Inquiry_Text__c | MED_Request__c.MED_Question__c | |
MED_Product__c | MED_Request__c.MED_Product__c | Uses |
Additional fields of note
Inbound Form (Source) Field | Notes |
|---|---|
MED_Requester_External_ID__c | Used to perform a lookup for an Account with a matching MED_External_ID__c. If a match is found, the corresponding Account Id is populated into the Case.AccountId field. |
MED_Federation_ID__c | Used to perform a lookup for an Account with a matching MED_External_ID__c. If a match is found, the corresponding Account Id is populated into the Case.MED_Referred_By__c. |
MED_Group_Identifier__c | Used in conjunction with MED_Channel_Details__c to ascertain whether a given record belongs to an Inbound Form Group. |
MED_Channel_Details__c | Used in conjunction with MED_Group_Identifier__c to ascertain whether a given record belongs to an Inbound Form Group. |
MED_External_ID__c | All custom integrations or custom code creating Inbound Forms must populate MED_External_ID__c with a unique value. Integrations that do not fill out this required field will fail. |
Inbound Form value mappings
In addition to the field mappings available to route inbound fields to local fields, there exists the ability to map or convert values within fields 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 Inquiry Management. This abstraction allows Administrators to manage the product catalog in the most advantageous manner within Medical Information Cloud Inquiry Management without impacting or constraining the ability to integrate with Veeva CRM to process MIRFs.
To enable value maps please designate the correct product matching strategy to be used within the system, available on the Global Settings custom metadata type in the Product Match Strategy field. Available values are:
Name: passes the received product name through to be utilized in a search against the Medical Information Cloud Inquiry Management product catalog.
Value Mapping, Name: the received product name on the Inbound Form will first be swapped with the mapped field value within the configured field mappings. If no match is located, the system will default back to a straight pass-through of the received name field to be leveraged in the product catalog search.
Regardless of whether the received product name is utilized as-is or swapped with a configured map, the product search is dependent upon the structure and configuration of your product catalog within Medical Information Cloud Inquiry Management. The two must work in conjunction with one another to ensure product matches are located as expected. This includes considerations such as whether:
the simplified product catalog within Medical Information Cloud Inquiry Management is being leveraged
a country is designated on the Inbound Form and corresponding products
the product Reporting Group or Product is case sensitive
Note
Presently value maps are only supported within the Product field (MED_Product__c) on Inbound Forms.
Product matching
Apart from user-configured Medical Information Cloud Inquiry Management value mappings, product matching rules are set by Medical Information Cloud Inquiry Management and follow the rules below when matching the Inbound Form Product value to a product that is set on the Request:
Only products with a country of
ZZ/Globalor that match the Inbound Form Country are looked at.If using the Simplified Product Catalogue, only products with
MED_Product_Familyrecord type are looked at. Otherwise, products withMED_Product_Familyrecord type are excluded.Only Active products are looked at.
Compare the Inbound Form Product value or MIC Value mapping value with the
Product Display Name. If the value matches exactly, use that product.Note
If multiple products match the
Product Display Nameexactly, the product with the matching Country to Inbound Form will be used over the product markedZZ/Global. If duplicate products are still found, one is chosen at random.
Creating value maps
Value maps are managed within the Medical Information Cloud Inquiry Management Value Mapping custom metadata type. The following points should be considered when creating value maps:
Each inbound value may only be mapped to a single target value.
It is possible to have multiple inbound values map to the same local value.
For details on the fields to be specified for value maps, visit the Medical Information Cloud Inquiry Management Value Mapping (MED_MIC_Value_Mapping__mdt) custom metadata type.
A sample Medical Information Cloud Inquiry Management Value Map for MIRF integration can be seen below.
Field | Value |
|---|---|
Inbound | Checked |
Outbound | Checked |
Source Entity | <Label of the Veeva Org ( |
Source Value | <Product display name> |
Target Value | <Product display name> |
Type | MIRF.MED_Product__c |
Unique Key | MIRF.MED_Product__c:<Source Entity>:<Source Value>:<TargetValue> |
Anonymization
When MED_Request__c.MED_Anonymize__c is checked and the record is not marked for legal hold, MED_Anonymize__c is checked on all related Inbound Forms.
Data propagation suppression
Should a Customer desire not to trigger the automatic propagation of Request and Interactions from the creation of a new Inbound Form record, the MED_Suppress_Request_Creation__c should be set to true. When set to true, all processing associated with the processing and propagation of data will be bypassed for the Inbound Form record in question.
Troubleshooting Inbound Forms
If an Inbound Form fails, an Error 
icon appears next to the Inbound Form on the Inbound Forms list view. The warning message for the Inbound Form is listed in the Quick Action Errors utility item and the Alt text for the Error icon.
Once errors have been addressed, Lightning administrators can use quick actions to rerun errored Inbound Forms and trigger the creation of Request records. The creation of a new Request is blocked if the Inbound Form being rerun is already associated with a Request.
Lightning quick actions include:
Mass Recreate Request - select multiple Inbound Forms and process them as a single batch. The quick action is located on the Inbound Form list view.
Recreate Request - refire a single Inbound Form. The quick action is located on the Inbound Form page layout.