Daten und Konfiguration in der Salesforce-Pipeline

Daten und Konfiguration, die keine Metadaten sind, fallen in vielen Salesforce-Pipelines durch: Planungsrichtlinien und Arbeitsregeln in Field Service, Betriebszeiten, Custom-Settings-Datensätze, Produkte und Preisbücher. Ein Metadaten-Deployment nimmt sie nicht mit, also stehen sie als manueller Schritt in einer Release-Tabelle. Meine Regel: Konfigurationsdaten liegen im Repository und laufen nach dem Metadaten-Deployment durch dieselbe Pipeline, mit SFDMU oder dem Datenmodul eines kommerziellen Werkzeugs. Stammdaten aus SAP kommen über die Schnittstelle, Testdaten als Seed-Datensatz. Kundendaten in Partial- und Full-Sandboxes werden nach jedem Refresh maskiert, zum Beispiel mit Data Mask & Seed von Salesforce.

Welche Daten gehören zur Konfiguration, und welche nicht?

Kapitel 6 hat beschrieben, wie Metadaten geprüft in Produktion kommen. Eine Salesforce-Org lebt aber auch von Datensätzen, die Verhalten steuern. Ich teile sie in vier Gruppen, weil jede Gruppe einen anderen Weg braucht:

Gruppe	Beispiele in der Fertigung	Quelle der Wahrheit	Weg in die Orgs
Konfigurationsdaten	Planungsrichtlinien, Arbeitsregeln, Serviceziele, Betriebszeiten, Custom-Settings-Werte, Zuordnungstabellen in eigenen Objekten	Repository	Pipeline, nach dem Metadaten-Deployment
Stammdaten	Produkte, Preisbücher, Materialnummern, Händlerstamm	SAP oder ein anderes führendes System	Schnittstelle in Produktion, Seed-Datensatz in Sandboxes
Testdaten	30 Händler, 200 Anlagen, Sonderfälle aus dem Service	Repository	Seed in Scratch Orgs und Developer-Sandboxes
Kundendaten	Fälle, Arbeitsaufträge, Verträge, Garantieanträge	Produktion	Kopie in Partial und Full, danach maskiert

Die Field-Service-Beispiele sind keine Theorie. Im Trailhead-Modul zu Planungsrichtlinien (öffnet in einem neuen Tab) legen Sie Arbeitsregeln über eine eigene Registerkarte an und wählen dabei einen Datensatztyp; die Richtlinie bündelt Arbeitsregeln und Serviceziele für die Planungs-Engine. Betriebszeiten sind laut Objektreferenz (öffnet in einem neuen Tab) das Objekt OperatingHours, das festlegt, wann ein Servicegebiet, eine Ressource oder ein Account für Arbeit verfügbar ist. Ändert jemand in der Integrationssandbox eine Arbeitsregel, damit Techniker nur Anlagen mit passender Qualifikation bekommen, ist das ein Datensatz. Kein Metadaten-Deployment trägt ihn weiter.

Die wichtigste Grenze verläuft zwischen Konfigurations- und Stammdaten. Ein Preisbuch ist laut Objektreferenz (öffnet in einem neuen Tab) die Liste der Produkte, die eine Org verkauft. Kommt diese Liste bei Ihnen aus SAP, wäre ein Deployment aus der Sandbox in die Produktion ein zweiter, konkurrierender Weg. Ich lasse Stammdaten deshalb nie durch die Release-Pipeline in die Produktion laufen.

Custom Metadata Types, Custom Settings und die Grenze zum Deployment

Für neue Konfiguration gibt es eine einfache Entscheidung, die viel Datenarbeit spart. Trailhead beschreibt den Unterschied im Modul zu Custom Metadata Types (öffnet in einem neuen Tab) deutlich: Datensätze von Custom Metadata Types lassen sich paketieren und über Metadata API oder Change Sets deployen. Datensätze von Custom Settings lassen sich auf keinem dieser Wege deployen.

Für einen Hersteller heißt das:

• Custom Metadata Types für Konfiguration, die im Repository versioniert und mit dem Release ausgerollt wird: Zuordnung von Produktgruppen zu Service-Warteschlangen, Schwellenwerte für Garantieprüfungen, Endpunkt-Schalter für Schnittstellen. Sie laufen im normalen Pull Request mit Review. Bei Delta-Deployments mit Abhängigkeiten, laut Dokumentation (öffnet in einem neuen Tab) noch in Beta, nimmt sfdx-hardis alle Datensätze eines Custom Metadata Types mit, sobald einer davon geändert wurde.
• Custom Settings nur dort, wo es fachlich nötig ist, etwa für Werte pro Benutzer oder Profil. Ihre Datensätze brauchen dann einen Datenschritt in der Pipeline.
• Eigene Objekte und Standardobjekte als Konfiguration, etwa die Field-Service-Objekte oder Preisregeln in einem Konfigurator. Hier haben Sie keine Wahl, sie sind Daten.

Konfigurationsdaten laufen durch dieselbe Pipeline

Externe IDs statt Salesforce-IDs. Eine Arbeitsregel hat in jeder Org eine andere Salesforce-ID. Ein Datenschritt muss den Datensatz an einem fachlichen Schlüssel erkennen, sonst legt er beim zweiten Lauf Dubletten an. Ich gebe jedem Konfigurationsobjekt ein Feld als externe ID, etwa einen sprechenden Code wie WR_SKILL_HYDRAULIK.

Die Daten liegen im Repository. Dann gilt für sie, was für Code gilt: Pull Request, Review, Historie. Ein geänderter Schwellenwert ist im Diff sichtbar, und niemand muss raten, wer ihn wann geändert hat.

Erst Metadaten, dann Daten. Ein Datensatz kann erst geladen werden, wenn das Feld existiert, in das er schreibt. Der Datenschritt läuft deshalb nach dem Metadaten-Deployment und nur, wenn dieses erfolgreich war.

SFDMU und sfdx-hardis

SFDMU (öffnet in einem neuen Tab) ist ein Open-Source-Plugin der Salesforce CLI für Datenmigrationen, laut npm-Eintrag (öffnet in einem neuen Tab) unter BSD-3-Lizenz. Es kopiert Datensätze direkt von Org zu Org oder aus CSV-Dateien, beherrscht Insert, Upsert, Update und Delete, verarbeitet mehrere verknüpfte Objekte in einem Lauf und wird über eine einzige Datei export.json konfiguriert. Dazu kommen Feldzuordnungen, Anonymisierung und zusammengesetzte externe ID-Schlüssel. Die Verarbeitung läuft lokal oder auf dem Pipeline-Runner, ohne Cloud-Dienst dazwischen.

sfdx-hardis bindet SFDMU über Deployment Actions (öffnet in einem neuen Tab) ein. Wie Deployment Actions in den Pull-Request-Fluss passen, steht in Kapitel 5. Im kostenlosen sfdx-hardis-Training gehören Deployment Actions für Referenzdaten zu Level 2; meine Eindrücke stehen in was ich aus dem sfdx-hardis-Training mitgenommen habe, eine Einführung in sfdx-hardis: Open-Source-DevOps erklärt.

Für Entwickler

Wie laufen Deployment Actions vom Typ data?

Eine Aktion vom Typ data lädt Datensätze aus einem SFDMU-Arbeitsbereich des Projekts in die Ziel-Org. Die Aktionen stehen in config/.sfdx-hardis.yml oder in einer Datei pro Pull Request und laufen standardmäßig einmal pro Org.

Nach einem fehlgeschlagenen Metadaten-Deployment werden sie nicht ausgeführt. Eine gescheiterte Aktion läuft beim nächsten Deployment mit demselben Pull Request erneut.

Für kleine Seed-Datensätze reicht oft die Salesforce CLI selbst. Salesforce empfiehlt die data-tree-Befehle (öffnet in einem neuen Tab) für kleine Mengen, etwa unter 3.000 Datensätzen, und die data-bulk-Befehle für große Volumen.

Was leisten Gearset, Copado und Flosum bei Daten?

Die kommerziellen Plattformen haben eigene Datenmodule mit Oberfläche. Laut Dokumentation der Anbieter:

Werkzeug	Was es bei Daten kann	Zu beachten
Gearset Data Deployments (öffnet in einem neuen Tab)	Abhängigkeiten über bis zu 15 Ebenen, Abgleich über externe ID, Maskierung mit Ersatzwerten, Flows, Trigger und Validierungsregeln vorübergehend abschaltbar, Vorlagen (öffnet in einem neuen Tab), CPQ- und Vlocity-Konfiguration (öffnet in einem neuen Tab)	Teil des Add-ons „Sandbox seeding & compliance“, nicht in der Deployment-Lizenz; laut Gearset (öffnet in einem neuen Tab) kein Rollback, kein Löschen, Produktion standardmäßig gesperrt
Copado Data Deploy (öffnet in einem neuen Tab)	Datenvorlagen für Konfigurationsdatensätze mit komplexen Beziehungen, fertige Vorlagen aus der DevOps Exchange, Maskierung sensibler Werte	in Copado Essentials laut Dokumentation (öffnet in einem neuen Tab) eine Option von Essentials Plus mit Lizenz pro Benutzer
Flosum Data Migrator (öffnet in einem neuen Tab)	Vorlagen mit Objekten, Feldern und Filtern, Beziehungen bleiben erhalten, Maskierung, Trigger abschaltbar	Fehlerbericht pro Datensatz

Was diese Werkzeuge gut machen: Ein Admin sieht vor dem Lauf, welche verknüpften Datensätze mitgehen, und muss keine export.json schreiben. Für CPQ-Konfiguration mit vielen verschachtelten Objekten ist das ein echter Vorteil. Welches Werkzeug insgesamt zu Ihrem Programm passt, entscheidet Kapitel 4; für Daten gilt dieselbe Regel wie für Metadaten. Das Werkzeug läuft auf Ihren Namen, und die Datenvorlagen liegen bei Ihnen, nicht im Konto eines Partners. Warum, steht in warum Kunden ihre DevOps-Tools selbst besitzen sollten.

Ein Punkt gilt für alle Werkzeuge:

Wie bleiben Kundendaten in Sandboxes geschützt?

Partial- und Full-Sandboxes enthalten nach jedem Refresh echte Kundendaten. Welche Umgebung welche Daten tragen darf, habe ich in Kapitel 3 festgelegt; welche Felder bei einem Hersteller heikel sind und was Coding-Agenten lesen dürfen, steht in Sandbox-Kundendaten: was KI-Coding-Agenten lesen dürfen.

Salesforce verkauft dafür Data Mask & Seed (öffnet in einem neuen Tab). Laut Trailhead ist Data Mask (öffnet in einem neuen Tab) ein Managed Package, das Sie in der Produktion installieren und das Daten in Full- und Partial-Sandboxes maskiert; die Produktion bleibt unverändert, und maskierte Daten lassen sich nicht zurückholen. Pro Feld wählen Sie laut Konfigurationsmodul (öffnet in einem neuen Tab) Zufallszeichen oder Zufallszahlen, einen Ersatz aus einer Bibliothek wie Namen oder Adressen, oder Löschen. Checkbox-, Lookup- und Picklist-Felder werden nicht unterstützt. Die Konfiguration kommt beim Refresh mit, den Lauf starten Sie in der Sandbox.

Der Seed-Teil füllt laut Produktseite Developer-, Developer-Pro-, Partial- und Full-Sandboxes mit Datensätzen, die Seed-Vorlagen filtern. Masken- und Seeding-Jobs lassen sich täglich, wöchentlich oder monatlich planen, und das Seeding umgeht Automatisierungen. Einen Preis nennt die Seite nicht. Gearset, Copado und Flosum maskieren beim Datentransport ebenfalls, und SFDMU kann anonymisieren. Der Unterschied: Data Mask bearbeitet eine vorhandene Sandbox-Kopie, die anderen maskieren Daten, die sie gerade bewegen.

Meine Reihenfolge nach jedem Refresh einer Partial- oder Full-Sandbox:

1. 01

   Maskierung starten

   Den Lauf starten und das Ausführungsprotokoll prüfen.

2. 02

   Neue Felder aufnehmen

   Felder, die seit dem letzten Lauf entstanden sind, in die Maskierung aufnehmen; diese Prüfung steht in der Release-Checkliste.

3. 03

   E-Mail-Felder maskieren

   E-Mail-Felder in Kontakten auf die Maskierungsliste setzen, damit kein Händler eine Testbenachrichtigung bekommt.

4. 04

   Konfiguration einspielen

   Konfigurationsdaten aus dem Repository laden, falls die Sandbox einen neueren Stand braucht als die Produktion.

5. 05

   Zugänge freigeben

   Erst danach Zugänge für Partner und Fachbereich freigeben.

Für Coding-Agenten gilt eine strengere Regel, die Kapitel 8 der KI-Masterclass beschreibt: Sie arbeiten in Scratch Orgs und Developer-Sandboxes mit Seed-Daten, nie in einer Full Copy.

Rechenbeispiel: Field Service für den Wartungsservice

Nehmen wir einen Maschinenbauer, der Field Service für Wartung und Reparatur beim Kunden einführt. Zwei Partner arbeiten auf derselben Org, SAP liefert Produkte, Materialnummern und Preise. Alle Zahlen sind Annahmen.

Ohne Datenschritt in der Pipeline sieht der Go-live so aus: Die Metadaten laufen sauber durch, dann pflegt ein Berater zwei Tage lang 6 Planungsrichtlinien, 25 Arbeitsregeln, 40 Betriebszeiten und 15 Servicegebiete von Hand in der Produktion nach, mit einer Tabelle aus der UAT-Sandbox als Vorlage. Drei Regeln stimmen danach nicht mit dem getesteten Stand überein, was erst auffällt, als Techniker Aufträge außerhalb ihres Gebiets bekommen.

Mit Datenschritt sieht derselbe Go-live anders aus:

• Jedes Konfigurationsobjekt hat ein Feld als externe ID, die Datensätze liegen als SFDMU-Arbeitsbereich im Repository des Herstellers.
• Änderungen an Arbeitsregeln laufen als Pull Request mit Review durch den Service-Prozessverantwortlichen.
• Nach dem Metadaten-Deployment lädt eine Deployment Action die Konfiguration in Integration, UAT, Staging und Produktion, jedes Mal mit demselben Stand.
• Produkte und Preisbücher kommen in der Produktion aus SAP; Sandboxes bekommen einen Seed-Datensatz mit 300 Teilen und zwei Preisbüchern.
• Die UAT-Sandbox als Partial Copy wird nach jedem Refresh maskiert, bevor der Partner Zugang bekommt.

Wäre das Programm auf Gearset, Copado oder Flosum, sähe die Struktur gleich aus, nur mit einer Datenvorlage statt export.json. Entscheidend ist, dass kein manueller Datenschritt mehr im Release-Plan steht.

Diese Regeln gehören in den Partnervertrag

In jeden Vertrag würde ich schreiben:

1. Konfigurationsdaten werden nie direkt in einer Stufen-Org gepflegt, nur im Repository.
2. Jedes Konfigurationsobjekt hat eine externe ID.
3. Neue Konfiguration entsteht als Custom Metadata Type, wenn kein fachlicher Grund dagegen spricht.
4. Stammdaten aus SAP laufen nie durch die Release-Pipeline in die Produktion.
5. Kein Partner bekommt Zugang zu einer Sandbox, bevor die Maskierung nach dem Refresh gelaufen ist.

Wann Sie Datenschritte im Release-Kalender einplanen und wie die drei Salesforce-Releases pro Jahr hineinspielen, behandelt Kapitel 8. Datenschritte und Sandbox-Stufen gehören zu meiner Arbeit in DevOps und Release-Management.