Policy Acknowledgement 対象者の自動更新、定期リマインダー、エスカレーションには、別のPolicy Acknowledgementサービスコンポーネントが必要です。Policy Adminは接続と通知の設定を保存し、サービスに同意状況を問い合わせることができます。これらのコントロールでサービスが展開されるわけではなく、すべてのバックグラウンドジョブの動作も証明されません。
サービスの前提条件を揃える
製品管理者アカウントを使用し、そのコンポーネントを担当する組織または提供元から、サービスエンドポイントと展開手順を入手します。フィールドのサンプルアドレスを、準備済みのテナントエンドポイントとみなさないでください。サービスの可用性、アプリケーション権限、配信のトラブルシューティングを誰が管理するか確認します。
SPFx API権限の承認とサービスの管理者同意は別の手順です。まず製品のインストール要件を完了します。サービスが提供またはテストされていない場合、保存されたキャンペーン設定を稼働中の自動化と説明するのではなく、定期動作が利用できないことを記録してください。
接続して同意を確認する
- Policy Adminを開き、通知を選択します。
- リマインダーサービスURLに発行されたサービスURLを入力します。
- 管理者の同意ページを開くを選択し、権限を持つ管理者でテナントの同意プロセスを完了します。
- 戻って同意の確認を選択します。
- 結果を確認して設定を保存します。
クライアントはテナント識別子を付けてサービスの/consentルートを開き、/api/statusに状態を要求します。肯定的なconsentGranted応答を期待し、報告されたlastRunを保存できます。これらはクライアントで確認できる統合上の期待値であり、検証済みのサーバー実装の説明ではありません。
チャネルと予定を設定する
電子メール、Microsoft Teams (アクティビティフィードとボット)、通知を停止する時間帯の開始（時）、通知を停止する時間帯の終了（時）、送信者のメールアドレスを確認します。時刻は0～23の範囲で、通知を控える時間帯の実際の動作はサービスに依存します。ブラウザの設定自体が配信を抑止すると考えず、サービスのタイムゾーン処理を検証してください。
各キャンペーンで、割り当て時通知、期限前の日数、期日通知、期限超過後の繰り返しリマインダー、エスカレーション閾値を確認します。Webパーツはこれらの値を保存します。実際のタイミング、繰り返し抑制、エスカレーション先は、それらを実行するサービスで確認する必要があります。
Teamsへの配信が必要な場合は、必要なアプリを展開し、配信コンポーネントを検証します。Teams アプリがテナントに追加されましたスイッチは保存されたフラグであり、インストール操作やボットの存在を証明するものではありません。KB10511. My PoliciesをMicrosoft Teamsに追加する方法を参照してください。Team Complianceの手動メールは別の機能で、これらのサービススイッチには従いません。KB10524. チームに手動のポリシーリマインダーを送信する方法を参照してください。
確認の記録方法を選ぶ
閲覧確認の記録方法をチャネル設定とは独立して設定します。Serviceモードに切り替える場合、サービスが試験用の確認を記録できることを確かめてから、役割で保存して権限を適用するを使ってロール権限を再適用します。モードを保存するだけでは権限は同期されません。保護モデルに依存する前にKB10509. Policy Acknowledgementのデータ保存：DirectモードとServiceモードを確認してください。
設定の証拠と運用の証拠を区別する
クライアントは、設定が保存され、状態エンドポイントが応答を返したことを示せます。これらが答えるのは「サービスが動く」より狭い問いです。どのジョブが展開され、どのアカウントやアプリ権限を使い、失敗した実行をどこで診断できるかをサービス所有者と合意します。Webパーツ画面はサーバー側の全詳細を提供しません。
| 観察 | 裏付けること | まだ必要なテスト |
|---|---|---|
| エンドポイント保存済み | クライアントに呼び出すアドレスがある。 | 可用性、認証、要求した操作。 |
| 同意が付与済みと報告 | 状態応答が同意を報告する。 | 正常な書き込みと必要なジョブの実行。 |
| 最終実行値が表示 | サービスが実行関連の値を提供した。 | どのジョブが、どのキャンペーンを処理し、どう終わったか。 |
| 通知設定が有効 | 要求チャネルが設定された。 | 意図する受信者への実際の配信。 |
| 割り当て作成済み | ハブに従業員の作業が存在する。 | 通知が送信・受信されたか。 |
必要な各機能について簡単な受け入れ記録を残します。たとえば、従業員の受領証は確認経路をテストし、定期リマインダーは別の操作をテストします。一つの経路の成功を、証拠なしに別の経路の承認へ使うべきではありません。
後の対象者変更を意図的にテストする
常時実行のシナリオでは、まず初回開始を完了して検証します。その後、適格なテスト従業員に管理された所属変更を行い、それを検出すべき処理実行をサービス所有者に特定してもらいます。作成された割り当てのポリシーバージョン、アカウント、期限を確認し、既存の同じバージョンの割り当てで重複を防ぐべきか調べます。
これは展開の受け入れ手順であり、クライアントがメンバーシップのスケジューラーを動かすという主張ではありません。割り当てが出なければ、「ジョブが実行されなかった」「ユーザーが除外された」「重複が正しくスキップされた」を区別します。キャンペーンを繰り返し作り直す前に関連データを調べます。
通知にも同じ方法を使います。期待するチャネル、受信者、予定を記録し、サービス実行と配信結果を比較します。ユーザーのメールボックスからの手動リマインダーは別の経路で、自動通知設定が機能していることを証明できません。
受け入れ確認を行う
既知の受信者による小規模なキャンペーンをテストします。初回の割り当て、定期リマインダー、常時実行が必要な場合は管理された対象者追加、使用する場合は期限超過のエスカレーションを検証します。予定時刻、実際の結果、サービスが報告する実行情報を記録します。メールとTeamsは別々にテストします。
❗ 重要
同意チェックの成功は、スケジューラーの健全性、メッセージ配信、証跡保護を証明しません。最終実行の値がない、または古い場合もサービス所有者による解釈が必要です。Webパーツのプロジェクトには別のサーバー実装がなかったため、その権限、スケジュール処理、失敗からの復旧は展開環境で検証する必要があります。
確認に失敗した場合は、設定とエラーの詳細を保持し、サービス所有者に連絡します。失敗した操作を特定せずに、同意、記録モード、権限を繰り返し変更しないでください。記録の失敗と通知の失敗を分けるにはKB10538. 確認の失敗と通知が届かない問題を解決するを使用します。
