Vistas y permisos: qué ve cada persona en tu base sin duplicarla

La primera vez que alguien monta una base para trabajar con clientes hace lo mismo: duplica la base.

Una para el cliente A, otra para el cliente B, otra para el C. Al principio parece limpio. Tres meses después tienes catorce bases, cambias un campo y tienes que cambiarlo catorce veces, y en dos de ellas se te olvida. Ahí empieza el desastre silencioso.

La alternativa correcta es una sola base y capas de visibilidad encima. Que es exactamente lo que hacen las herramientas serias por dentro, aunque no te lo cuenten así.

¿Cómo hago que cada usuario vea solo lo suyo?

Con un campo que diga de quién es cada fila, y una capa por encima que filtre por ese campo.

Eso es todo. Suena decepcionante porque lo es. El noventa por ciento de los sistemas de permisos que necesita un negocio pequeño se resuelven con una columna de correo electrónico y un filtro.

Lo que pasa es que hay que entender que en estas herramientas conviven dos cosas distintas que la gente confunde todo el rato: las vistas y los permisos. No son lo mismo y esa confusión es la que provoca los sustos.

La diferencia que te va a evitar un disgusto

Una vista es una forma de mirar la tabla. Filtras, ordenas, escondes campos y te queda una pantalla más cómoda. Pero la vista no protege nada: quien tiene acceso a la base puede quitar el filtro y ver el resto.

Un permiso sí es una barrera de verdad. Es lo que impide que una persona llegue a un dato aunque quiera.

Si le compartes a un cliente una vista filtrada de Airtable pensando que ahí solo ve lo suyo, le estás dando la base entera con un filtro puesto. Es como esconder el extracto del banco debajo de un mantel.

Grábate esto: las vistas son comodidad, los permisos son seguridad. Nunca uses una vista para tapar algo que no debe verse.

Paso 1: mete el campo de propietario en cada tabla

Vas a tu tabla de proyectos, pedidos, clientes o lo que sea, y creas un campo de texto o correo que se llame "cliente" o "propietario".

Cada fila tiene que tener ese campo relleno. Sin excepciones. Una fila sin propietario es una fila que se le va a colar a alguien.

Si tienes varias tablas relacionadas (proyectos, tareas de esos proyectos, facturas de esos proyectos), lo suyo es que la relación cuelgue del proyecto y el filtro se aplique en cascada. Pero si estás empezando, no te compliques: pon el campo en todas las tablas aunque se repita. Redundante sí, pero a prueba de balas.

Paso 2: pon el portal por encima, no compartas la base

Aquí es donde entra la capa de verdad. Herramientas como Softr se ponen encima de tu base y hacen dos cosas: enseñan los datos con una interfaz decente y controlan quién entra.

El cliente no toca tu base nunca. Entra a una web, hace login con su correo, y ve una lista. Esa lista es una consulta filtrada por su correo, hecha en el servidor. No hay filtro que pueda quitar porque nunca ha tenido la tabla delante.

La configuración concreta es de las pocas cosas que se hacen en dos clics: en el bloque de lista, activas la condición de que el campo "cliente" coincida con el usuario que ha iniciado sesión. Ya está. Ese es el mecanismo entero.

Si nunca has montado uno, el proceso completo lo tienes en el tutorial del portal privado de clientes con Softr. Y la parte de autenticación, que es la que más dudas genera, la explico aparte en cómo montar login de usuarios sin código.

Paso 3: define los tres roles que de verdad necesitas

He visto sistemas de permisos con nueve roles en negocios de dos personas. No hace falta.

Tú. Ves todo, editas todo. Trabajas directamente en la base.

Tu equipo. Ve todo lo operativo pero no la parte sensible. Aquí lo importante no es esconder por esconder: es que si alguien de tu equipo no necesita ver los márgenes o los datos de facturación, no los tenga delante todo el día.

El cliente. Ve sus filas y punto. Y con los campos justos: puede ver el estado de su proyecto, pero no tus notas internas sobre ese proyecto ni lo que te costó.

Ese tercer detalle es el que más se olvida. No basta con filtrar filas, hay que filtrar columnas. La columna "notas internas" no se muestra en el portal. Nunca.

Paso 4: prueba a ser tu propio cliente

Antes de dar acceso a nadie, créate una cuenta con un correo cualquiera que no sea el tuyo, dale acceso como cliente y entra desde una ventana de incógnito.

Y ahora intenta romperlo. Cambia el número que aparece en la URL a ver si te salen datos de otro. Prueba a entrar a una página que no está en tu menú escribiéndola a mano. Mira si al abrir un registro te aparece algún campo que no debería estar.

Este paso lleva quince minutos y es el único que separa un portal decente de una fuga de datos entre clientes. Que es, con diferencia, la peor cosa que te puede pasar en esto.

Lo que se te va a atascar

El usuario entra y no ve nada. El noventa por ciento de las veces es que el correo con el que se registró no coincide exactamente con el del campo de la base. Mayúsculas, un punto de más, un alias. Normaliza siempre a minúsculas.

Los archivos adjuntos. Ojo con esto, que es un agujero real. En muchas herramientas los archivos que subes tienen una URL pública: quien tenga el enlace, entra, aunque no haya hecho login. Si manejas documentos sensibles, comprueba cómo se sirven los archivos antes de meter ahí nada serio.

Las filas huérfanas. Una fila sin propietario no aparece para nadie, o peor, aparece para todos según cómo esté montado el filtro. Ponle a ese campo la condición de obligatorio.

Los límites de la capa gratuita. Casi todas estas herramientas limitan el número de usuarios con login. Y ese es justo el límite que vas a tocar primero, antes que el de registros. Mira ese número antes de prometerle acceso a treinta clientes.

Los cambios en cascada. Si un proyecto cambia de cliente, las tareas de ese proyecto también deberían cambiar. Si duplicaste el campo en todas las tablas por comodidad, esto hay que actualizarlo a mano o con una automatización. Es el precio de la redundancia.

Y ahora qué

Coge la base que ya tienes. Añade el campo de propietario. Rellénalo. Monta una página de portal con una sola lista filtrada y pruébala con dos correos distintos.

Con eso ya tienes el mecanismo entero funcionando. Todo lo demás (más páginas, más roles, más filtros) es repetir esa misma idea en sitios distintos.

Y no te montes el sistema de permisos definitivo antes de tener el primer cliente dentro. Se aprende muchísimo más viendo a una persona real usarlo que dibujando roles en un papel. Si aún no tienes clara la base de todo esto, la guía de bases de datos y CRM sin código te ordena las piezas antes de que empieces a poner puertas.

Algunos enlaces de este artículo son de afiliado: si contratas la herramienta, me llevo una comisión sin que a ti te cueste más.

Si no tienes claro por dónde empezar a meter IA y automatización en lo tuyo, hice un test corto que te dice en qué punto estás y qué toca hacer primero.

Hacer el test