Creating a user establishes an identity in a system. Designing an access model defines what people with different responsibilities should be allowed to do.
The model also needs to handle joining, changing jobs, exceptions, and leaving. Otherwise, account creation can be consistent while access decisions remain improvised.
Use a small fictional team to explore the distinction. The reasoning can come before a large governance platform or a complicated automation project.
Define three responsibilities before creating accounts
Imagine a project with contributors, reviewers, and an owner.
Contributors prepare sample documents. Reviewers read and comment on them. The owner approves final publication and is responsible for deciding who needs each level of access.
These are business responsibilities, not automatically the names of technical groups or application roles.
Write the permitted actions for each responsibility first. That gives you a requirement to translate into controls instead of letting whichever permissions are easiest to assign become the access model by default.
Map responsibilities to specific permissions
Create a small table in your notes with the responsibilities as rows and the actions as columns.
For each combination, mark whether the action is allowed, denied, or requires a separate approval. Be precise about actions such as viewing, editing, publishing, and administering.
Then decide how the test environment can represent those permissions.
A group or role may be a useful implementation mechanism, but the access model is the reasoning behind the assignment. Don't confuse naming a group with deciding what its members should be able to do.
Define how assignments change when responsibilities change
For each role in the fictional model, answer:
- Entry: Who confirms that someone now performs this responsibility?
- Transfer: What happens when a contributor becomes an owner or reviewer?
- Removal: Which old permissions should disappear or be reconsidered?
- Exception: How is a temporary deviation approved and tracked?
Model these events with fictional identities instead of only testing the initial assignment.
A process that continually adds permissions can leave people with access that no longer fits their work. Changes and removal should be part of the ordinary model, not unspecified cleanup for another team.
Record both the intended assignments and the observed behavior. That helps demonstrate that you thought about the lifecycle of the decision, not just which groups to populate on day one.
Keep approval and implementation distinct
The person who can technically assign a role is not necessarily the person who should decide that the role is appropriate.
In your scenario, identify the resource owner or another designated authority for the business decision. Then identify who implements the approved change and verifies the result.
The exact arrangement depends on the organization. The learning goal is to recognize that these are separate responsibilities that need to be connected.
A model becomes easier to operate when those responsibilities are visible rather than hidden inside an administrator's personal judgment.
Test the model with ordinary users
Create test accounts representing the fictional responsibilities and check the intended actions.
Test both what should work and what should remain unavailable. Then simulate a role change and inspect the resulting state.
Record discrepancies rather than adjusting the story to fit the configuration. An unexpected permission may reveal a problem with the mapping, inheritance, or another access path.
Use the problems that appear when roles multiply to think about how the model could become harder to maintain as requirements grow.
Explain the model as a portfolio decision
Your writeup should show the business responsibilities, permission matrix, assignment process, tests, and limitations.
Label any part you designed but did not implement. A clear conceptual model can be useful, but it should not be presented as a fully deployed system.
The project demonstrates a different skill from simply creating several accounts. It shows that you can connect access to a repeatable business requirement and evaluate whether the controls match that requirement.
The Six-Figure IAM Career Playbook connects directory access and identity lifecycle projects with a practical career plan. The $9 guide helps you move from routine account tasks toward evidence of deeper identity understanding.
Creating the user is one step. Designing the access model explains what should happen after the account exists—and when the person's responsibilities change.