Hasta ahora, abrir una página de una base de datos de Notion implicaba ver todas sus propiedades. Podías controlar quién entraba en cada página, pero no ocultar una columna concreta ni permitir que una persona editara un campo sin tocar los demás.
Eso cambia con Property access, el nombre oficial de los permisos por propiedad o por columna. Esta funcionalidad permite decidir quién ve cada propiedad, quién puede cambiar sus valores y quién no debería saber ni siquiera que existe.
Esta novedad completa una parte importante del modelo de permisos de Notion, pero también añade una complejidad que ya de por sí es bastante alta en cuanto a la gestión de los permisos en Notion. Sobre todo cuando estamos trabajando con equipos grandes.
Lo que sí hay que tener muy claro es que Property access no sustituye a los permisos de base de datos ni a page-level access. Cada capa resuelve un problema distinto y en este post, nos vamos a centrar únicamente en esta nueva funcionalidad recién salida del horno de Notion.
Las tres capas de permisos en Notion
Desde hace ya varios años, venimos diciendo que gestionar bien los permisos en Notion es una de las tareas más complicadas que hay.
Sin embargo, ahora mismo, a nivel macro, la forma más sencilla de entender las diferentes capas de permisos es verlas como una cascada:
1. El acceso a la base de datos define el punto de partida.
Aquí decides si los usuarios tienen o no acceso a la totalidad de la base de datos y con qué tipo de permiso.
2. Page-level access decide qué páginas concretas puede ver una persona.
Aquí puedes decidir si un usuario tiene acceso a una o varias páginas específicas dentro de la base de datos a la que no tiene acceso.
También puede darse la situación en la que el usuario tenga un acceso limitado a la totalidad de la base de datos con un permiso de Can View y que para las páginas en las que es el responsable o que haya creado tenga un permiso de Can Edit.
3. Property access decide qué propiedades puede ver o modificar una vez dentro de la página a la que tiene acceso.
Aquí la idea es que el usuario pueda ver la totalidad o ciertas páginas de la base de datos pero que no vea la totalidad de las columnas sino solo las que le interesen o las que pueda tener acceso.
En este sentido, si das acceso a un usuario a una propiedad y dicho usuario no tiene acceso a la página, no verá ni la columna ni la página.
Qué son los permisos por columna en Notion
Los permisos por columna en Notion permiten establecer una regla distinta para cada propiedad de una base de datos siempre y cuando tengas un plan Business o Enterprise. Cada regla combina un nivel predeterminado con excepciones para personas, grupos, propiedades de tipo persona o agentes.
Por ejemplo, puedes:
- Mostrar el Estado a todo el equipo, pero permitir que solo la persona asignada lo cambie.
- Ocultar Notas internas a clientes e invitados.
- Enseñar el Presupuesto a un departamento sin permitir que lo edite.
- Dejar que un agente actualice Estado de documentación sin darle acceso al presupuesto ni a las notas del cliente.
- Ocultar campos internos en las páginas publicadas en la web.
Antes, estos casos solían terminar en bases duplicadas, vistas separadas o automatizaciones que copiaban datos de un lugar a otro. Ahora una sola base puede servir a varias audiencias sin enseñar las mismas propiedades a todas ellas.
Cómo configurar permisos por propiedad
Las reglas se crean en la base original y desde una vista de tabla. No se configuran desde una vista vinculada.
- Abre la base de datos original en web o escritorio.
- Abre el menú de la propiedad que quieres controlar.
- Selecciona
Property access. - Define el acceso predeterminado para las personas que ya pueden abrir la base.
- Añade excepciones para personas, grupos, propiedades de tipo Persona o agentes.
- Elige el nivel correspondiente para cada excepción.
- Utiliza
Previewpara comprobar el resultado como otra persona. - Guarda la regla.
Un candado identifica las propiedades que tienen una regla propia. También puedes aplicar la misma configuración a varias propiedades.
La primera regla puede tardar unos minutos en guardarse porque Notion tiene que mover la información de esa columna. El tiempo aumenta en bases con muchas filas.
Los seis niveles de acceso
Los permisos por columna ofrecen seis niveles de acceso que hay que entender para no exponer datos sensibles:
- Inherit from database. La propiedad sigue el permiso general que la persona tiene sobre la base.
- Can edit property & values. Puede cambiar la configuración de la propiedad y sus valores.
- Can edit values only. Puede actualizar los valores, pero no modificar la propiedad.
- Can view property & values. Ve la propiedad y sus valores, sin poder editarlos.
- Can view property only. Sabe que la propiedad existe, pero no ve sus valores.
- No access. La propiedad y sus valores quedan ocultos.
En la mayoría de los sistemas, las opciones más útiles serán Can edit values only, Can view property & values y No access. Permiten separar operación, consulta y confidencialidad sin entregar control sobre el esquema de la base.
Can view property only tiene casos más concretos. Puede servir para mostrar que existe una aprobación o una auditoría sin revelar su contenido. Si el campo no aporta nada a esa audiencia, ocultarlo por completo suele crear una experiencia más limpia.
Un ejemplo práctico
Ahora que ya hemos repasado tanto de forma general como más específica los permisos por columna, vamos a ilustrar todo lo anterior con un ejemplo.
Imagina una base de proyectos donde todo el equipo debe consultar el estado, pero solo la persona responsable puede modificarlo.
La regla de Estado sería:
- Acceso predeterminado:
Can view property & values. - Excepción: la persona incluida en Owner.
- Acceso de la excepción:
Can edit values only.
El resultado parece sencillo, pero hay una segunda pregunta: ¿quién puede editar Owner?
Si cualquier persona puede asignarse como responsable, también puede conseguir permiso para cambiar el Estado. Por eso, cuando una excepción depende de una propiedad Persona, hay que proteger tanto el campo final como el campo que concede el acceso.
Limitaciones y errores frecuentes
Full access siempre gana
Las personas con Full access sobre la base conservan acceso total a todas sus propiedades. Una regla de columna no puede restringirlas.
Por eso, las pruebas deben hacerse con una persona que no tenga Full access. Probar solo como administrador puede dar una imagen falsa del resultado.
Se aplica el permiso más amplio
Si alguien coincide con varias excepciones, Notion aplica la menos restrictiva. Lo mismo ocurre cuando otro permiso de la base o de la página concede un acceso superior.
Cuando una restricción no funciona, hay que revisar la configuración completa de Share, el acceso predeterminado y todas las excepciones.
Fórmulas, rollups, botones y automatizaciones también respetan los permisos
Un flujo puede fallar o devolver un resultado inesperado si la persona que lo ejecuta no tiene acceso a una propiedad necesaria. Hay que probar cada fórmula, botón y automatización con el permiso real de su audiencia, no como administrador.
Si una fórmula utiliza información sensible, también conviene revisar si su resultado revela indirectamente el dato oculto.
No todas las propiedades se pueden restringir
Actualmente no se pueden aplicar estas reglas a:
- Title;
- ID;
- Created by;
- Created time;
- Last edited by;
- Last edited time;
- algunos tipos de propiedades sincronizadas;
- relaciones de subitems o páginas padre.
Property access tampoco está disponible en bases de datos wiki.
Muchas reglas pueden afectar al rendimiento
Las bases con muchas reglas pueden cargar más despacio, sobre todo si sus vistas filtran, ordenan o agrupan por propiedades restringidas. La solución no es añadir una regla a cada columna sin un modelo previo.
Cómo diseñar un modelo de permisos que no se rompa
Un buen punto de partida sería:
- Administradores: Full access sobre las bases que gestionan.
- Equipo: Can edit content o un nivel inferior, sin permiso para cambiar el esquema.
- Colaboradores externos: acceso a páginas concretas mediante page-level access.
- Agentes: solo las páginas y propiedades que necesita cada workflow.
- Propiedades sensibles: No access o solo lectura por defecto, con excepciones explícitas.
Gestiona el acceso mediante grupos siempre que sea posible. Es más fácil revisar un grupo de Finanzas o People Ops que mantener una lista de excepciones persona a persona. Recuerda que los invitados no pueden pertenecer a grupos.
Después configura base, página y propiedad en ese orden. Finalmente, prueba y revisa también las vistas vinculadas, fórmulas, botones, plantillas de bases de datos y automatizaciones.
Preguntas frecuentes sobre Property access
¿Property access y page-level access son lo mismo?
No. Page-level access controla qué páginas puede abrir alguien. Property access controla qué columnas ve o edita dentro de una página que ya puede abrir.
¿Los permisos por columna dan acceso a una página?
No. La persona necesita acceso previo a la base o a esa página concreta.
¿Puedo ocultar una propiedad a una persona concreta?
Sí. Puedes establecer No access como nivel predeterminado y añadir excepciones para las personas o grupos que sí deben verla. También puedes crear una excepción individual más restrictiva, siempre que otro permiso más amplio no la anule.
¿Puedo restringir propiedades a alguien con Full access?
No. Primero tendrías que reducir su permiso general sobre la base.
¿Puedo dejar que alguien cambie valores sin modificar la columna?
Sí. Utiliza Can edit values only.
¿Funciona con agentes de Notion?
Sí. Los agentes pueden recibir permisos propios sobre propiedades. Notion AI suele heredar los permisos del usuario que lo ejecuta.
¿Está disponible en todos los planes?
No. La configuración de Property access está disponible en Business y Enterprise.
Cómo podemos ayudarte en noxen studio
Los permisos por propiedad permiten mantener una sola fuente de verdad para varias audiencias. La parte difícil no es activar el menú, sino decidir qué debe ver cada rol, evitar vías de autoescalada y comprobar que las vistas y automatizaciones siguen funcionando.
En noxen studio diseñamos la arquitectura, los grupos, las reglas de acceso y las pruebas por perfil. También revisamos qué datos debería consultar o modificar cada agente de IA. El resultado es un sistema donde cada persona puede hacer su trabajo sin recibir más acceso del necesario.
Si quieres revisar los permisos y la arquitectura de tu workspace, cuéntanos qué necesitas y agenda una discovery call.