One record per person
A single item for each employee carrying the details the business asks about weekly, with their documents attached to it. Not a folder here, a spreadsheet row there, and a third version of the start date in someone’s notes.
SharePoint HR management system
A SharePoint HR management system for employee records, leave and self-service
One place for employee records, leave requests, HR documents and the self-service forms your staff currently email to somebody — built on the Microsoft 365 licenses you already hold, with permissions designed around who is allowed to open whose file. This is the transactional side of HR: records, requests, routing and access. One written scope, one fixed price agreed before work starts, typical delivery in 2–4 weeks with 30 days of hypercare.
Representative dashboard — sample data
What you get
Six pieces of employee administration, built as one thing
Every one of these exists in your company already. They are spread across a folder nobody is sure who can open, a spreadsheet one person maintains, and a mailbox where requests go to wait.
Fields that make a record complete
Manager, job title, department, employment type, start date, status, work location. Required where they matter, chosen from lists rather than typed, so the same department is not spelled four ways by the end of the year.
Leave requests that route themselves
A request goes to the right manager, the decision comes back with a name and a date attached, and the whole year is one filterable view. Nobody forwards an email to HR so it can be re-keyed into a spreadsheet.
Self-service forms, not an inbox
Address changes, employment letter requests, equipment requests, policy acknowledgments. Staff submit them themselves and each one lands as a tracked item with an owner, instead of as the eleventh unread message of the morning.
Documents with access designed first
Employee files are one of the few document sets where the wrong person opening the right folder is a serious event. The permission model is agreed in the first session and granted to groups, not assembled from one-off shares.
Task routing when a record changes
A joiner, a move between departments or a leaver raises the task list those moments always need, assigned to the people who own each step. The checklist stops living in one person’s notebook and starts living in the system.
How it works
Three steps from an inbox to something HR runs
- 1
Agree the record, the routes and the access rules
A working session with whoever owns HR decides what an employee record must carry, which requests exist and who approves each one, and — the question that takes longest — who may see which documents about whom. The answers are written down before anything is built.
- 2
Build the lists, the forms and the flows
The employee list, the restricted document library, the request forms, the approval routes and the task routing are configured in your own tenant, then tested with the people who will actually submit and approve things rather than demonstrated at them.
- 3
Load the people and hand over
Existing employee data is cleaned and loaded, the documents move into the library with the agreed permissions, the old locations are closed rather than left as a second source of truth, and HR gets a walkthrough plus 30 days of hypercare.
Why employee administration outgrows a folder first
HR data behaves unlike the rest of a company’s content. It is about named individuals, most of it is confidential to a small group, a lot of it is transactional rather than documentary — a request, a decision, a date — and the questions asked of it are questions a folder cannot answer. A shared drive can store a signed offer letter. It cannot tell you who is on leave next week, which employees have not acknowledged the handbook, or whether the person who left in March still has access to anything.
It is worth being precise about what this is and is not, because an HR portal sits next door to an intranet and the two get sold as one thing. An intranet answers “what is happening at this company”: news, a homepage, a policy hub, the place announcements land. That is a different build, and it is our SharePoint intranet and document management consulting engagement — delivered on the timetable our SharePoint intranet in 30 days page sets out, and priced the way our SharePoint intranet cost guide explains. This page is the other half: records, requests, routing and access. Plenty of companies end up wanting both, and they are usually sequenced rather than merged, because the permission model here is far tighter than anything a company homepage needs.
The employee record, and the fields that make it usable
Everything downstream depends on there being one record per person that is actually complete. In SharePoint that record is an item in a list, with a person column linking it to the real Microsoft 365 account rather than to a typed name, and with columns for the details HR is asked about. Microsoft’s guidance on adding columns to a content type (opens in new tab) covers the mechanics, including making a column required so a record cannot be saved half-finished and quietly rot.
One thing worth not rebuilding: the directory. Name, job title, department, manager and contact details already live on the Microsoft 365 profile behind every account, which is why we read the directory from there instead of maintaining a parallel copy. Microsoft’s reference on managing user profiles in the SharePoint admin center (opens in new tab) sets out where that data comes from and where it has to be edited — almost always in Microsoft Entra ID rather than in SharePoint. A hand-kept staff list is the most common thing we find and the easiest thing to retire.
| Part of the system | How it is built | What it usually replaces |
|---|---|---|
| Employee records | One list item per person, linked to their Microsoft 365 account, carrying the agreed fields | A folder per person plus a spreadsheet that duplicates half of it and disagrees with it |
| Employee directory | Read from the Microsoft 365 profile data already behind every account | A page somebody updates when they remember, and a printed list in a drawer |
| Leave and time-off requests | A form that writes to a list, and a flow that routes it to the manager and records the outcome | An email to a manager, forwarded to HR, re-typed into a tracker at month end |
| HR document storage | A restricted library, permissions granted to groups, separate from anything staff browse | A folder that is “private” because nobody has been given the link yet |
| Self-service forms | Staff-facing forms for address changes, letter requests, equipment and acknowledgments | Messages to a shared mailbox, actioned in whatever order they were opened |
| Approval routing | Power Automate approvals writing the decision, the approver and the date back to the record | A reply-all thread with three opinions and no recorded outcome |
| Joiner, mover and leaver task routing | A flow that raises the right task list, assigned to the people who own each step | A checklist in one person’s notebook that only works while that person is there |
Requests, and what self-service actually removes
The transactional half is where the time goes. Leave requests, address changes, employment letters, equipment, policy acknowledgments — individually trivial, collectively most of an HR administrator’s week, and almost always arriving as email. Self-service does not mean staff do HR’s job. It means the request arrives as a record with a status and an owner instead of as a message that has to be remembered.
Mechanically it is unremarkable, which is the point. Requests are list items; the forms people fill in are SharePoint list forms, customized in Power Apps where the default is not enough — Microsoft documents customizing a SharePoint list form in Power Apps (opens in new tab) if you want to see what that involves. Routing uses Power Automate’s approval actions (opens in new tab), which handle sequential and parallel sign-off, reminders and timeouts. If you want to understand the mechanics before commissioning anything, our guide to replacing email approvals with Power Automate builds one step by step, and where approvals across the whole business are the real problem rather than HR specifically, that is the remit of our Power Automate consulting engagement. Where the request needs a screen with real logic behind it rather than a form, it becomes a small app, which is custom Power Apps for business workflows territory.
What this engagement adds is the HR-shaped part: which request goes to the line manager and which to HR regardless of who submitted it, what happens when the approver is the person the request is about, how a manager sees their own team’s requests and nobody else’s, and what the flow does when someone has no manager recorded. We also insist on one production detail: the flows’ connections should be owned by a service account rather than by whoever built them, so the routing survives that person changing roles. It is a five-minute decision at build time and an outage nine months later if it is skipped.
Onboarding and offboarding appear here only as routing. When a record is created or its status changes, the flow raises the task list those moments need — the account, the equipment, the introductions, the return of the laptop — and assigns each step to the team that owns it. The system routes the work; it does not attempt to be a separate onboarding product.
Who is allowed to open an employee’s file
This is the part that takes the longest to agree and the least time to build, and it is the part a badly scoped HR portal gets wrong. There are usually three audiences and they are not nested neatly: the HR group, which sees everything; managers, who should see a defined subset about their own reports and nothing about anyone else; and employees, who should see the handful of documents that concern them. Say those three out loud before anyone configures anything, because the shape of the libraries follows from them.
The workable pattern is almost always separate libraries with distinct permissions rather than one library carved up item by item. Microsoft’s reference on permission levels in SharePoint (opens in new tab) explains how inheritance flows from site to library to item and what each level actually grants, and the guidance on customizing SharePoint site permissions (opens in new tab) makes the case for assigning permission levels to groups rather than to people one at a time. There is a hard reason to prefer that design as well as a maintenance one: Microsoft’s published SharePoint limits (opens in new tab) put the supported ceiling for unique permissions in a single list or library at 50,000 while recommending a general limit of 5,000 — and a per-employee-folder design in a company of any size heads toward that number rather than away from it.
Retention is the next conversation. Employee files are usually kept for a defined period after someone leaves rather than forever or until a tidy-up, and Microsoft Purview retention policies and labels (opens in new tab) are what enforce that without anyone having to remember. We configure it where you have a rule; where you do not have one yet, we say so and leave it out rather than inventing a schedule on your behalf, because how long you must keep a personnel record is a question for your own counsel and not one a Microsoft consultancy should answer for you. If the wider estate already carries years of broken inheritance and stale sharing links, that is a separate and larger job — our SharePoint governance consulting services handle the estate-wide version, and it is worth doing first if the HR site would otherwise inherit the mess.
Where your system of record should actually live
Here is the line we draw before anyone signs anything. If you already run a payroll platform or an HRIS, that product is your employee system of record and it should stay that way. The right design then has employee data flowing out of it rather than being maintained twice, and Microsoft’s overview of HR-driven provisioning with Microsoft Entra ID (opens in new tab) describes the established version of that pattern, where the HR application is the source of authority and identity follows it. What we build in that case is the transactional layer the HR product does not cover well — the requests, the routing, the documents — sitting alongside it, not competing with it.
If you do not run one, the honest question is whether you should buy one instead of building this. Sometimes you should, and the product vendors in this category are not going to be the ones who tell you when.
| If this describes you | The honest answer |
|---|---|
| You need to run payroll, file payroll taxes, or produce year-end tax forms | Buy a payroll product. We do not build payroll and would not try — the calculation and filing obligations are a vendor’s job to keep current, not a consultancy’s |
| You need benefits enrollment with carrier feeds and the reporting that goes with it | Buy. This is regulated, integration-heavy and changes annually; a dedicated product earns its fee here |
| You need an accountable vendor behind your employee system of record | Buy an HRIS, and keep it the master. We will build the request and document layer around it rather than duplicating the employee data |
| You need performance cycles, compensation planning and succession as a connected product | Buy, or scope something considerably larger than this engagement with clear eyes about what it will take |
| You mainly need records findable, leave routed, HR documents locked down and requests off email | Build it here. This is the common case for a company of this size, and it runs on licenses you already hold with no new vendor and no second login |
| You already pay for an HR product nobody uses because it is one more system to sign into | Worth a conversation before you do either. Sometimes the answer is to surface that product where people already work rather than to replace it |
What your licenses already cover
Most of this runs on entitlements you are already paying for, which is the whole argument for building it here rather than buying a per-seat product for a few hundred people. We would rather set out the exceptions plainly than let them surface after signature. Which parts of the automation stay inside your existing rights is worth checking against our note on Power Automate licensing for small business during scoping.
| Component | How it is delivered | Cost beyond the licenses you hold |
|---|---|---|
| Employee records and HR document library | SharePoint lists and libraries with an agreed content type and per-audience views | None — part of the SharePoint entitlement in standard Microsoft 365 business and enterprise plans |
| Leave and self-service request forms | SharePoint list forms, customized in Power Apps where the standard form is not enough | None where the build stays on SharePoint data and the standard connectors your plan includes |
| Approval and notification routing | Power Automate approval actions writing the decision back to the request record | None on standard connectors; premium connectors or a Dataverse-backed build is a licensing question we raise in scoping |
| Employee directory | Read from the Microsoft 365 profile data behind the accounts you already license | None — and no second copy of the staff list to maintain |
| Retention on employee files | Microsoft Purview retention policies or labels applied to the HR library | Depends on your plan — some retention capability is included and some is an add-on, so we check your tenant before scoping it |
| Reporting on headcount and requests | SharePoint views for day-to-day questions; a Power BI report where leadership wants the whole picture | Views cost nothing; a published Power BI report needs the relevant Power BI licensing, which we flag before building one |
Who this fits, and who it does not
The usual fit is a company of roughly 20 to 500 people already on Microsoft 365, where HR is one person or a small team, employee files live in a folder whose permissions nobody has audited, and requests arrive by email. The trigger is almost always specific: a leaver who kept access for a month, an auditor or insurer asking for records that took three days to assemble, a manager who saw a document they should not have, or the administrator who held the whole thing in their head handing in notice.
Two adjacent cases are worth naming so nobody buys the wrong build. If what you need to track is training rather than employment — course assignment, completion records, certification expiry — that is a different structure with different fields and our SharePoint learning management system engagement is the one that fits. And if the documents that need controlling are commercial agreements with other companies rather than records about your own people, the fields are renewal dates and counterparties instead, which our SharePoint contract management system engagement builds.
It fits badly in two cases and we will say so at the consultation rather than after. If nobody will own it, it will decay exactly like the folder it replaced, and the honest first step is settling that question rather than starting a build. And if your employee data is genuinely in a mess — three sources that disagree about start dates and job titles, leavers still listed as current — cleaning it is real work that happens either before the build or as an explicit, priced part of it. It is never free, and a project that pretends otherwise is the one that stalls in week two.
Everything produced is yours from day one: the lists, the library, the forms, the flows and the documentation live in your own Microsoft 365 tenant, never in ours. It is ordinary SharePoint and ordinary Power Automate, so any competent Microsoft partner — or your own team, after the walkthrough — can change it later without us. How the fixed fee is set and what is agreed before work starts is spelled out on our fixed-fee process page.
Related services
What usually sits either side of this build
SharePoint Consulting
The wider build: information architecture, libraries, metadata and an intranet designed rather than accumulated.
Power Automate Consulting
Approval, notification and provisioning workflows across the business, not only the ones HR owns.
Power Apps Consulting
When a request needs a real screen with logic behind it rather than a form on a list.
Further reading
Guides behind the decisions in this build
Hand-written guides from our article library.
Replace email approvals with Power Automate
How an approval flow is built, tested and escalated — the mechanics this page deliberately does not repeat.
Dataverse vs SharePoint lists
The backend decision behind the employee record, including row-level security and what it costs in licensing.
SharePoint vs OneDrive vs Teams storage
Which system a document belongs in, settled before a signed offer letter ends up in a personal drive.
FAQ
Questions people ask before booking
One list holding a single record per employee with the fields HR actually asks about, a restricted library for the documents attached to those people, the leave and self-service forms staff submit themselves, and Power Automate routing that sends each request to the right approver and writes the decision back to the record.
No, and we will say so at the consultation. Payroll runs, tax filing, benefits enrollment and carrier feeds belong to a payroll or HRIS product. If you already run one, it stays the system of record for employee data and this build reads from it rather than keeping a second copy that drifts.
Whoever you decide, agreed before anything is configured. The usual shape is a restricted HR library that only the HR group reaches, a narrower set a manager can see about their own reports, and the few documents an employee can see about themselves. Access is granted to groups, never person by person.
An employee opens a form, which creates an item in a list. A flow sends it to their manager for approval, writes the decision, the approver and the date back to that item, and notifies the employee. HR sees every request in one view instead of reconstructing the year from an inbox.
Mostly yes. The forms people fill in can be surfaced as a tab in Microsoft Teams, where they already are, and approvals arrive as a notification they action without opening anything else. Only the HR team works in the underlying lists and library day to day.
Typical delivery is two to four weeks from kickoff, with the date written into your scope. The fixed fee reflects how many forms and approval routes are in scope, how much existing employee data has to be cleaned before it loads, and how complicated the access rules turn out to be.
Book a free consultation
Get more from the Microsoft tools you already pay for
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
- Fixed-fee scope agreed before any work starts
- Senior, US-based Microsoft engineers — no handoffs
- Typical 2–4 week delivery
- 30 days of post-delivery hypercare included
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.