Model addresses

salesforce-address-model

In the standard configuration Salesforce comes with a rather simple way of capturing addresses. In the actual CRM implementation, this often does not meet the requirements. What can be done?

Salesforce Address “out of the box”

On the account object, Salesforce knows two addresses, namely the billing and shipping address. The conversion is identical for the contact object, where the two addresses are called Mailing address and Other address.

These two addresses contain several fields for capturing postal addresses, including a multi-line field for capturing the street incl. number, a P.O. Box address or several additional address lines. Salesforce then additionally stores the first 3 lines in separate fields that can be used in a report or transferred to target systems, for example.

squiis adresse

Countries and state as selection fields

There are also fields for the postal code, the city, the state and the country, each of which is entered as free text. However, there is the configuration option to replace the free text fields with selection list values so that this information can always be entered in a structured manner. This is recommended because otherwise you will be confronted with a wide variety of values per country (CH, Switzerland, Switzerland). If you do without this for specific reasons, I recommend to ensure the data quality with validation rules.

Google Maps Integration

Salesforce offers Google Maps integration for address entry. For example, you can search for “Schaffhauserstrasse 108” directly from Salesforce, and a click on the correct address automatically fills in the street and 8180 Bülach. Unfortunately, Google manages to enter “108 Schaffhauserstrasse”, and in addition, in order to use the function, it is mandatory that the Google map is displayed below the address in the layout. And then you also have to share your own location in the browser. In my opinion, this is not a really useful solution for working with addresses.

But how then?

So before you start, there are a few questions that need to be answered:

  • Can we implement our address model with 2 addresses per account and contact? If yes, then these addresses can be kept on the account and contact object. However, if there are more than two, then there is no way around creating a new “Addresses” object and relating the addresses recorded there to the account and contact.
    Tip: One of the addresses can be marked as the “main address” and transferred to the account or contact so that it is directly visible on the account/contact record.
  • Are there requirements from other systems as to how addresses are to be transferred? These must be validated and incorporated into the concept.
  • Should the address lines be entered in separate fields, i.e. one field each for street, addition, P.O. Box? (my recommendation)
  • Do we want to offer information about the country etc. as a list of values, and at best set a default value right away?
  • Do we primarily manage Swiss addresses or do we operate internationally?
  • Do we want to validate the input of the addresses, e.g. if the length of the ZIP code is correct depending on the country?

Alternative implementation based on Swiss addresses

In Switzerland (and other countries), city directories and often street directories can be obtained free of charge. Thus, an individual implementation can go in such a way that the user searches for the postcode/location from Salesforce and no longer enters it each time. The correct city, including canton and country, is then automatically inserted.

Example

On the following pictures such an implementation is roughly illustrated. All localities in Switzerland have been uploaded to Salesforce in a separate object. On the address, the user now searches for either town or zip code and makes the correct selection. Afterwards the fields PLZ, city and country are filled in accordingly.

salesforce plz suche 2
salesforce anschrift

It is also conceivable to upload the street directory to Salesforce. For localities and streets of Switzerland about 350 MB of the data storage is needed, for the localities it is about 10 MB.

The address marked as the main address will be displayed on the account. It is validated that only one address can be a main address, street and no. are separate fields. The address has a corresponding type. P.O. Box and other address lines are kept in separate fields. International addresses are entered in the same object. So they are available afterwards as well.

Source: https://swisspost.opendatasoft.com/explore/

Of course, there are a few more issues to discuss. Are addresses allowed to be mutated, or do they become inactive? Then it must be ensured that the main address can change. In Salesforce Standard, the contact automatically adopts the account address when it is created, but this must be configured independently in a custom solution.

All in all, however, I am convinced that a solution tailored to the specific needs around addresses is more powerful and sustainable, especially with regard to the use in documents or integrated systems.


André Ryf is Salesforce consultant, trainer and coach, and owner of squiis, your personal Salesforce Partner.

If you have any questions about Salesforce, please contact us. We are there for you in Zurich, Basel, Bern, St. Gallen and all other cities in Switzerland

Not yet a newsletter subscriber? Then register right here.

Teilen Sie diesen Blog Post mit Ihrem Netzwerk:
LinkedIn
Twitter
Facebook

Weitere Blog Artikel

salesforce-adressmodel

Anschriften modellieren

Im Standard kommt Salesforce mit einer eher einfachen Art für die Erfassung von Anschriften daher. Bei der konkreten CRM Umsetzung

salesforce-contact-management

Contact Management

In every CRM we manage contacts. These contacts are people with whom we have a relationship. However, we often record

Salesforce Kontaktmanagement

Kontaktmanagement

In jedem CRM verwalten wir Kontakte. Diese Kontakte sind Menschen, mit denen wir eine Beziehung pflegen. Oftmals erfassen wir jedoch