Points à noter lors de la mise à jour d'un champ utilisé dans une règle de validation.
Les règles de validation sont efficaces en cas de création manuelle d'un enregistrement. Toutefois, lorsque les champs utilisés dans une règle de validation (principaux ou secondaires) sont mis à jour par d'autres moyens, tels que la mise à jour de workflow et les API, la mise à jour du champ prime sur les règles de validation.
Ces cas sont expliqués avec des exemples supplémentaires ci-dessous :
Mise à jour d'un champ principal en utilisant une règle de validation
Exemple :
Admettons que vous avez une règle de validation pour le module Deals (Transactions) qui indique :
<<Si la remise est de> 20 %, lancer une alerte, « Désolé ! Cette réduction n'est pas acceptable. »>>
Cette règle de validation sera efficace uniquement lors de la création manuelle d'une transaction dans CRM avec une remise supérieure à 20 %. Cependant, si le champ principal Discount (Réduction) est mis à jour via l'un des moyens suivants, le champ mis à jour remplace la règle de validation.
En effet, si le champ de réduction est défini sur 25 % à la suite d'une mise à jour des champs de workflow, ce workflow prime. Par conséquent, la valeur sera acceptée par le système, même si la règle de validation est censée lancer une alerte pour toute valeur supérieure à 25 %.
Les modes suivants de mise à jour du champ primeront sur la règle de validation.
.
| Modes de mise à jour de champ dans CRM | Détails de la mise à jour d'un champ |
| Importer | Mise à jour lors de l'importation de nouveaux leads ou de l'écrasement des enregistrements existants |
| Règles de workflow | Mise à jour à la suite des actions de workflow |
| Processus d'approbation | Mise à jour lors de l'approbation ou du rejet d'un enregistrement |
| Blueprint | Mise à jour en tant que résultat des paramètres Après la transition. Lorsque vous créez une règle de validation, ainsi que la validation Blueprint du même champ, et si les deux conditions sont différentes, Blueprint remplace la règle de validation. C'est-à-dire que, tant que le champ se trouve dans un processus, la validation Blueprint est applicable. Lorsqu'un enregistrement sort d'un processus, la règle de validation est efficace. |
| API | Mis à jour via la méthode API updateRecords |
| Mise à jour de masse | Un champ principal utilisé dans une règle de disposition ne sera pas disponible pour une mise à jour en masse. |
Mise à jour d'un champ secondaire en utilisant une règle de validation
Ceci est une remarque importante. Lorsque vous tentez de mettre à jour les champs secondaires utilisés dans une règle de validation via les workflows, la mise à jour en masse, les API ou l'importation, CRM accepte les valeurs du champ secondaire quelles que soient les conditions dans la règle. Par conséquent, vos données peuvent rassembler des valeurs inacceptables malgré la règle de validation.
Par exemple, vous disposez d'une règle de validation afin de définir des réductions selon la région.
- La remise ne peut être supérieure à 20 % pour les États-Unis
- La remise ne peut être supérieure à 25 % pour le Royaume-Uni
- La remise ne peut être supérieure à 15 % pour l'Inde
Dans ce cas, Discount (Remise) est votre champ principal et les champs Regions (Régions) deviennent des champs secondaires.
Même si le champ Discount (Remise) peut ne pas apparaître sur une mise à jour massive, le champ Region (Région) est affiché. Si vous décidez de mettre à jour tous les champs Regions (Régions) et de les définir sur Inde, toutes vos transactions pourraient se retrouver avec des remises différentes pour « Inde », tandis que votre règle de validation prévoit les choses différemment ; vous obtiendrez ainsi des valeurs inacceptables dans votre module.
Pour le moment, CRM ne restreint pas la mise à jour des champs principaux et secondaires utilisés dans une règle de validation. Assurez-vous de vérifier si les champs sont utilisés dans une règle de validation avant de les mettre à jour.