Comment corriger INVALID_FIELD_FOR_INSERT_UPDATE dans les déploiements Salesforce

Le déploiement tente d'écrire dans un champ non modifiable, comme un champ de formule ou un champ que l'utilisateur exécutant l'opération ne peut pas modifier.

Se produit lors de : DML en compilation ou en exécution, le plus souvent dans un test Apex

Ce que cela signifie

INVALID_FIELD_FOR_INSERT_UPDATE signifie qu'une opération DML, généralement dans un test Apex, a tenté d'assigner une valeur à un champ qui ne peut pas être écrit directement. Cela se produit avec les champs de formule, les champs de synthèse (roll-up) et les champs système, ainsi que lorsque la sécurité au niveau du champ (Field-Level Security) rend un champ en lecture seule pour le profil qui exécute l'opération.

Pour les champs réellement non modifiables comme les formules, Apex détecte cela à la compilation si la syntaxe littérale SObject est utilisée ; pour les restrictions de sécurité au niveau du champ, cela n'apparaît qu'à l'exécution, car le même code peut réussir pour un profil et échouer pour un autre.

Diagnostic

Causes courantes

Écriture dans un champ de formule ou de synthèse (roll-up)

Le code de la factory de données de test assigne directement une valeur à un champ qui est en réalité calculé, ce qui fait que la plateforme rejette l'écriture.

La sécurité au niveau du champ rend le champ en lecture seule

Le profil ou l'ensemble d'autorisations qui exécute le déploiement n'a pas d'accès en modification sur le champ concerné.

Type de champ modifié en champ calculé

Un champ auparavant modifiable a été converti en champ de formule, mais le code qui y écrit directement n'a jamais été mis à jour.

La solution

Supprimer l'écriture directe
Supprimez la ligne de code de préparation de test qui assigne une valeur au champ de formule, de synthèse ou système.
Accorder l'accès en modification si le champ doit être modifiable
Mettez à jour la sécurité au niveau du champ sur le profil ou l'ensemble d'autorisations utilisé pour le déploiement si le champ doit réellement être modifiable.
Auditer les changements de type de champ
Après avoir converti un champ en formule, recherchez dans la base de code les écritures DML directes vers ce champ et supprimez-les.
```
grep -rn "Amount_Rollup__c\s*=" force-app/main/default/classes/
```

En pratique

Comment Serpent évite cela

Serpent AI signale les écarts de sécurité au niveau du champ entre les environnements dès la revue préalable, avant qu'ils ne deviennent un échec au moment de l'exécution. Consultez la bibliothèque des erreurs de déploiement Salesforce.

Métadonnées et données dans un seul flux de déploiement dans Serpent

Prévention

Rechercher dans la base de code avant de convertir un champ en formule

Recherchez dans Apex et Flow les écritures directes vers un champ avant de changer son type, et corrigez-les dans le même déploiement.

Synchroniser les factories de données de test avec les changements de sécurité au niveau du champ

Chaque fois que la FLS d'un champ change pour le profil de déploiement ou d'exécution des tests, vérifiez le code de préparation de test qui écrit dans ce champ.

Préférer des factories de test pilotées par le schéma à des listes de champs codées en dur

Construisez les données de test via une factory qui lit les champs modifiables à partir des résultats describe, afin qu'un changement de type de champ échoue tôt et bruyamment plutôt que silencieusement en production.

Erreurs associées

INVALID_FIELDUne erreur liée mais distincte : le nom du champ lui-même n'existe pas, plutôt que d'exister mais d'être non modifiable.MISSING_FIELDLa version spécifique aux vues de liste et aux rapports d'un champ que l'org cible ne trouve pas.

Questions fréquentes

INVALID_FIELD_FOR_INSERT_UPDATE, expliqué

Pourquoi cela ne s'est-il produit qu'après un déploiement récent ?

Vérifiez si un champ a récemment été converti en formule ou en synthèse (roll-up). Le code qui y écrivait directement échouera à partir de ce moment.

Cette erreur s'applique-t-elle aux champs système comme CreatedDate ?

Oui. Les champs gérés par le système comme CreatedDate, LastModifiedDate et Id ne peuvent pas être écrits directement via un DML ordinaire ; un petit nombre d'entre eux ne peut être défini que via des options d'API spéciales comme les champs d'audit inscriptibles, que la plupart des orgs n'activent pas.

'without sharing' ou 'with sharing' affecte-t-il cette erreur ?

Non. Les mots-clés de partage contrôlent la visibilité des enregistrements, pas la possibilité d'écrire au niveau du champ ; un champ de formule n'est pas modifiable, quel que soit le mode de partage de la classe Apex.

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