En un SaaS donde una persona puede trabajar en varias organizaciones o espacios, «¿quién creó este recurso?» no responde necesariamente a «¿a quién pertenece?». La diferencia afecta a quién puede verlo, modificarlo, transferirlo o conservarlo cuando alguien abandona un equipo. Resolverla tarde suele dejar reglas dispersas en consultas, controladores y tareas en segundo plano.
La propiedad de recursos en SaaS multiusuario es una decisión de dominio: determina qué entidad tiene la relación principal con un recurso y qué consecuencias tiene esa relación. No es sinónimo de autenticación, membresía ni permisos. Modelarla explícitamente permite que producto, datos y código compartan una regla coherente.
Identidad, pertenencia y propiedad son relaciones distintas
Un usuario representa una identidad que puede iniciar sesión. Una pertenencia expresa que esa identidad participa en una organización o espacio de trabajo, posiblemente con un rol o un estado. La propiedad indica qué entidad responde por un recurso según las reglas del producto. Una persona puede pertenecer a varios espacios y, a la vez, crear un documento que pertenece a uno de ellos.
Conviene separar también la autoría. El campo created_by puede conservar quién realizó la acción inicial, pero no debería decidir por sí solo la propiedad. Si quien creó el registro deja la organización, el recurso puede seguir perteneciendo a esta. A la inversa, una persona podría adquirir un recurso creado originalmente por otra.
Es útil documentar las respuestas a tres preguntas: quién es el propietario, quién puede operar sobre el recurso y quién realizó cada acción relevante. Si el mismo campo o relación pretende responderlas todas, el modelo probablemente está mezclando conceptos.
Elegir entre propiedad personal, organizativa o compartida
- Personal: el recurso pertenece a un usuario. Tiene sentido cuando su ciclo de vida sigue a esa persona y no a un equipo, como una preferencia privada. Hay que decidir qué sucede si la cuenta se desactiva o elimina.
- Organizativa: pertenece a una organización o espacio de trabajo. Es adecuada cuando el recurso debe continuar disponible para el equipo aunque cambien sus integrantes. La pertenencia del usuario habilita el acceso, pero no lo convierte en propietario individual.
- Compartida: varias entidades pueden tener una relación de titularidad o responsabilidad. Úsala solo si el dominio necesita realmente copropiedad. Si el requisito es que varias personas puedan consultar o editar, normalmente se trata de acceso mediante membresías o permisos, no de varios propietarios.
La decisión debe seguir el ciclo de vida del recurso y las reglas comerciales, no una preferencia por simplificar una tabla. Pregunta quién puede conservarlo, decidir su eliminación y responder por él al cambiar el equipo. También distingue «espacio de trabajo» de «organización»: si el primero es una subdivisión real con su propio ciclo de vida y límites, puede ser el propietario adecuado; si es solo una vista o contexto de navegación, quizá no.
Representar el dominio sin inferir al propietario
En un modelo sencillo, una tabla de recursos puede tener un propietario explícito, por ejemplo owner_type y owner_id, o referencias separadas como user_id y organization_id. La primera opción puede facilitar varios tipos de propietario, pero requiere validar referencias y considerar las limitaciones de integridad referencial de las relaciones polimórficas. Las referencias separadas hacen más explícitos los vínculos, aunque exigen impedir combinaciones inválidas.
Otra alternativa es una entidad común, por ejemplo workspace, si el dominio de verdad representa bajo ella tanto cuentas personales como equipos. No la introduzcas solo para ocultar diferencias: debe tener significado y reglas estables. En cualquier diseño, establece restricciones que impidan que un recurso quede asociado simultáneamente a propietarios incompatibles o a ninguno cuando la propiedad sea obligatoria.
Modela por separado las membresías, por ejemplo con una relación entre usuario y organización que incluya estado y rol. El contexto activo de la interfaz puede indicar dónde trabaja la persona ahora, pero no es autoridad suficiente: debe validarse en cada operación. Asimismo, el propietario no se debe calcular como «quien creó el recurso» ni como «la organización seleccionada actualmente».
Aplicar la propiedad en lecturas, escrituras y procesos automáticos
Las consultas deben incorporar el ámbito de propiedad y una comprobación de acceso apropiada. No basta con cargar el recurso por identificador y confiar en que la interfaz oculte los que no corresponden. En una aplicación PHP, centraliza la resolución del contexto y las reglas de autorización en una capa reutilizable, y evita replicar condiciones incompletas en cada controlador.
En escrituras, valida el propietario permitido y la pertenencia vigente del actor. También comprueba que los recursos relacionados —por ejemplo, una carpeta de destino— pertenecen a un ámbito compatible; de lo contrario, una actualización puede crear asociaciones cruzadas. Para operaciones administrativas, separa explícitamente la autorización excepcional de las reglas ordinarias y registra quién la ejecutó y por qué.
Las colas, comandos programados, webhooks e importaciones no siempre tienen un usuario interactivo. Deben transportar un identificador de propietario o contexto validado, en lugar de depender de una sesión implícita. El proceso debe aplicar las mismas reglas de ámbito que la aplicación web. Si opera con privilegios ampliados, limita y audita esos privilegios.
Tratar la transferencia como una operación de dominio
Cambiar el propietario no debería ser una edición genérica de un campo. Define precondiciones: quién puede iniciar la transferencia, qué relación debe tener el destinatario con el espacio y qué hacer si hay una invitación pendiente o una cuenta inactiva. La operación debería ser atómica cuando actualiza varias relaciones y efectos asociados.
Determina también qué sucede con dependencias, como archivos, integraciones, facturación o automatizaciones. No supongas que todo debe moverse junto con el recurso: esa política depende del producto. Si no es posible completar todos los cambios en una transacción, diseña un proceso recuperable, con estados claros e idempotencia para reintentos.
Conserva un registro de auditoría con actor, propietario anterior, nuevo propietario, momento y motivo cuando corresponda. Así se distingue quién autorizó el cambio de quién ejecutó la acción técnica. La autoría original puede mantenerse sin alterar, aunque la titularidad cambie.
Probar los límites que revelan errores de modelo
Automatiza pruebas de servicio y de integración para verificar tanto accesos permitidos como denegados. Una matriz útil incluye una persona en dos organizaciones, recursos propios y ajenos en ambas, membresías suspendidas o revocadas, transferencia a un destino no elegible y acceso por identificadores conocidos. Comprueba respuestas y efectos en datos; ocultar un botón no constituye una prueba de autorización.
Prueba también recursos sin propietario válido, relaciones duplicadas y fallos durante una transferencia. Si el esquema exige propietario, las restricciones de base de datos deben respaldar esa expectativa, y las migraciones deben detectar registros históricos inconsistentes antes de añadirlas. Para tareas en segundo plano, verifica que el contexto se mantiene y que un reintento no duplica cambios.
Lista de comprobación antes de ampliar el SaaS
- ¿Está definido si cada tipo de recurso pertenece a una persona, organización o espacio?
- ¿Se distingue propiedad de autoría, pertenencia, rol y contexto activo?
- ¿Las consultas de lectura y escritura validan el propietario y la membresía actual?
- ¿Las tareas automáticas reciben un ámbito explícito y aplican controles equivalentes?
- ¿La transferencia tiene precondiciones, efectos definidos, auditoría y estrategia de recuperación?
- ¿Hay pruebas para usuarios con varios espacios, bajas, accesos cruzados y datos inconsistentes?
Si alguna respuesta depende de convenciones no documentadas, conviene aclararla antes de añadir más tipos de recursos o flujos de colaboración. Un modelo explícito no elimina todos los casos complejos, pero hace visibles las decisiones y permite verificarlas en el esquema, las consultas y las pruebas.
