An Employee Directory Can Have Several Authoritative Sources

A multinational can need a shared organization view long before it is ready to replace its regional HR systems. Employees still need to find colleagues, managers still need to understand cross-border teams and leadership still needs a coherent workforce picture. The choice is not limited to waiting for one global HR platform or publishing a spreadsheet assembled by hand. An employee directory from multiple HR systems can start before any of them is replaced.

A directory can consolidate selected, governed facts from several authoritative sources. The word selected matters. It does not need to reproduce every payroll field or become the owner of every employment transaction. Its purpose is to make agreed information usable across the organization while preserving where that information comes from and who is responsible for correcting it.

Separate consolidation from replacement

A source-system replacement changes where business transactions are performed and maintained. A consolidation layer reads approved information, resolves its relationship to people and organizational units, and publishes a shared view. The two programs can support each other, but they have different scope and acceptance criteria.

A historical Workday account of Sanofi describes fragmented HR information following acquisitions and a desire for wider talent visibility. It reports a particular transformation rationale, not proof that every company needs the same system strategy or timetable. Workday, Sanofi case

For a company building an employee directory from multiple HR systems, the first deliverable should be an authority map. Identify which source owns which population and which fields. A regional HR system may own employment facts for local employees. A central platform may own common job architecture. Microsoft Entra ID may supply the identity used for collaboration. Employee contributions may enrich skills and experience under separate rules.

Avoid declaring one winner for every conflict. Authority can differ by field, population and effective period. During a transfer, the source responsible for a person may change. The policy needs to explain that transition so that yesterday’s authority does not overwrite today’s accepted record.

Establish identity before standardizing terminology

In an employee directory from multiple HR systems, first determine which records refer to the same person. Preserve source identifiers with their source context and link them to the relevant account through a reviewed process. A common employee number is helpful only if its uniqueness is established across the participating systems. Names and email addresses are useful clues, not universal proof.

SCIM’s core schema separates resource identifiers from client-supplied external identifiers. That supports a careful exchange model, but it does not eliminate the need to govern cross-source matching. IETF, RFC 7643

Review ambiguous records explicitly. A person working across legal entities may have several legitimate employment records. A contractor converting to an employee may appear under a different source reference. A recently acquired business may duplicate existing accounts. A forced one-row model can hide these realities rather than simplify them.

Once identity is clear, agree the organizational vocabulary. Keep legal employer separate from division, department separate from cost center and registered location separate from current workplace. Map equivalent terms where the business confirms equivalence. Retain meaningful local distinctions where it does not.

Make the common model small enough to govern

The first employee directory from multiple HR systems does not need every field available in every source. Start with information that supports the priority tasks and has an accountable owner. A small set of reliable attributes can be more useful than a broad profile filled with inconsistent values.

For each field, specify meaning, source, visibility, edit rights and expected freshness. Include the treatment of unknown and not-applicable values. If a country cannot supply a field, show the coverage gap rather than inventing a default that later appears in analysis as a real fact.

Use the same definitions in reporting. People, employees, external workers and FTE are different measures. Employee FTE should reflect the recorded working percentage for the eligible population, with coverage disclosed. A country with incomplete working-pattern data should not quietly appear less staffed simply because its feed contains fewer values.

Microsoft’s HR provisioning planning guidance includes matching, mapping and scope decisions as deployment concerns. Native provisioning can be part of the architecture; a consolidation design should acknowledge and coordinate with it rather than assume every existing connection must be replaced. Microsoft, cloud HR provisioning

Add multiple HR systems to the employee directory in a deliberate order

The largest source is not always the best first source. A smaller, well-understood population can establish the common model and correction process. A deliberately difficult second source can test whether those decisions work across different terminology, identifiers and employment arrangements.

Choose each wave for what it will teach. Include a cross-source manager relationship early. Also add a person whose source authority changes after a transfer. Include a field that one source supplies and another cannot. These cases reveal whether consolidation is genuinely designed for a plural estate or merely a copy of the first system’s assumptions.

Before publication, compare expected and observed populations and review exceptions with local owners. Do not require every country to resolve every optional field before the directory becomes useful. Do require explicit acceptance of what is missing and a clear route for improving it.

Keep multiple HR systems from contesting the employee directory

Two-way flows need a field-level rule about who may write what. An update should not bounce between systems simply because both directions are enabled. Where the directory helps HR correct organizational information, the writeback route must respect the target’s authority and any on-premises controls.

Microsoft Graph distinguishes application access from access on behalf of a signed-in user. Those permission models should be understood for the planned connections and operations, rather than hidden behind a general statement that the system integrates with Microsoft 365. Microsoft, permissions overview

Separate the right to read a fact from the right to publish or change it. An integration account may retrieve data that ordinary employees should not see. A local steward may correct a department without receiving broad administrative access. Exports and agent answers need to follow the intended audience rules as carefully as profile screens do.

Distinguish a temporary integration exception from an accepted long-term difference. Both need an owner, but only the former should appear as unfinished rollout work. This prevents a global standardization program from treating every legitimate local distinction as a defect.

Turn exceptions into a durable operating process

Each unresolved record should have a reason and an owner. A source outage, ambiguous match and disputed department label require different action. The central team should not become the permanent translator for every local issue. Local owners need enough visibility to resolve their part, while the common service retains a consistent record of the outcome.

Track repeated exceptions by cause. If the same field is corrected after every run, fix the authority or mapping rule. Where a source regularly supplies incomplete extracts, address the extract process. If employees cannot interpret a normalized label, revisit the vocabulary with them. Consolidation quality improves when resolution changes the next run.

TeamConnect AI provides imports, configured connector templates, and governed organizational views for this operating model. A proposed deployment can make people findable and feed Organization Insights from the same accepted data, without moving all HR transactions into a new system. The value lies in consolidation and stewardship, not a claim that source complexity has ceased to exist.

When you add TeamJML AI, the organization and shared catalogs inform approved lifecycle work. Primary and continuing additional responsibilities contribute to requirements, while verified differences determine IT tasks. A department change that leaves access unchanged updates context without generating unnecessary fulfillment work. This is a Cubeet application proposal, not a statement about Sanofi’s deployment.

Set the completion test for an employee directory from multiple HR systems

Make onboarding the next source a test of the operating model. The new team should be able to understand the identity rules, propose mappings and identify unresolved ownership without rediscovering decisions made during the first implementation. Reusable configuration matters, but reusable reasoning matters too. Record why an exception exists and when it should be reconsidered so consolidation becomes easier to extend rather than harder to understand.

The program is ready for a wider audience when employees can complete the priority discovery tasks and operators can explain the source of important facts. Leadership should see scope, coverage and unresolved issues alongside the workforce view. A shared directory does not require pretending that every source has become identical.

Ask one practical question before expanding: if a person moves between two participating systems tomorrow, can the organization preserve their identity, publish the correct effective structure and explain any access consequence? A clear answer demonstrates a working federation of responsibilities. It is a stronger foundation than an arbitrary promise to consolidate every source within a fixed number of days.