Las correspondencias de clientes dudosas necesitan un proceso claro

Si una integración no puede identificar con fiabilidad al cliente de una operación, ese caso debe seguir siendo tratable. Necesita un rol responsable, la información necesaria y un retorno controlado al procesamiento. Un registro de errores y la instrucción de reenviar más tarde no resuelven una identidad de negocio incierta.

Microsoft también contempla intervenciones manuales con un motivo de fallo trazable en procesos de varios pasos. Nuestro ejemplo espera antes de escribir en destino.

Un caso pendiente necesita un resultado visible

En este ejemplo completamente ficticio, la solicitud de proyecto R-28 debe crear un borrador de proyecto en el ERP. El cliente CRM C-508 no tiene una correspondencia confirmada. La persona responsable establece que debe usarse la cuenta de cliente ERP existente K-410. La tabla describe el flujo deseado.

Un nombre en una lista no debe determinar por sí solo la elección del cliente. El tratamiento debe mantener unidos motivo del caso, versión de origen revisada, correspondencia anterior, elegida y justificación de la decisión. Solo el rol autorizado puede acceder a estos casos.

La corrección debe considerar el estado actual

Los datos o permisos pueden cambiar entre visualización y confirmación. Antes de continuar, compruebe los permisos actuales y si la cuenta elegida todavía puede usarse. OWASP exige comprobar los permisos en cada petición. Una pantalla de edición ya abierta no sustituye esa comprobación.

Dos personas que trabajan a la vez tampoco deben guardar decisiones contradictorias sin que se detecte. Deben reconocerse al confirmar tanto los requisitos modificados como un caso ya resuelto. Si las condiciones dejan de cumplirse, la operación permanece pendiente de nueva aclaración.

Repetir no debe crear un segundo borrador

Todos los intentos quedan vinculados a la misma solicitud de proyecto. Además, el destino necesita protección: por ejemplo, una creación idempotente que no genere otro borrador al repetir lo mismo, o una referencia externa cuya unicidad se imponga en destino y permita consultar el resultado de forma fiable. El identificador de operación no evita por sí solo los duplicados.

Si falta la respuesta después de escribir, aclare primero el resultado de la operación existente. AWS advierte que un tiempo de espera agotado no excluye efectos ya producidos. Hasta aclararlo, un resultado desconocido no debe tratarse como fallo seguro ni sustituirse por una solicitud nueva arbitraria.

Limite la intervención manual a los casos necesarios

Una correspondencia inequívoca y verificada puede procesarse automáticamente. No todos los registros necesitan aprobación humana. Para los demás casos deben ser visibles el responsable, el tiempo de respuesta acordado y el escalado; una lista creciente sin responsable no resuelve el problema.

Nuestro ejemplo se detiene antes de crear el proyecto. Si ya se ha creado algo para el cliente equivocado, hace falta una corrección de negocio específica que tenga en cuenta los vínculos generados.

Fuentes

• Microsoft — Compensating Transaction pattern

• OWASP — Authorization Cheat Sheet

• AWS — Timeouts, retries, and backoff with jitter