HR can trigger an identity change before anyone opens an administration console. A new hire, transfer, or departure needs to become an appropriate access decision.
Correct automation still needs reliable information and clear approval. If the source record is incomplete, a workflow can execute exactly as designed and still grant the wrong access.
For an IAM learning project, trace where each required fact comes from and who owns the decision. That lets you practice lifecycle reasoning before treating account creation as the whole problem.
Separate the business event from the access decision
A hire tells you someone is joining. It doesn't automatically tell you every application and permission they should receive.
A department change tells you something about the person's role. It may not explain which temporary responsibilities remain or which access should be removed immediately.
For a fictional employee, list the event and the information required to act on it: identity, role, manager, effective date, and the relevant access owner.
The exact fields depend on the organization. The exercise is to discover what the decision needs rather than assume that an account-creation request contains a complete answer.
Identify who owns each fact and access decision
The information needed for a lifecycle change may come from different people. Record those responsibilities explicitly:
| Information or decision | What your scenario must identify |
|---|---|
| Start or departure date | The source authorized to confirm the event |
| Role or department | The owner of the relevant business definition |
| Resource access | The person authorized to approve the entitlement |
| Missing or conflicting value | The owner who can clarify it before a change proceeds |
A directory administrator shouldn't have to guess because a request contains an empty field.
In your fictional scenario, decide what happens when two inputs conflict. Does the request pause for clarification, and who receives it?
This is part of the technical design: it prevents a reliable automation process from converting uncertain information into an unjustified access change.
Model an incomplete record before automating
Create a fictional request with one missing or inconsistent piece of information.
Perhaps the employee's department is blank, the manager is unknown, or the effective date conflicts with the approved request. Write the expected response: pause the affected action, record the reason, and route the question to the appropriate owner.
Don't make “guess from another employee” the default recovery method. Similar titles do not necessarily justify identical access.
A small exception case can reveal whether you understand the process more effectively than a perfect set of sample data where every workflow succeeds.
Connect reliable inputs to lifecycle actions
Microsoft's Lifecycle Workflows overview describes tasks and execution conditions used around joiner, mover, and leaver events.
The product is one implementation of a broader problem: deciding which action should run for which identity and when.
You can practice the reasoning manually before using a particular automation feature. Record the input, decision, action, and verification. Then investigate which steps your available platform can automate and what licensing or prerequisites apply.
Don't claim an automated lifecycle process when the lab only documents a manual sequence. Both can teach something, but they demonstrate different capabilities.
Show that the result matches the business event
After a change, verify the intended access state rather than merely confirming that a workflow ran.
For a mover, compare what was added, retained, and removed. For a departure, state which access paths your project addresses and what remains outside its scope.
A useful portfolio artifact includes the source-data assumptions and exception handling alongside the technical result. It shows you understand why the change should happen, not only how to trigger it.
Include the effective time in the record when it affects the scenario. A technically correct change applied too early or too late may still fail the business requirement. Document how your exercise handles that timing rather than leaving it implicit.
The Six-Figure IAM Career Playbook introduces lifecycle and governance work as practical career directions. It helps connect the ordinary business event—somebody joining, moving, or leaving—to the identity responsibilities you can learn and demonstrate next. The ebook is $9.