Field Notes
One Workforce Platform, Two Employer Identities
A field note on the identity architecture challenge of supporting a shared HR platform across two companies while preserving employer identity, access boundaries and governed staff mobility.
A common mistake in enterprise transformation is assuming that a shared platform requires a shared identity model.
That was not the right answer for OneHR.
The program introduced a shared Workday HR platform across Toyota Motor Corporation Australia and Toyota Finance Australia. From a business perspective, the intent was clear: create a more consistent HR experience, reduce duplicated process effort, improve reporting, and allow the organisation to make better use of workforce capability across company boundaries.
Architecturally, the harder question was not whether the companies could share a platform. It was how they could do so without collapsing their employer identities, access controls, security boundaries or downstream operating responsibilities.
Three identities, three responsibilities
The solution was to separate three concepts that are often blurred:
- Human identity: who the person is.
- Employer identity: which legal employing company owns the employment relationship.
- Application access identity: which systems, roles and entitlements the person needs to perform their current work.
Workday became the authoritative source for employee and contingent worker identity, employment status, organisation, position and manager information. MyAccess/SailPoint consumed this data to support joiner, mover and leaver processing, while Azure Entra ID remained the authentication authority for company sign-in and SSO.
That distinction mattered.
The architecture was not simply "connect Workday to SailPoint". It was a decision framework for how identity, employment, position and access should relate.
Shared capability without forced sameness
It meant that the business could move toward a shared HR operating model while still maintaining company-specific controls. Company identifiers, HR security boundaries, identity-governance rules, worker type handling and downstream filters became part of the control model.
The architecture clarified where to standardise, where to preserve separation, where to automate, and where governance needed to remain explicit.
That decision framework enabled a shared HR operating model, preserved employer identity, supported governed application access, and made staff mobility and future secondments implementable without treating the organisation as a single flat identity domain.
Business decisions made implementable
The outcome was an architecture that supported shared enterprise capability without forcing artificial organisational sameness. Staff mobility, shared services and future secondments could be supported because the model preserved the employer identity while allowing work identity and system access to follow the role being performed.
This is where architecture created value: not by producing diagrams as an end in themselves, but by separating responsibilities clearly enough that business decisions about privacy, access, standardisation and company separation could be governed and delivered.
Architecture lesson
Shared platforms work best when identity is modelled as a set of related but distinct responsibilities, not as a single flat account record.