---
title: "Policy Acknowledgement: requisitos y permisos"
description: "Revise los requisitos de implementación, Microsoft Graph, el centro, el contenido de origen y el servicio antes de configurar Policy Acknowledgement."
url: https://vitextra.com/es/support/kb/10497
language: es
published: 2026-11-08
modified: 2026-11-08
products:
  - "Policy Acknowledgement"
author: "Lidija Reising"
tags: ["requisitos Policy Acknowledgement", "permisos Graph", "permisos SharePoint", "consentimiento del servicio"]
---

# Policy Acknowledgement: requisitos y permisos

Revise los requisitos de implementación, Microsoft Graph, el centro, el contenido de origen y el servicio antes de configurar Policy Acknowledgement.

Prepare los permisos de implementación, el acceso al contenido de origen y los roles del producto antes de iniciar una campaña de políticas. La aprobación de los permisos de Microsoft Graph y la asignación de roles del producto son tareas independientes.

## Acceso para implementación y configuración

La solución es un paquete SPFx para SharePoint Online. Siga [KB10035. Cómo instalar un producto Vitextra en SharePoint Online](https://vitextra.com/es/support/kb/10035) para instalar el paquete. La persona que realiza la configuración inicial debe poder administrar el sitio de almacenamiento seleccionado y crear las listas necesarias. Para crear un sitio nuevo, también necesita permiso para crear dicho sitio en el inquilino.

Antes de configurar un grupo de administradores, Policy Admin utiliza como alternativa al propietario del sitio. Una vez asignado ese grupo, la pertenencia al grupo determina quién administra el producto. Los roles del producto no conceden automáticamente permiso para editar páginas de SharePoint ni implementar aplicaciones en el inquilino.

## Permisos de Microsoft Graph

El paquete de la solución solicita los siguientes ámbitos de Microsoft Graph:

| Ámbito | Uso en el producto |
|---|---|
| `User.Read.All` | Perfiles de empleados e información de la organización. |
| `GroupMember.Read.All` | Pertenencia a grupos utilizada por audiencias y roles. |
| `Directory.Read.All` | Datos del directorio para las búsquedas de empleados y grupos. |
| `Mail.Send` | Correo de recordatorio manual enviado desde el buzón del usuario actual. |

Solicite al administrador del inquilino que apruebe las solicitudes del paquete mediante el proceso de administración de acceso a las API de SharePoint de su organización. Si los selectores de empleados o grupos no cargan datos, verifique esas aprobaciones antes de cambiar las reglas de audiencia.

![Comprobaciones de instalación en Policy Admin](https://static.vitextra.com/articles/10497/installation-state-es.png)
*Comprobaciones de instalación en Policy Admin*

## Permisos del centro y del contenido

Asigne grupos de roles y aplique permisos en Policy Admin. Todos los elementos web deben conectarse al centro previsto. Los empleados también necesitan acceso al contenido original de la política: configurar una URL en la ficha no concede permiso sobre el archivo, la página o el sitio web externo referenciado.

Para controlar el acceso, utilice grupos explícitos de Entra ID o grupos de SharePoint del sitio del centro. No considere la opción **Todos los usuarios con licencia** una validación de licencias por usuario: la lógica actual de resolución de roles no comprueba la licencia de cada usuario.

## Comprobar cada capa de acceso de forma independiente

Un despliegue funcional requiere varias formas independientes de acceso. Quien despliega el paquete no tiene por qué ser quien gestiona las políticas, y un empleado no necesita privilegios de despliegue para leer una asignación. Separar estas responsabilidades facilita diagnosticar un fallo sin conceder acceso administrativo amplio como solución provisional.

| Capa de acceso | Comprobación de aceptación útil | Consecuencia habitual de un fallo |
|---|---|---|
| Paquete y página | El usuario previsto puede cargar la página publicada y el elemento web. | No se puede acceder a la aplicación o representarla. |
| Directorio | El operador autorizado puede resolver los empleados y grupos previstos. | Pueden fallar los selectores, la selección de audiencia o la resolución de roles. |
| Datos del centro | La cuenta puede leer los registros necesarios para su rol. | La página puede abrirse pero fallar al cargar políticas o asignaciones. |
| Contenido de origen | El empleado puede abrir directamente el documento o sitio web. | Una ficha de política visible puede tener contenido ilegible. |
| Escritura de pruebas | Un empleado piloto puede completar la ruta de registro configurada. | La lectura funciona, pero la confirmación falla. |
| Jerarquía de informes | El directorio contiene las relaciones de responsables esperadas. | El equipo de un responsable puede estar incompleto o diferir de lo esperado. |

Realice las comprobaciones con cuentas representativas. Un administrador que también sea propietario del sitio puede tener éxito mediante acceso elevado de SharePoint aunque un empleado normal falle. Del mismo modo, un propietario de política que pertenezca a varios grupos de roles no sustituye de forma fiable a una cuenta de autor restringida.

## Preparar el traspaso del despliegue

Registre la URL del centro elegida, la página de entrada de empleados, la página del lector, los grupos de roles y las ubicaciones de origen. Identifique quién puede mantener cada elemento. Un propietario de política debe saber a quién contactar si se mueve un archivo de origen; un administrador de soporte debe poder distinguir un problema de navegación de página de uno de escritura del servicio sin reconstruir el despliegue desde cero.

Compruebe la identidad de directorio y el responsable del empleado representativo antes de iniciar el piloto. Las campañas guardan información del empleado y del responsable en las asignaciones. Los cambios posteriores del directorio no significan que se haya reescrito cada campo de las asignaciones antiguas. Por ello, una reorganización requiere verificar los informes de equipo, además de comprobar que el empleado pueda iniciar sesión.

Para recordatorios manuales por correo, pruebe al operador que realmente los enviará. La aplicación usa el buzón de esa persona, mientras las notificaciones automáticas dependen de la configuración independiente del servicio. Aprobar una solicitud API relacionada con correo no verifica por sí solo un buzón, la entrega a un destinatario concreto ni el servicio en segundo plano.

Conserve los resultados de estas comprobaciones junto con los detalles del despliegue. Cuando se comunique un fallo, incluya la cuenta afectada, el centro y la página, la operación y la hora del error. Esto permite actuar mejor que una declaración general de que “los permisos se aprobaron”, porque cada capa puede funcionar o fallar independientemente.

## Servicio y modo de registro

El modo Service necesita una URL de servicio accesible y una verificación satisfactoria del consentimiento del administrador. Este consentimiento es independiente de la aprobación de permisos de Graph del paquete SPFx. Los recordatorios automáticos, las escalaciones y el procesamiento continuo de la audiencia requieren el componente de servicio independiente; introducir los ajustes no ejecuta esas tareas.

❗ **Importante**  
El modo Direct concede a los empleados permisos de contribución en las listas de asignaciones y confirmaciones. Revise [KB10500. Cómo configurar los roles y permisos de Policy Acknowledgement](https://vitextra.com/es/support/kb/10500) y [KB10509. Almacenamiento de datos de Policy Acknowledgement: modos Direct y Service](https://vitextra.com/es/support/kb/10509) antes de utilizar datos de empleados de producción. Los filtros de los elementos web y la segmentación de audiencias no sustituyen los permisos sobre los datos.