Roles y permisos en una app: quién puede hacer qué

En cuanto una app tiene más de un tipo de persona usándola, aparece la pregunta de quién puede ver y hacer qué. Los roles y permisos en una app resuelven eso: el dueño ve todo, el empleado solo su sector, el cliente únicamente sus propios datos. Parece un detalle de configuración, pero condiciona la estructura de la base de datos, las pantallas y buena parte de las pruebas, por lo que es mejor definirlo al principio.

Qué diferencia hay entre rol y permiso

Un permiso es una acción concreta: ver pedidos, editar precios, anular un turno, exportar clientes. Un rol es un conjunto de permisos con un nombre: «administrador», «encargado», «empleado», «cliente». Se asigna el rol a la persona y el sistema deduce lo que puede hacer. Esto evita configurar permisos uno por uno para cada usuario.

Perfiles típicos

Perfil	Suele necesitar	Suele no poder
Cliente final	Ver y modificar sus propios datos, pedidos o turnos	Ver datos de otros clientes
Empleado	Operar la tarea diaria: atender pedidos, registrar cobros	Cambiar configuración o ver reportes financieros
Encargado o supervisor	Ver el equipo, aprobar excepciones, consultar reportes de su sector	Gestionar otros locales o administrar roles
Administrador	Todo lo anterior, más usuarios, configuración y exportaciones	Nada, por eso hay que cuidar quién lo es

Es un punto de partida, no una receta: tu negocio puede tener perfiles como contador externo, técnico, repartidor o profesional que solo ve su propia agenda.

Tres modelos de diseño

Pocos roles fijos

Lo más simple: tres o cuatro roles definidos de antemano, que no se editan desde la app. Es rápido de construir y fácil de entender. Funciona bien cuando la estructura del negocio es estable.

Roles editables

El administrador puede crear roles nuevos y tildar qué permisos incluyen. Da flexibilidad, pero suma pantallas, validaciones y un riesgo: alguien puede armar una combinación que el equipo no previó.

Permisos por ámbito

Además del rol, importa el alcance: este encargado administra la sucursal A pero no la B; este profesional solo ve sus turnos. Se trata de permisos que dependen del dato, y son los más frecuentes en negocios con varios locales o equipos.

Dónde se aplican los permisos

Un error común es ocultar botones en la pantalla y creer que con eso alcanza. Si el servidor no verifica cada pedido, cualquiera con conocimientos mínimos puede invocar la acción directamente. La regla es que la verificación vive en el servidor; la interfaz solo refleja lo permitido para que la experiencia sea clara. Esto se relaciona con la seguridad de datos y con cómo se identifica a cada persona, tema de login y autenticación.

Situaciones que conviene resolver

• ¿Qué pasa cuando alguien se va del equipo? Se debe poder desactivar su acceso de inmediato sin perder el historial de lo que hizo.
• ¿Quién puede crear otros administradores?
• ¿Se necesita que una acción delicada, como un reembolso, requiera aprobación de un segundo rol?
• ¿Una persona puede tener más de un rol, o varios locales con roles distintos?
• ¿Hay accesos temporales, como un contador que entra solo a fin de mes?
• ¿Se registra quién hizo cada cambio sensible?

Principio rector: permisos mínimos

Conviene que cada rol arranque con lo mínimo y que se agreguen permisos cuando hay una razón, y no al revés. Es más fácil ampliar un acceso que enterarse tarde de que alguien veía datos que no debía. Este enfoque también ayuda al cumplimiento de las obligaciones de confidencialidad sobre datos personales.

Impacto en el alcance y el costo

Con un solo tipo de usuario no hay nada que diseñar. Con dos o tres roles fijos, el costo es moderado. Aumenta con los roles editables, los permisos por ámbito, las aprobaciones en dos pasos y los registros de auditoría. Además, cada rol multiplica las pruebas: hay que verificar no solo lo que puede hacer, sino que no pueda hacer lo demás. Gran parte de esto se vuelve visible en el panel de administración, donde se asignan y gestionan los accesos.

Riesgos habituales

• Dar a todos el rol de administrador «para que no se trabe nada».
• Definir roles después de construir, con lo cual hay que rehacer pantallas y datos.
• Roles tan finos que nadie sabe qué incluye cada uno.
• Compartir una misma cuenta entre varios empleados, lo que impide saber quién hizo qué.

Qué preguntar antes de incluirlos

1. ¿Qué tipos de personas van a usar el sistema?
2. ¿Qué debería poder hacer cada tipo, y qué definitivamente no?
3. ¿Hay varias sucursales, equipos o sectores con información separada?
4. ¿Quién administra los accesos del día a día?
5. ¿Es necesario dejar constancia de quién hizo cada acción?

Siguiente paso

Un esquema de roles en una hoja de papel, con quién hace qué, ahorra mucho retrabajo después. Si querés armarlo con ayuda, escribinos desde el formulario de contacto.