Una persona aprueba una solicitud y el sistema ejecuta una operación sobre datos que han cambiado desde que los revisó. Existe un registro de aprobación, pero ya no está claro qué autorizó realmente.
Un flujo de aprobación necesita vincular decisión, versión y acción. El botón ‘Aprobar’ solo es comprensible cuando la persona sabe qué contenido está validando y qué ocurrirá después.
Define la acción que habilita la decisión
Distingue revisar datos, aceptar una propuesta y autorizar su ejecución. En algunos procesos coinciden; en otros pertenecen a roles diferentes. No sustituyas esa definición por una cadena de correos sin una condición de cierre.
La introducción a aprobaciones de Power Automate describe distintos patrones de respuesta, como esperar a todos o utilizar la primera respuesta. Elegir uno requiere conocer la regla del proceso: que la herramienta permita un comportamiento no significa que sea el adecuado para cada autorización.
Conserva en la solicitud la acción propuesta, el alcance y quién puede decidir. Si una persona solo puede revisar una unidad de negocio, esa restricción debe aplicarse a la operación, no limitarse a filtrar la lista que ve.
Presenta la evidencia que permite decidir
Incluye los valores relevantes, su procedencia y las diferencias respecto al estado anterior. Una referencia a un documento puede ser necesaria, pero obliga a comprobar que el aprobador tiene acceso y que está viendo la versión correcta.
Para un cambio ficticio de catálogo, muestra qué productos cambian, qué campos se modifican y cuándo se aplicarían. ‘Actualizar catálogo’ no permite evaluar el mismo alcance que una lista de modificaciones identificadas.
No sobrecargues la pantalla con datos que no intervienen en la decisión. El objetivo es que el aprobador pueda detectar una diferencia importante y entender su consecuencia.
Fija qué ocurre si cambia el contenido
Relaciona la aprobación con una versión de la solicitud. Cuando se modifique un campo que afecta a la decisión, invalida o reabre la aprobación según la regla acordada.
Distingue una corrección de presentación de un cambio sustantivo. Esa distinción debe estar definida por el proceso; no puede depender de que el sistema considere pequeño un cambio de texto o importe.
Antes de ejecutar, comprueba que la versión autorizada sigue siendo la que se utilizará. La revisión visual previa no protege frente a una modificación concurrente posterior.
Trata delegación y caducidad como estados explícitos
| Situación | Decisión de diseño necesaria |
|---|---|
| Aprobador ausente | Quién puede sustituirlo y dentro de qué alcance |
| Solicitud sin respuesta | Escalado, recordatorio o caducidad acordados |
| Cambio de rol | Comprobación del permiso antes de aceptar la respuesta |
| Respuesta después de caducar | Rechazo o reapertura explícita |
| Aprobaciones simultáneas | Una transición coherente con la regla del flujo |
| Rechazo con cambios solicitados | Nueva versión y relación con la decisión anterior |
No conviertas el silencio en aprobación salvo que esa sea una regla expresamente definida para el proceso. Un recordatorio enviado tampoco demuestra que alguien haya revisado el contenido.
Separa aprobación y resultado de ejecución
Después de aprobar, el destino puede rechazar la operación o devolver un resultado incierto. Conserva ambos hitos: decisión aceptada y efecto confirmado.
La recuperación debe respetar la misma versión autorizada y las garantías de idempotencia. Repetir una acción no debería ampliar el alcance de la aprobación ni ejecutarla dos veces inadvertidamente.
Si el fallo exige cambiar los datos, decide si requiere otra aprobación. La cola de excepciones debe presentar ese contexto al operador.
Prueba el flujo desde situaciones que generan dudas
Modifica la solicitud mientras está pendiente, cambia el rol del aprobador y envía dos respuestas casi simultáneas. Comprueba también una respuesta tardía y un fallo del destino después de aprobar.
En cada caso debe poder explicarse qué versión quedó autorizada, por quién, con qué alcance y qué efecto se confirmó.
Para diseñar aprobaciones dentro de una automatización, comparte con Nexeus Big Data las decisiones actuales y las modificaciones que hoy obligan a volver a revisar. Ese criterio permite construir un flujo cuyo historial conserve el significado de cada autorización.