Smarte Adress-Validierung in Salesforce – Teil 1

Saubere und aktuelle Daten sind für jedes Unternehmen wichtig. Vorallem die Adresse der Geschäftskontakte sollte korrekt und aktuell sein.

Schließlich will sich niemand durch eine falsche Empfängeradresse auf einer pdf blamieren oder – schlimmer noch – riskieren, dass beispielsweise Rechnungen auf dem Postweg nicht zustellbar sind.

Dieser Beitrag ist ein Update zu dem Blogbeitrag, bzw. der Solution „Smart Standard Address Field Update“ vom Mai 2015.
Zu dieser Zeit wurde noch ausschließlich in Salesforce Classic gearbeitet, nur einige wenige Lightning Features, wie z. B. der Prozessgenerator (Process Builder) waren bereits generell verfügbar – wenn auch noch lange nicht in dem Umfang, wie wir ihn heute kennen.

Da es sich bei dem Smart Standard Address Field Update um eine sehr schöne und nützliche Lösung handelt, ist es mehr als 3 Jahre später höchste Zeit, die Lösung von damals auf einen zeitgemäßen „Best Practice“-Stand zu bringen.  

Um die Länge eines Blogbeitrags nicht zu sprengen, haben wir die Evaluation und Beschreibung der Lösung in 3 Teile aufgesplittet. Dies ist Teil 1, der sich mit den grundsätzlichen Einstellungen beschäftigt. Teil 2 beschreibt die Umsetzung für Standardobjekte/-felder, Teil 3 die Umsetzung für benutzerdefinierte Objekte/Felder.

Die Anforderungen

Die Anforderungen an das Smart Standard Address Field Update lauteten:

• Validierung der Adress-Felder an Account und Lead basierend auf der eingegebenen Postleitzahl 
• Validierung multinationaler Accounts mit aktivierter Auswahlliste für Bundesstaat sowie Land/Region
• Warnhinweis an Nutzer ausgeben, falls die Validierung einen Fehler erkennt
• Berücksichtigung doppelter Postleitzahlen (also, wenn mehrere Orte/Städte der gleichen Postleitzahl zugeordnet sind )
• Darstellung der Adresse im Layout auf Google Maps

Vorab, die Lösung von damals würde grundsätzlich auch heute in Lightning funktionieren. Durch die Updates der letzten 3 Jahre haben wir aber heute mehr „out-of-the-box“ Produktivitäts-Features sowie mehr Möglichkeiten im Flow und mithilfe von Lightning Components, die Lösung auf ein höheres Level zu bringen.

Die Anforderungen aus dem Jahr 2015 haben wir noch erweitert:

• Lightning-Ready Solution nach Best Practices
• Dynamisches Gerüst, das auch für Benutzerdefinierte Objekte funktioniert

Zudem werden wir in dieser Reihe bei „Clicks, Not Code“ bleiben.

Out-of-the-box Features

Ein paar Releases nach der ursprünglichen Anforderungsdefinition nutzen wir überwiegend Salesforce Lightning und 2 der Produktiv-Features scheinen auf den ersten Blick die grundsätzlichen Anforderungen (valide Adresse und Darstellung auf Google Maps) out-of-the-box zu erfüllen.

Die Adresssuchfunktion (autocomplete von Standardadressen) im Salesforce Standard deckt die grundsätzliche Anforderung „valide Adresse“ bereits ab. Zudem ist diese Funktionalität für Standard-Adressfelder an allen Standard-Objekten verfügbar.

Dazu müsste man nur die Karten und Standort Features aktivieren. Auch die Darstellung auf der Karte wird mit einem Klick aktiviert.

Aber…

Mal vorausgesetzt, dass alle Mitarbeiter beim Erstellen und Bearbeiten der Adressdaten die Google-Suche nutzen (was man derzeit nicht überprüfen kann) und vernachlässigt, dass der Autocomplete nur für einige wenige Länder optimiert ist:
Was passiert mit bereits vorhandenen Daten? Die bereits in Salesforce, einem ERP oder einer Excel-Liste existieren und/oder über Schnittstellen in Salesforce importiert werden?

Für diese Fälle benötigen wir das Kontrollinstrument der „Smart Adress Field Updates“.

Data.com Clean?

Data.com Clean ist eine Lösung, die Account-, Kontakt- und Lead-Daten in Salesforce mit externen Datenbanken abgleicht und ggf. bereinigt. Dabei handelt es sich zweifellos um eine sehr gute Lösung, um nachhaltig eine hohe Datenqualität zu gewährleisten.

Aber sie hat auch einige Nachteile: Zunächst einmal müssen Lizenzen gekauft werden, der Service funktioniert nur für die oben genannten Standard-Objekte (Personenaccounts werden nicht unterstützt), es gibt monatliche Obergrenzen und die Services sind nur bedingt in Lightning verfügbar.

Geocode Datenintegrationsregeln

Auch die Geocode Datenintegrationsregeln (ehemals Geocode Clean Rules), die auch ohne den Kauf weiterer Lizenzen in der Sales Cloud verfügbar sind, helfen nicht wirklich weiter, um die Qualität der Adressdaten zu validieren und zu kontrollieren.

Zwar liefern uns die Regeln neben den Geokoordinaten auch einen Wert für die Genauigkeit, die als Qualitätsindikator der Adresse dienen könnte, aber im realen Use Case, ist dieser Wert leider doch ungeeignet.

Ein simples Beispiel:

Geben wir für einen Account unsere Adresse ein, erhalte ich für die Genauigkeit den Wert „Block“ (das ist die dritthöchste Stufe und schon relativ genau). Ersetze ich die (korrekte) Postleitzahl „60325“ zu „12345“ und aktualisiere die Datenintegrationsregel „Geocodes for Account Billing Address“ (wofür ich nach Salesforce Classic wechseln muss) bleiben die Latitude, Longitude und Genauigkeit unverändert.

Die Lösung

Wir behalten also den Lösungsansatz von 2015 bei. Dieser basiert auf einem benutzerdefinierten Objekt, das als Postleitzahlen Datenbank diente, benutzerdefinierten Feldern je zu validierendes Objekt, einem Prozess Builder Prozess pro Objekt.

Daneben wurden die Auswahllisten für Bundesstaat und Land/Region konfiguriert und aktiviert, sowie ein Report für multiple Orte für die gleiche Postleitzahl angelegt.

Die größten Änderungen der heutigen Lösung sind das Ersetzen des benutzerdefinierten Objekts für Postleitzahlen durch zwei benutzerdefinierte Metadaten Typen und den Report durch eine Flow-Komponente.

Um die Blogpost-Serie überschaubar zu halten, werden wir uns zunächst auf die Felder der Rechnungsanschrift am Account konzentrieren. Das Prinzip ist für alle Standard-Adressfelder das gleiche.

Aufsetzen der Accountdaten

1. Konfiguration der Auswahllisten für Bundesstaat und Land/Region

Zunächst die Fleißarbeit: Die Konfiguration und Aktivierung der Auswahllisten für Bundesstaat und Land/Region. Wir limitieren die Auswahl der Länder auf solche, die für uns relevant sind und pflegen exemplarisch Regionen für Deutschland und Österreich ein.

Darauf im Detail einzugehen würde an dieser Stelle den Rahmen sprengen.

2. Erste Anpassungen am Account

Am Account legen wir 2 Validierungsregeln an. Die erste validiert, ob ein Wert für die Postleitzahl eingegeben wurde, die zweite, ob diese im korrekten Format für dieses Land eingegeben wurde.

Damit wir die Postleitzahlen validieren können, müssen wir sicherstellen, dass Werte für Land (Rechnungsanschrift) und PLZ (Rechnungsanschrift) oder Stadt (Rechnungsanschrift) angegeben werden.

Zusätzlich legen wir eine Validierung auf das Format der Postleitzahl an. An dieser Stelle zunächst nur für das Postleitzahlenformat, das aus 5 Zahlen besteht.

Anmerkung: Um die Validierung der Postleitzahl hinreichend für alle Länder abzudecken, müssten Stand heute für jedes Postleitzahlenformat einige Zeilen an Formel-Code geschrieben werden. Mit dem Winter '19 Release, kann dies durch eine Validierung über Custom Metadata Types deutlich vereinfacht und dynamischer gestaltet werden. 

Vorsicht beim Datenimport

Wichtig: Die Validierungsregeln wie hier dargestellt, werden auch bei Datenimporten anschlagen.
Daher sollten für Massenuploads, beispielsweise aus Excel-Tabellen, die Daten bereinigt werden, bevor sie importiert werden.
Bei Integrationen zu anderen Systemen ist das schon schwieriger, v. a., da hier oft Daten der letzten X Jahre importiert werden. Hierfür grenzen wir die Validierungsregeln entsprechend ab, so dass der Import nicht fehlschlägt.

Was wir aber an dieser Stelle tun, ist ein Picklistenfeld am Account anzulegen, dass als Indikator dafür dient, ob die Adresse valide ist und/oder Werte fehlen.

Dazu legen wir einen Globalwertesatz „Address Quality“ an, der momentan nur den Wert „Adresse unvollständig“ enthält. Am Account legen wir eine Auswahlliste „Rechnungsadresse Qualität“ an.