¿Necesitas que cada elemento de una Microsoft List sea visible solo para su propio equipo? En esta guía práctica verás qué permite SharePoint, por qué los filtros no son seguridad y cómo aplicar permisos únicos por elemento (manualmente o con Power Automate). Incluye checklist, buenas prácticas y plantillas.
Contexto y problema real
El objetivo es que cada elemento de una lista de SharePoint (Microsoft Lists) sea visible únicamente para el grupo indicado en la columna “Division/Group”. Por ejemplo, que PU Group solo vea sus elementos, y GR&A Group solo los suyos. Al intentar cambiar Manage access elemento por elemento, los usuarios siguieron viendo todo.
Por qué ocurrió: si no se detiene la herencia de permisos del elemento y no se retiran los grupos generales (p. ej., Members, Visitors o “Everyone…”), los usuarios conservan acceso por herencia, aunque la tarjeta de Manage access muestre cambios parciales.
Qué es posible y qué no en SharePoint
- No existe seguridad por valor de columna en listas. Ni audience targeting ni las vistas filtradas aplican seguridad; solo cambian cómo se presenta el contenido.
- Para aislar elementos por grupo, hay que romper la herencia de permisos del elemento y asignar permisos únicos únicamente al grupo objetivo.
- Las personalizaciones de formularios (Power Apps), los formatos de vista y las columnas ocultas no sustituyen a la seguridad.
Soluciones posibles
| Enfoque | Cómo funciona | Ventajas | Limitaciones | Cuándo usarlo |
|---|---|---|---|---|
| Permisos manuales por elemento | Romper herencia y asignar el grupo correcto en cada elemento. | 100% nativo; control total. | Tedioso y propenso a errores si hay volumen. | Pocos elementos o casos puntuales. |
| Power Automate | Flujo que rompe herencia y concede permisos al grupo de la columna. | Consistente, auditable y escalable. | Requiere mantenimiento del flujo. | Escenarios con muchos elementos o cambios frecuentes. |
| Permisos por contenedor | Separar por listas o carpetas y heredar permisos del contenedor. | Más simple de administrar. | Menos granular; puede requerir reestructurar. | Cuando cada grupo trabaja en su propia “bandeja”. |
| Solo autor (nativo) | Configurar “leer/editar solo los elementos creados por el usuario”. | Muy simple. | No funciona por grupo; solo por creador. | Casos en que cada usuario solo ve lo suyo. |
Procedimiento manual por elemento
- En el elemento, abre Manage access → Advanced.
- Haz clic en Stop inheriting permissions.
- Retira los grupos generales heredados (p. ej., Members, Visitors, “Everyone…”). Deja Owners solo si corresponde.
- Concede permisos solo al grupo que debe ver el elemento (p. ej., PU Group) con el rol adecuado (Read o Edit).
- Guarda/Comparte.
Este método funciona, pero no escala. Si la lista crece, lo ideal es automatizar.
Automatización con Power Automate
La estrategia es que el flujo se ejecute al crear/modificar un elemento, rompa la herencia de permisos y asigne solo el grupo de la columna Division/Group.
Estructura del flujo recomendada
- Disparador: When an item is created or modified (SharePoint).
- Comprobación de datos: si Division/Group está vacío, registrar y detener (o asignar temporalmente Owners con lectura).
- Obtener grupo objetivo: si la columna es de tipo Person or Group (permitiendo grupos de SharePoint), utiliza su DisplayName para consultar el Id del grupo.
- Romper herencia del elemento: no copiar permisos heredados y limpiar sub-ámbitos.
- Opcional: volver a conceder Owners con Full Control si tu gobierno interno lo exige.
- Conceder permisos: asignar Read o Edit al grupo de la columna.
- Auditoría: escribir fecha/resultado en un campo de control (p. ej., SecurityStatus).
Acciones HTTP tipo REST sugeridas
Usa Send an HTTP request to SharePoint en cada paso REST. A continuación, endpoints genéricos y parámetros típicos. Sustituye contoso, sitio, Lista y los nombres de acciones según tu entorno. Configura cabeceras con Accept: application/json;odata=nometadata y Content-Type: application/json;odata=nometadata.
Obtener Id del grupo a partir del nombre
Si la columna Division/Group es Person or Group (permitiendo grupos), puedes usar el DisplayName:
GET https://contoso.sharepoint.com/sites/sitio/api/web/sitegroups/getByName('@{encodeUriComponent(triggerOutputs()?['body/Divisionx002f_Group/DisplayName'])}')
Salida esperada: un objeto con la propiedad Id del grupo (principalId).
Romper herencia del elemento
POST https://contoso.sharepoint.com/sites/sitio/_api/web/lists/getByTitle('Lista')/items(@{triggerOutputs()?['body/ID']})/breakroleinheritance(copyRoleAssignments=false, clearSubscopes=true)
Con copyRoleAssignments=false se eliminan los permisos heredados. clearSubscopes=true limpia sub-ámbitos únicos previos.
Obtener el Id de la definición de rol
Para usar nombres estándar (Read, Edit, Contribute, etc.), obtén su Id:
GET https://contoso.sharepoint.com/sites/sitio/_api/web/roledefinitions/getbyname('Read')
Repite la operación si necesitas un rol distinto (p. ej., Edit).
Conceder permisos al grupo objetivo
POST https://contoso.sharepoint.com/sites/sitio/api/web/lists/getByTitle('Lista')/items(@{triggerOutputs()?['body/ID']})/roleassignments/addroleassignment(principalid=@{outputs('GetGroup')?['body/Id']},roledefid=@{outputs('GetReadRole')?['body/Id']})
Agregar de nuevo a Owners (si tu gobierno lo exige)
Si necesitas que Owners conserve control total por cada elemento, repite la operación anterior con el Id del grupo de Owners y el Id de la definición de rol correspondiente (Full Control).
Lógica de actualización cuando cambia el grupo
En modificaciones, lo más robusto es volver a romper herencia y reconstruir las asignaciones. Alternativamente, detecta cambios con Get changes for an item or a file (properties only) y, si Division/Group cambió, ejecuta:
- removeroleassignment del grupo anterior, y
- addroleassignment para el nuevo grupo.
POST .../roleassignments/removeroleassignment(principalid=@{variables('OldGroupId')},roledefid=@{outputs('GetReadRole')?['body/Id']})
Campos y configuración recomendados en la lista
- Division/Group: tipo Person or Group, permitiendo Groups de SharePoint. Selección única.
- SecurityStatus (Texto): “Asignado a PU Group (Read) – 2025-08-30 10:34”.
- SecurityLastRun (Fecha/Hora): marca temporal del último ajuste de permisos.
- SecurityRole (Elección): Read | Edit (si el rol depende del elemento).
Control de excepciones
- Si Division/Group está vacío: asignar Owners con Read y registrar incidente.
- Si el grupo no existe: escribir en SecurityStatus y notificar al propietario de la lista.
- Implementar reintentos controlados ante errores 429/503.
Rediseño por contenedores
Si la necesidad de granularidad elemento a elemento no es crítica, crear una lista o carpeta por grupo simplifica mucho la seguridad. Los elementos heredan permisos del contenedor, lo que:
- Reduce el número de ámbitos de permisos únicos.
- Minimiza la complejidad del flujo (o incluso lo elimina).
- Facilita auditoría y administración.
Un patrón habitual es tener una lista maestra para la administración (visible a Owners) y una lista por grupo para el trabajo diario.
Configuración nativa por autor
En Advanced settings de la lista existe la opción “Leer/Editar solo los elementos creados por el usuario”. Esto no resuelve escenarios por grupo, pero sirve cuando cada usuario debe ver únicamente lo que crea.
Buenas prácticas de gobierno y rendimiento
- Evita escribir nombres a mano en Division/Group: usa el tipo Person or Group para seleccionar grupos reales y evitar errores de tipeo.
- Define un rol consistente por defecto (p. ej., Read) y solo eleva a Edit cuando sea necesario.
- Monitorea el número de elementos con permisos únicos: un gran volumen puede impactar rendimiento y administración. Si esperas miles, prioriza automatización o permisos por contenedor.
- Estándar de grupos: usa SharePoint Groups gestionados por TI (no grupos personales). Nombra los grupos de forma estable (PU Group, GR&A Group, etc.).
- Auditoría: registra en campos dedicados y, si es posible, envía un resumen diario/semanal a los Owners.
- Pruebas con identidad real: valida con una cuenta que solo pertenezca al grupo objetivo o usa Check Permissions en la página de permisos del elemento.
Checklist de verificación rápida
- [ ] El elemento no hereda permisos del sitio/lista.
- [ ] Se retiraron Members/Visitors (y cualquier “Everyone…”).
- [ ] Solo está asignado el grupo correcto con el rol adecuado.
- [ ] La columna Division/Group usa tipo Person or Group (o existe una tabla de mapeo fiable en el flujo).
- [ ] Prueba con una cuenta que solo pertenezca al grupo objetivo (o usa Check Permissions).
Diagnóstico y resolución de problemas
- Sigue apareciendo todo: revisa que el elemento no herede permisos y que se hayan quitado los grupos generales (Members/Visitors).
- Usuarios ven 403: valida que el grupo asignado existe en el sitio correcto (no en otro sitio) y que la asignación usó el Id de ese grupo.
- Flujo falla intermitente: agrega reintentos y esperas exponenciales en las acciones HTTP y considera un scope de try/catch con “Configure run after”.
- El campo de grupo está vacío: agrega validaciones en la creación (Reglas en Power Apps o columna requerida).
- Necesidad de excepciones: si un elemento debe ser visible a dos grupos, concede permisos a ambos (dos llamadas a addroleassignment).
Plantilla conceptual del flujo
Trigger: When an item is created or modified (SharePoint)
Initialize variable RoleName = 'Read' (o según columna SecurityRole)
HTTP GetGroup:
GET /\api/web/sitegroups/getByName('@{encodeUriComponent(triggerOutputs()?\['body/Division\x002f\_Group/DisplayName'])}')
HTTP GetRole:
GET /\_api/web/roledefinitions/getbyname('@{variables('RoleName')}')
HTTP BreakInheritance:
POST /\_api/web/lists/getByTitle('Lista')/items(@{triggerOutputs()?\['body/ID']})/breakroleinheritance(copyRoleAssignments=false,clearSubscopes=true)
(Opt) HTTP AddOwners:
POST /\_api/web/lists/getByTitle('Lista')/items(@{triggerOutputs()?\['body/ID']})/roleassignments/addroleassignment(principalid=\,roledefid=\)
HTTP AddTargetGroup:
POST /\_api/web/lists/getByTitle('Lista')/items(@{triggerOutputs()?\['body/ID']})/roleassignments/addroleassignment(principalid=@{outputs('GetGroup')?\['body/Id']},roledefid=@{outputs('GetRole')?\['body/Id']})
Update item:
SecurityStatus = concat('Asignado a ', triggerOutputs()?\['body/Division\x002f\Group/DisplayName'], ' (', variables('RoleName'), ') - ', utcNow())
SecurityLastRun = utcNow() Matriz de decisión rápida
| Escenario | Recomendación | Notas |
|---|---|---|
| Pocos elementos; cambios esporádicos | Permisos manuales por elemento | Documenta el procedimiento para el equipo. |
| Muchos elementos; cambios frecuentes | Power Automate | Rompe herencia y asigna grupo en cada alta/cambio. |
| Equipos trabajan aislados sin cruces | Permisos por contenedor | Una lista/carpeta por grupo, herencia simple. |
| Visibilidad solo por autor | Opción nativa por creador | No es por grupo; úsala únicamente para autor. |
Preguntas frecuentes
¿Las vistas filtradas o el audience targeting ocultan datos sensibles?
No. Son ayudas de presentación, no seguridad. Para ocultar de verdad, usa permisos por elemento o por contenedor.
¿Power Apps puede impedir que un usuario vea elementos?
No. Puede ocultar controles en el formulario, pero si el usuario tiene permiso en la lista, puede ver el elemento por otras vías.
¿Puedo asignar dos grupos al mismo elemento?
Sí. Repite addroleassignment para cada grupo y rol.
¿Es mejor usar grupos de Microsoft 365 o grupos de SharePoint?
Para permisos finos en listas, los SharePoint Groups son prácticos y predecibles. Si tu gobierno usa M365 Groups, asegúrate de que están visibles y gestionados en el sitio donde vive la lista.
¿Qué pasa si muevo el elemento a otra carpeta o lista?
Cambiar de contenedor puede modificar herencias. Tras mover, vuelve a aplicar o validar derechos con tu flujo.
Resumen y recomendación
SharePoint no ofrece seguridad por columna en listas. La forma correcta de que cada elemento sea visible solo por su grupo es aplicar permisos únicos por elemento: manualmente cuando el volumen es pequeño o, preferentemente, automatizado con Power Automate. Si la granularidad no es crítica, un diseño por contenedores (listas o carpetas por grupo) simplifica la administración y mejora el rendimiento. Sea cual sea el enfoque, valida con cuentas de prueba, registra auditoría y evita basarte en vistas o audience targeting para proteger información sensible.
Guía rápida paso a paso
Opción manual
- Abrir permisos avanzados del elemento.
- Detener herencia.
- Quitar Members/Visitors/Everyone.
- Conceder Read o Edit solo al grupo de Division/Group.
- Probar con una cuenta del grupo objetivo.
Opción automatizada
- Crear flujo al crear/modificar.
- Validar que Division/Group no esté vacío.
- Obtener Id del grupo y Id del rol.
- Romper herencia (sin copiar permisos).
- Conceder permisos al grupo (y, si aplica, a Owners).
- Registrar estado y fecha de ejecución.
Advertencias y límites
- Un gran número de elementos con permisos únicos puede afectar rendimiento y administración. Planifica capacidad y monitoreo.
- Los filtros y el audience targeting no reemplazan la seguridad: no confíes en ellos para ocultar datos sensibles.
- Documenta qué roles usas (Read, Edit) y por qué, para evitar escaladas innecesarias de privilegios.
- Capacita a los Owners del sitio en “Permisos avanzados” y “Check Permissions” para diagnósticos rápidos.
Conclusión
Si necesitas que “PU Group” vea solo lo suyo y “GR&A Group” solo lo suyo, no hay atajos de columna: rompe la herencia y aplica permisos únicos por elemento. Automatiza con Power Automate para consistencia, o rediseña por contenedores cuando la simplicidad prime. Con la checklist y las plantillas anteriores, podrás implementarlo de forma segura, repetible y alineada a buenas prácticas de Microsoft 365.