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 :
Admettons que vous ayez une règle de validation pour le module Transactions qui indique :
<<Si la remise est > 20 %, émettre 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 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, malgré la règle de validation qui est censée déclencher une alerte pour toute valeur supérieure à 25 %.
Les moyens suivants pour la mise à jour du champ primeront sur la règle de validation.
| Moyens de mettre à jour des champs dans CRM | Détails de la mise à jour d'un champ |
| Importation | Mis à jour lors de l'importation de nouveaux leads ou de l'écrasement des enregistrements existants |
| Règles de workflow | Mis à jour à la suite des actions de workflow |
| Processus d'approbation | Mis à jour lors de l'approbation ou du rejet d'un enregistrement |
| Blueprint | Mis à 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 s'applique. |
| API | Mis à jour via la méthode API updateRecords |
| Mise à jour en masse | Un champ principal utilisé dans une règle de disposition ne sera pas disponible pour une mise à jour en masse. |
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.
Dans ce cas, Réduction est votre champ principal et les champs Régions deviennent des champs secondaires.
Même si le champ Réduction peut ne pas apparaître sur une mise à jour de masse, le champ Région est affiché. Si vous décidez de mettre à jour tous les champs 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 non acceptables 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.