既存の入退社ワークフローを別部署向けに流用する場合は、Microsoft Entra管理センターで元のワークフローを選び、Cloneを実行します。ただし、複製後はすぐに作成せず、名前、説明、実行対象、開始タイミング、タスクを別部署向けに変更することが重要です。
特に注意したいのが、複製元を選ぶと最初にReview + createタブが開く点です。そのままCreateを押すと、元の設定をほぼそのまま使ったワークフローを作成できます。別部署のユーザーに誤って処理を実行しないよう、必ず各設定タブへ戻って内容を確認してください。([Microsoft Learn][1])
Entra Lifecycle Workflowsを複製するための前提条件
Lifecycle Workflowsの複製には、次のライセンスと管理者ロールが必要です。
| 項目 | 必要条件 |
|---|---|
| ライセンス | Microsoft Entra ID GovernanceまたはMicrosoft Entra Suite |
| 管理者ロール | Lifecycle Workflows Administrator以上 |
| 操作場所 | Microsoft Entra管理センター |
| 複製機能 | CloneはMicrosoft Entra管理センターのみで利用可能 |
Microsoft Entra ID GovernanceまたはMicrosoft Entra Suiteの対象ライセンスが必要です。また、操作する管理者には、少なくともLifecycle Workflows Administratorロールが必要です。([Microsoft Learn][1])
既存ワークフローのCloneは、Microsoft Entra管理センターから利用する機能です。Microsoft Graphを使ってゼロからワークフローを作成する方法とは異なるため、両者を混同しないようにしてください。([Microsoft Learn][1])
既存の入退社ワークフローを複製する方法
ワークフローを複製する入口は2つあります。すでに複製元が決まっている場合は、ワークフロー一覧から操作する方法が分かりやすいでしょう。
ワークフロー一覧から複製する
- Microsoft Entra管理センターへサインインします。
ID Governanceを開きます。Lifecycle workflowsを選択します。Workflowsを開きます。- 複製元にするワークフローを選択します。
Cloneを選択します。
既存ワークフローの内容を確認しながら複製元を選びたい場合に適した入口です。([Microsoft Learn][1])
Create workflowから複製する
ワークフロー作成画面から開始することもできます。
ID Governanceを開きます。Lifecycle workflowsを選択します。Create workflowを開きます。Clone an existing workflowカードを探します。Browse workflowsを選択します。- 複製したいワークフローを選びます。
どちらの入口を使っても、既存ワークフローを新しいワークフローの出発点として利用できます。([Microsoft Learn][1])
Clone後にそのままCreateを押してはいけない理由
複製元のワークフローを選択すると、Review + createタブが直接開きます。
ここでCreateを選択すると、設定を変更せずにワークフローを作成できます。しかし、別部署向けのワークフローを作る場合、そのまま作成するのは避けるべきです。
Review + createから次の各タブへ戻り、設定を変更してから作成します。
- ワークフロー名
- 説明
- administrative scope
- Execution conditions
- Tasks
すべての変更が終わったら、再びReview + createへ戻り、最終確認後にCreateを実行します。([Microsoft Learn][1])
別部署向けに変更するときの確認項目
Lifecycle Workflowsは、大きく分けるとTasksとExecution conditionsで構成されます。
Tasksは、ワークフローが実行されたときに行う処理です。一方、Execution conditionsは、どのユーザーを対象にし、いつワークフローを開始するかを定義します。([Microsoft Learn][1])
別部署向けに複製するときは、次の構成表に沿って確認すると設定漏れを防ぎやすくなります。
| 確認項目 | 確認する内容 | 未変更の場合に起こり得る問題 |
|---|---|---|
| 名前 | 部署名と入社・異動・退社などの用途が分かるか | 複製元と見分けられなくなる |
| 説明 | 対象部署と用途が明記されているか | 管理者が目的を判断できない |
| administrative scope | 複製先の運用方針に合っているか | 想定と異なる管理範囲になる |
| Execution conditionsの対象 | 別部署のユーザーが対象になっているか | 元部署のユーザーに処理される |
| Execution conditionsのタイミング | 入社前、入社時、退社時など、意図した開始条件か | 想定外の時点で処理が始まる |
| Tasks | 別部署でも必要な処理だけになっているか | 不要な処理や不足した処理が発生する |
| スケジュール | テスト前に有効化しようとしていないか | 確認前に広い範囲へ展開される |
なかでも最優先で確認すべきなのは、Execution conditionsの対象ユーザーです。
タスクだけを別部署向けに変更しても、対象条件が元部署のままであれば、元部署のユーザーに新しいタスクが実行される可能性があります。
TasksとExecution conditionsの違い
複製作業では、TasksとExecution conditionsを別々に確認する必要があります。
| 設定 | 役割 | 別部署向けに確認するポイント |
|---|---|---|
| Tasks | ワークフロー開始後に実行する処理 | 部署固有の処理を残すか、変更するか |
| Execution conditions | 対象ユーザーと実行開始のタイミング | 元部署ではなく別部署が対象になっているか |
例えば、複製元のワークフローが「部署Aの入社者」を対象としていたとします。
別部署向けに複製した場合は、少なくとも次のように見直します。
- ワークフロー名を部署B向けに変更する
- 説明に部署B用であることを記載する
- 対象ユーザーの条件を部署B向けに変更する
- 実行開始のタイミングが用途に合っているか確認する
- 部署Aだけで必要だったタスクを見直す
- 部署Bで必要なタスク構成になっているか確認する
「複製できたこと」と「別部署向けに正しく変更できたこと」は同じではありません。複製後の確認作業までを、ワークフロー作成の一部として扱うことが重要です。
対象ユーザーの設定を最優先で確認する
別部署向けワークフローで最も影響が大きい設定は、対象ユーザーを決める条件です。
Lifecycle Workflowsでは、Execution conditionsが「誰に」「いつ」ワークフローを実行するかを定義します。したがって、別部署向けに変更するときは、画面上の名前や説明だけでなく、実際の対象条件を確認しなければなりません。([Microsoft Learn][1])
確認時は、少なくとも次の3点を分けて考えます。
誰が対象になるか
複製元の部署ではなく、新しい部署のユーザーが対象になる条件へ変更します。
条件を見たときに、「どのユーザーが一致するか」を説明できない状態では作成を進めない方が安全です。
いつ対象になるか
対象ユーザーが正しくても、実行開始のタイミングが複製元のままでは、意図した入退社処理にならない可能性があります。
部署だけでなく、入社、異動、退社など、ワークフローの目的に合ったタイミングになっているかを確認します。
タスクが対象者に合っているか
対象条件を別部署向けに変更した後は、その対象者に対して各タスクを実行して問題ないかを確認します。
元部署の運用をそのまま別部署へ適用できるとは限りません。対象条件とタスクは、必ず組み合わせて確認してください。
複製後の名前は用途まで分かる形にする
複製元と似た名前のまま運用すると、管理画面で選び間違えやすくなります。
ワークフロー名には、次の要素を入れると識別しやすくなります。
- 対象部署
- ライフサイクルの段階
- 用途
- 必要に応じて運用区分
例えば、単に「入社ワークフロー」とするよりも、「部署B・入社者向け」のように、対象が判断できる名前にします。
説明欄にも、対象部署と用途を記載します。名前だけでは表現しきれない適用範囲や運用上の目的を残しておくことで、後から確認する管理者も判断しやすくなります。
作成時はスケジュールを有効化せずテストを優先する
新しく作成したLifecycle Workflowは、少人数でテストできるよう、既定では無効の状態になります。公式ドキュメントでも、多数のユーザーへ展開する前に小規模な対象でテストすることが案内されています。([Microsoft Learn][1])
別部署向けワークフローでは、作成と本番運用を分けて進めると安全です。
| 段階 | 実施内容 |
|---|---|
| 作成 | 複製後の設定を変更し、無効状態で作成する |
| 確認 | 対象条件、開始タイミング、タスクを再確認する |
| テスト | 少人数を対象とした検証を行う |
| 展開 | 確認後にスケジュールを有効化する |
Review and createでは、ワークフローの設定を確認し、スケジュールを有効にするかどうかを選択できます。ただし、別部署向けに複製した直後は、設定確認とテストを優先し、本番スケジュールの有効化を急がない方が安全です。([Microsoft Learn][1])
よくある設定ミス
Review + createでそのまま作成する
複製元を選ぶとReview + createが直接表示されるため、設定済みのように見えます。
しかし、別部署向けに変更する場合は、各タブへ戻って内容を修正する必要があります。
Tasksだけを変更する
タスクを別部署向けに変更しても、Execution conditionsが元部署のままでは、対象ユーザーを取り違える可能性があります。
タスクを変更したら、必ず対象ユーザーと開始タイミングも確認します。
Execution conditionsだけを変更する
対象部署を変更しても、タスクが複製元のままでは、別部署に不要な処理が残る可能性があります。
対象条件とタスクは、どちらか一方だけでなく、セットで確認します。
名前だけを変更して完了したと判断する
表示名を変えても、内部の対象条件やタスクは自動的に別部署向けになるわけではありません。
名前と説明の変更は識別のために必要ですが、実際の動作を決めるのはExecution conditionsとTasksです。
作成と同時に本番運用を始める
新規ワークフローは既定で無効です。この状態を利用し、少人数でのテストを先に行います。
作成直後にスケジュールを有効化するのではなく、作成、確認、テスト、本番展開を分けて進める方が安全です。
Microsoft Graphの作成機能とCloneを混同する
既存ワークフローのCloneは、Microsoft Entra管理センターで利用します。
Microsoft Graphによるワークフロー作成は、テンプレートや既存ワークフローを使わず、ゼロから作成する場合の方法です。Graphに複製操作があることを前提にせず、既存ワークフローを流用するときは管理センターのCloneを使用します。([Microsoft Learn][1])
作成前の最終チェックリスト
Createを押す前に、次の項目を確認してください。
- ワークフロー名から対象部署と用途を判別できる
- 説明に別部署向けであることを記載した
- administrative scopeを確認した
- 対象ユーザーが元部署のままになっていない
- 実行開始のタイミングが目的に合っている
- 複製元の不要なタスクが残っていない
- 別部署に必要なタスクが不足していない
Review + createの内容を最終確認した- 本番スケジュールをすぐに有効化しない
- 少人数でのテスト後に展開する方針になっている
既存の入退社ワークフローを別部署向けに展開する場合、Cloneによって作成時間を短縮できます。ただし、複製元を選択するとReview + createが直接開くため、設定を確認せずに作成しないことが重要です。
まず、Execution conditionsで対象ユーザーと開始タイミングを別部署向けに変更します。次に、Tasksが新しい対象者に適した内容になっているかを確認します。そのうえで無効状態のまま作成し、少人数でのテストを経てからスケジュールを有効化してください。
[1]: https://learn.microsoft.com/en-us/entra/id-governance/create-lifecycle-workflow “Create a lifecycle workflow – Microsoft Entra ID – Microsoft Entra ID Governance | Microsoft Learn”
コメント