Policy Acknowledgement Les mises à jour automatiques du public, rappels planifiés et escalades nécessitent le composant de service distinct de Policy Acknowledgement. Policy Admin stocke les paramètres de connexion et de notification et peut interroger le service sur le consentement. Ces contrôles ne déploient pas le service et ne prouvent pas que toutes les tâches d’arrière-plan sont opérationnelles.
Obtenir les prérequis du service
Utilisez un compte d’administrateur du produit et obtenez le point de terminaison et les instructions de déploiement auprès de l’organisation ou du fournisseur responsable du composant. Ne considérez pas une adresse d’exemple dans un champ comme un point de terminaison de locataire provisionné. Confirmez qui gère la disponibilité du service, les autorisations d’application et les problèmes de livraison.
L’approbation des autorisations d’API SPFx et le consentement administrateur du service sont deux étapes distinctes. Terminez d’abord les exigences d’installation du produit. Si le service n’a pas été fourni ou testé, documentez l’indisponibilité du fonctionnement planifié au lieu de décrire des paramètres de campagne enregistrés comme une automatisation active.
Connecter et vérifier le consentement
- Ouvrez Policy Admin et sélectionnez Notifications.
- Renseignez URL du service de rappel avec l’URL de service fournie.
- Sélectionnez Ouvrir la page de consentement administrateur et effectuez le processus de consentement du locataire avec un administrateur autorisé.
- Revenez et sélectionnez Vérifier le consentement.
- Examinez le résultat et enregistrez les paramètres.
Le client ouvre la route /consent du service avec l’identifiant du locataire et interroge /api/status pour son état. Il attend une réponse positive consentGranted et peut enregistrer une valeur lastRun signalée. Ce sont des attentes d’intégration visibles dans le client, pas la documentation d’une implémentation serveur vérifiée.
Configurer les canaux et les calendriers
Examinez Courrier électronique, Microsoft Teams (flux d'activité et bot), Début de la plage sans notifications (heure), Fin de la plage sans notifications (heure) et Adresse électronique de l’expéditeur. Les heures utilisent une plage de 0 à 23 ; le comportement prévu des heures de silence dépend du service. Vérifiez sa gestion des fuseaux horaires au lieu de supposer que le paramètre du navigateur bloque lui-même les envois.
Pour chaque campagne, examinez la notification lors de l’attribution, les jours avant l’échéance, la notification à l’échéance, les rappels répétés de retard et les seuils d’escalade. Les composants WebPart stockent ces valeurs. Les horaires réels, la prévention des répétitions et les destinataires d’escalade doivent être vérifiés auprès du service qui les exécute.
Si une livraison Teams est nécessaire, déployez l’application requise et vérifiez le composant de livraison. Le commutateur L'application Teams a été ajoutée au locataire est un indicateur enregistré, pas une action d’installation ni la preuve qu’un bot existe. Consultez KB10511. Ajouter My Policies à Microsoft Teams. Les e-mails manuels de Team Compliance sont distincts et ne suivent pas ces commutateurs de service ; consultez KB10524. Envoyer des rappels manuels de politiques à votre équipe.
Choisir le mode d’enregistrement des confirmations
Définissez Qui enregistre les confirmations de lecture indépendamment de la configuration des canaux. Lors du passage au mode Service, vérifiez que le service peut enregistrer une confirmation pilote, puis réappliquez les autorisations des rôles depuis Rôles avec Enregistrer et appliquer les autorisations. Enregistrer le mode seul ne synchronise pas les autorisations. Consultez KB10509. Stockage des données Policy Acknowledgement : modes Direct et Service avant de vous fier au modèle de protection.
Distinguer les preuves de configuration des preuves opérationnelles
Le client peut montrer que les paramètres ont été enregistrés et que le point de terminaison d’état a répondu. Ces observations répondent à des questions plus étroites que « le service fonctionne ». Convenez avec le responsable des tâches déployées, des comptes ou autorisations d’application utilisés et du lieu de diagnostic d’une exécution échouée. L’interface WebPart ne fournit pas tous ces détails serveur.
| Observation | Ce qu’elle appuie | Ce qui reste à tester |
|---|---|---|
| Point de terminaison enregistré | Le client dispose d’une adresse à appeler. | Disponibilité, authentification et opération demandée. |
| Consentement signalé comme accordé | La réponse d’état signale le consentement. | Réussite de l’écriture et exécution des tâches requises. |
| Dernière exécution affichée | Le service a fourni une valeur liée à une exécution. | Quelle tâche a tourné, quelle campagne elle a traitée et son résultat. |
| Préférence de notification activée | Le canal demandé est configuré. | Livraison réelle au destinataire prévu. |
| Attribution créée | Une tâche employé existe dans le hub. | Si une notification a été envoyée et reçue. |
Conservez un petit dossier d’acceptation pour chaque fonction requise. Par exemple, un reçu employé teste le parcours de confirmation, tandis qu’un rappel planifié teste une autre opération. La réussite d’un parcours ne doit pas valider un autre sans preuve.
Tester délibérément un changement ultérieur du public
Pour un scénario continu, terminez et vérifiez d’abord le lancement initial. Organisez ensuite un changement contrôlé d’appartenance pour un employé test admissible et demandez au responsable du service d’identifier l’exécution censée le détecter. Vérifiez version de politique, compte et échéance de l’attribution créée, et si une attribution existante de même version devait empêcher un doublon.
C’est une procédure d’acceptation de déploiement, pas l’affirmation que le client exécute un planificateur d’appartenance. Si aucune attribution n’apparaît, distinguez « la tâche n’a pas tourné », « l’utilisateur a été exclu » et « un doublon a été correctement ignoré ». Examinez les données pertinentes avant de recréer répétitivement la campagne.
Utilisez la même démarche pour les notifications : documentez canal, destinataire et calendrier attendus, puis comparez exécution du service et résultats de livraison. Les rappels manuels envoyés depuis une boîte utilisateur sont un parcours distinct et ne prouvent pas le fonctionnement de la configuration automatique.
Effectuer les contrôles d’acceptation
Testez une petite campagne avec des destinataires connus. Vérifiez une attribution initiale, un rappel planifié, un ajout contrôlé au public si un fonctionnement continu est requis et une escalade de retard si utilisée. Notez l’heure attendue, le résultat réel et les informations d’exécution signalées par le service. Testez séparément les e-mails et Teams.
❗ Important
Un contrôle de consentement réussi ne prouve pas le bon fonctionnement du planificateur, la livraison des messages ni la protection des preuves. Une valeur de dernière exécution absente ou ancienne doit également être interprétée par le responsable du service. L’implémentation serveur distincte n’était pas disponible dans le projet WebPart ; ses autorisations, sa planification et sa reprise après échec doivent donc être vérifiées dans le déploiement.
Si les contrôles échouent, conservez la configuration et les détails des erreurs et contactez le responsable du service. Ne modifiez pas à répétition le consentement, le mode d’enregistrement ou les autorisations sans identifier l’opération défaillante. Utilisez KB10538. Dépanner les confirmations en échec et les notifications manquantes pour distinguer les échecs d’enregistrement des échecs de notification.
