Puntos que se deben tomar en cuenta durante la actualización de un campo utilizado en una regla de validación.
Las reglas de validación son eficaces durante la creación de un registro de manera manual. Sin embargo, cuando los campos utilizados en una regla de validación (ya sea principal o secundaria) se actualizan de otras maneras, como mediante la actualización del flujo de trabajo y las API, la actualización del campo tiene prioridad por sobre las reglas de validación.
Estos casos se explican con más ejemplos a continuación:
La actualización de un campo principal mediante una regla de validación
Ejemplo:
Existe una regla de validación para el módulo Acuerdos en la que se indica:
<<Si el descuento es > 20 %, emitir una alerta. "Lo sentimos. Este descuento no se puede aceptar".>>
Esta regla de validación funcionará cuando cree manualmente un acuerdo en CRM con un descuento superior al 20 %. Sin embargo, si el campo principal Descuento se actualiza de cualquiera de las siguientes formas, la actualización del campo anulará la regla de validación.
Es decir, si el campo de descuento se actualiza con un 25 % a través de una actualización de campo de flujo de trabajo, este flujo de trabajo tiene prioridad, por lo que el sistema aceptará el valor a pesar de la regla de validación que se supone que emite una alerta para los valores que superan el 25 %.
Las siguientes son las formas de actualización de campo que tendrán prioridad sobre la regla de validación.
| Medios de actualización de campo en CRM | Detalles de la actualización de campo |
| Importar | Actualizado durante la importación de nuevos clientes potenciales o la sobrescritura de registros existentes |
| Reglas de flujo de trabajo | Actualizado como consecuencia de la acción del flujo de trabajo |
| Proceso de aprobación | Actualizado durante la aprobación o el rechazo de un registro |
| Blueprint | Actualizado como resultado de la configuración después de la transición. Cuando crea una regla de validación, así como una validación de Blueprint para el mismo campo y, si las dos condiciones son diferentes, Blueprint anula la regla de validación. Es decir, siempre que el campo esté dentro de un proceso, la validación de Blueprint es aplicable. Cuando un registro haya salido de un proceso, la regla de validación es efectiva. |
| API | Actualizado a través del método updateRecords de API |
| Actualización masiva | El campo principal utilizado en una regla de diseño no estará disponible para la actualización masiva. |
La actualización de un campo secundario mediante una regla de validación
Esta es una nota importante. Cuando intente actualizar alguno de los campos secundarios utilizados en una regla de validación mediante flujos de trabajo, actualizaciones masivas, importaciones o API, CRM aceptará los valores del campo secundario, independientemente de las condiciones de la regla. Como resultado, sus datos pueden obtener valores inaceptables a pesar de la regla de validación.
Por ejemplo, si tiene una regla de validación para definir descuentos en función de la región.
- El descuento no puede ser superior al 20 % para EE. UU.
- El descuento no puede ser superior a un 25 % para Reino Unido
- El descuento no puede ser superior a un 15 % para India
En este caso, el descuento es su campo principal y las regiones se convierten en los campos secundarios.
A pesar de que exista la posibilidad de que el descuento ni siquiera aparezca en una actualización masiva, en Región sí lo hará. Si decide actualizar a todas las regiones a India, es posible que todos sus acuerdos terminen con diferentes descuentos para "India", a pesar de que la regla de validación prescribe las cosas de manera diferente, lo que implica que su módulo presente valores inaceptables.
CRM actualmente no restringe la actualización de campo de los campos secundarios utilizados en una regla de validación. Procure verificar que los campos se utilicen en una regla de validación antes de actualizarlos.
