Tipps & Tricks rund um die Datenmigration nach Salesforce: Damit wird Ihre nächste Datenmigration mit Sicherheit ein Erfolg.
Es ist ein gutes Gefühl eine neue Salesforce-Umgebung für Kunden einzurichten. Man kann sich selbst austoben und gleichzeitig Kunden glücklich machen. Doch je näher der "Go-Live"-Termin rückt, desto größer wird die Angst. Und diese Angst hat einen Namen: Datenmigration!
Jeder Kunde bringt bereits bestehende oder potenzielle Kunden, Events und Aufgaben, offene Offerten oder Verhandlungen mit, die als Accounts, Leads, Tasks, Events und Opportunities in der neuen Sales Cloud angelegt werden möchten. Das kann jeden erfahrenen Salesforce Berater zur Verzweiflung bringen ... oder auch nicht, wenn Sie weiterlesen, wird Ihre nächste Datenmigration nur halb so schlimm.
Vorbemerkung
Ich nutze zur Datenmigration den häufig genutzten Data Loader in Kombination mit Excel. Die Tipps und Tricks aus diesem Blogbeitrag richten sich also hauptsächlich an diejenigen, die ebenfalls mit dieser Kombination arbeiten. Doch auch Salesforce Administratoren und Salesforce Berater, die nicht den Data Loader benutzen, sollten jetzt nicht einfach aufhören zu lesen. Auch für Sie habe ich ein paar Geheimnisse auf Lager.
Aber dieser Picklisten-wert existiert doch!
Wenn Sie zwei Bildschirme benutzen, kennen Sie sicher das Gefühl. Manchmal möchte man dem Data Loader auf dem einen Bildschirm, den anderen Bildschirm mit den Import-Daten förmlich zudrehen und sagen: "Hey, schau - hier sind die Picklisten-Werte. Siehst du sie!" Und dennoch, der Data Loader würde nicht aufhören zu meckern.
Also, was ist passiert?
In den meisten unserer Neueinführungen bauen wir nicht in der Produktion. Sandboxen sind der perfekte Ort, um zu bauen und zu spielen, auch für künftige Endnutzer. Man denkt sich also nicht böses und fängt bei den Benutzerprofilen an. Testen. Deployment. Gut, geschafft!
Jetzt kommen neue Felder: Picklisten, Datum, Datum, Text, Text Area, wieder ein Datum ... oh und noch eine Pickliste abhängig vom Account Type. Vielleicht schon ein paar automatische Updates dazu? Testen. Deployment. Puh, wieder alles gut gegangen!
Ups, ach ja, der Kunde möchte zwei verschiedene Datensatztypen für den Account. Kein Problem! Testen. Deployment. Dann etwas später: Endlich alles fertig! Jetzt nur noch die Daten ins System einspielen und die Nutzer können losziehen und die Salesforce-Welt erkunden.
Doch dann, die Fehlermeldung, die viele von uns kennen: "Invalid value for restricted picklist field".
Was ist zu tun?
Keine Sorge: Sie müssen Ihren Computer nicht aus dem Fenster schmeißen und auch nicht an der geistigen Zurechnungsfähigkeit des Data Loaders zweifeln. Dieser Fehler birgt sehr viele Geheimnisse, die ich für Sie jetzt ein für alle Mal aus der Welt schaffen möchte.
Instinktiv sucht man natürlich nach etwaigen Tippfehlern in der vorliegenden Importdatei. Wenn Sie hier nicht weiter kommen liegt das Problem in Salesforce. Neben fehlerhaften Importdateien gibt es zwei weitere möglichen Ursachen für diesen Fehler.
Die Erste sind Abhängigkeiten zwischen Werten von zwei unterschiedlichen Picklisten, im Speziellen die Abhängigkeit eines benutzerdefinierten Feldes von einem Standardfeld. Bekommt also ein importierter Datensatz nun einen bestimmten Wert des Standardfeldes und sind diesem Wert die Werte des abhängigen Feldes noch nicht zugeordnet, so sind sie für den Data Loader praktisch nicht vorhanden.
Die Lösung daher: Einfach noch einmal kontrollieren, ob Abhängigkeiten zwischen einzelnen Feldern richtig zugeordnet sind.
Die Zweite sind die Abhängigkeiten von Picklisten von verschiedenen Datensatztypen. Dieses Problem tritt vor allem dann auf, wenn zuerst Datensatztypen und danach erst Picklisten-Felder in einem Deployment verschoben werden. Leider werden bei diesem Vorgang die neuen Werte der Pickliste nicht automatisch für den schon vorhandenen Datensatztyp in der Empfängerumgebung freigeschaltet. Das muss im Anschluss noch passieren, ansonst ist das Gemecker des Data Loader vorprogrammiert.
Die Lösung hier also: Sie heißt wieder "Vertrauen ist gut, Kontrolle ist besser!" Schauen Sie im Setup noch einmal nach ob Picklistenwerte den Datensatztypen zugeordnet sind. Jetzt heißt es tatsächlich: Endlich alles fertig! Daten ins System einspielen und die Nutzer können loslegen.
Ein weiteres Beispiel: Datenmigration und Zeitzonen
Zeit spielt eine große Rolle. Meist gibt es davon zu wenig. Umso wichtiger ist es, sie sich einzuteilen und zu Terminen pünktlich zu sein. Sie verabschieden sich also nach einem Tag, der schon wieder zu wenig Zeit hatte, mit den Worten "Tschüss, wir meeten uns dann morgen um 12 mit den Jungs aus dem Marketing!" in den Feierabend und bekommen prompt eine Antwort: "Nein, du meinst um 10?!"
Also, was ist passiert?
In Salesforce ist das Meeting ganz eindeutig auf 12 Uhr terminiert und dennoch ist es um 10 Uhr. Das ist eine lange Geschichte und sie hat etwas mit Zeitzonen, der Sommerzeit und dem Data Loader zu tun. Also machen Sie sich bereit.
In der Excel-Datei des Datenmigrations-Spezialisten stand der Termin auf 10 Uhr und hier wurde auch nichts daran verändert. Jedenfalls nicht durch den Spezialisten. Hier kommt die Zeitzone ins Spiel: Die Uhrzeit wurde vom Data Loader als Zeit der "UTC"-Zeitzone aufgefasst und die Uhrzeit wurde automatisch in die Zeit der Zeitzone desjenigen umgerechnet, der die Daten importiert. Die unterscheidet sich aber, je nachdem, ob die Sommer- oder Winterzeit gilt um eine oder zwei Stunden.
Was ist zu tun?
Wenn dieses Problem auftritt, hilft es nicht nur Ihre Zeitzone in Ihren persönlichen Einstellungen in Salesforce auf "UTC" umzustellen, wichtig gerade für diejenigen, die den Data Loader benutzen. Denn auch im Data Loader kann in den Einstellungen die Zeitzone eingestellt werden.
Sollte also bei Testimporten auffallen, dass Termine mit der falschen Zeit importiert wurden, dann sollten Sie sich der richtigen Zeitzone in Ihren Salesforce-Einstellungen und den Data Loader-Einstellungen vergewissern.
Sehr deutlich wurde das Problem bei mir als Opportunities falsche Abschlusstermine aufwiesen. Bei Datumsfeldern ist dieser Fehler noch schlechter zu erahnen. So waren die Abschlusstermine bei jeder Opportunity immer um einen Tag verschoben. Auch hier war das Problem die Zeitzone - Datumsfelder werden im Hintergrund nämlich mit Zeitangabe gespeichert. Diese hat dann den Wert 0 Uhr. Plus eine oder zwei Stunden ergibt das den nächsten Tag.
Es geht weiter: Datumsformate und Import
Nachdem der Streit um den versehentlich verschobenen Termin beigelegt war, sitzen Sie und Ihr Kollege nun doch noch bei einem Feierabendbier zusammen:
"Ich muss diese Woche noch richtig Gas geben, ich habe noch fünf Opportunities, die ich schon letzten Monat hätte abschließen sollen.". "Bist du dir sicher? Ich erinnere mich noch an den Excel-Export aus unserem alten System. Die Opportunities waren alle auf Ende des Monats datiert. Du hast also noch Zeit."
Also, was ist passiert?
Beim Import von Datumsfeldern gilt es nicht nur die Zeitzone zu beachten, sondern auch das Datumsformat. Wird das nicht gemacht, so kann aus dem 8. September schnell der 9. August werden oder aus dem 12. Juni ein schickes Geschenk zum Nikolaustag für den Chef.
Was ist zu tun?
Sobald Datumsfelder importiert werden müssen, lohnt sich ein Blick in die eigenen Salesforce-Einstellungen, speziell auf das eingestellte "Locale". Dieses wirkt sich auf das Datumsformat aus. Ist dort also "Deutsch" hinterlegt, so muss in der CSV-Importdatei auch das Datum im Format "dd.mm.yyyy" angegeben sein.
Zum Problem wurde es bei mir, da ich auf meinem Rechner selbst das amerikanische Datumsformat nutze, also "mm/dd/yyyy". In der Kundenumgebung aber, durch die "Locale"-Einstellung, das britische Datumsformat importiert werden musste, also "dd/mm/yyyy". Dieser kleine Unterschied ließ nach dem ersten Testimport wahlweise den Data Loader oder die Nutzer an mir verzweifeln.
Der Unterschied zwischen Euro und Schweizer Franken
Ein Unternehmen, das weltweit agiert, verkauft seine Produkte und Dienstleistungen auch in unterschiedlichen Währungen. Also ist auch hier Vorsicht geboten und vor allem darauf zu achten mit welchem Nutzer die Datensätze in Salesforce erstellt werden.
Wir haben nun folgende Situation: "Hey, ich verkaufe für unser schweizer Tochterunternehmen Produkte an Schweizer in der Schweiz in Schweizer Franken. Wieso steht in meiner Opportunity Euro?"
Also was ist passiert?
Wenn die Multi-Currency-Funktionalität aktiviert wurde, ist automatisch auf allen Objekten ein Währungsfeld entstanden. Dieses muss natürlich auch in den Importdateien beachtet werden, erst recht wenn man Opportunities, Orders oder Quotes importiert. Wird beim Import keine Währung angegeben, so wird das Feld "Currency", da verpflichtend, automatisch mit der "Default"-Währung des Erstellers der Datensätze befüllt.
Was ist zu tun?
Auf jeden Fall sollte das Währungsfeld in der Importdatei ausgefüllt sein und somit auch importiert werden. Wenn Sie sich sicher sind, dass sie wirklich nur Datensätze mit einer einzigen Währung importieren, lohnt es sich, auf diese Währung in den eigenen Einstellung umzustellen. Das Problem mit der Übernahme von "Default"-Werten des Erstellers, wenn keine anderen Werte angegeben werden, besteht auch bei Datensatztypen. Hier ist eine Kontrolle des eigenen Profils erforderlich.
Sie sehen: Datenmigration ist immer noch eine Herausforderung und dennoch mit diesem Wissen hat zumindest für mich das Schreckgespenst gehörig an Schrecken verloren. Der nächste Import kann also kommen!