Wie migriert man Record Types in Salesforce?

Die Migration von Salesforce-Datensätzen zu einem neuen Record Type bedeutet, das Feld RecordTypeId bei jedem betroffenen Datensatz zu aktualisieren und gleichzeitig Validation Rules, Flows, Apex und Approval Processes an die neue Konfiguration anzupassen. Wird der Audit-Schritt übersprungen, brechen Automatisierungen lautlos. Dieser Artikel beschreibt den Fünf-Phasen-Prozess, mit dem CRM-Teams Record Types migrieren, ohne bestehende Geschäftslogik zu zerstören.

Was verändert eine Salesforce Record Type Migration tatsächlich?

Ein Salesforce Record Type steuert drei Dinge für einen Datensatz: welche Picklist-Werte verfügbar sind, welches Page Layout der Nutzer sieht, und welchem Geschäftsprozess der Datensatz folgt. Record Types ermöglichen es Organisationen, unterschiedliche Prozesse für unterschiedliche Nutzer auf demselben Objekt anzubieten. Die Migration zu einem neuen Record Type bedeutet, dass jeder betroffene Datensatz eine neue RecordTypeId erhält, wodurch sich seine Picklist-Optionen, sein Layout und der zuständige Sales Process ändern können. Deshalb ist eine Migration nie ein reines Datenupdate. Sie betrifft jede Automatisierung, die auf RecordTypeId liest oder filtert.

Validation Rules, Flows, Apex-Trigger, Approval Processes und selbst Report-Filter verweisen häufig auf einen bestimmten Record Type, entweder über eine fest codierte ID oder über den Namen. Wird die RecordTypeId eines Datensatzes ausgetauscht, hört jede Automatisierung, die noch auf die alte Konfiguration zeigt, entweder auf zu funktionieren oder funktioniert fehlerhaft. Salesforce begrenzt Organisationen zudem auf 200 Record Types pro Objekt, weshalb die meisten Migrationen mehrere ältere Typen zu weniger, saubereren Typen zusammenführen, statt einen Eins-zu-eins-Ersatz zu schaffen. Wer die Migration von vornherein um diese Grenze herum plant, vermeidet ein Jahr später ein zweites Aufräumprojekt.

Warum müssen Sie Automatisierungen vor der Änderung eines Record Types prüfen?

Bevor Sie Daten anfassen, finden Sie alles in der Organisation, das auf den alten Record Type verweist. Dazu gehören fest codierte IDs in Validation Rule Formeln, Entry Criteria bei Approval Processes und Assignment Rules, Cross-Object-Formeln und Rollups auf verwandten Objekten sowie Filter in Reports und List Views. Diesen Schritt zu überspringen ist die häufigste Ursache für eine gescheiterte Record Type Migration, weil das Datenupdate gelingt, während die abhängige Automatisierung leise zerbricht. Dokumentieren Sie jede gefundene Komponente, bevor Sie zur nächsten Phase übergehen, und betrachten Sie das Audit erst dann als abgeschlossen, wenn jeder der unten genannten Automatisierungstypen geprüft wurde.

‍

‍

Record-Triggered Flows verdienen besondere Aufmerksamkeit, da ihr Start-Element Entry Conditions nutzt, um zu entscheiden, ob der Flow überhaupt läuft. Filtern die Entry Conditions eines Flows auf die alte RecordTypeId, hört der Flow einfach auf, bei migrierten Datensätzen zu feuern, ohne einen Fehler auszulösen, was diesen Fehlerfall beim Testen leicht übersehen lässt. Das Start-Element jedes Record-Triggered Flows gegen Ihr Record Type Inventar zu prüfen ist keine Option. Es ist der Schritt, den die meisten Audits auslassen und auf den die meisten Rollbacks zurückgehen.

Wie richten Sie den neuen Record Type vor der Migration ein?

Erstellen Sie den neuen Record Type, bevor Sie bestehende Daten anfassen, und bestätigen Sie, dass er dem richtigen Page Layout und, sofern relevant, einem Sales Process zugeordnet ist. Diese Reihenfolge ist wichtig, weil Data Loader ein Update ablehnt, wenn die Ziel-RecordTypeId noch nicht aktiv und korrekt konfiguriert ist. Erfahrene Salesforce-Praktiker weisen durchgängig darauf hin, dass ein Daten-Backup vor jeder Record Type Änderung unabhängig vom Umfang zur unverzichtbaren Praxis gehört. Bestätigen Sie, dass die Picklist-Werte korrekt auf den neuen Typ abgestimmt sind, da eine Abweichung hier als Validierungsfehler auftaucht, sobald der migrierte Datensatz das nächste Mal von einem Nutzer bearbeitet wird.

Wie extrahieren und mappen Sie Datensätze auf den neuen Record Type?

Exportieren Sie die zu migrierenden Datensätze über Reports, Data Loader, Workbench oder ein ETL-Tool und schließen Sie die aktuelle RecordTypeId jedes Datensatzes in den Export ein. Fügen Sie in einer Tabelle eine Spalte für die neue 18-stellige RecordTypeId hinzu und ordnen Sie jeden alten Wert seinem Ersatz zu. Salesforce verlangt für API-gesteuerte Updates das 18-stellige, nicht case-sensitive ID-Format statt der 15-stelligen ID, die in manchen UI-Ansichten angezeigt wird. Bestätigen Sie daher, dass Sie die richtige Version kopiert haben, bevor Sie die Mapping-Datei erstellen. Bewahren Sie diese Mapping-Datei auf, da die Aufräumarbeiten in Phase 5 davon abhängen, genau zu wissen, welche alte ID welcher neuen zugeordnet wurde.

Wie laden und verifizieren Sie das Record Type Update?

Führen Sie das Update zuerst in einer Sandbox aus, um Abhängigkeiten zu erfassen, die das Audit übersehen hat, da eine Änderung der RecordTypeId nach der Übernahme in die Produktivumgebung nicht rückgängig gemacht werden kann. Salesforces eigener Support empfiehlt, vor einem vollständigen Batch zunächst zwei oder drei Datensätze zu testen, gerade weil die Änderung über Data Loader selbst nicht rückgängig gemacht werden kann.

1. Führen Sie den vollständigen Update-Prozess an einer Sandbox-Kopie der Produktivdaten durch, bevor Sie Live-Datensätze anfassen, und bestätigen Sie, dass keine abhängige Automatisierung fehlerhaft reagiert.
2. Schalten Sie jede Validation Rule, jeden Trigger und jeden Flow ab, der das Übernehmen des RecordTypeId Updates verhindern würde.
3. Laden Sie Ihre Mapping-Datei, wählen Sie Update für das Zielobjekt und mappen Sie RecordTypeId auf Ihre neue ID-Spalte.
4. Schalten Sie Validation Rules, Trigger und Flows wieder ein, sobald das Update erfolgreich abgeschlossen ist.
5. Prüfen Sie stichprobenartig eine Auswahl migrierter Datensätze direkt in Salesforce, um zu bestätigen, dass Record Type, Layout und Picklist-Werte korrekt angezeigt werden.

Change Management Praxis empfiehlt, jeden Schritt zu dokumentieren, bevor er live geht, und den Setup Audit Trail nach Abschluss des Deployments zu überwachen, da eine Record Type Migration an anderer Stelle in der Organisation leise Berechtigungen oder Automatisierungen beeinflussen kann. Behandeln Sie den Sandbox-Durchlauf als Generalprobe für exakt die spätere Produktivsequenz, nicht als grobe Annäherung, da Unterschiede zwischen beiden Umgebungen der häufigste Grund sind, warum Migrationen scheitern.

Was müssen Sie nach Abschluss der Migration aufräumen?

Aktualisieren Sie jede fest codierte Referenz, die während des Phase-1-Audits markiert wurde, sodass jede auf den neuen statt den alten Record Type zeigt. Sobald kein aktiver oder historischer Datensatz mehr vom alten Record Type abhängt, deaktivieren oder löschen Sie ihn, da Salesforce eine Löschung nicht zulässt, solange Datensätze noch darauf verweisen. Bewahren Sie die Mapping-Datei und einen vollständigen Datenexport von vor der Migration auf. Da die Änderung der RecordTypeId nicht rückgängig gemacht werden kann, ist dieses Backup der einzige Weg zur Wiederherstellung, falls im Nachhinein ein Mapping-Fehler auffällt. Betrachten Sie das Aufräumen als Teil der Migration selbst, nicht als optionale Folgeaufgabe.

Häufig gestellte Fragen

Kann man eine Salesforce Record Type Migration rückgängig machen, nachdem sie ausgeführt wurde?

Nein. Das Aktualisieren der RecordTypeId über Data Loader ist nicht rückgängig zu machen, und Salesforces eigene Anleitung empfiehlt, vor einem vollständigen Batch zunächst zwei oder drei Datensätze zu testen. Taucht danach ein Mapping-Fehler auf, ist der einzige Weg zur Wiederherstellung das erneute Laden aus einem Datenexport von vor der Migration. Deshalb gehört das Exportieren der aktuellen RecordTypeId Werte vor Beginn zu den Pflichtschritten und nicht zu den optionalen.

Was ist RecordType.DeveloperName, und warum sollte man es statt einer fest codierten ID verwenden?

RecordType.DeveloperName ist ein stabiler Verweis auf einen Record Type über den Namen statt über seine 15- oder 18-stellige ID, die sich zwischen Sandboxes und Organisationen ändert. Fest codierte IDs brechen, sobald Sie in eine andere Umgebung deployen oder den Record Type selbst migrieren. Validation Rule Formeln und Apex, die auf DeveloperName statt auf eine literale ID verweisen, überstehen beide Szenarien ohne Anpassung.

Wie viele Datensätze sollte man testen, bevor man ein vollständiges Data Loader Update ausführt?

Zwei oder drei, laut Salesforces eigener Support-Anleitung, da die Änderung der RecordTypeId nach der Übernahme nicht rückgängig gemacht werden kann. Bestätigen Sie, dass sich der kleine Batch korrekt verhält, prüfen Sie, ob abhängige Automatisierung wie erwartet feuert, und fahren Sie erst dann mit dem vollständigen Produktivbatch fort. Diesen Schritt zu überspringen ist der schnellste Weg, aus einer Migration ein Datenwiederherstellungsprojekt zu machen.

Wie viele Record Types kann ein einzelnes Salesforce Objekt haben?

Salesforce empfiehlt maximal 200 Record Types pro Objekt, auch wenn die Plattform bei dieser Zahl keine technische Hartgrenze erzwingt. Die meisten Migrationen sind eine gute Gelegenheit, mehrere überlappende ältere Record Types zu einem kleineren, saubereren Satz zusammenzuführen, statt einen Eins-zu-eins-Ersatz zu schaffen, was das Objekt langfristig wartbarer macht.

Kann man die RecordTypeId eines Datensatzes auf Master setzen oder leer lassen?

Nein. Salesforce erlaubt kein Data Loader Update, das RecordTypeId auf Master oder auf einen Nullwert setzt. Das Ziel muss ein aktiver, korrekt konfigurierter Record Type sein. Bestätigen Sie, dass der neue Record Type vollständig eingerichtet ist, einschließlich Page Layout und Sales Process Zuordnung, bevor Sie das Massen-Update starten, sonst schlägt der Ladevorgang fehl.

Braucht man für eine kleine Record Type Migration eine Sandbox?

Ja, selbst für eine Handvoll Datensätze. Sandbox-Tests existieren genau dafür, abhängige Automatisierungsprobleme zu erfassen, bevor sie die Produktivumgebung erreichen. Diesen Schritt bei einer folgenreichen, nicht rückgängig zu machenden Änderung wie einer Record Type Migration zu überspringen ist exakt das Szenario, vor dem Anleitungen zu Sandbox-Tests am deutlichsten warnen, unabhängig davon, wie wenige Datensätze betroffen sind.