Comment corriger INSUFFICIENT_ACCESS_OR_READONLY dans les déploiements Salesforce

L'utilisateur exécutant le déploiement ou le chargement de données n'a pas la permission de créer, modifier ou supprimer l'objet ou le champ visé.

Survient pendant : un DML à l'exécution, dans les chargements de données, les appels API et les tests Apex

Ce que cela signifie

INSUFFICIENT_ACCESS_OR_READONLY signifie que le profil ou le permission set de l'utilisateur exécutant n'accorde pas le niveau d'accès requis par l'opération, le plus souvent la sécurité au niveau champ ou les permissions CRUD sur l'objet dans l'org cible. Cela diffère de INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY, qui concerne un enregistrement référencé plutôt que l'objet directement écrit.

C'est le cas de l'objet direct : l'enregistrement ou le champ visé par l'instruction DML est celui auquel l'utilisateur exécutant n'a pas accès, pas un enregistrement lié touché au passage.

Diagnostic

Causes courantes

Le profil de l'utilisateur d'intégration ou de déploiement manque de permission sur l'objet

Le profil de l'utilisateur API ou CI a un accès en lecture seule ou aucun accès à l'objet, souvent parce que sa portée a été volontairement restreinte pour la sécurité.

La sécurité au niveau champ masque le champ pour ce profil

La permission sur l'objet existe, mais un champ spécifique est réglé comme invisible ou en lecture seule pour le profil ou le permission set de l'utilisateur exécutant.

Le permission set n'a pas été déployé ni affecté dans l'org cible

Un permission set accordant l'accès requis existe dans le contrôle de source mais n'a pas été déployé et affecté à l'utilisateur de déploiement dans l'org cible.

La solution

Accordez les permissions objet et champ à l'utilisateur de déploiement
Mettez à jour le profil ou le permission set de l'utilisateur de déploiement ou d'intégration pour inclure les permissions CRUD sur l'objet et la sécurité au niveau champ requises.
Déployez et affectez les permission sets manquants
Incluez les métadonnées du permission set dans le déploiement et confirmez qu'il est affecté à l'utilisateur exécutant dans l'org cible, pas seulement dans la source.
```
sf org assign permset --name Integration_Data_Access --target-org myOrgAlias
```
Utilisez un utilisateur d'intégration dédié avec un permission set stable
Standardisez l'accès au déploiement et à l'API sur un utilisateur et un permission set conçus à cet effet, plutôt que sur le compte d'un admin individuel susceptible de changer.

En pratique

Comment Serpent évite cela

Serpent gère les permission sets qu'il attribue aux utilisateurs CI et d'intégration par org, si bien que les écarts d'accès entre environnements apparaissent comme un blocage de tâche plutôt que comme un pipeline en échec. Voir la bibliothèque des erreurs de déploiement Salesforce.

Traçabilité des approbations et des audits dans Serpent

Prévention

Déployez l'affectation du permission set en même temps que le permission set lui-même

Incluez les métadonnées PermissionSetAssignment dans le même déploiement qu'un nouveau permission set, afin que l'accès arrive réellement dans l'org cible, pas seulement la définition.

Vérifiez l'accès de l'utilisateur d'intégration à chaque nouveau champ

Ajoutez la revue de sécurité au niveau champ pour le permission set de l'utilisateur d'intégration permanent comme élément de checklist à chaque changement de schéma, pas comme une réflexion après coup.

Ne partagez jamais un identifiant admin personnel pour des intégrations planifiées

Les comptes personnels sont désactivés, la MFA change et les mots de passe sont réinitialisés ; un utilisateur d'intégration dédié avec un permission set géré évite ces trois modes de défaillance.

Erreurs associées

INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITYLe même problème de permissions sur un enregistrement lié touché indirectement, au lieu de l'objet directement écrit.INSUFFICIENT_ACCESSLa version plus large au niveau de l'API, couvrant aussi les échecs de portée OAuth et de restriction IP.

Questions fréquentes

INSUFFICIENT_ACCESS_OR_READONLY, expliqué

Pourquoi le même déploiement fonctionne-t-il pour un admin mais échoue pour l'utilisateur CI ?

L'utilisateur CI ou d'intégration a presque toujours un profil plus restreint et plus verrouillé qu'un admin. Comparez ses accès objet et champ à ce que le déploiement écrit réellement.

Un permission set l'emporte-t-il sur un réglage de profil plus restrictif ?

Pour les permissions objet et champ, oui ; un permission set peut accorder un accès supplémentaire au-delà du profil, mais il ne peut pas accorder plus que ce que la licence globale et les limites de fonctionnalités de l'org permettent.

READONLY dans le nom de l'erreur signifie-t-il que le champ est un champ de formule ?

Pas nécessairement. Cela signifie généralement que la sécurité au niveau champ de l'utilisateur est réglée en lecture seule sur un champ ordinaire modifiable, bien que cela puisse aussi s'appliquer à des champs réellement non modifiables comme les formules.

Démarrez gratuitement. Sans carte bancaire, sans installation, sans engagement.

Configuration en moins de 15 minutes. Aucun recrutement DevOps nécessaire.

Démarrer gratuitement Réservez une démo