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.
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. |
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.
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.
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.