La respuesta corta
Un proceso de aprobación sobre la entidad Quote, disparado al crear o actualizar y
acotado por un nodo de filtro normal, que es donde vive el umbral. Un total del
presupuesto con el operador More y un valor de 10000 es todo lo
que significa «solo por encima de 10K». El mismo mecanismo funciona con un porcentaje de
descuento o un campo de margen.
El control es recordLock, no una notificación. Dirija la aprobación a
SalesUnitManager en lugar de a personas con nombre, para que resista
los cambios de personal. Y revise expirationResult antes de ponerlo en
marcha: puede fijarse en Approve, lo que significa que una aprobación que nadie
responde se concede automáticamente.
El problema de negocio
Los comerciales hacen descuentos para cerrar. La mayoría de las veces eso es exactamente lo que usted quiere que hagan, y pedir permiso para cada pequeña concesión ralentizaría a todo el equipo sin ningún beneficio.
El problema está en la cola de la distribución. Unos pocos presupuestos cada trimestre llevan un descuento o un total que ningún superior habría aceptado, y se descubren a posteriori: al registrar el pedido, al facturar o cuando alguien ejecuta un informe de márgenes. Para entonces, el cliente ya tiene la cifra por escrito.
Lo que pidió el negocio:
- los presupuestos que superan un umbral de valor no pueden avanzar hasta que alguien los apruebe;
- todo lo que queda por debajo del umbral no se ve afectado en absoluto: ningún paso adicional, ninguna notificación, nada;
- el aprobador es quien gestione en ese momento la unidad de ventas a la que pertenece el presupuesto, sin mantener ninguna lista;
- un registro de auditoría que muestre quién aprobó qué y cuándo;
- y que el registro quede realmente retenido, no solo marcado.
Por qué falla el enfoque obvio
Se prueban cuatro cosas antes de que alguien recurra a un proceso de aprobación real, y todas fallan de la misma forma fundamental: registran una intención en lugar de impedir una acción.
Un campo obligatorio «aprobado por el responsable»
Autodeclarado y sin control. Quien quiere el descuento es quien marca la casilla, y nada
del registro cambia cuando lo hace. El resultado es un campo que siempre vale
true y no significa nada.
Una automatización que envía un correo al responsable
Es una notificación, no una barrera. En el momento en que sale el correo, el presupuesto ya está guardado, ya se puede imprimir y ya se puede enviar. Le dice lo que ha pasado; no impide que pase.
Una etapa del pipeline llamada «Approval»
Una convención, no un control. Las etapas las mueven los usuarios, y un usuario que necesita sacar un presupuesto la pasará de largo. Además, falsea los datos sin que se note: la etapa dice «aprobado» porque alguien arrastró una tarjeta.
Nombrar a los aprobadores uno a uno
Esta sí funciona, hasta la primera reorganización. Los aprobadores con nombre dejan de funcionar cuando alguien cambia de equipo, se ausenta o deja la empresa, y el modo de fallo es una cola de aprobaciones esperando a una persona que ya no existe. Además, la lista tiene que mantenerla para siempre quien recuerde que existe.
El requisito real son dos cosas a la vez: un bloqueo del registro mientras la decisión está pendiente y un enrutamiento dinámico que resuelva el aprobador a partir de la estructura de la organización en el momento en que se genera la aprobación. El proceso de aprobación de Coevera ofrece ambas cosas; nada más en la plataforma ofrece ninguna de las dos.
Configuración: tres llamadas, no una
Crear un proceso de aprobación no lo configura, y configurarlo no lo activa. Son tres operaciones distintas, y detenerse después de las dos primeras deja un proceso que parece estar ahí y no hace nada.
| Paso | Contiene |
|---|---|
| 1 · Crear | Solo name, description y ownerId. Ni disparador, ni filtro, ni aprobadores. |
| 2 · Configurar | Todo el esquema, como una cadena JSON: disparador, filtro, configuración y los nodos de decisión. |
| 3 · Activar | Una llamada aparte. Hasta que se ejecuta, no se dispara nada. |
El esquema, por partes
La carga útil de configuración tiene cuatro miembros de primer nivel.
trigger
Indica la entidad y el evento y, lo que resulta útil, quién puede dispararlo. Además del tipo de entidad y de un evento como crear o actualizar, el disparador lleva una opción de actor con listas de unidades y de usuarios. Si se deja en cualquier usuario, se aplica a todos; si se acota, permite poner una barrera a los presupuestos de un equipo sin tocar los de otro.
filter: donde vive el umbral
Es un nodo de filtro normal, la misma estructura que se usa en toda la automatización de
la plataforma. El ejemplo capturado se llama según lo que hace —sum over 10K— y
contiene una única regla: el campo de total del presupuesto, el operador
More y el valor 10000.
Dos consecuencias que vale la pena destacar. Por debajo del umbral no se crea ninguna aprobación: no es una aprobación que apruebe automáticamente las operaciones pequeñas, simplemente no se dispara. Y como es un nodo de filtro general, el umbral puede ser cualquier cosa por la que se pueda filtrar: un porcentaje de descuento, un campo de margen, una categoría de producto o varias condiciones combinadas.
Tenga en cuenta que un valor de filtro numérico sobre un campo monetario se almacena como una tupla que lleva el importe junto con una referencia a la moneda: en un campo multimoneda, un número a secas no lo es todo.
settings: quién decide y qué queda congelado
| Opción | Qué hace |
|---|---|
approvers | Una lista de entradas, cada una un usuario con nombre o un tipo de rol, como el responsable de la unidad de ventas. |
allApprove | Si todos los aprobadores deben estar de acuerdo o basta con uno cualquiera. |
canDelegate | Si un aprobador puede delegar la decisión en otra persona. |
recordLock | El mecanismo de control. Determina quién puede editar el registro mientras la decisión está pendiente. |
expiration / expirationDays / expirationResult | Si una aprobación pendiente vence, al cabo de cuánto tiempo y qué veredicto adopta al vencer. |
salesProcessDependency | Vincula la aprobación a la posición del registro en el proceso de ventas. |
Use un tipo de rol para el aprobador, no un id de usuario. Un aprobador de tipo responsable de la unidad de ventas se resuelve a partir de la unidad de ventas a la que está asignado el registro cuando se genera la aprobación. Sigue funcionando a través de reorganizaciones, bajas y vacaciones, y no necesita mantenimiento a medida que cambia la forma de la empresa. Los aprobadores con nombre son el motivo más habitual por el que un proceso de aprobación deja de funcionar sin que nadie lo note un año después de construirse.
approveNodes y rejectNodes
Dos arrays de nodos de automatización, que se ejecutan según la decisión correspondiente. Son los mismos tipos de nodo que se usan en la automatización normal, así que todo lo que puede hacer la automatización lo puede hacer una decisión: el ejemplo capturado usa un nodo de actualización de registro para mover la etapa del pipeline del presupuesto cuando se concede la aprobación.
Un detalle de forma que pilla desprevenida a la gente: en un nodo de actualización de
registro, la carga útil vive en el input de la entidad como una cadena JSON,
mientras que el array operations solo indica qué campos de su interior se
están escribiendo. Proporcionar operaciones con un input vacío produce un error genérico
que no ayuda.
Qué configurar realmente
Para el requisito del §1, la forma es:
| Opción | Valor | Por qué |
|---|---|---|
| Entidad / evento del disparador | Quote · crear o actualizar | Captura tanto un presupuesto creado por encima del umbral como uno editado después hasta alcanzarlo. |
| Actor del disparador | Cualquier usuario | Una gobernanza que exime a algunas personas no es gobernanza. |
| Filtro | Total · More · umbral | Por debajo, no se dispara nada. |
| Aprobadores | Responsable de la unidad de ventas (tipo de rol) | Resiste los cambios de personal y de organización sin mantenimiento. |
allApprove | false, para un único aprobador | Solo tiene sentido con más de un aprobador; fíjelo deliberadamente si añade un segundo. |
recordLock | Pueden editar los Approval Process Managers | Bloquea a quien lo creó y deja una vía de escalado. Consulte la salvedad del §6. |
expirationResult | Reject, no Approve | Consulte el §6: la alternativa concede sin avisar una aprobación que nadie dio. |
| Nodo de aprobación | Mover la etapa del pipeline | Hace visible la decisión en el registro, no solo en el historial de aprobaciones. |
| Nodo de rechazo | Mover la etapa y notificar | La vía de rechazo es la que más a menudo se deja vacía. Consulte el §6. |
Nombrar el filtro según su significado de negocio y no según su mecánica compensa más adelante: el nombre es lo que ve un administrador cuando intenta averiguar por qué un presupuesto está bloqueado.
Cómo hacer visible la decisión
El historial de aprobaciones registra quién decidió qué y cuándo, y eso satisface la auditoría. No satisface al equipo de ventas, que necesita ver el estado en el propio registro.
Para eso sirven los nodos de decisión. Al aprobarse, mueva el presupuesto a una etapa que se lea como aprobada; al rechazarse, muévalo a una que se lea como rechazada y avise al propietario. Si debe ejecutarse una automatización posterior (publicar un valor, crear una tarea, escribir de vuelta en un registro principal), el nodo de decisión puede disparar otro proceso en lugar de intentar hacerlo todo por sí mismo.
Si el Quote es un proxy que sustituye a algo que no puede alojar una aprobación por sí mismo, la escritura de vuelta es el objetivo mismo del diseño; ese patrón es el del Blueprint 001.
Límites y compromisos
La opción que convierte la gobernanza en teatro
expirationResult puede fijarse en aprobar. Con el vencimiento
activado y ese veredicto, una aprobación que nadie responde se concede
automáticamente cuando transcurre el plazo.
Esto es peor que no tener ningún proceso de aprobación. Genera un registro de auditoría que muestra una aprobación que ninguna persona dio nunca, y lo descubrirá quien haga la auditoría, no usted. Si llega a activar el vencimiento, el resultado debe ser rechazar, con el escalado gestionado por los nodos de rechazo. Compruebe este valor explícitamente en cada proceso de aprobación que herede.
El bloqueo no es una congelación
El bloqueo del registro tiene dos modos: el registro sigue siendo editable por los Approval Process Managers, o por los Approval Process Managers y los aprobadores. Es de solo lectura para todos los demás, y en ninguno de los dos modos queda congelado. Es sensato, porque deja una vía de escalado cuando algo urgente está atascado, pero significa que el registro no es inmutable mientras está pendiente. No lo describa ante un auditor como si lo fuera.
A qué no se puede asociar una aprobación
Las aprobaciones solo pueden tener como destino Account, Contact, Lead, Opportunity o Quote. Las entidades personalizadas no se admiten como destino de aprobaciones, y el propio registro de aprobación no admite campos personalizados, así que cualquier metadato de aprobación sobre el que necesite hacer informes tiene que vivir en el registro de destino. Ambas restricciones, y el patrón de proxy que las sortea, están en el Blueprint 001.
Fuente. Centro de ayuda de Coevera, Working with Approval Processes: las aprobaciones «pueden aplicarse a Accounts, Contacts, Leads, Opportunities y Quotes».
La vía de rechazo suele faltar
En todas las implementaciones que hemos revisado, la rama de aprobación estaba completa y la de rechazo estaba vacía o incompleta. El fallo es silencioso: un registro rechazado simplemente se queda donde estaba, sin ninguna señal para su propietario, y parece idéntico a uno que sigue esperando. Construya los nodos de rechazo al mismo tiempo que los de aprobación, o no los construirá nunca.
Otras cosas que conviene saber
- Creado no significa activado. Un proceso puede existir, estar completamente configurado, informar de que está sano y no dispararse nunca.
- La configuración es una cadena JSON dentro de la petición, lo que significa que no se valida contra el esquema como los argumentos normales. Se requieren marcadores de tipo en la raíz y en los nodos anidados, y una carga útil sin ellos se rechaza con un mensaje que no lo dice.
- Los valores de filtro monetarios llevan una referencia a la moneda junto al importe. Un umbral sobre un campo multimoneda no es solo un número.
- Aquí solo se ha verificado una configuración capturada. El comportamiento con varios aprobadores (el orden, la aprobación parcial, lo que hace una delegación con el registro de auditoría) debe probarse en su propio espacio antes de confiar en él.
Verificación
Un proceso de aprobación es un control. Un control que se cree que funciona y no funciona es el peor estado posible, así que el plan de pruebas importa aquí más que en la mayoría de las implementaciones.
- Confirme que se ejecutaron los tres pasos: creado, configurado y activado. Vuelva a leer el estado de activación en lugar de suponer que la llamada tuvo éxito.
- Pruebe por debajo del umbral. El comportamiento correcto es que no ocurra nada en absoluto: ningún registro de aprobación, ninguna notificación, ningún bloqueo. Una aprobación que se dispara y se aprueba automáticamente es otro diseño, y equivocado.
- Pruebe por encima del umbral y, por separado, pruebe a editar un presupuesto hasta que supere el umbral. El evento de crear o actualizar es lo que captura el segundo caso, y es el que la gente olvida probar.
- Verifique el bloqueo como quien crea el presupuesto, no como administrador. Inicie sesión como usuario de ventas e intente la edición. Los administradores a menudo no pueden reproducir el bloqueo en absoluto, y por eso se da por bueno cuando no funciona.
- Ejercite deliberadamente la vía del vencimiento. Fije un vencimiento corto en un espacio de pruebas, deje que transcurra y confirme que el veredicto que adopta es el que pretendía.
- Ejercite el rechazo, no solo la aprobación. Confirme que el registro se mueve y que el propietario se entera.
- Confirme que la resolución del aprobador sigue la unidad de ventas del registro. Asigne un presupuesto de prueba a otra unidad de ventas, genere la aprobación y compruebe que se dirige al responsable de esa unidad.
Qué indicaría una regresión: aprobaciones que aparecen en presupuestos por debajo del umbral; una aprobación pendiente cuya lista de aprobadores está vacía; registros por encima del umbral que llegan a un estado cerrado sin ninguna aprobación en su historial; o un historial de aprobaciones que muestra decisiones fechadas exactamente al cumplirse el intervalo de vencimiento, lo que significa que decide el plazo y no una persona.
Preguntas frecuentes
¿Cómo se exige aprobación para un presupuesto que supera un determinado importe o descuento?
En Coevera CRM, un proceso de aprobación sobre la entidad Quote incluye un nodo de filtro estándar, de modo que el umbral se expresa como una condición de campo normal: por ejemplo, el total del presupuesto con el operador More y un valor de 10000. Por debajo del umbral no ocurre nada y no se crea ninguna aprobación; por encima, la aprobación se genera automáticamente al crear o actualizar el registro. Como el filtro es un nodo de filtro normal, el mismo mecanismo funciona con un campo de porcentaje de descuento, un campo de margen o una combinación de condiciones.
¿Una aprobación del CRM impide realmente que se modifique el registro, o solo avisa a alguien?
Bloquea el registro. La configuración de la aprobación incluye un modo de bloqueo del registro, y ese es el mecanismo de control, no ninguna notificación. Hay dos modos: el registro sigue siendo editable por los Approval Process Managers, o por los Approval Process Managers y los aprobadores, y es de solo lectura para todos los demás. Ninguno de los dos modos es una congelación total, así que el bloqueo es un control sobre el usuario de ventas; conviene saberlo antes de describirlo como inmutable ante un auditor.
¿Pueden las aprobaciones dirigirse automáticamente a un responsable en lugar de nombrar aprobadores concretos?
Sí. Una entrada de aprobador puede indicar un tipo de rol en lugar de un id de usuario, por ejemplo el responsable de la unidad de ventas, que se resuelve a partir de la unidad de ventas a la que está asignado el registro en el momento en que se genera la aprobación. Es mucho preferible a nombrar a personas concretas, porque sigue funcionando cuando alguien cambia de equipo, se ausenta o deja la empresa, y no necesita reconfigurarse a medida que cambia la organización.
¿Qué ocurre si nadie responde a una aprobación pendiente?
Depende de la configuración del vencimiento, y conviene revisar con atención esa opción: el resultado del vencimiento puede fijarse en aprobar, lo que significa que una aprobación que nadie atiende se concede automáticamente cuando transcurre el plazo. Un control de gobernanza que aprueba sin avisar al vencer el plazo es peor que no tener control, porque genera un registro de auditoría que muestra una aprobación que ninguna persona dio. Fije deliberadamente el resultado del vencimiento.