Use one fictional employee to demonstrate how access changes when someone joins, transfers, and leaves.
The project should show three verified states, not three account-management screenshots. Record what the employee needs, what changes, and why each permission is added, retained, or removed.
Keep the scenario small enough that a reader can inspect the decisions. You can model parts you haven't implemented, provided you label them clearly. That creates a more useful business story than presenting every step as a fully automated enterprise lifecycle process.
Give the employee a role and a starting requirement
Imagine a fictional employee named Morgan joining the sales team.
Morgan needs basic employee services and read access to a sales application. Morgan does not need finance approval rights or administrative access.
Write those requirements before creating anything. Identify who supplies the employee information and who approves the application role.
In the lab, those people can be fictional workflow roles represented in a document. You do not need to build an HR platform to demonstrate that the source and approval decisions matter.
Verify the joiner's initial access state
After creating the fictional identity, record four things:
| Item | What to capture |
|---|---|
| Intended assignments | The approved access for Morgan's starting role |
| Observed assignments | What the implemented system actually shows |
| Allowed action | A test of the required work |
| Prohibited action | A test showing excluded access remains unavailable |
If an application account or approval is simulated, state that instead of implying the whole workflow is live.
The useful starting state is that Morgan can perform the defined work and cannot perform the excluded action under the conditions you tested.
An account-list screenshot alone doesn't establish that. Capture the behavior and the relevant context before moving to the transfer stage, so the later comparison starts from a result you've actually verified.
Make the move a before-and-after comparison
Now Morgan transfers to a reporting team. The new role needs a different resource. The old sales access may need to end, or a limited overlap may be approved for a handover.
Represent the decision explicitly:
| Access | Before move | Intended after move |
|---|---|---|
| General employee services | Present | Retained |
| Sales application | Present | Removed or time-limited |
| Reporting resource | Absent | Added after approval |
Don't automatically choose removal or retention for every scenario. Explain the fictional business decision and then implement the part your environment supports.
Verify the change as the employee experiences it
Check that the new work is possible and that the old access behaves according to the decision.
Account for the relevant user session and application behavior in your test. A change visible in an administration screen is not always the same as a verified user outcome.
Record what you refreshed, where you checked, and which systems were outside the lab's scope.
This gives the project a more useful story than “added Morgan to another group.” It demonstrates that you understood the existing access as well as the new request.
Treat leaving as a set of responsibilities
When Morgan leaves, identify the access paths and ownership issues the process must address.
Your small lab may test account disablement and group removal while documenting separate application sessions or data-transfer decisions as limitations.
Don't imply that one directory action ends every possible session or removes every local application account.
Use the wider offboarding checklist to explain why the technical scope needs to be stated carefully.
Package the project around three state changes
Your final page can show the initial state, the move, and the departure with the decision and evidence for each.
Include any exception, such as a temporary handover permission, and explain who owns the follow-up. Use fictional data throughout.
A reader should be able to see what changed, why it changed, and how you checked it. They shouldn't need to inspect every configuration screenshot to understand the business story.
The Six-Figure IAM Career Playbook includes identity lifecycle work alongside directory access and SSO labs. The $9 guide helps connect these practical examples to a suitable IAM role and a 90-day plan.
One employee is enough to demonstrate several important identity decisions. Keep the scenario small and the evidence complete.