La migración que solo cubrió el presente

Si vas a montar o a contratar un sistema para atender clientes, esta nota te avisa de un fallo que no se ve el día del estreno. Aparece más tarde, el día en que llega el primer cliente nuevo.

Detrás suele haber una migración: un cambio que se le aplica de una vez a los datos que ya están guardados. Se probó, funcionó y cubrió a todo el mundo que existía en ese momento. Solo que el mundo siguió creciendo y la migración no.

El nuestro fue así. Introdujimos bandejas por rol: un asesor de Ventas no tiene por qué leer las reclamaciones de Posventa. La regla nueva era estricta: sin asignación explícita, ninguna bandeja.

Una bandeja recién conectada es invisible para todo el equipo hasta que el dueño decide quién la atiende. Por defecto, cerrada. Nunca «visible para todos» justo cuando nadie ha decidido todavía de quién es.

Aplicar esa regla de golpe habría dejado a ciegas a todos los equipos de todos los negocios hasta que cada dueño entrara a repartir. Así que la migración sembró, para cada negocio que ya existía, todas las parejas de rol y bandeja que ya se daban. Lo que veían ayer, lo siguen viendo hoy. De ahí en adelante manda la regla estricta.

Eso cubrió a las conexiones que existían el día de la migración. Pero un negocio nuevo se da de alta, invita a su equipo y después conecta su WhatsApp. Su bandeja nace después de la migración. Nadie la siembra.

El resultado quedó escrito en un comentario del código. Los tres vendedores aceptan la invitación y entran. La lista les dice que no ha entrado ninguna conversación, mientras entran cien mensajes al día. El único que ve algo es el propietario, que es justo el que no atiende.

Una migración que arregla el presente y no deja nada previsto para el futuro no es una migración. Es una bomba con el reloj puesto en el primer cliente nuevo.

Dentro de la misma migración hubo un segundo error, cazado a tiempo. Hay roles de catálogo común, como «Asesor», que se comparten entre negocios. Esos roles llevan el identificador de negocio en nulo, que es la forma que tiene la base de datos de decir que ahí no hay dato.

Para emparejar roles con bandejas hay que cruzar dos tablas, y a ese cruce se le llama JOIN. El nuestro hacía lo primero que sale: bandeja.negocio = rol.negocio. Un nulo no es igual a nada, ni siquiera a otro nulo. Los roles compartidos no casaban, y casi todo el equipo de casi todos los negocios habría abierto la consola vacía.

La condición correcta contempla los dos casos: rol propio del negocio, o rol de sistema con el negocio en nulo. El comentario de la migración lo deja escrito, con el error incluido, para que nadie vuelva a escribir lo primero que sale.

• Sembrar sola la primera bandeja de un negocio, en los cuatro sitios donde puede nacer una conexión. Solo la primera: en las siguientes ya hay una decisión de reparto que respetar.
• Reparar hacia atrás con otra migración, pero solo en los negocios donde ningún rol alcanzaba ninguna bandeja. Donde alguien ya había repartido, no se tocó nada.
• Dejar que el propietario vea todas las bandejas siempre. No es comodidad, es la salida de emergencia. Si el reparto pudiera dejarlo sin ninguna, un error de configuración cerraría la consola por dentro. El único que puede arreglar el reparto sería el único que ya no ve la pantalla donde se arregla.
• Avisar en la pantalla de canales de las bandejas huérfanas, las que reciben mensajes y ningún rol alcanza, para que el dueño las reparta antes de que alguien lo descubra solo.

• Preguntar, ante cada migración que siembra datos: ¿qué pasa con la fila que nace mañana? Si la respuesta es «nada», falta el mecanismo.
• Probar el despliegue con un negocio creado después de la migración, no solo con los que ya existían.
• Revisar, cuando hay recursos compartidos entre negocios, cada cruce de tablas que compare identificadores de negocio: el nulo no casa.
• Dejar siempre un rol que no se pueda bloquear a sí mismo.
• Convertir el fallo silencioso en un aviso: si algo recibe mensajes y nadie puede verlos, que la pantalla lo diga.