Policy Acknowledgement Une confirmation en échec et une notification absente peuvent survenir indépendamment. Un employé peut avoir une attribution valide sans recevoir d’e-mail, et une demande de confirmation peut écrire une preuve avant l’échec d’une étape ultérieure. Établissez quelle opération a échoué avant de réessayer ou de changer le mode d’écriture.
Préserver le contexte de l’échec
Consignez le hub, le compte de l’employé, la version de politique, l’identifiant d’attribution, le texte d’erreur et l’heure approximative. Demandez si l’employé a vu un reçu ou un message de réussite avant l’erreur. Rechargez My Policies et rouvrez l’attribution pour examiner son état actuel. Évitez les clics répétés pendant le traitement de la première requête.
Pour les notifications, identifiez si le message attendu était un rappel manuel, un e-mail automatique ou une notification Teams. Notez le destinataire prévu, la campagne et l’heure. Ces chemins n’utilisent pas tous le même expéditeur ni la même implémentation.
Diagnostiquer une confirmation en échec
En mode Direct, le navigateur lit l’empreinte précédente, ajoute un enregistrement de confirmation, puis met à jour l’attribution. Ces écritures sont distinctes. Des erreurs d’autorisation, de connectivité ou de liste peuvent interrompre la séquence et laisser une preuve sans l’état d’attribution attendu.
En mode Service, le navigateur envoie une requête POST au point de terminaison configuré /api/acknowledge via la connexion au service, puis lit l’enregistrement obtenu depuis SharePoint. La requête peut échouer en raison de la disponibilité du service, de l’authentification, du consentement, du format de réponse ou de l’accès à l’enregistrement sauvegardé. Un échec de lecture après une écriture réussie du service diffère d’une requête n’ayant jamais atteint le service.
Un administrateur doit comparer la référence de confirmation et l’état de l’attribution à la preuve correspondante, en utilisant le compte, la version et l’heure pour l’investigation. Ne modifiez pas les empreintes des preuves et ne supprimez pas un enregistrement pour donner l’apparence d’une nouvelle tentative propre. Si une sauvegarde partielle est confirmée, convenez d’une correction contrôlée avec le responsable du hub ou du service.
❗ Important
Une requête de service en échec ne bascule pas automatiquement vers l’écriture directe. Changer de mode modifie les autorisations et le chemin d’écriture des preuves ; ce n’est pas une option de nouvelle tentative sans conséquence. Une deuxième soumission peut aussi créer des preuves supplémentaires si la première opération a partiellement réussi.
Diagnostiquer les rappels manuels absents
Les rappels manuels de retard sont envoyés via la boîte aux lettres de l’utilisateur connecté. Vérifiez la capacité d’envoi de ce compte et examinez ses messages envoyés si disponibles. L’expéditeur configuré des notifications automatiques et les heures de silence ne contrôlent pas ce chemin manuel.
Les messages sont envoyés séquentiellement pour les attributions. Une opération groupée peut envoyer certains messages puis échouer ; une écriture d’audit peut aussi échouer après l’envoi. Déterminez quels destinataires ou attributions ont déjà été traités avant de répéter toute l’action. Consultez KB10524. Envoyer des rappels manuels de politiques à votre équipe pour le processus de rappel manuel et ses limites.
Diagnostiquer les messages automatiques absents
- Vérifiez que l’attribution attendue existe ; un aperçu du public n’est pas un lancement terminé.
- Vérifiez les paramètres de notification e-mail ou Teams concernés et les heures de silence configurées.
- Confirmez l’URL du service et l’état du consentement administrateur.
- Examinez les informations de dernière exécution signalées, puis demandez au responsable du service d’examiner la tâche réelle et les résultats de livraison.
- Vérifiez le compte destinataire et examinez la livraison séparément de la création d’attribution.
Le point de terminaison d’état peut signaler le consentement et une dernière exécution, mais un contrôle réussi ne prouve pas qu’une tâche de notification a été exécutée pour cette campagne ou qu’un message a été livré. Enregistrer des préférences de notification ne déploie pas le service externe. L’application Teams personnelle fournie ne prouve pas, à elle seule, qu’un bot de notification est installé.
Rapprocher le résultat visible avant de réessayer
| Observation | Ce que l’administrateur doit examiner |
|---|---|
| L’employé a reçu un reçu mais le compteur de campagne est ancien | D’abord états d’attribution et de preuve ; l’actualisation du compteur est distincte. |
| Une preuve existe mais l’attribution reste ouverte | Si la mise à jour d’attribution a échoué après l’écriture de preuve. |
| Le service signale un enregistrement sauvegardé mais le lecteur affiche une erreur | Identifiant retourné et capacité du client à le lire. |
| Certains rappels manuels sont arrivés avant l’erreur groupée | Quels messages d’attribution ont été envoyés avant l’échec. |
| Une attribution existe mais aucun message automatique n’est arrivé | Exécution du service et livraison, séparément de la création d’attribution. |
Ne déduisez pas une transaction complète d’un seul indicateur. Une réussite dans le journal du service, une ligne SharePoint, un reçu dans le navigateur et un compteur actualisé décrivent des étapes différentes. Rapprochez-les avec attribution, version, compte et heure plutôt qu’avec seulement un titre partagé entre plusieurs publications.
Si une deuxième soumission a déjà été tentée, dites-le à l’administrateur et fournissez les heures approximatives. Préservez les enregistrements pendant l’analyse de la séquence. Supprimer une preuve apparemment en double peut rompre la chaîne ou retirer le contexte nécessaire à la compréhension de l’échec initial.
Préparer une transmission ciblée au support
Fournissez l’opération en échec, le mode d’écriture, le hub et la page, le compte affecté, la version et l’identifiant d’attribution. Incluez l’erreur exacte et précisez si la source était lisible, si le bouton était disponible et si un reçu est apparu. Pour les cas de service, demandez au responsable de corréler l’heure à la requête et au résultat ; n’incluez aucun jeton d’authentification ni secret.
Pour les messages absents, identifiez le parcours attendu : rappel manuel, e-mail automatique ou livraison Teams. Indiquez les vérifications faites sur l’attribution et l’expéditeur ou l’exécution du service. Une préférence enregistrée n’est pas une preuve de livraison, et un message sur un canal ne prouve pas la réussite de l’autre.
Après correction du défaut identifié, testez une opération contrôlée et examinez son résultat complet avant de répéter une action groupée. Cela vérifie le rétablissement tout en gardant compréhensibles la cause et les éventuels enregistrements partiels restants. Conservez les détails initiaux afin qu’une nouvelle tentative réussie n’efface pas l’explication des événements antérieurs.
Vérifier le rétablissement
Utilisez une attribution connue pour confirmer qu’une confirmation réussie produit le reçu et l’état d’attribution attendus. Pour les notifications, vérifiez le chemin de livraison prévu avec le responsable du service ou l’expéditeur, puis l’accès de l’employé à l’attribution. Conservez l’erreur initiale et les constats d’écriture partielle dans le dossier d’investigation. Consultez KB10525. Connecter le service de politiques et configurer les notifications automatiques pour la configuration du service et KB10526. Consulter les confirmations de politiques antérieures et leurs reçus pour l’interprétation des reçus.
