ライフサイクル ワークフローのデプロイを計画する
ライフサイクル ワークフローは、自動化を増やすことにより、組織が Microsoft Entra ユーザーを管理するのに役立ちます。 ライフサイクル ワークフローを使うと、次のことができます。
- タスクを簡素化および自動化する他のワークフローにより、人事主導のプロビジョニング プロセスを拡張します。
- ワークフロー プロセスを一元化して、ワークフローのすべての作成と管理を 1 か所で簡単に行うことができるようにします。
- ワークフローの履歴と監査ログを使って、最小限の労力でワークフローのシナリオのトラブルシューティングを行います。
- 大規模なユーザー ライフサイクルを管理します。 組織が成長しても、ユーザー のライフサイクルの管理に必要な他のリソースは少なく済みます。
- 自動化されたライフサイクル ワークフローにより、これまで行われていた手動タスクを削減または排除します
- ロジック アプリを適用し、既存のロジック アプリを使ってワークフローをさらに複雑なシナリオ用に拡張します
ライフサイクル ワークフローは Microsoft Entra ID Governance の機能です。 他に、エンタイトルメント管理、アクセス レビュー、Privileged Identity Management (PIM)、使用条件などの機能があります。 これらの機能によって、次の疑問を解決できます。
- どのユーザーがどのリソースへのアクセス権を持つ必要があるか。
- それらのユーザーはそのアクセス権によって何を実行するか。
- アクセスを管理するための効果的な組織的管理は存在しているか。
- 監査者は管理が機能していることを確認できるか。
- ユーザーは、入社初日の準備ができているか、またはタイムリーにアクセス権が削除されているか。
ライフサイクル ワークフローのデプロイを計画することは、組織内のユーザーに対する望ましいガバナンス戦略を確実に実現するために不可欠です。
デプロイ計画について詳しくは、「Microsoft Entra のデプロイ計画」をご覧ください。
ライセンス要件
この機能を使用するには、Microsoft Entra ID Governance または Microsoft Entra スイートのライセンスが必要です。 要件に適したライセンスを見つけるには、「Microsoft Entra ID ガバナンス ライセンスの基礎」をご覧ください。
ライフサイクル ワークフローのデプロイ プロジェクトを計画する
組織のニーズを考慮して、環境にライフサイクル ワークフローをデプロイするための戦略を決定します。
適切な関係者を関わらせる
テクノロジ プロジェクトが失敗した場合、その原因は通常、影響、結果、および責任に対する想定の不一致です。 これらの落とし穴を回避するには、適切な関係者が担当していることを確認し、またそのプロジェクトの役割が明確になっていることを確認します。
ライフサイクル ワークフローの場合は、組織内の次のチームの代表者を含めることが考えられます。
IT 管理は、IT インフラストラクチャ、クラウドへの投資、サービスとしてのソフトウェア (SaaS) アプリを管理します。 このチームは次のことを行います。
- Microsoft 365 や Microsoft Entra ID など、インフラストラクチャとアプリに対するライフサイクル ワークフローをレビューします。
- ユーザーに対してライフサイクル ワークフローをスケジュールして実行します。
- GRAPH または拡張性を使って、プログラムによるライフサイクル ワークフローが管理およびレビューされるようにします。
セキュリティ所有者は、プランが組織のセキュリティ要件を満たすことを確認します。 このチームは次のことを行います。
- ライフサイクル ワークフローが組織のセキュリティ ポリシーを満たすことを確認します
コンプライアンス マネージャーは、組織が内部ポリシーに従い、規制を遵守していることを確認します。 このチームは次のことを行います。
- 新しいライフサイクル ワークフローのレビューを要求またはスケジュールします。
- コンプライアンスのための文書と記録の保存など、ライフサイクル ワークフローのレビューに関するプロセスと手順を評価します。
- 最も重要なリソースについて、過去のレビューの結果をレビューします。
人事担当者 - 人事プロビジョニングのシナリオにおいて属性のマッピングと設定を支援します。 このチームは次のことを行います。
- employeeHireDate と employeeLeaveDateTime の設定に使われる属性の決定を手伝います。
- ソース属性が設定され、値を持っていることを確認します
- employeeHireDate と employeeLeaveDateTime にマップできる代替属性を特定して提案します
開発チームは、組織のアプリケーションを構築および管理します。 このチームは次のことを行います。
- GRAPH を使ってカスタム ワークフローを開発します
- 拡張性を使って、ライフサイクル ワークフローと Logic Apps を統合します。
連絡を計画する
コミュニケーションは、新しいビジネス プロセスの成功に必要不可欠です。 エクスペリエンスがいつ、どのように変わるのかについて、ユーザーに事前に連絡します。 問題が発生した場合にサポートを受ける方法を伝えます。
アカウンタビリティの変更の連絡
ライフサイクル ワークフローは、手動プロセスの責任のビジネス所有者への移行をサポートします。 各チームの責任の明確なプロセスと理解を確立します。 IT 部門からこれらのプロセスを切り離すことで、正確さと自動化が向上します。 このシフトによって、リソース所有者の説明責任と責務の文化が変わります。 この変更を事前に伝えて、リソース所有者がトレーニングを受けられるよう、また、分析情報を用いて適切な決定を行えるようにします。
ライフサイクル ワークフローの概要
このセクションでは、デプロイを計画する前に知っておく必要があるライフサイクル ワークフローの概念について説明します。
ライフサイクル ワークフローをデプロイするための前提条件
ライフサイクル ワークフローをデプロイする前に確認しておく必要のある、組織とテクノロジに関する重要な情報を次に示します。 ライフサイクル ワークフローのデプロイを試みる前に、各項目に対して "はい" と答えられることを確認します。
| Item | 説明 | ドキュメント |
|---|---|---|
| インバウンドのプロビジョニング | Workday や SuccessFactors からの HR インバウンド、MIM など、Microsoft Entra で従業員のユーザー アカウントを作成するためのプロセスがあります。 または、Active Directory でユーザー アカウントを作成するプロセスがあり、それらのアカウントが Microsoft Entra ID に対してプロビジョニングされます。 |
Workday から Active Directory Workday から Microsoft Entra ID SuccessFactors から Active Directory SuccessFactors から Microsoft Entra ID Microsoft Entra Connect Microsoft Entra Connect クラウド同期 API 駆動型インバウンド プロビジョニング (パブリック プレビュー) |
| 属性の同期 | Microsoft Entra ID のアカウントに、employeeHireDate と employeeLeaveDateTime 属性が設定されています。 これらの値は、アカウントが HR システムから作成されるとき、または Microsoft Entra Connect やクラウド同期を使って AD から同期されるときに設定される場合があります。部署などのスコープを決定するために使われ、データが設定される、またはデータを設定できる追加の属性があります。 | ライフサイクル ワークフローの属性を同期する方法 |
ワークフローの各部分について
ライフサイクル ワークフローのデプロイの計画を始める前に、ワークフローの各部分とライフサイクル ワークフローに関する用語について、理解しておく必要があります。
ドキュメント「ライフサイクル ワークフローについて」では、ポータルを使ってワークフローの各部分が説明されています。 ドキュメント「ライフサイクル ワークフローの開発者向け API リファレンス」では、Graph の例を使ってワークフローの各部分が説明されています。
このドキュメントを使って、デプロイする前にワークフローの各部分を理解できます。
制限と制約
次の表は、ライフサイクル ワークフローを作成してデプロイするときに注意する必要がある情報です。
| Item | 説明 |
|---|---|
| Workflows | テナントあたり 50 個のワークフローに制限 |
| カスタム タスクの数 | ワークフローあたり 25 個に制限 |
| offsetInDays の値の範囲 | -180 日から 180 日の間 |
| ワークフローの実行スケジュール | 既定は 3 時間ごと - 1 から 24 時間の範囲で実行するように設定できます |
| カスタム タスク拡張機能 | 100 個に制限 |
| オンデマンド ユーザーの制限 | 最大 10 ユーザーに対してオンデマンド ワークフローを実行できます |
| 拡張性コールバック タイムアウトの制限 | 最小 3 分 - 最大 5 時間 |
次の追加情報に注意する必要があります。
- リアルタイムの退職者と異動者のシナリオでスケジュールを有効にすることはできません。 これは仕様です。
ライフサイクル ワークフロー作成チェックリスト
次の表は、ワークフローを設計および計画するときに使用できる手順の簡単なチェックリストです。
| 手順 | 説明 |
|---|---|
| シナリオを決定する | ワークフローで対処するシナリオを決定します |
| 実行条件を決定する | ワークフローを実行するユーザーとタイミングを決定します |
| タスクを確認する | タスクを確認し、追加タスクをワークフローに追加します |
| ワークフローを作成する | 計画して設計した後、ワークフローを作成します。 |
| パイロットを計画する | ワークフローのパイロット、実行、テストを計画します。 |
シナリオを決定する
ポータルでライフサイクル ワークフローを作成前に、デプロイするシナリオを決定する必要があります。 現在、使用可能なシナリオの一覧については、次の表をご覧ください。 これらはポータルで使用できるテンプレートに基づいており、それぞれに関連付けられているタスクの一覧が示されています。
| シナリオ | 定義済みタスク |
|---|---|
| 雇用前の従業員をオンボードする | TAP を生成してメールを送信する |
| Onboard new hire employee (新入社員をオンボードする) | ユーザー アカウントを有効にする ウェルカム メールを送信する ユーザーをグループに追加する |
| 従業員のリアルタイム退職 | ユーザーをすべてのグループから削除する ユーザーをすべての Teams から削除する ユーザー アカウントを削除する |
| Pre-Offboarding of an employee (従業員のオフボーディング前) | ユーザーを選択したグループから削除する ユーザーを選択した Teams から削除する |
| 従業員をオフボードする | ユーザー アカウントを無効にする ユーザーをすべてのグループから削除する ユーザーをすべての Teams から削除する |
| Post-Offboarding of an employee (従業員のオフボーディング後) | ユーザーのすべてのライセンスを削除する ユーザーをすべての Teams から削除する ユーザー アカウントを削除する |
| リアルタイムの従業員の変更 | カスタム タスク拡張機能を実行する |
| Employee group membership changes (従業員グループ メンバーシップの変更) | ユーザーのアクセス パッケージ割り当ての削除 選択した Teams からユーザーを削除する マネージャーにユーザーの移動を通知するメールを送信する |
| Employee job profile change (従業員ジョブ プロファイルの変更) | マネージャーにユーザーの移動を通知するメールを送信する 選択したグループからユーザーを削除する 選択した Teams からユーザーを削除する ユーザー アクセス パッケージの割り当てを要求する |
Employee group membership changes (従業員グループ メンバーシップの変更)
組み込みテンプレートについて詳しくは、「ライフサイクル ワークフロー テンプレート」をご覧ください。
実行条件を決定する
シナリオを決定したので、シナリオを適用する組織内のユーザーを確認する必要があります。
ワークフローの実行条件の部分では、ワークフローが誰に対して (スコープ) いつ (トリガー) 実行されるかを定義します。
スコープは、ワークフローの実行対象を決定します。 これは、条件に基づいてユーザーをフィルター処理するルールによって定義されます。 たとえば、ルール "rule": "(department eq 'sales')" は、営業部門のメンバーであるユーザーに対してのみタスクを実行します。
トリガーは、ワークフローが実行されるタイミングを決定します。 これは、オンデマンド (即時) に設定するか、スケジュールに従って実行することができます。 ポータルであらかじめ定義されているテンプレートのほとんどは、トリガー条件が満たされた場合スケジュールに従って実行されます。
属性の情報
ワークフローのスコープのルール セクションでは属性が使われます。 次の条件を追加して、タスクを適用するユーザーをさらに絞り込むことができます。
- および
- かつ次の値ではない
- または
- または次の値ではない
また、多数のユーザー属性から選ぶこともできます。
ただし、実行条件で使う属性を選ぶ前に、属性にデータが設定されていること、または必要なデータの設定を開始できることを確認する必要があります。
これらの属性のすべてが既定で設定されるわけではないため、HR インバンド クラウド専用プロビジョニング、Microsoft Entra Connect、またはクラウド同期を使うときに、HR 管理者または IT 管理者に確認する必要があります。
時刻の情報
次に示すのは、ワークフローの設計時に注意する必要があるタイム ゾーンに関する重要な情報です。
- Workday と SAP SF は、常に協定世界時 (UTC) で時刻を送信します。
- タイム ゾーンが 1 つの場合は、時刻部分を自分に合ったものにハードコーディングすることをお勧めします。 たとえば、新規採用シナリオの場合は午前 5 時、在職最終日シナリオの場合は午後 10 時にします。
- 一時アクセス パス (TAP) を使っている場合は、最大有効期間を 24 時間に設定することをお勧めします。 このようにすると、異なるタイムゾーンにいる可能性のある従業員に送信された後で TAP の有効期限が切れないようにすることができます。 詳しくは、「パスワードレスの認証方法を登録するように Microsoft Entra ID で一時アクセス パスを構成する」をご覧ください。
詳しくは、「ライフサイクル ワークフローの属性を同期する方法」をご覧ください。
タスクを確認する
シナリオおよび対象ユーザーとタイミングを決定したので、あらかじめ定義されているタスクで十分か、追加のタスクが必要かを、検討する必要があります。 次の表は、現在ポータルで利用できる定義済みのタスクの一覧です。 次の表を使って、タスクをさらに追加する必要があるかどうかを判断してください。
| タスク | 説明 | 関連するシナリオ |
|---|---|---|
| ユーザーをグループに追加する | ユーザーを選択したグループに追加します | 就職者 - 退職者 - 異動者 |
| ユーザーを選択した Teams に追加する | ユーザーを Teams に追加します | 就職者 - 退職者 - 異動者 |
| ユーザーにライセンスを割り当てる | ユーザーにライセンスを割り当てる | 就職者 - 異動者 |
| ユーザー アカウントを削除する | Microsoft Entra ID でユーザー アカウントを削除する | 退職者 |
| ユーザー アカウントを無効にする | ディレクトリでユーザー アカウントを無効にします | 就職者 - 退職者 |
| ユーザー アカウントを有効にする | ディレクトリでユーザー アカウントを有効にします | 就職者 - 退職者 |
| TAP を生成してメールを送信する | 一時アクセス パスを生成し、ユーザーのマネージャーにメールで送信します | 就職者 |
| ユーザーのすべてのライセンスを削除する | ユーザーに割り当てられているすべてのライセンスを削除します | 退職者 |
| ユーザーをすべてのグループから削除する | すべての Microsoft Entra グループのメンバーシップからユーザーを削除する | 退職者 |
| すべての Teams からユーザーを削除する | すべての Teams メンバーシップからユーザーを削除します | 退職者 |
| 選択したグループからユーザーを削除する | 選択した Microsoft Entra グループのメンバーシップからユーザーを削除する | 就職者 - 退職者 - 異動者 |
| 選択した Teams からユーザーを削除する | 選択した Teams のメンバーシップからユーザーを削除します | 就職者 - 退職者 - 異動者 |
| カスタム タスク拡張機能を実行する | カスタム タスク拡張機能を実行して、外部システムにコールアウトします | 就職者 - 退職者 - 異動者 |
| ユーザーの最終日後にメールを送信する | 最終在籍日の後でユーザーのマネージャーにオフボーディング メールを送信します | 退職者 |
| ユーザーの最終日より前にメールを送信する | 最終在籍日の前にユーザーのマネージャーにオフボーディング メールを送信します | 退職者 |
| ユーザーの最終日にメールを送信する | 最終在籍日にユーザーのマネージャーにオフボーディング メールを送信します | 退職者 |
| ウェルカム メールを送信する | 新規採用者にウェルカム メールを送信します | 就職者 |
| オンボード リマインダーのメールを送信する | オンボード リマインダー メールをユーザーの上司に送信する | 就職者 |
| ユーザー アクセス パッケージの割り当てを要求する | 選択したアクセス パッケージへのユーザー割り当てを要求する | 就職者 - 異動者 |
| ユーザーのアクセス パッケージの割り当てを削除する | 選択したアクセス パッケージからユーザー割り当てを削除する | 退職者 - 異動者 |
| ユーザーのすべてのアクセス パッケージの割り当てを削除する | ユーザーに割り当てられているすべてのアクセス パッケージを削除する | 退職者 |
| 選択したライセンスの割り当てをユーザーから削除する | 選択したライセンスの割り当てをユーザーから削除します | 退職者 - 異動者 |
| ユーザーのすべての保留中のアクセス パッケージ割り当て要求をキャンセルする | ユーザーのすべての保留中のアクセス パッケージ割り当て要求をキャンセルする | 退職者 |
タスクについて詳しくは、ライフサイクル ワークフローのタスクに関する記事をご覧ください。
グループとチームのタスク
グループまたはチームのタスクを使用している場合は、ワークフローで 1 つまたは複数のグループを指定する必要があります。 次のスクリーンショットで、タスクの黄色の三角形は情報が不足していることを示します。
タスクを選択すると、グループを追加または削除するためのナビゲーション バーが表示されます。 グループを追加するには、[x 個のグループが選択されました] リンクを選びます。
カスタム タスク拡張機能
ライフサイクル ワークフローを使うと、就職者、異動者、または退職者のシナリオに基づいてトリガーできるワークフローを作成できます。 ライフサイクル ワークフローには、ユーザーのライフサイクル全体にわたって一般的なシナリオを自動化する組み込みタスクがいくつか用意されていますが、これらの組み込みタスクではいつかは限界に達する可能性があります。 拡張性機能を使うと、カスタム タスク拡張機能の概念を利用して、ライフサイクル ワークフローの一部として外部システムを呼び出すことができます。
カスタム タスク拡張機能とライフサイクル ワークフローとの対話方法に関するシナリオとして、次の 3 つの方法のいずれかが考えられます。
- ファイア アンド フォーゲット シナリオ - ロジック アプリを開始したら、ロジック アプリからの想定される応答を待たずに、直ちに次のタスクの実行を続けます。
- ロジック アプリからの応答を待機するシーケンシャル タスク実行 - ロジック アプリを開始すると、シーケンシャル タスク実行はロジック アプリからの応答を待機します。
- サード パーティ システムの応答を待機するシーケンシャル タスク実行 - ロジック アプリを開始すると、シーケンシャル タスク実行は、ロジック アプリをトリガーして正常に実行されたかどうかをカスタム タスク拡張機能に通知するサード パーティ システムからの応答を待機します。
- カスタム拡張機能について詳しくは、ライフサイクル ワークフローの拡張性に関する記事をご覧ください
ワークフローを作成する
ワークフローを設計して計画したので、ポータルでそれを作成できます。 ワークフローの作成について詳しくは、「ライフサイクル ワークフローを作成する」をご覧ください。
パイロットを計画する
お客様には、最初は小規模なユーザー グループまたは 1 人のテスト ユーザーでライフサイクル ワークフローのパイロットを行うことをお勧めします。 パイロットに基づいて、プロセスやコミュニケーションを必要に応じて調整することができます。 これは、セキュリティとコンプライアンスの要件を満たすためのユーザーとレビュー担当者の能力を高めるのに役立ちます。
パイロットでは次のようにすることをお勧めします。
- ユーザーの小さなサブセットに結果が適用されるライフサイクル ワークフローから始めます。
- 監査ログを監視し、すべてのイベントが適切に監査されていることを確認します。
詳しくは、「パイロットのベスト プラクティス」をご覧ください。
ワークフローをテストして実行する
ワークフローを作成したら、ワークフローをオンデマンドで実行してテストする必要があります。
オンデマンド機能を使うと、ライフサイクル ワークフローが意図したとおりに動作しているかどうかをテストして評価できます。
テストが完了したら、ライフサイクル ワークフローを修正するか、さらに広範な配布を準備することができます。
監査ログ
監査ログからさらに情報を取得することもできます。 これらのログには、ポータルの Microsoft Entra ID の [監視] でアクセスできます。 詳しくは、Microsoft Entra IDでの監査ログに関する記事と「ライフサイクル ワークフローの履歴」をご覧ください。
ライフサイクル ワークフローの計画の例
| 段階 | 説明 |
|---|---|
| シナリオを決定する | 新しいマネージャーにメールを送信する採用前ワークフロー。 |
| 実行条件を決定する | 営業部門の新入社員に対して、employeeHireDate の 2 日前に、ワークフローが実行されます。 |
| タスクを確認する。 | ワークフローでは定義済みのタスクを使います。 追加するその他のタスクはありません。 |
| ポータルでワークフローを作成する | ポータルで新規採用者向けの定義済みテンプレートを使います。 |
| ワークフローを有効にしてテストする | オンデマンド機能を使って、1 人のユーザーでワークフローをテストします。 |
| テスト結果の確認 | テスト結果をレビューし、ライフサイクル ワークフローが意図したとおりに動作していることを確認します。 |
| ワークフローを幅広いユーザーにロールアウトする | 関係者に連絡して、ワークフローの運用が始まり、HR が採用マネージャーにメールを送信する必要がなくなったことを知らせます。 |
次の手順
以下の関連テクノロジについて理解します。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示