So beheben Sie INVALID_ID_FIELD in Salesforce-Bereitstellungen

Eine an eine Lookup- oder DML-Operation übergebene Datensatz-ID ist fehlerhaft, hat die falsche Länge oder gehört zum falschen Objekt.

Tritt auf bei: DML zur Laufzeit und Lookup-Zuweisung, nicht beim Metadaten-Deployment

Was das bedeutet

INVALID_ID_FIELD bedeutet, dass die von Salesforce empfangene ID nicht zu einem gültigen Datensatz für das Feld aufgelöst werden kann, in das sie übergeben wurde. Das ist fast immer eine fest codierte oder falsch verarbeitete ID: die falsche Länge, die falsche Groß-/Kleinschreibung oder eine ID, die zu einem anderen Objekt gehört als vom Feld erwartet.

Jede Salesforce-Datensatz-ID trägt ein dreistelliges Schlüsselpräfix, das ihr Objekt identifiziert, 001 für Account, 003 für Contact, und so weiter, sodass dieser Fehler häufig auf eine ID des falschen Objekts zurückzuführen ist, die einem Lookup zugewiesen wird, der ein anderes erwartet.

Diagnose

Häufige Ursachen

15-stellige ID statt 18-stelliger

Eine aus einer Browser-URL kopierte Datensatz-ID ist die 15-stellige, groß-/kleinschreibungsempfindliche Version, und Schreibweise oder Kürzung haben sie unterwegs beschädigt.

Org-spezifische ID in der Ziel-Org wiederverwendet

Eine ID aus der Quell-Org wurde fest in Metadaten oder Testcode codiert, aber genau diese ID entspricht keinem Datensatz in der Ziel-Org.

Falscher Objekttyp für den Lookup

Das Schlüsselpräfix der ID gehört zu einem anderen Objekt, als das Lookup-Feld erwartet, zum Beispiel eine Contact-ID, die in ein Account-Feld übergeben wird.

Die Lösung

Immer die 18-stellige ID verwenden
Standardisieren Sie im Code auf die groß-/kleinschreibungsunabhängige 18-stellige Datensatz-ID und codieren Sie niemals eine 15-stellige fest ein.
Stattdessen über eine externe ID suchen
Ersetzen Sie fest codierte Datensatz-IDs durch eine Abfrage auf eine stabile externe ID oder ein eindeutiges Feld, damit sich die Referenz je Org korrekt auflöst.
Prüfen, ob der Objekttyp übereinstimmt
Vergleichen Sie das dreistellige Schlüsselpräfix der ID mit dem vom Feld erwarteten Objekt, bevor Sie sie übergeben.
```
Id anyId = '001XXXXXXXXXXXXXXX';
String prefix = String.valueOf(anyId).left(3);
System.debug(Schema.getGlobalDescribe().values());
```

In der Praxis

Wie Serpent das verhindert

Serpent AI löst Referenzen beim Verschieben von Änderungen zwischen Umgebungen über einen Business Key statt über die rohe Datensatz-ID auf, sodass diese Fehlerklasse ein Deployment erst gar nicht erreicht. Siehe die Bibliothek der Salesforce-Bereitstellungsfehler.

Metadaten und Daten in einem einzigen Deployment-Flow in Serpent

Prävention

Datensatz-ID-Variablen als Id typisieren, nicht als String

Verwenden Sie den Apex-Typ Id statt String für alles, was eine Datensatzkennung enthält, damit ein fehlerhafter oder falsch langer Wert bereits bei der Zuweisung fehlschlägt, nicht tief in einem DML-Aufruf.

Datensatz-IDs niemals aus einer Browser-URL in den Code kopieren

Fragen Sie den Datensatz über ein stabiles Feld ab, statt eine in einer URL beobachtete ID einzufügen, die leicht abgeschnitten oder falsch getippt wird.

Objekttyp bei dynamischen Lookups zum Zeitpunkt der Zuweisung validieren

Wenn das Zielobjekt eines Lookup-Felds dynamisch bestimmt wird, prüfen Sie das Schlüsselpräfix der eingehenden ID gegen das erwartete Objekt, bevor Sie zuweisen.

INVALID_ID_FIELD, erklärt

Wie unterscheide ich eine 18-stellige ID von einer 15-stelligen?

Die 18-stellige ID endet immer mit drei zusätzlichen, groß-/kleinschreibungsunabhängigen Zeichen nach den ursprünglichen 15. Wenn eine ID genau 15 Zeichen hat, gilt sie als unsicher zum Fest-Codieren.

Sind Schlüsselpräfixe in jeder Salesforce-Org gleich?

Präfixe für Standardobjekte wie 001 für Account sind org-übergreifend konsistent, aber Präfixe für benutzerdefinierte Objekte werden pro Org bei der Objekterstellung vergeben und unterscheiden sich zwischen Umgebungen.

Erfasst Id.valid() in Apex jeden von diesem Fehler abgedeckten Fall?

Es prüft, ob eine Zeichenfolge syntaktisch die Form einer gültigen ID hat, bestätigt aber nicht, dass der Datensatz tatsächlich existiert oder zum richtigen Objekt gehört; beide Prüfungen bleiben nötig.

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

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

Kostenlos starten Demo buchen