La suscripción decide quién entra, no el permiso

Si vendes varios productos a los mismos clientes, esta nota separa tres preguntas que se suelen responder con un único sistema de permisos, y que no son la misma.

• ¿Existe esto aquí? ¿Está montado en este servidor?
• ¿Lo tiene el negocio? ¿Lo contrató?
• ¿Puede esta persona? ¿Se lo dio su jefe?

Meterlas todas en el sistema de permisos es lo que sale solo, y produce cosas raras: un permiso que hay que quitarle a todo el equipo cuando el cliente se da de baja, o un cliente que ve un botón de algo que su servidor ni siquiera tiene instalado.

La consola es del negocio que contrató el servicio, no de un rol.

Quién puede abrir la consola de un producto lo decide la suscripción. Se pregunta si ese negocio contrató ese servicio, y punto.

Un permiso serviría para otra cosa: decir quién dentro de ese negocio puede tocarla. Hoy no hace falta —todos los de un cliente ven lo mismo— y el día que haga falta se añade, encima y sin reemplazar nada.

Esa es la forma de no equivocarse con estas capas: son acumulativas, no alternativas. Contratar te da la puerta; el permiso reparte llaves dentro. Si usas permisos para responder si el negocio contrató, el día que se dé de baja tienes que ir rol por rol a quitarlo, y alguno se te queda.

Hay una excepción, y merece contarse porque es una decisión comercial escrita en el código.

Un negocio marcado como demostración entra a la pantalla de configuración sin tener suscripción. El argumento cabe en una frase: la configuración es lo que se le está vendiendo. No se le puede pedir que pague para ver cómo se entra.

Y la bandeja final también se le deja ver, porque ahí radica la demostración: sin llegar a ver su propio WhatsApp dentro, no ha visto el producto.

El resto de consolas siguen exigiendo suscripción. La excepción es estrecha y está escrita, que es la diferencia entre una excepción y un agujero: cualquiera que lea ese archivo ve cuál es y por qué.

Detalle de trato, y de los que distinguen un producto cuidado.

Un usuario de la plataforma —de los nuestros— no pertenece a ningún negocio, así que no tiene bandeja que mirar. Lo fácil es mandarlo a la pantalla de inicio de sesión o a un «no autorizado».

Lo que hacemos es distinguir el caso y explicarlo, y mandarlo donde sí hay algo que hacer. No está haciendo nada mal: está en el sitio equivocado.

Las cuatro filas dicen cosas distintas. Responder a las cuatro con «no autorizado» es barato de programar y caro de soportar: cada una genera una llamada que alguien tiene que atender.

Nuestro asistente conversacional no tiene suscripción propia. Quien tenga cualquier cosa activa, lo tiene.

El motivo es de producto y no de código: no es un producto, es la forma de preguntarle a los que ya se tienen. Cobrarlo aparte obligaría a explicarle a un cliente que puede ver su bandeja pero no preguntar por ella.

Esa frontera no la entiende nadie, y las fronteras que no se entienden se convierten en llamadas al soporte y en desconfianza. Cuando una línea de facturación necesita un párrafo de explicación, casi siempre está mal trazada.

Dicho esto, el permiso sí existe encima: el negocio puede querer que su equipo conteste y no que consulte. La suscripción dice si el negocio lo tiene; el permiso, si esta persona puede.

Queda la primera de las tres, que es además la más olvidada.

Que el asistente exista o no en un servidor no es una propiedad del negocio: es una propiedad del despliegue. La misma versión del código puede tenerlo encendido en un sitio y apagado en otro. Así que el interruptor no vive en la base de datos, vive en la configuración del servidor: sin la llave del proveedor, no hay asistente.

Y la consecuencia práctica es bonita: se puede publicar el código antes que la llave y no cambia nada para nadie. El menú no lo enseña, la ruta no lo ofrece. El día que la llave aparezca en la configuración, se enciende solo.

Que falte la llave no es un error que haya que enseñar. Es que todavía no existe.

• Separa las tres preguntas. Existe aquí, lo contrató el negocio, puede esta persona. Tres mecanismos, no uno.
• No uses permisos para decir qué contrató un cliente. El día de la baja tendrás que ir rol por rol.
• Escribe tus excepciones donde se leen. Una excepción escrita es una decisión; una sin escribir es un agujero.
• Responde distinto a cada «no». Cada «no autorizado» genérico es una llamada al soporte.
• Si una línea de facturación necesita un párrafo, muévela. Las fronteras que no se entienden se pagan en desconfianza.