Automatizar una operación no siempre significa ejecutarla sin intervención. Si una acción puede alterar datos importantes, aplicar una condición comercial, mover fondos o afectar a terceros, quizá deba esperar a que una persona la autorice. Un flujo de aprobación humana en automatizaciones PHP establece ese control sin convertir el proceso en una cadena informal de mensajes y decisiones difíciles de reconstruir.
La clave no es añadir un botón de «aprobar», sino definir qué se propone, quién puede decidir, sobre qué información, durante cuánto tiempo y qué ocurre después. El sistema debe poder explicar cada estado y evitar que una aprobación antigua o duplicada ejecute una acción distinta de la que se revisó.
Decidir cuándo pausar una operación
Una revisión posterior sirve para detectar problemas después de que la acción ocurra. Una aprobación previa, en cambio, detiene la ejecución hasta recibir una decisión. Conviene exigir autorización cuando el impacto potencial, la dificultad de revertir la acción o la incertidumbre exceden el nivel aceptado para la automatización.
Evalúa cada operación con preguntas concretas: ¿puede cambiar un dato difícil de recuperar?, ¿afecta a dinero, derechos, acceso o compromisos con clientes?, ¿existe una regla verificable que permita ejecutarla de forma autónoma?, ¿cuánto daño causaría un error y cuánto tiempo hay para responder? Una operación rutinaria, reversible y limitada podría ejecutarse automáticamente y quedar registrada para revisión. Una acción excepcional o de alto impacto puede requerir autorización antes de ejecutarse.
Evita aplicar el control humano a todo por defecto. Una cola saturada causa demoras y fomenta aprobaciones mecánicas. Define umbrales y excepciones, y mide pendientes, tiempos de espera, rechazos y expiraciones para identificar reglas que convenga ajustar. La decisión debe basarse en el riesgo real, no solo en que una operación sea técnicamente posible.
Definir qué se propone y qué puede autorizarse
La persona revisora necesita entender el efecto de la operación, no descifrar un objeto interno de PHP. Presenta el valor actual y el propuesto, el motivo, el origen de los datos, las consecuencias relevantes y cualquier limitación. Si la decisión depende de una regla, muestra la explicación necesaria para aplicarla. Oculta o protege los datos personales que no hagan falta.
Separa el comando de propuesta de la autorización. La propuesta describe la acción y sus parámetros; la autorización permite ejecutar esa propuesta concreta. No debe conceder permisos generales ni permitir que quien aprueba edite silenciosamente los parámetros. Si hacen falta cambios, la persona revisora puede solicitar una modificación; el sistema crea una propuesta actualizada que deberá pasar por las reglas de autorización correspondientes.
Aplica mínimo privilegio: restringe quién puede crear, autorizar, rechazar o cancelar propuestas, y comprueba esos permisos en el servidor en cada transición. Cuando el riesgo lo justifique, exige que quien propone no pueda autorizar su propia operación. Esa separación debe implementarse en la lógica de permisos, no depender únicamente de ocultar botones en la interfaz.
Modelar estados y transiciones explícitas
Representa el proceso como una máquina de estados. Un conjunto inicial útil puede incluir pending, approved, executing, rejected, changes_requested, expired, cancelled y executed. Una propuesta pendiente puede aprobarse, rechazarse, cancelarse o expirar; una aprobada puede pasar a ejecución solo si sigue vigente; una que se está ejecutando puede terminar como ejecutada o volver a un estado recuperable si se determina que no hubo efecto. Una propuesta ejecutada no puede volver a aprobarse.
Guarda el estado actual junto con un historial inmutable de decisiones y transiciones. Registra identificador de la propuesta, estado anterior y nuevo, actor, fecha y hora, motivo y referencia a la versión de los datos revisados. No sustituyas el historial al actualizar el registro: es necesario para auditar qué ocurrió y diagnosticar fallos.
En PHP, centraliza las transiciones en un servicio de dominio o componente equivalente. Evita que distintos controladores cambien directamente el estado con actualizaciones genéricas. Valida la transición y los permisos dentro de una transacción cuando corresponda, y rechaza acciones incompatibles con el estado actual. Esta estructura reduce errores de concurrencia y facilita probar las reglas sin depender de la interfaz.
Evitar aprobaciones obsoletas y ejecuciones duplicadas
Los datos pueden cambiar mientras una propuesta espera. Una persona no debe autorizar una condición que ya no coincide con la operación que se va a ejecutar. Guarda una versión, fecha de actualización o huella de los campos relevantes al crear la propuesta. Al aprobar, vuelve a comprobarla contra el estado vigente.
La comprobación al aprobar no basta: los datos aún pueden cambiar antes de aplicar la operación. Inmediatamente antes de ejecutar, vuelve a comparar la versión o huella vigente con la aprobada. Si difiere, detén el proceso, invalida la autorización para esa propuesta y solicita una nueva decisión sobre los datos actualizados. Según el riesgo, puedes mostrar las diferencias y exigir una confirmación explícita, pero no reutilizar automáticamente la aprobación anterior.
Una caducidad limita cuánto tiempo se considera válida la decisión. Al vencer, marca la propuesta como expirada y exige una nueva autorización para continuar. Cada reintento debe comprobar que la autorización sigue vigente; nunca reutilices una autorización vencida para reanudar o repetir la ejecución.
La aprobación debe referirse a una propuesta identificable y no ser una señal reutilizable. Para evitar que dos trabajadores concurrentes ejecuten la misma propuesta, reclama o bloquea atómicamente su transición de approved a executing: solo un trabajador puede obtenerla si la propuesta sigue aprobada y vigente. En esa protección local, comprueba también la idempotencia y registra el identificador único de operación antes de continuar. Esto evita duplicados dentro del sistema, pero una transacción de base de datos no garantiza por sí sola que una API externa aplique un efecto una sola vez.
Si la acción ocurre en otro servicio, usa una clave de idempotencia que ese servicio acepte y procese de manera idempotente, si está disponible. Registra el identificador de correlación, el intento y las respuestas. Si se pierde la respuesta o el resultado es desconocido, no repitas el efecto a ciegas: consulta el estado remoto por ese identificador o reconcilia el resultado con datos fiables. Si no se puede confirmar si el efecto ocurrió, detén nuevos intentos automáticos y deriva el caso a una persona operadora. Un fallo conocido antes de enviar la solicitud puede permitir reintentar, siempre que se vuelva a comprobar estado y autorización.
Si un trabajador falla y deja una propuesta en executing, no la marques automáticamente como ejecutada ni la reenvíes sin diagnóstico. Un proceso de recuperación debe determinar si el efecto ocurrió, usando el registro local y, cuando proceda, consultando el servicio remoto. Si confirma que no ocurrió, puede devolver la propuesta a un estado ejecutable solo tras validar de nuevo vigencia, datos y autorización; si el resultado sigue siendo desconocido, debe mantenerla bloqueada y escalarla.
Diseñar una cola operativa y una alternativa manual
La cola debe permitir encontrar pendientes por antigüedad, impacto, responsable y fecha de expiración, además de mostrar el contexto que sustenta la decisión. Explica por qué un caso está bloqueado y qué acción corresponde: esperar, solicitar cambios, cancelar o escalar. La interfaz también debe dejar claro qué ocurrirá al aprobar, no solo ofrecer botones de decisión.
Define una alternativa cuando falle una dependencia, como el servicio de notificaciones o una integración necesaria para ejecutar la acción. Se puede conservar la propuesta pendiente y proporcionar un procedimiento controlado para que una persona autorizada revise el caso en el sistema operativo disponible. La vía manual debe respetar las mismas comprobaciones, registrar actor y motivo, evitar la ejecución paralela y reconciliar el resultado al restablecerse la integración.
No conviertas una caída técnica en aprobación implícita. Si la identidad, los permisos o la información necesaria no pueden verificarse, el sistema debe fallar de forma segura: pausar, informar y escalar. Define quién puede desbloquear el proceso, cómo se documenta esa intervención y qué tareas deben revisarse al recuperar el servicio.
Probar el flujo y vigilar su funcionamiento
Prueba las reglas de dominio y los recorridos completos: aprobación, rechazo, solicitud de cambios, expiración, cancelación y reintentos. Añade pruebas de permisos para confirmar que una persona sin autorización no puede cambiar el estado, y de concurrencia para que dos decisiones simultáneas no produzcan dos ejecuciones.
Incluye casos en los que cambian los datos durante la espera o justo antes de ejecutar, la ejecución remota falla después de aceptar la solicitud y una respuesta se pierde aunque el efecto haya ocurrido. Comprueba que la reclamación atómica permite que solo un trabajador ejecute la propuesta, que los reintentos rechazan autorizaciones vencidas y que cada intervención manual deja un registro suficiente. En producción, vigila el volumen y la antigüedad de pendientes, las expiraciones, los errores de ejecución y los casos que requieren conciliación.
Un flujo bien diseñado mantiene la supervisión humana donde aporta control, sin dejar la seguridad a la memoria de los equipos. Estados explícitos, permisos separados, datos revisados vigentes, ejecución idempotente y una ruta clara ante fallos convierten una aprobación informal en un proceso verificable.
