A new employee is joining Wire Finance.
At first, onboarding might sound simple:
create an account and give them access.
But that immediately raises several questions.
Who confirms who the employee is?
Who determines their department and job role?
Which access should they receive automatically?
What happens if they require something outside their normal baseline?
Who prepares their device?
And who confirms everything is ready before the employee begins work?
The Joiner process gives Wire Finance a repeatable way to answer those questions.
The Joiner Process
The process begins before an account exists.
Approved Hire
│
▼
Employment Information Confirmed
│
▼
Business Role Defined
│
▼
Identity Created
│
▼
Attributes Established
│
▼
Baseline + Department + Role Access
│
▼
Licence + Applications + Device
│
▼
Authentication Setup
│
▼
Access Validated
│
▼
Ready to Work
This flow shows something important:
identity creation does not happen first.
Before IT creates an employee identity, Wire Finance needs an approved business event and enough trusted information to understand who the employee is and what their role should require.
The technical identity should reflect the business decision — not define it.
Start With an Approved Hire
The Joiner process begins with an approved employment event.
Conceptually:
Approved Hire
↓
Joiner Process
HR provides the authoritative employment information, while the hiring manager provides the business context surrounding the role.
This establishes the information that will later drive identity creation and access.
The account should not be created first and then gradually corrected as missing information arrives.
Wire Finance wants the identity to begin life with the clearest possible understanding of the employee behind it.
From Employee Information to Identity
The Joiner process turns business information into identity information.
Important attributes include things such as:
- employee name
- employee identifier
- employment type
- company
- department
- job title
- account type
- account status
Some of these attributes are particularly important because Wire Finance uses them to determine organisational relationships.
For example:
Olivia Carter
│
├── Company = Wire Finance
├── Department = Finance
└── Job Title = Finance Analyst
Those relationships can then drive the appropriate identity groups.
Company = Wire Finance
↓
SG-BASE-ALL-STAFF
Department = Finance
↓
SG-DEPT-FINANCE-USERS
Job Title = Finance Analyst
↓
SG-ROLE-FINANCE-ANALYST
This means Wire Finance is not manually designing Olivia’s normal access from scratch.
Her approved organisational attributes establish which normal access relationships should apply.
The Joiner Access Model
For Olivia Carter, the normal Joiner access path looks like this:
Olivia Carter
│
▼
WF-BASE-001
Standard Employee Baseline
│
+
▼
Finance Department Baseline
│
+
▼
Finance Analyst Role Baseline
Each layer exists for a different reason.
The company baseline applies because Olivia is an employee.
The Finance baseline applies because she works in Finance.
The Finance Analyst baseline applies because of the job she performs.
The result is much more predictable than manually deciding every permission for every new starter.
Trusted Attributes Matter
Dynamic access only works if the attributes driving it can be trusted.
If someone’s department is incorrectly recorded as Finance, the identity model may place them into Finance-related groups.
If the wrong job title is assigned, role membership may also become incorrect.
Attributes used for access decisions therefore become part of the security model.
Wire Finance treats attributes such as:
- company
- department
- job title
- user type
- account status
as security-relevant information.
Changes to these values should reflect approved business events rather than arbitrary technical edits.
The detailed Microsoft Entra configuration for these attributes and dynamic groups is covered later during implementation.
Who Provides What?
Onboarding is a shared business and technical process.
Different people contribute different information or actions.
| Information / Decision | Provider / Owner |
|---|---|
| Legal name | HR |
| Preferred name | Employee / HR |
| Employee identifier | HR / approved workforce record |
| Job title | HR |
| Department | HR |
| Employment type | HR |
| Start date | HR |
| Manager | HR / business management |
| Work location | HR / business management |
| Role responsibilities | Hiring manager |
| Required applications | Manager + application owner where required |
| Required data access | Manager + data owner where required |
| Sensitive or exception access | Manager + resource owner + Security where required |
| Privileged access requirement | Manager + IT / Security approval |
| Device requirement | Manager + IT |
| Account creation | IT |
| Identity attributes | IT based on approved workforce information |
| Baseline / department / role membership | Derived from approved identity attributes where appropriate |
| Pilot membership | IT / Security through explicit assignment |
| Licence assignment | IT based on approved service requirements |
| Device provisioning | IT / Deployment & Support |
| Authentication setup | Employee with IT-enforced requirements |
| Final access validation | Manager + IT |
| Security monitoring | SOC / Security Operations |
The table highlights an important distinction.
HR and managers establish business truth.
IT turns that information into a technical identity.
Security reviews access that carries additional risk.
The technical controls should reflect those approved decisions rather than replace them.
Dynamic Access and Deliberate Assignment
Not everything in the Joiner process should be assigned in the same way.
Wire Finance distinguishes between relationships that can be derived predictably and relationships that require a deliberate decision.
Attribute-Driven Relationships
Normal organisational relationships can be determined from trusted identity attributes.
Examples include:
Wire Finance employee
↓
SG-BASE-ALL-STAFF
Finance department
↓
SG-DEPT-FINANCE-USERS
Finance Analyst role
↓
SG-ROLE-FINANCE-ANALYST
These relationships are suitable for dynamic membership because they describe predictable facts about the employee.
Deliberate Assignments
Other relationships should not appear simply because of a department or job title.
Examples include:
- pilot participation
- licence assignment during the pilot
- exception access
- privileged administrative access
These require explicit decisions.
For example:
New Employee
│
├── Normal organisational access
│ └── Attribute driven
│
└── Additional controlled access
└── Explicitly approved
This prevents the Joiner process from quietly bundling sensitive access into normal onboarding.
Normal Access and Additional Access
The normal Joiner model is:
Company Baseline
+
Department Baseline
+
Role Baseline
Anything outside that model needs its own justification.
For example, Olivia joining Finance does not automatically justify:
SG-EXCEPTION-PAYMENT-PROCESSING
Her department and role establish her normal Finance access.
Payment authority is a separate business decision.
Likewise, joining the IT department does not automatically grant administrative privileges.
A job may explain why privileged access is required, but the privileged identity and administrative assignment still follow their own approval path.
The goal is:
give the employee the access required for the role — not the most access possible.
Licensing the Joiner
A new employee also needs the services required to work.
Wire Finance uses group-based licensing rather than assigning licences individually without structure.
During the current pilot, Microsoft 365 E5 licensing is represented through:
SG-LICENCE-M365-E5
Membership is deliberately assigned during the pilot.
This gives IT explicit control over licence consumption while the environment is being validated.
Conceptually:
Approved Joiner
↓
Requires Microsoft 365 Services
↓
SG-LICENCE-M365-E5
↓
Microsoft 365 E5
As Wire Finance matures, the licensing model can be reviewed to determine whether trusted workforce attributes should eventually automate more of this process.
Preparing the Device
A working identity is only part of the employee experience.
The employee also needs a device.
The Joiner process therefore connects identity onboarding with endpoint provisioning.
Conceptually:
Approved Employee
│
├── Identity
│
├── Access
│
├── Licence
│
└── Corporate Device
Wire Finance will later use Microsoft Intune and Windows Autopilot to provision and manage corporate Windows endpoints.
The detailed device-registration, Autopilot, compliance, application-deployment, and security configuration belongs in the Device Provisioning Model and endpoint implementation chapters.
At the Joiner stage, the important point is simply that identity and device readiness need to meet before the employee can work securely.
Authentication Setup
A new identity also needs a working authentication path.
The employee must be able to establish their credentials and satisfy the organisation’s authentication requirements before accessing company services.
Authentication setup may include:
- initial credential establishment
- first sign-in
- required MFA registration
- approved authentication methods
- validation that the employee can successfully authenticate
The exact authentication methods and access policies are implemented later in the Microsoft Entra configuration.
The Joiner process simply establishes the requirement:
the employee should not be considered ready until their authentication path works securely.
Ready to Work
Creating the account is therefore only one milestone.
Before the Joiner process is considered complete, Wire Finance should confirm that:
- the identity exists
- the employee attributes are correct
- expected dynamic groups have been evaluated
- required deliberate group assignments have been made
- the appropriate licence is available
- required applications are available
- the corporate device is ready
- authentication works
- normal access matches the employee’s role
- unnecessary access has not been introduced
- the manager and IT can confirm readiness
This changes the definition of successful onboarding.
The end state is not:
Account created.
It is:
the right person has the right identity, the right access, the required services, a trusted device, and a working authentication path before they begin their role.
Joiner Validation
A repeatable onboarding process also needs validation.
Wire Finance should be able to answer:
Does the employee exist correctly?
↓
Are their attributes correct?
↓
Did expected group memberships appear?
↓
Were deliberate assignments approved?
↓
Is the correct licence present?
↓
Is the device ready?
↓
Can the employee authenticate?
↓
Can they access what they need?
↓
Are they blocked from what they should not have?
That final question matters just as much as confirming that required access works.
Successful onboarding means validating both:
what the employee can access
and:
what the employee cannot access.
The Joiner Process Is Complete
The Joiner process begins with an approved business event and ends with a validated working identity.
Approved Hire
↓
Trusted Employee Information
↓
Identity Created
↓
Attributes Established
↓
Normal Access Derived
↓
Additional Access Approved Separately
↓
Licence + Device + Applications
↓
Authentication Established
↓
Access Validated
↓
Ready to Work
But the identity created today will not necessarily remain correct forever.
Employees change departments.
They receive promotions.
Their responsibilities change.
They may gain or lose sensitive access.
And some may gain or lose privileged responsibilities.
When that happens, simply adding more permissions is not enough.
The next lifecycle challenge is to determine:
what should be removed, what should remain, and what should be added when an employee’s relationship with Wire Finance changes?
That is the Mover process.
Identity Lifecycle