Comment corriger CANNOT_MODIFY_MANAGED_OBJECT dans les déploiements Salesforce

Le déploiement tente de modifier un composant appartenant à un package géré installé, que les orgs abonnées ne peuvent pas modifier directement.

Apparaît pendant : la validation du déploiement des métadonnées, avant toute exécution de DML

Ce que cela signifie

CANNOT_MODIFY_MANAGED_OBJECT signifie que le déploiement tente de modifier des métadonnées appartenant à un package géré, un champ, un objet ou une classe Apex installé depuis l'AppExchange ou un package géré interne. Les orgs abonnées peuvent étendre les objets d'un package géré de manières spécifiques définies par le package, mais ne peuvent pas modifier directement les composants protégés du package lui-même.

L'erreur survient au moment du déploiement, avant qu'aucun enregistrement ne soit touché, car l'API Metadata vérifie la propriété des composants dans le cadre de la validation du package déployé.

Diagnostic

Causes courantes

Le change set inclut accidentellement un composant de package géré

Un champ ou une mise en page appartenant à un package installé a été inclus dans le package de déploiement aux côtés des métadonnées natives de l'org, souvent via un retrieve avec caractère générique.

Tentative de modification d'un attribut que le package n'expose pas

Le package marque certains attributs comme protégés, donc même une modification qui semble autorisée, comme modifier une valeur de liste de sélection, échoue si le package ne l'autorise pas.

Décalage de version du package entre les orgs

Les orgs source et cible ont des versions différentes du même package géré installé, et un composant protégé dans une version est modifiable dans une autre.

La solution

Retirez le composant géré du package de déploiement
Excluez toute métadonnée dont le préfixe de namespace appartient au package installé, et ne déployez que les changements natifs de l'org.
Utilisez plutôt les points d'extension pris en charge par le package
Étendez les objets gérés via des champs personnalisés, des métadonnées personnalisées ou des API exposées par l'éditeur du package, plutôt que de modifier les composants du package lui-même.
Alignez les versions du package entre les orgs avant de déployer
Mettez à niveau ou rétrogradez le package géré pour que les orgs source et cible utilisent la même version avant de réessayer.

En pratique

Comment Serpent évite cela

Serpent AI reconnaît les composants de package géré avec namespace lors du cadrage d'une tâche, afin qu'ils soient automatiquement exclus d'un package de déploiement au lieu de provoquer une release en échec. Consultez la bibliothèque des erreurs de déploiement Salesforce.

Constructeur de pipelines CI/CD no-code dans Serpent

Prévention

Ne faites jamais de retrieve avec un caractère générique sur une org riche en packages

Limitez les retrieves de l'API Metadata à des noms de composants explicites et natifs de l'org, afin qu'un champ ou une mise en page avec namespace n'atterrisse jamais accidentellement dans votre source.

Suivez les versions de package installées par org

Tenez un registre de la version du package géré exécutée par chaque environnement, et vérifiez-le avant de promouvoir des métadonnées touchant des composants proches du package.

Excluez par défaut les préfixes de namespace de votre package.xml

Configurez votre outillage de déploiement pour ignorer tout composant dont le nom d'API porte un préfixe de namespace tiers connu, sauf ajout explicite.

Erreurs associées

DUPLICATE_DEVELOPER_NAMEUn autre conflit de nommage qui survient lorsque des métadonnées packagées et natives de l'org se chevauchent.INVALID_TYPEUn blocage lié survenant au déploiement lorsque des métadonnées dépendent d'une fonctionnalité ou d'une édition absente de l'org cible.

Questions fréquentes

CANNOT_MODIFY_MANAGED_OBJECT, expliqué

Puis-je un jour modifier directement les champs d'un package géré ?

Seulement les champs et paramètres que l'éditeur du package marque explicitement comme modifiables dans les orgs abonnées. Tout le reste est protégé par conception, et la solution consiste presque toujours à exclure ce composant de votre déploiement plutôt qu'à forcer la modification.

Comment distinguer un composant géré d'un composant natif de l'org ?

Le nom d'API d'un composant géré porte le préfixe de namespace du package, comme packagename__FieldName__c, tandis que les métadonnées personnalisées natives de l'org n'ont aucun préfixe de namespace.

Désinstaller puis réinstaller le package résout-il le problème ?

Non, et cela risque une perte de données. La protection est intentionnelle ; réinstaller la même version du package ne change rien aux attributs modifiables.

Commencez gratuitement. Sans carte bancaire, sans installation, sans engagement.

Configuration en moins de 15 minutes. Aucune embauche DevOps nécessaire.

Commencer gratuitement Réserver une démo