Zo los je CANNOT_MODIFY_MANAGED_OBJECT op in Salesforce-deployments

Het deployment probeert een component te wijzigen die bij een geïnstalleerd managed package hoort, wat subscriber-orgs niet rechtstreeks kunnen aanpassen.

Verschijnt tijdens: validatie van metadata-deployment, voordat er DML wordt uitgevoerd

Wat het betekent

CANNOT_MODIFY_MANAGED_OBJECT betekent dat de deployment metadata probeert te wijzigen die eigendom is van een managed package, een veld, object of Apex-klasse die is geïnstalleerd vanuit de AppExchange of een intern managed package. Subscriber-orgs kunnen objecten van managed packages op specifieke, door het package gedefinieerde manieren uitbreiden, maar kunnen de eigen beschermde componenten van het package niet rechtstreeks bewerken.

De fout treedt op tijdens de deployment, voordat records worden aangeraakt, omdat de Metadata API het eigendom van componenten controleert als onderdeel van de validatie van het package dat je deployt.

Diagnose

Veelvoorkomende oorzaken

Change set bevat per ongeluk een managed package-component

Een veld of layout dat bij een geïnstalleerd package hoort, is samen met org-native metadata in het deploymentpakket terechtgekomen, vaak via een wildcard retrieve.

Poging om een attribuut te bewerken dat het package niet blootstelt

Het package markeert bepaalde attributen als beschermd, dus zelfs een op het oog toegestane wijziging, zoals het bewerken van een picklistwaarde, mislukt als het package dit niet toestaat.

Package-versieverschil tussen orgs

De bron- en doel-org hebben verschillende versies van hetzelfde managed package geïnstalleerd, en een component die in de ene versie beschermd is, is in de andere bewerkbaar.

De oplossing

Verwijder de managed component uit het deploymentpakket
Sluit alle metadata uit waarvan het namespace-voorvoegsel bij het geïnstalleerde package hoort, en deploy alleen org-native wijzigingen.
Gebruik in plaats daarvan de ondersteunde uitbreidingspunten van het package
Breid managed objects uit via custom fields, custom metadata of API's die de package-leverancier aanbiedt, in plaats van de eigen componenten van het package te bewerken.
Stem package-versies tussen orgs op elkaar af vóór het deployen
Upgrade of downgrade het managed package zodat de bron- en doel-org dezelfde versie draaien voordat je het opnieuw probeert.

In de praktijk

Hoe Serpent dit voorkomt

Serpent AI herkent managed package-componenten met een namespace bij het bepalen van de scope van een taak, zodat ze automatisch worden uitgesloten van een deploymentpakket in plaats van een mislukte release te veroorzaken. Bekijk de bibliotheek met Salesforce-deploymentfouten.

No-code CI/CD-pipelinebuilder in Serpent

Preventie

Gebruik nooit een wildcard retrieve tegen een org met veel packages

Beperk Metadata API-retrieves tot expliciete, org-native componentnamen, zodat een veld of layout met namespace nooit per ongeluk in je bron terechtkomt.

Houd geïnstalleerde package-versies per org bij

Houd bij welke managed package-versie elke omgeving draait, en controleer dit voordat je metadata promoot die package-aangrenzende componenten raakt.

Sluit namespace-voorvoegsels standaard uit van je package.xml

Configureer je deploymenttooling om elke component over te slaan waarvan de API-naam een bekend namespace-voorvoegsel van derden bevat, tenzij deze expliciet is toegevoegd.

Gerelateerde fouten

DUPLICATE_DEVELOPER_NAMENog een naamconflict dat optreedt wanneer packaged en org-native metadata elkaar overlappen.INVALID_TYPEEen gerelateerde blokkade tijdens het deployen wanneer metadata afhankelijk is van een functie of editie die de doel-org mist.

Veelgestelde vragen

CANNOT_MODIFY_MANAGED_OBJECT, uitgelegd

Kan ik ooit rechtstreeks velden van een managed package bewerken?

Alleen de velden en instellingen die de package-leverancier expliciet als bewerkbaar markeert in subscriber-orgs. Al het andere is by design beschermd, en de oplossing is bijna altijd om die component uit je deployment uit te sluiten in plaats van de wijziging te forceren.

Hoe herken ik een managed component ten opzichte van een org-native component?

De API-naam van een managed component draagt het namespace-voorvoegsel van het package, zoals packagename__FieldName__c, terwijl org-native custom metadata helemaal geen namespace-voorvoegsel heeft.

Lost het de-installeren en opnieuw installeren van het package dit op?

Nee, en het brengt risico op gegevensverlies met zich mee. De bescherming is by design; het opnieuw installeren van dezelfde package-versie verandert niets aan welke attributen bewerkbaar zijn.

Start gratis. Geen creditcard, geen installatie, geen verplichting.

Binnen 15 minuten ingesteld. Geen DevOps-aanwerving nodig.

Start gratis Boek een demo