Inbound Forms

The 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 . This object serves as an integration staging table of sorts. When Inbound Form instances are created within , there exists functionality behind the scenes to propagate this information into the appropriate locations within 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 . 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 to transfer Medical Inquiries to , 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 . 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.

Interaction (Case) Field Mappings

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 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 MED_Inbound_Form__c.MED_Product__c with the Product Match Strategy with optional Value Mappings to find and fill with a relevant MED_Product__c record. For additional details refer to Value Map.

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 . This abstraction allows Administrators to manage the product catalog in the most advantageous manner within 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 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 . 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 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 value mappings, product matching rules are set by 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/Global or that match the Inbound Form Country are looked at.

• If using the Simplified Product Catalogue, only products with MED_Product_Family record type are looked at. Otherwise, products with MED_Product_Family record 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 Name exactly, the product with the matching Country to Inbound Form will be used over the product marked ZZ/Global. If duplicate products are still found, one is chosen at random.

Creating value maps

Value maps are managed within the 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 Value Mapping (MED_MIC_Value_Mapping__mdt) custom metadata type.

A sample Value Map for MIRF integration can be seen below.

MIRF value map example

Field	Value
Inbound	Checked
Outbound	Checked
Source Entity	<Label of the Veeva Org (MED_Veeva_Org__mdt) metadata record to be mapped>
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.