So beheben Sie CANNOT_MODIFY_MANAGED_OBJECT in Salesforce-Deployments

Das Deployment versucht, eine Komponente zu ändern, die zu einem installierten Managed Package gehört, das Subscriber-Orgs nicht direkt bearbeiten können.

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

Was das bedeutet

CANNOT_MODIFY_MANAGED_OBJECT bedeutet, dass das Deployment versucht, Metadaten zu ändern, die einem Managed Package gehören, ein Feld, Objekt oder eine Apex-Klasse, die aus dem AppExchange oder einem internen Managed Package installiert wurde. Subscriber-Orgs können Objekte von Managed Packages auf bestimmte, vom Package definierte Weisen erweitern, können jedoch die geschützten Komponenten des Packages selbst nicht direkt bearbeiten.

Der Fehler tritt zur Deployment-Zeit auf, bevor Datensätze berührt werden, weil die Metadata API die Komponenten-Eigentümerschaft im Rahmen der Validierung des zu deployenden Packages prüft.

Diagnose

Häufige Ursachen

Change Set enthält versehentlich eine Managed-Package-Komponente

Ein Feld oder Layout, das zu einem installierten Package gehört, wurde zusammen mit org-nativen Metadaten in das Deployment-Paket gezogen, oft durch einen Wildcard-Retrieve.

Versuch, ein Attribut zu bearbeiten, das das Package nicht freigibt

Das Package markiert bestimmte Attribute als geschützt, sodass selbst eine scheinbar erlaubte Änderung, wie das Bearbeiten eines Picklist-Werts, fehlschlägt, wenn das Package dies nicht zulässt.

Package-Versionsunterschied zwischen Orgs

Die Quell- und Ziel-Org haben unterschiedliche Versionen desselben Managed Packages installiert, und eine in einer Version geschützte Komponente ist in einer anderen bearbeitbar.

Die Lösung

Entfernen Sie die Managed-Komponente aus dem Deployment-Paket
Schließen Sie alle Metadaten aus, deren Namespace-Präfix zum installierten Package gehört, und deployen Sie nur org-native Änderungen.
Nutzen Sie stattdessen die unterstützten Erweiterungspunkte des Packages
Erweitern Sie Managed Objects über benutzerdefinierte Felder, benutzerdefinierte Metadaten oder vom Package-Anbieter bereitgestellte APIs, statt die eigenen Komponenten des Packages zu bearbeiten.
Package-Versionen zwischen Orgs vor dem Deployment angleichen
Aktualisieren oder downgraden Sie das Managed Package, damit Quell- und Ziel-Org dieselbe Version verwenden, bevor Sie es erneut versuchen.

In der Praxis

Wie Serpent das verhindert

Serpent AI erkennt Managed-Package-Komponenten mit Namespace beim Festlegen des Aufgabenumfangs, sodass sie automatisch aus einem Deployment-Paket ausgeschlossen werden, anstatt einen fehlgeschlagenen Release zu verursachen. Siehe die Bibliothek der Salesforce-Deployment-Fehler.

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

Prävention

Führen Sie niemals einen Wildcard-Retrieve gegen eine package-lastige Org aus

Beschränken Sie Metadata-API-Retrieves auf explizite, org-native Komponentennamen, damit ein Feld oder Layout mit Namespace nie versehentlich in Ihrer Quelle landet.

Verfolgen Sie installierte Package-Versionen pro Org

Führen Sie eine Aufzeichnung darüber, welche Managed-Package-Version jede Umgebung ausführt, und prüfen Sie diese, bevor Sie Metadaten befördern, die package-nahe Komponenten betreffen.

Schließen Sie Namespace-Präfixe standardmäßig aus Ihrer package.xml aus

Konfigurieren Sie Ihr Deployment-Tooling so, dass jede Komponente übersprungen wird, deren API-Name ein bekanntes Drittanbieter-Namespace-Präfix trägt, sofern nicht ausdrücklich hinzugefügt.

CANNOT_MODIFY_MANAGED_OBJECT, erklärt

Kann ich Felder eines Managed Packages jemals direkt bearbeiten?

Nur die Felder und Einstellungen, die der Package-Anbieter in Subscriber-Orgs ausdrücklich als bearbeitbar markiert. Alles andere ist absichtlich geschützt, und die Lösung besteht fast immer darin, diese Komponente von Ihrem Deployment auszuschließen, statt die Änderung zu erzwingen.

Wie unterscheide ich eine Managed-Komponente von einer org-nativen?

Der API-Name einer Managed-Komponente trägt das Namespace-Präfix des Packages, etwa packagename__FieldName__c, während org-native benutzerdefinierte Metadaten überhaupt kein Namespace-Präfix haben.

Behebt eine Deinstallation und Neuinstallation des Packages das Problem?

Nein, und es riskiert Datenverlust. Der Schutz ist beabsichtigt; eine Neuinstallation derselben Package-Version ändert nichts daran, welche Attribute bearbeitbar sind.

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

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

Kostenlos starten Demo buchen