How to Give New Hires a Living Employee Org Chart with an AI Company Brain

A new hire asking who can approve something needs a route, not a reporting line. We recommend building the living org chart as a table of routes, each one a question class, an owner, a delegate, a source and an effective date, and letting the assistant answer only when exactly one route matches the question and the asker. The reporting tree is an input to that table and never the answer. When zero or two routes match, the assistant hands the question to a named team and does not guess from a job title.

A reporting line answers a different question

A manager may approve time off but not production access. A department head may own a function and delegate a regional process. A subject expert can explain a policy without the authority to approve an exception. If the assistant treats every question as "find the manager", it sends new hires to people who cannot finish the task. Titles mislead too. GitLab's organizational structure page points out that a title such as product manager, accounting manager or account manager, with no comma after "manager", belongs to an individual contributor with no direct reports, while "Manager," with a comma means a people manager. A rule that matches the word manager would send an expense question to the wrong person.

Freshness is the second problem. Reorganizations, leave, open roles and transfers change the route while screenshots and onboarding decks stay the same. We recommend indexing responsibilities and reading relationships live. The route records are the part that only people know and only people can keep current, so they belong in the index. Who reports to whom is already maintained by the directory, and a copy goes stale the day after the next reorganization.

The Microsoft Graph manager endpoint returns a user's current manager and can expand the chain up to the root, so the index never needs to store one. GitLab's structure page makes the same call from the other side: its HRIS is the single source of truth for team member and organizational information, and the org chart is read from there.

Privacy is the third constraint. An employee directory can hold personal phone numbers, locations, assistant relationships, management levels and profile notes that a new hire does not need. NIST's Privacy Framework is voluntary and offers a Quick Start Guide of basic questions for getting started with managing privacy risk. The first question here is which profile fields a new hire needs to route a question. The rest stays out of the index, however convenient it would be to search.

The route record

Keep identity facts and responsibility facts apart. Identity data comes from the HR system or directory, and responsibility records come from the team that owns the process. The assistant indexes a safe projection of both, not an unrestricted copy of either. A minimal route record looks like this:

route_id: expense-approval-us
question_class: employee_expense_exception
scope:
 legal_entity: kipwise_us
 worker_type: employee
 region: us
accountable_team: finance_operations
primary_owner: user_1842
delegate: user_2910
effective_from: 2026-08-15
effective_until: null
knowledge_source_id: finance-expense-ownership
review_owner: finance_ops_lead
review_due_at: 2026-11-15
visible_profile_fields:
 - display_name
 - team
 - work_contact
escalation_team: people_operations

• question_class stops a broad title match from deciding ownership. "Finance" is no use as a route when the new hire needs an expense exception, a payroll correction, a procurement review or a revenue-recognition answer.
• scope holds only the attributes that change the answer. Never pass medical information, compensation, performance data or full HR records into retrieval.
• primary_owner and delegate are directory identities, and both must resolve to active identities before the route is eligible.
• knowledge_source_id, review_owner and the dates make the answer verifiable. A route without an owner or a review date becomes another static org chart after the next reorganization.

Build it in five steps

1. One system of record per field

Declare which system owns each field. The HR system may own employment status and manager ID, the identity directory work email and account status, and a maintained knowledge page or service catalog the process responsibility and escalation policy. Graph keeps tenant data and people data apart in the same way: its organization resource describes the tenant, with its ID, display name, address and service plans, while a person's manager is a relationship on the user. Index only the documented fields each lookup needs. If two systems both claim the manager field, write down which one wins and alert on disagreement. Never take whichever value was indexed last.

2. Project only safe fields

Write an allowlist for the onboarding use. Display name, team, work contact, manager reference, supported region and active status is a practical set, and home contact details, birthdays, private notes and compensation do not help a new hire route work. Apply access control before retrieval, not after the model writes an answer, so the new hire's identity and groups decide which route records and fields enter the context. If a route points to a restricted team, return the approved contact channel and not hidden names or structure.

3. Link people to maintained responsibilities

Ask each operating team to maintain route records for the questions it actually owns, starting with payroll problems, expense exceptions, workplace and application access, benefits, security incidents and policy interpretation. GitLab's onboarding handbook shows why one new hire has several routes: the manager and a People Operations specialist are both assigned to the onboarding issue, each with their own tasks before the start date, and access requests belong to the IT team. None of those three is found by walking the reporting chain. Give every route a named review owner, who is accountable for its accuracy even when the contact belongs to another team.

4. Resolve with rules, and keep the model out of the choice

Filter deterministically first, on active employment state, legal entity, region, worker type, question class and effective date. Then use semantic retrieval only to pick among the approved routes that remain.

def resolve_route(question, employee, now):
    candidates = routes.where(
        question_class=classify(question),
        legal_entity=employee.legal_entity,
        region=employee.region,
        worker_type=employee.worker_type,
        effective_from__lte=now,
    ).where_not_expired(now)

    candidates = enforce_permissions(employee, candidates)
    candidates = [
        r for r in candidates
        if identities.active(r.primary_owner) and identities.active(r.delegate)
    ]

    if len(candidates) != 1:
        return escalate_with_reason(candidates)

    route = candidates[0]
    # availability is a yes/no flag; the leave record and its reason never reach this code
    contact = route.primary_owner if identities.available(route.primary_owner) else route.delegate
    return answer_with_source(route, contact)

A zero-result or multi-result state is an exception that needs a named team, not a prompt asking the model for its best guess. We recommend that the resolver receives only a yes or no availability flag from the HR or calendar system, never the leave record or its reason, and that the answer names only the contact in effect. A leave type is sensitive personal data, and a new hire gains nothing from learning that the usual owner is out. They need the person who can act today.

5. Show the evidence with the answer

The answer names the contact or team, the responsibility being routed, the scope that matched, the source and the last review or effective date, and it separates advice from approval authority. For example: "Finance Operations owns US employee expense exceptions. Contact Jordan through the Finance Help channel. This route applies to US employees and was reviewed on August 15. The linked policy explains the required evidence. Jordan can route the exception, but the designated approver makes the final decision." That gives a usable route without exposing the finance reporting tree.

When things change or fail

A living map needs event-driven updates and periodic reconciliation. Microsoft Entra lifecycle workflows name the same three events, joiner, mover and leaver, and can scope and trigger tasks from user attributes such as the department. A mover event is the moment to recompute every route that names the person or sends questions to them, and so are a manager change, the start and end of a leave, a deactivation and an effective-date transition.

• The owner is inactive. Suppress the route, try an active approved delegate and alert the review owner.
• Two routes match. Show neither as authoritative, and send the question class and scope to the escalation team for correction.
• No route matches. Say which scope lacks coverage and open a gap record. Do not fall back to the nearest job title.
• The source is overdue for review. Label it stale, restrict consequential instructions and require owner confirmation.
• Directory and HR data disagree. Freeze manager-dependent routing until the precedence rule resolves the conflict.
• The employee cannot view the source. Return a safe contact channel and report the permission mismatch to the content owner.
• A delegate period expires. Restore the primary owner only after identity availability and route dates both pass validation.

Track these as route-quality data, not employee-performance data. The metric that matters is the share of approved question classes that have exactly one current route, and it says nothing about which new hire asked for help most often.

Test it before anyone relies on it

A directory page view does not prove that a new hire can find help. Give the new hire two or three synthetic scenarios, such as reporting a missing application entitlement or asking who handles an expense outside the standard policy, and have them find the route through the assistant. It passes when the answer names the current route, shows the source, respects permissions and offers a valid escalation path. Kipwise's new-hire onboarding workflow provides product context for assigning reading and tracking progress. Treat route verification as its own result. Do not infer it from a generic onboarding completion percentage.

Build a test matrix across regions, entities, roles and permission groups, with negative tests for restricted teams, inactive owners, expired delegates, duplicate records and missing routes. Run a nightly reconciliation of every route reference against the identity directory, and sample answers after each reorganization to confirm that the old route is gone. Call the system a living org chart only after it passes those checks following a simulated manager change and an owner deactivation.

Start with ten questions

List the ten questions new hires most often route through a manager today. Give each one a question class, an owner, a delegate, a source, a scope and a review date, and connect only the directory fields needed to resolve them. Test the flow with two synthetic new-hire profiles and deliberately deactivate one owner. If the assistant returns a sourced route for the valid cases and a clear escalation for the failure, extend the map one operating team at a time.