DUPLICATE_DEVELOPER_NAME bei Salesforce-Deployments beheben

Zwei Metadatenkomponenten teilen sich denselben Developer Name, den Salesforce eindeutig verlangt.

Tritt auf bei: Metadaten-Deployment-Validierung, bevor DML ausgeführt wird

Was das bedeutet

DUPLICATE_DEVELOPER_NAME bedeutet, dass das Deployment versucht, eine Komponente, einen Record Type, ein Global Value Set oder ein Permission Set zu erstellen, dessen Developer Name in der Ziel-Org bereits existiert oder mit einer anderen Komponente im selben Deployment kollidiert. Developer Names müssen innerhalb ihres Namespace eindeutig sein, daher blockiert Salesforce das Deployment, statt einen Gewinner auszuwählen.

Das tritt am häufigsten bei Komponenten ohne objektspezifischen Namespace auf, wie Global Value Sets und Permission Sets, da Record Types und Custom Fields auf ihr übergeordnetes Objekt beschränkt sind und nur mit Geschwistern desselben Objekts kollidieren.

Diagnose

Häufige Ursachen

Kollision durch parallele Entwicklung
Zwei Entwickler haben unabhängig voneinander eine Komponente mit demselben Developer Name in separaten Branches oder Sandboxes erstellt.
Umbenannte Komponente hinterließ ein veraltetes Duplikat
Eine Komponente wurde in der Quelle umbenannt, aber der alte Developer Name existiert noch in der Ziel-Org, und das Deployment versucht, eine zweite hinzuzufügen.
Kopierte Metadaten nie umbenannt
Metadaten-XML wurde als Ausgangspunkt für eine neue Komponente dupliziert, und der Developer Name wurde vor dem Commit nie geändert.

Die Lösung

  1. Die neuere Komponente umbenennen
    Geben Sie der eingehenden Komponente einen eindeutigen Developer Name und aktualisieren Sie alle Metadaten, die per Name darauf verweisen.
  2. Das veraltete Duplikat löschen, falls überflüssig
    Wenn die vorhandene Komponente in der Ziel-Org wirklich nicht mehr benötigt wird, entfernen Sie sie vor dem erneuten Deployment.
  3. Namenskonventionen abstimmen
    Vereinbaren Sie im Team ein Namensmuster für Record Types, Value Sets und Permission Sets, um künftige Kollisionen zu vermeiden.
In der Praxis

Wie Serpent das verhindert

Serpent AI markiert überlappende Developer Names zwischen parallelen Tasks bereits beim Scoping, bevor zwei Arbeitszweige in einem Deployment aufeinandertreffen. Siehe die Bibliothek der Salesforce-Deploymentfehler.

No-Code-CI/CD-Pipeline-Builder in Serpent

Prävention

Developer Names nach Team oder Funktionsbereich präfixieren
Führen Sie eine Namenskonvention ein, etwa ein Team- oder Modul-Präfix, für Global Value Sets und Permission Sets, damit zwei parallel arbeitende Personen kaum denselben Namen wählen.
Aktuelle Metadaten abrufen, bevor eine neue Komponente erstellt wird
Synchronisieren Sie unmittelbar vor dem Hinzufügen eines Record Type oder Value Sets mit der Ziel-Org, damit ein dort bereits vorhandener Name zuerst lokal sichtbar wird.
Einen kopierten Developer Name niemals unbearbeitet lassen
Machen Sie das Umbenennen von Developer Name und Label zur allerersten Änderung, wenn Sie eine bestehende Metadatendatei als Vorlage duplizieren.
Häufige Fragen

DUPLICATE_DEVELOPER_NAME, beantwortet

Löst Salesforce eine Developer-Name-Kollision jemals automatisch auf?
Nein. Salesforce blockiert das Deployment immer, statt Komponenten stillschweigend umzubenennen oder zusammenzuführen, daher muss der Konflikt manuell gelöst werden.
Kann ich einen Developer Name umbenennen, nachdem die Komponente erstellt wurde?
Bei den meisten Metadatentypen nein; der Developer Name wird bei der Erstellung festgelegt und ist praktisch dauerhaft. Sie können meist das Label ändern, aber der zugrunde liegende Developer Name bleibt fest.
Müssen Developer Names in der gesamten Org eindeutig sein, oder nur pro Objekt?
Das hängt vom Metadatentyp ab. Record Types und Custom Fields sind auf ihr Objekt beschränkt, sodass derselbe Name auf zwei verschiedenen Objekten existieren kann; Global Value Sets und Permission Sets gelten org-weit und müssen überall eindeutig sein.

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

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

Neugierig auf schnelleres Shipping, bevor Sie einsteigen? Sprechen wir

Unverbindlich.