In production · Two Rivers Regional Health District

Internal tool

New hire onboarding checklist assistant

Result in one line: Cut first-week help desk tickets from 11 to 3 per new hire

Builds a personalized checklist for each new hire, opens the access requests it can, and answers policy questions from the staff handbook.

Published January 27, 2026 Updated May 11, 2026 Verified June 5, 2026

Skills needed to set it up

Power user

Readiness

Guided setup Needs customization Human review built in

Data it touches

Personal information (PII) Internal, non-public data

Who sees the output

Internal staff

License

Not open source — available on request

Cost to stand up

No new spend

Portable to other platforms

No — tied to its platform

Use case category

Administrative & task automation

Reviews it went through

Labor or workforce consultation Records retention review

What do these mean?

Power user

Someone comfortable with spreadsheets, forms and low-code tools.

Guided setup

A wizard or script walks you through installation.

Needs customization

Your team will need to adapt it before use.

Human review built in

A person checks the AI's output before it is used.

Personal information (PII)

Names, addresses, IDs or other personal identifiers.

Internal, non-public data

Non-public operational data without personal identifiers.

Internal staff

Used only inside the organization.

Not open source — available on request

Peer jurisdictions can ask; say how in the access terms below.

No new spend

Built with licences, staff and infrastructure the organization already had.

No — tied to its platform

Depends on one vendor's services end to end.

Administrative & task automation

Forms, intake, scheduling, records — the routine work that eats staff time.

Labor or workforce consultation

Discussed with the union or the affected staff before rollout.

Records retention review

Confirmed how long the outputs must be kept and where.

Problem

Onboarding a new employee involved six people sending overlapping emails. HR sent forms, IT sent an account notice, the supervisor sent a schedule, building services sent badge instructions, and the new hire pieced it together. Nothing tracked what had actually been done. New inspectors regularly reached their second week without database access, and our service desk logged about 11 tickets per new hire in the first week — almost all of them “where do I find” or “who approves this”.

What we built

A checklist app on our low-code platform, plus a chat assistant that answers questions from published internal policy pages.

When HR marks a position filled, the app builds a checklist from a task library keyed to role, start date and work location. A field inspector gets vehicle and tablet tasks; an analyst does not. The app opens the access requests it is allowed to open, routes each to the right approver, and shows the new hire and the supervisor the same list.

How it works

The task library is a spreadsheet HR maintains — about 90 tasks with rules for when each applies. That spreadsheet, not the model, decides what appears on a checklist.

The assistant is a retrieval assistant over our handbook, IT policies and the access catalog. It answers only from those pages and shows the section it used. It is explicitly out of scope for anything about pay, classification, discipline or personnel records, and it says so rather than guessing. Out-of-scope questions are logged, which turned out to be a useful list for HR.

Every access request still needs a human approval. The assistant drafts and tracks; it does not grant.

Results

First-week help desk tickets fell from 11 to 3 per new hire. Time from start date to full system access dropped from a median of nine days to three. Supervisors report the biggest change is simply being able to see what is outstanding without asking.

Lessons learned

The rules belong in the spreadsheet, not the prompt. Every time we let the model decide which tasks applied, it produced a reasonable-looking checklist that was subtly wrong for someone. Keeping the logic where HR can read and edit it made the tool defensible and easy to hand over.

How to reuse

The runbook walks through the build in the order we did it: task library first, checklist app second, assistant last. Doing the assistant first is tempting and wrong — the checklist alone delivered most of the benefit, and it works without any AI at all.

About

Area of work

• HR & workforce
• IT & operations

Review status

Reviewed & approved

How it's built

How AI is involved

AI is part of the solution

Types of AI

• Chat assistant
• Document Q&A (RAG)
• Agents & automation

AI tools & models

• Azure OpenAI GPT-4o
• Power Automate
• SharePoint

Where it runs

• Low-code platform
• Microsoft Azure

Sharing & licensing

Access terms

The Power Platform solution file is available to other agencies on request; it needs an Azure OpenAI deployment of your own.

Portability notes

Built in Power Apps and Power Automate against Azure OpenAI; moving it means rebuilding the flows on another low-code platform.

What it took

Cost to keep running

No ongoing cost

How it was bought

• Existing enterprise licence

Who it affects

Every new hire meets it in their first week, which makes it an accessibility question before anything else. We tested the checklist with a screen reader and with our two colleagues who use one daily, and the plain-language pass brought it from a grade 14 reading level to grade 8 — the same standard we hold public notices to.

Data & access

No PII/PHI in the shared material

Yes

Data sources

• HR position control list
• Staff handbook
• IT access catalog

Data-governance caveats

New-hire records include personal information; the assistant reads only the checklist status fields, and the HR system remains the record of truth.