Wie migrierst Du Record Types in Salesforce?

Die Migration von Salesforce-Datensätzen auf einen neuen Record Type bedeutet, das Feld RecordTypeId bei jedem betroffenen Datensatz zu aktualisieren und gleichzeitig Validierungsregeln, Flows, Apex und Genehmigungsprozesse auf die neue Konfiguration abzustimmen. Überspringst Du das Audit, brechen Automatisierungen unbemerkt weg. Dieser Artikel zeigt den fünfstufigen Prozess, mit dem CRM-Teams Record Types migrieren, ohne bestehende Business-Logik zu beeinträchtigen.

Was ändert sich durch eine Salesforce Record Type Migration wirklich?

Ein Salesforce Record Type steuert drei zentrale Elemente eines Datensatzes: welche Auswahllistenwerte verfügbar sind, welches Page Layout angezeigt wird und welchem Business-Prozess der Datensatz folgt. Über Record Types können Organisationen verschiedenen Nutzergruppen unterschiedliche Prozesse für dasselbe Objekt bereitstellen. Bei der Migration auf einen neuen Record Type erhält jeder betroffene Datensatz eine neue RecordTypeId – das kann Auswahllisten, Layouts und den zugrundeliegenden Sales-Prozess verändern. Deshalb ist eine solche Migration nie ein reines Daten-Update: Sie betrifft jede Automatisierung, die auf die RecordTypeId zugreift oder danach filtert.

Validierungsregeln, Flows, Apex-Trigger, Genehmigungsprozesse und sogar Berichtsfilter verweisen häufig auf einen bestimmten Record Type, entweder über eine fest codierte ID oder über den Namen. Wenn Du die RecordTypeId eines Datensatzes änderst, wird jede Automatisierung, die noch auf die alte Konfiguration verweist, entweder gar nicht oder fehlerhaft ausgeführt. Salesforce empfiehlt maximal 200 Record Types pro Objekt. Daher konsolidieren die meisten Migrationen mehrere ältere Typen in weniger, sauberere Typen, anstatt sie 1:1 zu ersetzen. Wer die Migration von vornherein unter dieser Prämisse plant, spart sich ein zweites Bereinigungsprojekt ein Jahr später.

Warum Du Automatisierungen auditieren musst, bevor Du einen Record Type änderst

Bevor Du Daten anfasst, finde alles in der Org, was sich auf den alten Record Type bezieht. Dazu gehören hartcodierte IDs in Validation Rules, Einstiegskriterien in Approval-Prozessen und Assignment Rules, objektübergreifende Formeln und Rollups auf verknüpften Objekten sowie Filter in Reports und Listenansichten. Diesen Schritt zu überspringen, ist die mit Abstand häufigste Ursache für gescheiterte Record-Type-Migrationen: Das Daten-Update gelingt zwar, aber die abhängigen Automatisierungen gehen im Stillen kaputt. Dokumentiere jede Komponente, die Du findest, bevor Du zur nächsten Phase übergehst, und betrachte das Audit erst dann als abgeschlossen, wenn jeder der folgenden Automatisierungstypen geprüft wurde.

Record-triggered Flows verdienen besondere Aufmerksamkeit, da ihr Start-Element über Einstiegskriterien entscheidet, ob der Flow überhaupt ausgeführt wird. Filtern die Einstiegskriterien eines Flows auf die alte RecordTypeId, feuert der Flow bei migrierten Datensätzen einfach nicht mehr – ohne eine Fehlermeldung auszugeben. Genau das macht diesen Fehler beim Testen so leicht zu übersehen. Das Start-Element jedes Record-triggered Flows gegen Dein Record-Type-Inventar zu prüfen, ist keine Option, sondern Pflicht. Es ist der Schritt, den die meisten Audits auslassen und auf den die meisten Rollbacks zurückzuführen sind.

Wie richtest Du den neuen Record Type vor der Migration ein?

Erstelle den neuen Record Type, bevor Du bestehende Daten anfasst, und stelle sicher, dass er dem richtigen Page Layout und – falls relevant – einem Sales Process zugewiesen ist. Diese Reihenfolge ist entscheidend, da der Data Loader ein Update ablehnt, wenn die Ziel-RecordTypeId noch nicht aktiv und sauber konfiguriert ist. Erfahrene Salesforce-Praktiker empfehlen ausnahmslos, vor jeder Record-Type-Änderung ein Backup Deiner Daten zu erstellen – unabhängig vom Umfang. Prüfe zudem, ob Picklist-Werte für den neuen Typ korrekt zugewiesen sind; ein Mismatch führt sonst genau in dem Moment zu einem Validierungsfehler, in dem der migrierte Datensatz das nächste Mal von einem User bearbeitet wird.

Wie extrahiert und mappt man Datensätze auf den neuen Record Type?

Exportiere die zu migrierenden Datensätze über Berichte, Data Loader, Workbench oder ein ETL-Tool und beziehe die aktuelle RecordTypeId jedes Datensatzes in den Extrakt ein. Füge in einer Tabelle eine Spalte für die neue 18-stellige RecordTypeId hinzu und mappe jeden alten Wert auf seinen Ersatz. Salesforce erfordert für API-gestützte Updates das 18-stellige, nicht case-sensitive ID-Format anstelle der in einigen UI-Ansichten angezeigten 15-stelligen ID. Stelle daher sicher, dass Du die korrekte Version kopierst, bevor Du die Mapping-Datei erstellst.

Bewahre diese Mapping-Datei gut auf, denn das Aufräumen, das wir in unserem Salesforce-Datenmigrations-Leitfaden beschreiben, setzt voraus, dass Du genau weißt, welche alte ID welcher neuen entspricht.

Wie lädst und verifizierst Du das Record-Type-Update?

Führe das Update zuerst in einer Sandbox durch, um Abhängigkeiten zu erkennen, die beim Audit übersehen wurden – denn eine Änderung der RecordTypeId lässt sich nach dem Einspielen in die Produktivumgebung nicht mehr rückgängig machen. Salesforces eigene Support-Richtlinien empfehlen, vor einem vollständigen Batch-Lauf mit zwei oder drei Datensätzen zu testen, eben weil die Änderung über den Data Loader selbst nicht rückgängig gemacht werden kann.

Führe den gesamten Update-Prozess zunächst in einer Sandbox-Kopie der Produktionsdaten durch, bevor Du Live-Datensätze anfasst – und stelle sicher, dass keine abhängigen Automatisierungen fehlerhaft auslösen.

Deaktiviere alle Validierungsregeln, Trigger oder Flows, die das Speichern des RecordTypeId-Updates blockieren könnten.

Lade Deine Mapping-Datei hoch, wähle „Update“ für das Zielobjekt und ordne RecordTypeId Deiner neuen ID-Spalte zu.

Aktiviere Validierungsregeln, Trigger und Flows wieder, sobald das Update erfolgreich abgeschlossen ist.

Führe Stichproben migrierter Datensätze direkt in Salesforce durch, um sicherzustellen, dass der neue Record Type, das Layout und die Picklist-Werte korrekt dargestellt werden.

Best Practices im Change Management empfehlen, jeden Schritt vor dem Rollout zu dokumentieren und den Setup-Audit-Trail nach dem Deployment zu überwachen – denn eine Record-Type-Migration kann unbemerkt Berechtigungen oder Automatisierungen an anderer Stelle in der Org beeinflussen. Betrachte den Sandbox-Durchlauf als Generalprobe für den exakten Ablauf in der Production, nicht als grobe Annäherung; genau in den Abweichungen zwischen Sandbox und Production scheitern Migrationen am häufigsten.

Was solltest Du nach Abschluss der Migration bereinigen?

Aktualisiere jede hartcodierte Referenz, die während des Phase-1-Audits markiert wurde, sodass sie auf den neuen Record Type statt auf den alten verweist. Sobald kein aktiver oder historischer Datensatz mehr vom alten Record Type abhängt, deaktiviere oder lösche ihn – Salesforce erlaubt kein Löschen, solange noch Datensätze darauf verweisen. Behalte die Mapping-Datei und einen vollständigen Datenexport von vor der Migration. Da die Änderung der RecordTypeId irreversibel ist, ist dieses Backup Dein einziger Rettungsanker, falls im Nachhinein ein Mapping-Fehler auftritt. Teams, die bereits Salesforce-Lizenzen und Queues bereinigt haben, kennen das Muster: Betrachte das Aufräumen als Teil der Migration selbst, nicht als optionale Nacharbeit.

Häufig gestellte Fragen

Lässt sich eine Salesforce Record-Type-Migration rückgängig machen, sobald sie durchgelaufen ist?

Nein. Das Aktualisieren von RecordTypeId über den Data Loader ist nicht umkehrbar, und Salesforce empfiehlt selbst, vor dem vollständigen Batch-Lauf zunächst mit zwei oder drei Datensätzen zu testen. Tritt danach ein Mapping-Fehler auf, bleibt als einziger Rettungsweg nur das Zurückspielen über einen Datenexport von vor der Migration. Genau deshalb ist der Export der aktuellen RecordTypeId-Werte vor dem Start ein zwingender Schritt und keine optionale Vorsichtsmaßnahme.

Was ist RecordType.DeveloperName und warum sollte man ihn statt einer hartcodierten ID nutzen?

RecordType.DeveloperName ist eine stabile Referenz auf einen Record Type über seinen Namen – statt über seine 15- oder 18-stellige ID, die sich zwischen Sandboxes und Produktivumgebungen unterscheidet. Hardcodierte IDs brechen ab dem Moment, in dem Du in eine andere Umgebung deployst oder den Record Type selbst migrierst. Validierungsregel-Formeln und Apex, die DeveloperName statt einer fixen ID referenzieren, überstehen beide Szenarien ohne jede Anpassung.

Mit wie vielen Datensätzen solltest Du testen, bevor Du ein vollständiges Data-Loader-Update durchführst?

Laut offiziellem Salesforce-Support empfiehlt sich ein Test mit zwei bis drei Datensätzen, da die RecordTypeId-Änderung nach dem Speichern nicht rückgängig gemacht werden kann. Verifiziere, dass sich dieser kleine Batch korrekt verhält, prüfe, ob abhängige Automatisierungen wie erwartet auslösen, und starte erst danach den vollständigen Produktionslauf. Wer diesen Schritt überspringt, verwandelt eine Migration im Handumdrehen in ein Datenrettungsprojekt.

Wie viele Record Types kann ein einzelnes Salesforce-Objekt haben?

Salesforce empfiehlt maximal 200 Record Types pro Objekt, auch wenn die Plattform hier kein striktes technisches Limit vorgibt. Die meisten Migrationen bieten eine hervorragende Gelegenheit, überlappende ältere Record Types zu einem kleineren, sauberen Set zu konsolidieren, anstatt sie 1:1 zu übernehmen – so bleibt das Objekt auch künftig deutlich wartungsfreundlicher.

Kannst Du die RecordTypeId eines Datensatzes auf Master aktualisieren oder sie null lassen?

Nein. Salesforce erlaubt es im Data Loader nicht, RecordTypeId auf Master oder einen Null-Wert zu setzen. Das Ziel muss ein aktiver, korrekt konfigurierter Record Type sein. Stelle sicher, dass der neue Record Type vollständig eingerichtet ist – inklusive Page Layout und Sales Process Assignment –, bevor Du das Bulk-Update startest, andernfalls schlägt der Load fehl.

Brauchst Du eine Sandbox für eine kleine Record-Type-Migration?

Ja, selbst bei einer Handvoll Datensätzen. Sandbox-Tests existieren genau dafür: um Abhängigkeiten und Automatisierungsprobleme abzufangen, bevor sie ins Produktivsystem gelangen. Sie bei einer so folgenreichen, unumkehrbaren Änderung wie einer Record-Type-Migration auszulassen, ist genau das Szenario, vor dem Best Practices für Sandbox-Testing am eindringlichsten warnen – völlig unabhängig davon, wie wenige Datensätze betroffen sind.