This guide is intended to assist a Salesforce developer/administrator with migrating from our Experian Data Validation for Classic (AKA v5) app to our latest Lightning app, specifically maintaining all the existing validation status data for your address, email or phone fields.

EDQ Logs object

Our Experian Data Validation for Salesforce Lightning app makes use of a custom object for storing API transaction logs, which are saved against each validated field to keep track of its status. Creating these EDQ Log objects for all existing validated fields is key to a successful migration. These objects are tied to a record ID and field name, which makes them easily searchable, and they can also optionally contain additional information like phone codes. These will automatically be displayed beside their associated fields in either the EDQ Record Detail component or the standalone validation components for Address, Email and Phone, so long as they match the field name and the current value of the field. The key fields in this object are as follows:

Field name Description
LEDQ_RecordId__c The ID of the record against which the validation has been saved.
LEDQ_FieldAPIName__c The API name of the field against which the validation has been saved. For addresses, this is the Street or Street 1 field for 7-line addresses.
LEDQ_InputValue__c The value of the field when it was validated, in Base64 format. See the guidance below for how this is formed for addresses.
LEDQ_Type__c The type of validation, in title case (Address | Email | Phone).
LEDQ_Status__c The status of the validation, see the status code section of the object guide for a list of these.
LEDQ_More_Info__c JSON object containing additional information about a validation, see guidance below.
LEDQ_TimeStamp__c The timestamp to be displayed against the validation, in DateTime format.
LEDQ_ErrorMessage__c Plain text error message, if one was encountered.
LEDQ_ErrorJSON__c A JSON error response, if one was received from the API.

InputValue field

The InputValue field is formed by converting the value of the associated field into Base64 format. For emails and phone numbers this is fairly simple. Take the email or phone number (including area code) and convert it to Base64 format before saving it to the EDQ Log object.

Input Base64
12125552435 MTIxMjU1NTI0MzU=
test@tests.net dGVzdEB0ZXN0cy5uZXQ=

For addresses, it is formed from a comma-separated string made up of some of the address components. Unpopulated address component fields are still included.

<Street>,<State>,<Postal Code>,<Country>

For example:

Input Base64
20 Test St,OH,20020,United States MjAgVGVzdCBTdCxPSCwyMDAyMCxVbml0ZWQgU3RhdGVz
44 Example Drive,,SW138JD,United Kingdom NDQgRXhhbXBsZSBEcml2ZSwsU1cxMzhKRCxVbml0ZWQgS2luZ2RvbQ==

The second example has no state, but it is still included as a blank string.

More Info field

This is a JSON object that contains some extra information, some of which can be displayed in the validation status panel that appears beneath validated fields.

JSON property name Description
validatedNumber The full number as it was validated by the API, including area code.
phoneType The type of phone number (Landline | Mobile).
phoneCode The phone code prefix.
number The full number as it was originally entered – this will likely be the same as validatedNumber.
formattedNumber The full number with any formatting marks such as parentheses and dashes.
codeLessNumber The number without the country code.
codeKey The unique identifier for the country code, which helps to differentiate between countries with the same code, for example, USA (+1) and Canada (+1).

The codeKey field is encoded in Base64 format and is formed from the phone code and full country name:

Input Base64
44--United Kingdom NDQtLVVuaXRlZCBLaW5nZG9t
1--Canada MS0tQ2FuYWRh
1--United States MS0tVW5pdGVkIFN0YXRlcw==

If this field isn't present, the system will attempt to use the phoneCode to determine the country. If neither are present, a phone code will not be preselected.

Example Apex Class

We've taken the guidelines on this page and provided an example Apex Class which includes Status Maps for the mapping from old Classic status values to the new ones used in the Lightning app, and demonstrates creating EDQ Log objects for the Billing Address, Email and Phone fields of a fixed Account record. This example can be used as the basis for building out a set of migration classes specific to your organization and objects.

Download v5_migration.cls