Una automatización puede llegar a un punto en el que no deba avanzar sin una decisión, un dato o una comprobación. Por ejemplo, puede necesitar aprobación antes de confirmar una operación sensible o esperar información que solo una persona puede aportar. En esos casos, el sistema debe conservar un estado recuperable y explicar qué falta, no limitarse a detener la ejecución actual.
Diseñar cómo pausar y reanudar una automatización en PHP implica separar el estado del proceso de la ejecución del trabajo. La pausa debe ser intencionada, persistente y auditable; la reanudación debe comprobar que el proceso sigue siendo válido y que los efectos ya aplicados no se repiten. Esto es distinto de diseñar una cola de revisión: aquí el foco es el ciclo de vida del flujo y su continuación segura.
Distingue una pausa de una espera o un fallo
No todo proceso que no avanza está pausado. Una llamada a una API que todavía no ha respondido es una espera externa. Un error de red puede justificar un reintento. Una excepción no recuperable puede terminar el proceso como fallido. Una pausa deliberada, en cambio, significa que el flujo ha llegado a un límite conocido y requiere una condición explícita para continuar o terminar.
Usar un estado distinto para cada situación evita decisiones operativas equivocadas. Reintentar una acción que espera aprobación puede repetir una petición innecesaria; tratar como fallo una pausa legítima puede activar alertas o políticas de recuperación que no corresponden. Define, como mínimo, estados separados para ejecución, espera externa, intervención requerida, completado, cancelado y fallido. Añade expiración si el negocio necesita que una pausa deje de ser válida después de un plazo.
Antes de incorporar una pausa, concreta qué la provoca y quién puede resolverla. Una tarea pendiente que se completa automáticamente cuando llega una respuesta no siempre necesita intervención humana. Sí puede requerirla una decisión con impacto económico, legal, de acceso o de seguridad. La distinción determina quién puede actuar, qué evidencia guardar y qué ocurre si nadie responde.
Persiste estado y punto de continuación
El proceso debe sobrevivir al fin de la petición PHP, al reinicio de un trabajador y a una nueva versión del servicio. Guarda en almacenamiento persistente un identificador estable, el estado actual, el paso alcanzado, el motivo de la pausa, las referencias a los datos necesarios y las marcas de tiempo relevantes. Registra también quién pausó o resolvió el proceso, cuando proceda, y la decisión tomada.
Evita guardar solo un mensaje como «esperando aprobación». No identifica qué ejecución está detenida, qué paso debe continuar ni si los datos han cambiado. En cambio, representa la pausa como parte del modelo del proceso, con un contexto suficiente para validar la reanudación. Conserva las referencias a información sensible siempre que sea posible, en lugar de duplicar datos sin necesidad; aplica controles de acceso y retención acordes con su naturaleza.
Define transiciones permitidas y compruébalas en el servidor. Por ejemplo, un proceso en estado de intervención requerida puede pasar a ejecución, cancelado o expirado; uno completado no debería volver a ejecución mediante una petición ordinaria. Una función PHP puede validar la transición, pero la regla debe quedar protegida también frente a concurrencia en la base de datos, no solo en la interfaz.
Separa el registro del proceso de la ejecución
Registrar que el proceso debe continuar y ejecutar sus pasos son operaciones relacionadas, pero no idénticas. Si se actualiza el estado y el proceso termina antes de iniciar el trabajo, el flujo puede quedar atascado. Si se inicia el trabajo antes de guardar la transición, una repetición puede ejecutar el mismo paso. Diseña la coordinación para que el estado persistente permita recuperar el trabajo pendiente.
Una opción común es guardar la transición y una instrucción de continuación en una misma transacción de base de datos, por ejemplo mediante un patrón de salida transaccional. Un trabajador separado lee esa instrucción y ejecuta el siguiente paso. La selección concreta depende de la arquitectura; lo importante es que el sistema pueda detectar trabajo no consumido y recuperarlo, en vez de confiar en que una petición web permanezca activa.
Los efectos externos requieren atención adicional. Una transacción local no puede deshacer por sí sola un correo enviado, un cargo confirmado o una llamada ya aceptada por otro servicio. Diseña cada paso con una clave de idempotencia cuando el destino lo permita, registra el resultado antes de avanzar y contempla reconciliación o compensación cuando una operación no pueda repetirse de forma segura. No marques un paso como completado antes de saber qué resultado tuvo.
Controla reanudar, cancelar y expirar
La acción de reanudar debe verificar el estado vigente, la identidad y los permisos de quien solicita la operación, y que se hayan satisfecho las condiciones necesarias. No basta con mostrar un botón a una persona autorizada: el servidor debe volver a validar todo al recibir la solicitud. Si la decisión requiere una justificación o un dato adicional, valida y conserva esa información como parte de la resolución.
Trata también la cancelación y la expiración como transiciones explícitas, no como eliminación del registro. Cancelar debe impedir nuevos pasos y dejar claro si existen efectos anteriores que no pueden revertirse. Expirar debe definir qué sucede después: terminar el proceso, solicitar una nueva intervención o derivar el caso a otra acción. El comportamiento depende de la regla de negocio y debe ser visible para operaciones.
Las solicitudes repetidas y las carreras son normales: una persona puede hacer doble clic o dos actores pueden actuar casi a la vez. Utiliza una actualización condicional, un bloqueo o un control de versión para que solo una transición válida gane. Una segunda solicitud debe recibir un resultado coherente con el estado actual, sin volver a ejecutar los efectos. Guarda un identificador de operación o una clave de idempotencia para reconocer repeticiones.
Haz que la pausa sea comprensible y verificable
La vista operativa debe explicar por qué el proceso está detenido, qué paso queda pendiente, qué información falta, quién puede actuar y qué consecuencias tiene cada opción. Evita botones ambiguos o acciones que mezclen aprobar, corregir datos y continuar. Presenta solo la información necesaria para decidir, con acceso limitado según el rol. Un historial de transiciones permite distinguir una espera legítima de un proceso bloqueado o mal configurado.
Prueba el flujo con interrupciones antes y después de cada efecto externo. Verifica que un reinicio no pierda la pausa, que una reanudación repetida no duplique acciones y que una cancelación impida pasos posteriores. Incluye casos de datos modificados durante la detención, permisos revocados, expiración, respuestas tardías y dos solicitudes simultáneas. Comprueba también los registros y alertas: deben permitir localizar el proceso y entender el siguiente paso sin exponer secretos.
Lista de comprobación para decidir el comportamiento
- Esperar: existe una respuesta externa en curso y el sistema puede continuar automáticamente cuando llegue, con límites de tiempo y recuperación definidos.
- Pausar para intervención: hace falta una decisión o un dato humano explícito antes de ejecutar pasos posteriores.
- Reintentar: ha ocurrido un fallo transitorio y repetir el paso es seguro o está protegido mediante idempotencia.
- Terminar: no hay una continuación válida, o el proceso se completó, se canceló, expiró o falló de forma definitiva.
Antes de desplegar el flujo, confirma que cada transición está autorizada, que el estado persiste, que los efectos previos no se repiten y que el equipo sabe cómo resolver la pausa. Si no puedes responder qué se reanudará, con qué datos y bajo qué condiciones, el proceso todavía no tiene un punto de continuación seguro.
