How to Set Up Time-Off Requests for New Hires with an AI Company Brain

Answer a new hire's time-off question only after the HR system has confirmed who they are, which policy applies and who approves, and send anything that might be protected leave to the leave team the same day without collecting the story. A right answer for the wrong employee record is worse than a slow one. We recommend three habits on top of that. Record time off the hire arranged before joining as an approved absence before day one. Never let the assistant state FMLA eligibility. And test the request route with a draft request before the hire needs it. The company brain explains current policy and safe next steps, while eligibility, approvals, private details and request state stay with the teams and systems that own them.

Resolve the policy from the HR record

Do not let the model pick a policy by semantic similarity. Build a routing record from the HR system, or another named system of record, before any retrieval:

employee_id: emp_1042
lifecycle_state: active
start_date: 2026-09-14
work_country: US
work_region: CA
legal_entity: example_us_inc
worker_type: full_time
leave_profile_status: active
manager_id: mgr_87
policy_set_id: us_ca_full_time_2026
policy_effective_date: 2026-01-01
policy_owner: people_ops_us

The company brain uses policy_set_id as a hard retrieval filter. It does not infer the country from an IP address, guess the worker type from a job title, borrow a manager's policy because it looks similar, or calculate a balance that the HR system owns. Each policy page needs an owner, an effective date, an audience scope and a replacement relationship, and if two current pages conflict the assistant stops and routes the question to the owner and does not blend the text. A slower handoff costs less than a fast answer built on the wrong employee record.

def answer_time_off_question(employee):
    if employee.lifecycle_state != "active":
        return route_to("people-ops", "Time-off profile is not ready")
    if employee.leave_profile_status != "active":
        return create_setup_exception(employee)
    if not employee.policy_set_id:
        return block_policy_answers(employee, reason="missing policy_set_id")
    docs = retrieve(policy_set_id=employee.policy_set_id, effective_on=today())
    return answer_with_citations(docs, next_step=open_request_system(employee))

Keep the record current after day one. Microsoft's lifecycle workflows split a person's time with an organization into joiner, mover and leaver, and a transfer to another location, manager or legal entity is the kind of move the mover phase describes. Rerun the routing when a relevant attribute changes, mark old policy bindings as superseded and keep their history, and suspend automated policy answers until the owner fixes a record that no longer resolves. A published policy or a changed attribute should invalidate cached answers, and consequential guidance should show the source title and effective date beside it.

Time off the hire arranged before joining

Ask at the offer stage whether the hire has time off already booked, such as a trip, a wedding or a school break, and enter the agreed days in the HR system as an approved absence before day one. The Department of Labor says on its vacation leave page that the Fair Labor Standards Act does not require payment for time not worked, such as vacations, and that these benefits are matters of agreement between employer and employee. A day promised in an offer email is therefore a legitimate exception, as long as it is written where the HR system and the assistant can read it. Otherwise the hire, who may not have accrued anything yet, asks the assistant about the trip and is told there is no balance, and the assistant appears to have broken the manager's promise.

GitLab's onboarding handbook shows a pattern worth copying: it documents the dates, such as a national holiday or its Family and Friends Day, when People Operations cannot assist with onboardings, so a hire can see when help is unavailable. Do the same for the team that answers leave questions, and list the company's non-working days beside the policy so the hire knows which days come out of the balance and which do not.

Eligibility for protected leave is not a chat answer

Offer neutral categories first, such as vacation, ordinary sick time, scheduled personal time, parental leave, workplace accommodation, family or medical leave and "I am not sure", and ask for a category and never a personal story. For ordinary PTO the assistant explains the cited policy and links the request system. For anything that may be protected, it names the approved private route and stops collecting details. The handoff holds only routing data and never the narrative, attachments or reason:

{
  "employee_id": "emp_1042",
  "request_category": "family_or_medical_leave",
  "source": "onboarding_assistant",
  "policy_set_id": "us_ca_full_time_2026",
  "private_case_required": true
}

Do not let the assistant answer "Does FMLA cover me?". The Department of Labor's FMLA Employer's Guide sets four tests: a covered employer, at least 12 months with that employer, at least 1,250 hours of service in the 12 months before the leave starts, and 50 or more employees within 75 miles of the worksite. The 12 months need not be consecutive, so a returning employee's earlier time can count (a break of seven years or more can be excluded), and only hours actually worked count toward the 1,250, so PTO, sick leave and holidays add nothing.

The guide notes that 1,250 hours averages a little more than 24 hours a week, so a part-timer can pass 12 months of service and still fall short. A tenure counted from the start date in the routing record is therefore wrong in both directions, and eligibility should be a value the HR system computes.

The guide also gives the employer five business days, from a request or from learning that leave may qualify, to tell the employee whether they are eligible, with at least one reason when they are not. These are the leave team's duties. We recommend that the assistant answers with the route and the owner, not with "you haven't been here a year", which would be an eligibility decision made by a chatbot, outside the notice process and with no owner behind it. These are US federal rules, and other countries and states set their own, which the leave team or counsel maps for each place you hire.

NIST's Privacy Framework page lists a Data Governance and Management Profile among its projects, which is worth a look from the team that will own the allowlist. The framework is voluntary and creates no duty here, but the question it raises applies directly: whether holding a leave reason in the knowledge layer protects the person or only exposes them. Keep the layer to categories, routing and safe status such as profile_ready, request_received or action_required.

Prove the route before it matters

A correct policy answer does not show that the workflow works. During onboarding, run a draft request in a sandbox, a draft state or a provider-supported validation mode, and never submit real leave to test an integration. If none exists, check each dependency separately and have the hire confirm that the right request screen and approver appear. Success is a conjunction and not one checkbox:

ready = (
    employee_profile_active
    and policy_set_resolved
    and request_system_accessible
    and approver_resolved
    and employee_confirmed_route
)

Also check that notifications reach the hire and the owner, that deleting the test removes it, and that the company brain receives safe status and no request content. If one condition fails, keep the onboarding item open and assign the exception. Kipwise's employee onboarding workflow supports assigned reading, searchable company knowledge, and progress tracking. Use those capabilities for guidance and ownership, while keeping the HR system as the source of request acceptance and balance state.

Give each failure an owner and a safe message

Most failures are ordinary data or integration problems, and they turn harmful only when the assistant hides them behind a confident answer. Avoid messages that reveal internal security details or speculate about legal eligibility.

Measure the process, not the reasons

People Operations needs to know whether onboarding works and has no need for a searchable feed of why employees take leave. Track the share of new hires with a resolved policy set by day one, the time from active employee record to active leave profile, missing approvers and rejected readiness checks, the age of unresolved setup exceptions, and the share of policy answers that carry a current source and effective date. Keep these apart from request content and employment decisions, restrict access to exception records, and audit who can view them.

Add protected and location-specific leave only after one worker group and one ordinary PTO category pass the routing record, the private handoff and the draft-request test with a test employee.