Policy Acknowledgement Автоматическое обновление аудитории, запланированные напоминания и эскалации требуют отдельного служебного компонента Policy Acknowledgement. Policy Admin сохраняет параметры подключения и уведомлений и может запросить у службы состояние согласия. Эти элементы управления не развёртывают службу и не доказывают работоспособность всех фоновых заданий.
Подготовка необходимых компонентов службы
Используйте учётную запись администратора продукта и получите конечную точку службы и инструкции по развёртыванию у организации или поставщика, отвечающего за этот компонент. Не считайте пример адреса в поле подготовленной конечной точкой вашего клиента. Уточните, кто отвечает за доступность службы, разрешения приложения и диагностику доставки.
Одобрение разрешений API SPFx и согласие администратора для службы — разные шаги. Сначала выполните требования установки продукта. Если служба не предоставлена или не проверена, зафиксируйте недоступность запланированной обработки, а не описывайте сохранённые параметры кампании как работающую автоматизацию.
Подключение и проверка согласия
- Откройте Policy Admin и выберите Уведомления.
- Укажите выданный URL службы в Адрес службы напоминаний.
- Нажмите Открыть страницу согласия администратора и завершите процедуру согласия клиента с уполномоченным администратором.
- Вернитесь и нажмите Проверить согласие.
- Проверьте результат и сохраните настройки.
Клиент открывает маршрут службы /consent с идентификатором клиента и запрашивает /api/status для проверки состояния. Он ожидает положительный ответ consentGranted и может сохранить сообщённое значение lastRun. Это видимые в клиенте ожидания интеграции, а не описание проверенной серверной реализации.
Настройка каналов и расписаний
Проверьте Электронная почта, Microsoft Teams (лента активности и бот), Начало периода без уведомлений (час), Конец периода без уведомлений (час) и Адрес электронной почты отправителя. Часы задаются в диапазоне от 0 до 23; фактическая работа тихих часов зависит от службы. Проверьте обработку часовых поясов, не предполагая, что настройка в браузере сама блокирует доставку.
Для каждой кампании проверьте уведомление при назначении, дни до срока, уведомление в день срока, повторные напоминания о просрочке и пороги эскалации. Веб-части сохраняют эти значения. Фактическое время, подавление повторов и получателей эскалации нужно проверять в службе, которая их выполняет.
Если требуется доставка через Teams, разверните нужное приложение и проверьте компонент доставки. Переключатель Приложение Teams добавлено в тенант — сохранённый флаг, а не действие установки или доказательство наличия бота. См. KB10511. Добавление My Policies в Microsoft Teams. Ручные письма Team Compliance независимы и не подчиняются этим переключателям службы; см. KB10524. Как отправлять команде напоминания о политиках вручную.
Выбор способа записи подтверждений
Настройте Кто создаёт записи об ознакомлении отдельно от каналов. При переходе в режим Service убедитесь, что служба записывает пилотное подтверждение, затем повторно примените разрешения ролей из Роли кнопкой Сохранить и применить права. Одно сохранение режима не синхронизирует разрешения. Изучите KB10509. Хранение данных Policy Acknowledgement: режимы Direct и Service, прежде чем полагаться на модель защиты.
Отличие подтверждения настройки от подтверждения работы
Клиент может показать, что настройки сохранены и конечная точка статуса вернула ответ. Эти наблюдения отвечают на более узкие вопросы, чем «служба работает». Согласуйте с владельцем службы, какие задания развёрнуты, какие учётные записи или разрешения приложения они используют и где диагностировать неудачный запуск. Интерфейс веб-части не предоставляет все эти серверные сведения.
| Наблюдение | Что оно подтверждает | Что ещё нужно проверить |
|---|---|---|
| Конечная точка сохранена | У клиента есть адрес для обращения. | Доступность, аутентификацию и запрошенную операцию. |
| Согласие отмечено как предоставленное | Ответ статуса сообщает о согласии. | Успешную запись и выполнение необходимых заданий. |
| Показано значение последнего запуска | Служба передала значение, связанное с запуском. | Какое задание выполнялось, какую кампанию обработало и с каким результатом. |
| Предпочтение уведомлений включено | Требуемый канал настроен. | Фактическую доставку нужному получателю. |
| Назначение создано | Работа сотрудника существует в центре. | Было ли уведомление отправлено и получено. |
Ведите небольшой журнал приёмки каждой требуемой функции. Например, квитанция сотрудника проверяет путь подтверждения, а запланированное напоминание — другую операцию. Успех одного пути не должен без доказательств закрывать проверку другого.
Целенаправленная проверка последующего изменения аудитории
Для постоянного сценария сначала завершите и проверьте первоначальный запуск. Затем организуйте контролируемое изменение членства подходящего тестового сотрудника и попросите владельца службы указать запуск обработки, который должен его обнаружить. Проверьте версию политики, учётную запись и срок созданного назначения, а также должно ли существующее назначение той же версии предотвращать дублирование.
Это процедура приёмки развёртывания, а не утверждение, что клиент запускает планировщик членства. Если назначение не появилось, различайте «задание не запускалось», «пользователь исключён» и «дубликат корректно пропущен». Изучите соответствующие данные, прежде чем многократно создавать кампанию заново.
Применяйте тот же подход к уведомлениям: документируйте ожидаемые канал, получателя и расписание, затем сопоставляйте выполнение службы и результаты доставки. Ручные напоминания из почтового ящика пользователя — отдельный путь, который не доказывает работоспособность автоматических уведомлений.
Приёмочные проверки
Проверьте небольшую кампанию с известными получателями. Проверьте первоначальное назначение, запланированное напоминание, контролируемое добавление в аудиторию при необходимости постоянного режима и эскалацию просрочки, если она используется. Запишите ожидаемое время, фактический результат и сообщённые службой сведения о запуске. Отдельно проверьте электронную почту и Teams.
❗ Важно
Успешная проверка согласия не доказывает исправность планировщика, доставку сообщений или защиту доказательств. Отсутствующее или старое значение последнего запуска также требует интерпретации владельцем службы. Отдельная серверная реализация отсутствовала в проекте веб-частей, поэтому её разрешения, расписания и восстановление после ошибок нужно проверить в развёрнутой среде.
При неудачных проверках сохраните конфигурацию и сведения об ошибке и обратитесь к владельцу службы. Не меняйте многократно согласие, режим записи или разрешения, не определив сбойную операцию. Используйте KB10538. Устранение ошибок сохранения подтверждений и отсутствующих уведомлений, чтобы отделить ошибки записи от ошибок уведомлений.
