Address Validation Solution
The states and countries in the Salesforce standard object state and country picklists are based on ISO-3166 alpha-2 standard values. This means that for each State/Province (text only) and Country (text only) field, a picklist-typed Country Code field is created, which provides support for various usability enhancements, such as viewing Salesforce in different languages and enabling easier integration with custom functionality. Thus, Salesforce can automatically display a country picklist field in the language of the respective organization so, for example, “Spain” would be seen as “Espagne” in a French user’s profile.
On the other hand, the customer’s external address validation service returned country names in the respective native language, e.g. “Spain” -> “Espana”, “Sweden” -> “Sverige”, as well as state/province codes based on ISO-3166 alpha-3 values. Salesforce and the address validation application both needed to be made compatible with each other to address the mismatch between the expected State/Province picklist code and the validated State/Province and Country field. The service also lacked support for mapping state/province output to Salesforce standard state and country code values. The discrepancy between the expected output values of the two entities resulted in impaired functionality, so that no state or country was mapped in the respective picklist fields, although the address validation request was successfully completed.
Moreover, an additional challenge was presented by the design choice of a separate custom integration of the customer, which was responsible for the address visualization on a map widget. This service displayed the country values only in English so there was no way for the French user to see "Espagne" instead of "Spain", for example. This meant that additional logic was needed to map another different output to a standardized value within Salesforce.
Thus, there was no one-size-fits-all solution for the mismatch between the baseline values of the existing services of the customer. Complex logic was needed to solve the challenges and ensure seamless communication between the 3 entities (Salesforce, the address validation service and the map visualization service).
Our team solved the technical challenges facing the client by designing and developing a personalized intermediate service for state and country translation.
The solution checks returned values in a custom-made country and state picklist dictionary by comparing them to values within that dictionary and then distributes the correct values to Salesforce so that the existing two services can communicate and fulfill their purpose of validating and visualizing addresses. The state and country values in the dictionary have been sourced from the customer’s own org through the use of Salesforce Metadata API.
The solution leverages the power of Apex and JavaScript, using the most up-to-date development practices and security-aware design. It also works out of the box for the users of the customer’s CRM and utilizes an easy-to-understand dictionary structure which allows administrators to adjust values on the go. In addition, the team provided comprehensive documentation covering product installation and migration to other environments, to enable administrators who are not familiar with the solution to install it and migrate settings to subsequent environments.
Last but not least, our QA specialists performed extensive testing to ensure that all aspects of the end solution satisfy the customer’s needs and our quality standards.
