H2R 202 ยท IDENTITY AND ACCESS
How do identity, access, and HR data boundaries work?
H2R data determines who a worker is, what employment relationship is active, which data they may see, and when access should start or end. HR administrators and system managers need to separate HR permissions, enterprise identity, access-governance decisions, and target-system roles.
CONTROL CHAIN
Read the whole decision, not just its final screen
The result is trustworthy only when its business event, rule, identity, execution, and evidence agree.
- 01Employee eventInput
- 02Employment eligibilityEligibility
- 03Identity matchIdentity
- 04Governance decisionDecision
- 05Target roleTarget
- 06Access evidenceEvidence
FIRST DECISION
Separate eligibility from permission and provisioning
An employee can be eligible for access without yet having a target role; an approved role can exist without successful provisioning. Establish which layer owns the observed result before changing it.
Role-based permissions govern who can view or maintain Employee Central data, objects, and populations. They are not automatically the same as ERP, Microsoft, or other application roles.
A stable employee or person identifier must connect EC with IDM, GRC, Entra, and target accounts. Duplicate or mismatched identities create both access risk and false support conclusions.
IDM and GRC use worker status, organisation, job, manager, and policy to determine eligibility, approval, risk, and provisioning. The approval record does not itself prove target access.
ADMINISTRATOR AND SYSTEM-MANAGER LENS
What to understand before changing a setting
These are design and control questions. Detailed queues and incidents belong in 303 and 606.
HR permissions
Role-based permissions govern who can view or maintain Employee Central data, objects, and populations. They are not automatically the same as ERP, Microsoft, or other application roles.
Identity matching
A stable employee or person identifier must connect EC with IDM, GRC, Entra, and target accounts. Duplicate or mismatched identities create both access risk and false support conclusions.
Access governance
IDM and GRC use worker status, organisation, job, manager, and policy to determine eligibility, approval, risk, and provisioning. The approval record does not itself prove target access.
Lifecycle timing
Hire, transfer, leave, rehire, and retroactive change can each change access eligibility. Effective date, provisioning schedule, and emergency-access process must be explicit.
Target evidence
Prove access in the target system and review whether it is appropriate for the employee, manager, population, and sensitive data involved.
Separation of duties
Protect the boundary between HR data maintenance, role approval, role provisioning, and access review so that no one step silently overrides another.
INTERMEDIATE SCENARIO
A transferred employee can still approve work for the former team
The EC transfer may be correct while an old target-system role remains. Determine whether the old entitlement came from a role, a target population, a manager relationship, or a direct assignment; then correct the owning layer and prove both removal and new access.
- Confirm the effective-dated EC assignment and employment status.
- Check the IDM/GRC decision and provisioning outcome for both old and new access.
- Verify the roles and approval scope directly in the receiving system.
Use 303 for operating hand-offs and 606 when a live case needs diagnosis and controlled recovery.