FIELD_CUSTOM_VALIDATION_EXCEPTION bei Salesforce-Deployments beheben

Eine benutzerdefinierte Validation Rule in der Ziel-Org hat den Datensatz blockiert, und der Fehlertext ist die eigene Meldung der Regel.

Tritt auf bei: DML zur Laufzeit, meist innerhalb der Ausführung von Apex-Tests

Was das bedeutet

FIELD_CUSTOM_VALIDATION_EXCEPTION bedeutet, dass eine von Ihnen oder einem anderen Admin konfigurierte Validation Rule den zu speichernden Datensatz abgelehnt hat. Salesforce hängt die exakte Fehlermeldung der Validation Rule an die Exception an, sodass die Lösung meist direkt im Fehlertext sichtbar ist, sobald Sie wissen, welcher Datensatz und welche Regel dies ausgelöst haben.

Da Deployments in die Produktion Apex-Tests gegen die echten, aktiven Validation Rules der Produktion ausführen, ist dies einer der häufigsten Wege, wie eine Validation Rule, die in einer Sandbox unproblematisch war, eine Freigabe blockiert: In der Sandbox war diese Regel einfach nicht aktiviert.

Diagnose

Häufige Ursachen

Testdaten erfüllen die Regel nicht

Die Datenfactory eines Apex-Tests erstellt Datensätze, die gegen eine Validation Rule verstoßen, die in der Ziel-Org, aber nicht in der Quell-Sandbox aktiv ist.

Validation Rule inkonsistent zwischen Umgebungen

Der Aktivierungsstatus oder die Logik der Regel unterscheidet sich zwischen Umgebungen, weil eine Änderung nicht überall übernommen wurde.

Neue Regel kollidiert mit bestehenden Datenmustern

Eine im selben Deployment hinzugefügte Validation Rule kollidiert mit der Art, wie bestehende Automatisierung oder Tests Datensätze erstellen.

Die Lösung

Den eigenen Fehlertext der Regel lesen
Die Meldung nach dem Fehlercode nennt die genaue Bedingung, die fehlgeschlagen ist; beginnen Sie dort, statt zu raten.
Die Testdaten-Factory aktualisieren
Passen Sie das Apex-Test-Setup so an, dass generierte Datensätze der Bedingung der Validation Rule entsprechen.
Regelaktivierung über Orgs hinweg angleichen
Stellen Sie sicher, dass die Validation Rule in jeder vom Deployment betroffenen Umgebung konsistent aktiv (oder inaktiv) ist.

In der Praxis

Wie Serpent das verhindert

Serpent AI zeigt die exakte Validation-Rule-Meldung bereits beim Preflight an, bevor das eigentliche Deployment läuft, sodass Sie die Regel oder die Daten einmal beheben, statt zu raten. Siehe die Bibliothek der Salesforce-Deploymentfehler.

Metadaten und Daten in einem einzigen Deployment-Flow in Serpent

Prävention

Validation Rules mit derselben Strenge wie Apex deployen

Verfolgen Sie Änderungen an Validation Rules in der Versionsverwaltung und befördern Sie sie durch dieselbe Pipeline wie Code, statt sie ad hoc im Setup einer einzelnen Org zu bearbeiten.

Testdaten-Factories anhand der aktiven Regeln des Objekts aufbauen, nicht anhand von Stammeswissen

Überprüfen Sie beim Schreiben der Testdaten-Factory jede aktive Validation Rule eines Objekts, statt sich darauf zu verlassen, was in der Vergangenheit zufällig bestand.

Vor der Freigabe gegen eine produktionsähnliche Sandbox validieren

Führen Sie ein Check-only-Deployment gegen eine vollständige Sandbox mit den echten, aktiven Validation Rules der Produktion aus, damit eine Regellücke vor dem Freigabefenster auffällt, nicht währenddessen.

FIELD_CUSTOM_VALIDATION_EXCEPTION, beantwortet

Ist es sicher, die Validation Rule während des Deployments einfach zu deaktivieren?

Nur als letztes Mittel, und niemals in der Produktion. Die zugrunde liegenden Testdaten oder den Datensatz zu korrigieren ist sicherer, als eine Regel abzuschalten, die reale Daten schützt.

Kann eine Validation Rule bei einem im Seitenlayout nicht sichtbaren Feld auslösen?

Ja. Validation Rules werten die gespeicherten Feldwerte des Datensatzes unabhängig von der Sichtbarkeit im Seitenlayout aus, sodass ein verstecktes Feld ein Speichern trotzdem blockieren kann.

Warum besteht derselbe Test allein, schlägt aber in der vollständigen Suite fehl?

Wahrscheinlich hat ein früherer Test im Lauf einen gemeinsamen Zustand geändert, eine Custom Setting, einen Datensatz, den die Validation Rule prüft, gegen den die Daten des fehlschlagenden Tests nun verstoßen. Isolieren Sie den früheren Test, um dies zu bestätigen.

Kostenlos starten. Keine Kreditkarte, keine Installation, keine Verpflichtung.

In unter 15 Minuten eingerichtet. Keine DevOps-Einstellung nötig.

Kostenlos starten Demo buchen