Las actualizaciones automáticas de audiencia, los recordatorios programados y los escalamientos requieren el componente de servicio independiente de Policy Acknowledgement. Policy Admin almacena ajustes de conexión y notificación y puede consultar al servicio sobre el consentimiento. Estos controles no despliegan el servicio ni demuestran que todas las tareas en segundo plano estén operativas.
Obtener los requisitos previos del servicio
Use una cuenta de administrador del producto y obtenga el punto de conexión del servicio y las instrucciones de despliegue de la organización o proveedor responsable de ese componente. No trate una dirección de ejemplo de un campo como un punto de conexión aprovisionado para el inquilino. Confirme quién gestiona la disponibilidad del servicio, los permisos de aplicación y los problemas de entrega.
La aprobación de permisos API de SPFx y el consentimiento del administrador del servicio son pasos distintos. Complete primero los requisitos de instalación del producto. Si el servicio no se ha suministrado o probado, documente que el comportamiento programado no está disponible en lugar de describir los ajustes guardados de campaña como automatización activa.
Conectar y comprobar el consentimiento
- Abra Policy Admin y seleccione Notificaciones.
- Introduzca en URL del servicio de recordatorio la URL del servicio proporcionada.
- Seleccione Abrir la página de consentimiento del administrador y complete el proceso de consentimiento del inquilino con un administrador autorizado.
- Vuelva y seleccione Verificar el consentimiento.
- Revise el resultado y guarde los ajustes.
El cliente abre la ruta /consent del servicio con el identificador del inquilino y solicita /api/status para conocer su estado. Espera una respuesta positiva de consentGranted y puede guardar un lastRun comunicado. Son expectativas de integración visibles en el cliente, no documentación de una implementación de servidor verificada.

Configurar canales y calendarios
Revise Correo electrónico, Microsoft Teams (feed de actividad y bot), Inicio del período sin notificaciones (hora), Fin del período sin notificaciones (hora) y Dirección de correo electrónico del remitente. Las horas usan un intervalo de 0 a 23; el comportamiento previsto de las horas de silencio depende del servicio. Verifique su tratamiento de zonas horarias en lugar de suponer que el ajuste del navegador suprime por sí mismo las entregas.
Para cada campaña, revise la notificación al asignar, los días previos al plazo, la notificación en la fecha límite, los recordatorios repetidos tras el vencimiento y los umbrales de escalamiento. Los elementos web almacenan esos valores. La temporización real, la supresión de repeticiones y los destinatarios de escalamiento deben comprobarse en el servicio que los ejecuta.
Si se necesita entrega por Teams, despliegue la aplicación requerida y verifique el componente de entrega. El interruptor La aplicación de Teams se ha agregado al espacio empresarial es una marca almacenada, no una acción de instalación ni prueba de que exista un bot. Consulte KB10511. Cómo añadir My Policies a Microsoft Teams. Los correos manuales de Team Compliance son independientes y no siguen estos interruptores del servicio; consulte KB10524. Cómo enviar recordatorios manuales de políticas a su equipo.
Elegir cómo se registran las confirmaciones
Configure ¿Quién registra las confirmaciones de lectura? independientemente de los canales. Al cambiar al modo Service, confirme que el servicio puede registrar una confirmación piloto y vuelva a aplicar los permisos de roles desde Roles mediante Guardar y aplicar permisos. Guardar solo el modo no sincroniza los permisos. Revise KB10509. Almacenamiento de datos de Policy Acknowledgement: modos Direct y Service antes de depender del modelo de protección.
Separar pruebas de configuración de pruebas operativas
El cliente puede mostrar que se guardaron ajustes y que el punto de estado devolvió una respuesta. Esas observaciones responden a preguntas más limitadas que “el servicio funciona”. Acuerde con el propietario qué tareas están desplegadas, qué cuentas o permisos de aplicación usan y dónde diagnosticar una ejecución fallida. La interfaz del elemento web no proporciona todos esos detalles del servidor.
| Observación | Qué respalda | Qué sigue necesitando prueba |
|---|---|---|
| Punto de conexión guardado | El cliente tiene una dirección que llamar. | Disponibilidad, autenticación y operación solicitada. |
| Consentimiento comunicado como concedido | La respuesta de estado comunica consentimiento. | Escritura correcta y ejecución de tareas requeridas. |
| Valor de última ejecución mostrado | El servicio aportó un valor relacionado con ejecución. | Qué tarea se ejecutó, qué campaña procesó y su resultado. |
| Preferencia de notificación activada | El canal solicitado está configurado. | Entrega real al destinatario previsto. |
| Asignación creada | Existe trabajo del empleado en el centro. | Si se envió y recibió una notificación. |
Mantenga un registro pequeño de aceptación para cada función requerida. Por ejemplo, un justificante de empleado prueba la ruta de confirmación, mientras un recordatorio programado prueba otra operación. El éxito en una ruta no debe aprobar otra sin pruebas.
Probar deliberadamente un cambio posterior de audiencia
Para un escenario continuo, complete y verifique primero el inicio inicial. Después prepare un cambio controlado de pertenencia de un empleado de prueba elegible y pida al propietario del servicio que identifique la ejecución que debería detectarlo. Compruebe versión de política, cuenta y plazo de la asignación creada e inspeccione si una asignación existente de la misma versión debería evitar duplicados.
Este es un procedimiento de aceptación del despliegue, no una afirmación de que el cliente ejecute un programador de pertenencia. Si no aparece asignación, distinga entre “la tarea no se ejecutó”, “se excluyó al usuario” y “se omitió correctamente un duplicado”. Inspeccione los datos pertinentes antes de recrear repetidamente la campaña.
Use el mismo enfoque para notificaciones: documente canal, destinatario y horario esperados y compare después ejecución del servicio y resultados de entrega. Los recordatorios manuales enviados desde el buzón de un usuario son otra ruta y no demuestran que funcione la configuración automática de notificaciones.
Ejecutar comprobaciones de aceptación
Pruebe una campaña pequeña con destinatarios conocidos. Verifique una asignación inicial, un recordatorio programado, una incorporación controlada a la audiencia si se necesita comportamiento continuo y un escalamiento por vencimiento si se utiliza. Registre la hora esperada, el resultado real y la información de ejecución comunicada por el servicio. Pruebe correo y Teams por separado.
❗ Importante
Una comprobación de consentimiento correcta no demuestra la salud del programador, la entrega de mensajes ni la protección de las pruebas. Un valor de última ejecución ausente o antiguo también requiere interpretación del propietario del servicio. La implementación independiente del servidor no estaba disponible en el proyecto de elementos web, por lo que sus permisos, programación y recuperación ante errores deben verificarse en el despliegue.
Si las comprobaciones fallan, conserve la configuración y los detalles del error y contacte con el propietario del servicio. No cambie repetidamente consentimiento, modo de registro o permisos sin identificar la operación fallida. Use KB10538. Resolver confirmaciones fallidas y notificaciones ausentes para separar fallos de registro de fallos de notificación.