Si una aplicación la usan varias personas, necesitas saber quién puede ver o cambiar cada cosa. Así se evitan sorpresas como que una persona con permiso de lectura edite una decisión o que un equipo vea datos de otro. “Habrá administradores y usuarios” deja abierta la mayor parte de ese comportamiento.
Puedes explicar cómo trabaja tu equipo y qué información debe quedar separada. Ricardo puede convertirlo contigo en reglas, una matriz de permisos y pruebas; no necesitas preparar esa matriz antes de consultar un proyecto.
Empieza por acciones y responsabilidades
El nombre del perfil no describe todos sus permisos. Una persona puede pagar una suscripción sin editar el contenido, o trabajar con datos sin administrar miembros.
Conviene separar estas responsabilidades:
| Responsabilidad | Pregunta que debe poder resolver |
|---|---|
| Usuario del producto | ¿Cómo completo mi trabajo? |
| Comprador | ¿Qué se contrata, renueva o cancela? |
| Administrador del equipo | ¿Quién entra y con qué acceso? |
| Operador del servicio | ¿Cómo se atiende una incidencia? |
| Responsable de producto | ¿Qué comportamiento y cambios se aceptan? |
En un producto pequeño una persona puede asumir varias. Dejarlas separadas en el diseño evita conceder acceso a datos solo porque alguien necesita resolver una cuestión de facturación.
Un ejemplo con dos equipos
Cuaderno de equipos es un ejemplo ficticio para registrar proyectos y decisiones. Tiene dos organizaciones de prueba y tres perfiles dentro de cada una: propietaria, editora y lectora.
Una decisión pertenece a un proyecto; el proyecto pertenece a una organización. La persona tiene una relación con esa organización. Esa cadena debe intervenir al decidir el acceso.
La editora del equipo A puede corregir una decisión de A. Otra editora de B, aunque tenga el mismo rol, no debería poder modificarla. El nombre “editora” es solo una parte de la regla.
La matriz que permite revisar el resultado
Este es el acuerdo del ejemplo. No es una lista universal de roles:
| Acción sobre la organización propia | Propietaria | Editora | Lectora |
|---|---|---|---|
| Consultar proyectos y decisiones | Sí | Sí | Sí |
| Crear un proyecto | Sí, si el plan lo permite | Sí, si el plan lo permite | No |
| Crear o corregir una decisión | Sí | Sí | No |
| Exportar lo que puede consultar | Sí | Sí | Sí |
| Cambiar miembros o roles | Sí | No | No |
| Cambiar plan o cancelar | Sí | No | No |
| Acceder a otra organización sin pertenecer a ella | No | No | No |
La tabla muestra también que un permiso puede depender de otra condición. Tener rol de editora no garantiza poder crear un proyecto si se ha alcanzado el límite acordado del plan.
Si tu trabajo necesita excepciones —por proyecto, fecha o relación— conviene contarlas al definir el alcance. El profesional puede plasmarlas en una regla comprensible en vez de multiplicar perfiles con nombres parecidos.
Define qué datos pertenecen a quién
Para concretar el producto, el equipo de desarrollo debe relacionar estos elementos:
- Organización: agrupa proyectos, miembros y configuración.
- Miembro: relaciona una persona con una organización y un rol.
- Proyecto: pertenece a una organización.
- Decisión: pertenece a un proyecto.
- Evento de cambio: indica qué acción relevante ocurrió, sobre qué elemento y cuándo.
Después decide qué debe pasar cuando cambia una relación. Si una persona deja el equipo, ¿sus decisiones permanecen? ¿Quién puede corregirlas? ¿Se conserva la autoría necesaria? ¿Qué acceso termina?
También hay que distinguir exportación de una decisión y exportación de toda una organización. La segunda puede revelar más información y necesita un permiso distinto si el producto lo requiere.
El alcance debe reflejar la necesidad del trabajo. Evita recoger datos personales “por si acaso”: cada campo añadido exige pensar quién lo usa, cuánto se conserva y quién puede consultarlo.
La interfaz orienta y la aplicación aplica la regla
Si una lectora no puede editar, la interfaz debe ayudarle a entenderlo. Puede mostrar el contenido en lectura y explicar qué acceso necesitaría para cambiarlo.
Una aplicación real tiene que comprobar además la autorización al procesar la acción. Ocultar un botón no impide que se intente una petición por otra vía. OWASP recomienda permisos mínimos, denegación por defecto y comprobación de autorización en cada petición. Guía de autorización de OWASP, consultada el 10/09/2026.
El diseño necesita cubrir también archivos, búsquedas, exportaciones y tareas en segundo plano. Un listado filtrado no sirve de separación si una exportación obtiene datos de otro equipo. La guía de seguridad multiempresa de OWASP, consultada el 10/09/2026, recoge esas superficies.
Convierte la matriz en pruebas
Para cada regla importante, el desarrollo debe preparar un caso que funcione y otro que se rechace. Como comprador podrás revisar el resultado observable:
| Prueba | Acción | Resultado esperado |
|---|---|---|
| Edición permitida | Editora de A corrige una decisión de A | El cambio se conserva |
| Rol insuficiente | Lectora de A intenta corregir esa decisión | Se rechaza y el dato no cambia |
| Organización distinta | Editora de B intenta abrir la decisión de A | No se entrega el contenido |
| Exportación | Lectora de A exporta su proyecto permitido | Solo incluye los datos autorizados |
| Cambio de acceso | Se retira la pertenencia de una persona | Las acciones posteriores respetan el nuevo estado |
| Límite de plan | Editora crea por encima del límite | Se explica el límite sin borrar proyectos existentes |
Cuando revises el resultado, comprueba el dato final y la respuesta, no solo si aparece un mensaje. Un aviso de “sin permiso” acompañado de una modificación efectiva es un fallo.
El demostrador SaaS permite explorar personajes, organizaciones y límites con datos de prueba. Muestra decisiones de producto; por sí solo no acredita autenticación, separación segura de datos ni seguridad de un SaaS en producción. Su caso explica qué necesitaría una operación real.
Diseña los cambios de rol y la salida
Hay decisiones fáciles de olvidar:
- Quién puede convertir a otra persona en propietaria.
- Qué ocurre si se intenta eliminar a la última propietaria.
- Cómo se revoca el acceso y desde cuándo surte efecto.
- Qué conserva una cuenta al cancelar.
- Cómo se corrige una asignación equivocada.
- Qué información necesita un operador para atender una incidencia.
No todas requieren una gran interfaz administrativa. Sí necesitan un comportamiento acordado. Si todavía no se sabe, deben figurar como preguntas de alcance.
En el ejemplo, reducir un plan no borra el trabajo que excede el nuevo límite: conserva consulta y exportación, y restringe nuevas altas hasta resolverlo. Es una decisión de producto que puede comprobarse y explicarse a quien usa la aplicación.
Llévalo al encargo
Puedes llegar con situaciones sencillas: quién necesita consultar, corregir, administrar o salir del equipo, y qué datos no deberían ver otras personas. Ricardo puede ayudarte a definir la matriz, las relaciones y las pruebas, o ejecutar los requisitos que ya tengas preparados.
El mapa de alcance permite relacionar cada permiso con la capacidad que lo necesita. La guía de primera versión ayuda a decidir cuáles hacen falta desde el inicio. Si hay cobros, revisa también el ciclo de acceso y suscripción.
La guía de una idea a una aplicación o SaaS sitúa estos permisos dentro de las decisiones de solución, alcance y operación.
Así podrás revisar una aplicación por su comportamiento: quién puede hacer qué, sobre qué datos y bajo qué condiciones. Si quieres comentar una aplicación con Ricardo, no necesitas entregar previamente una matriz de permisos.