HR Dashboard Template

This is a column contract, not a workbook. Bring one row per current employee carrying a hire date, a department and a location, and the people dashboard builds itself: headcount, tenure, the department and location shape of the company, and the remote split. Salary is optional and the page is honest about what including it costs you.

Load the template with sample data

The sample is the fastest way to see whether the layout fits before you go and find your own export, and in this domain it is also the safe way: judge the panels on invented people rather than on your colleagues.

Download the sample CSV to use as the target shape for your mapping.

The column contract

The exact headers in the sample file. One row is one person, and the grain matters: this is a snapshot of who is here today, not a history of everyone who ever was.

Column	What it holds	Role	Required	What breaks without it
`employee_id`	Stable internal identifier for the person.	identifier	Required	There is no reliable way to count people. Two employees sharing a name become one row in any grouping, and duplicates cannot be found.
`name`	Display name of the employee.	identifier	Optional	Nothing structural. Dropping it is the single easiest way to make the file safer to have on a laptop.
`department`	Function the person sits in.	category	Required	The main breakdown goes, and a headcount with no department is a single number that tells a planning conversation nothing.
`title`	Job title or level, such as Analyst or Associate.	category	Optional	Seniority mix disappears, so a department of twenty juniors and one of twenty principals look identical.
`hire_date`	Date the person joined, as an ISO date.	date	Required	No tenure, no hiring trend, no cohort view. Half this layout is built on this one column.
`salary`	Annual base compensation, one currency.	currency	Optional	The compensation panels are not built. Everything else works, which is why leaving this column out is a genuine option rather than a compromise.
`location`	Office or city the person is attached to.	category	Optional	You lose the geographic view, which is the panel that explains most of the variation in the salary panels.
`remote`	Whether the person works remotely: true or false.	boolean	Optional	The remote split is gone, and with it any read on how office attachment differs by team or by city.

Notice that tenure is not a column. It is derived from hire_date on purpose, because a stored tenure number goes stale the day after it is exported and nothing in the file says so.

What you get

A headcount strip. Total people, number of departments, number of locations and the share working remotely, each as a tile with the underlying count beside the percentage.
Headcount by department. A ranked bar with the count written on each one, which is the panel that gets pointed at in every planning meeting.
Hiring over time. Joins per month derived from hire_date, so the hiring waves and the freezes are both visible as shape rather than as anecdote.
Tenure distribution. A histogram of years since hire. A company with a tall bar under one year and almost nothing past three has a retention story it may not have told itself yet.
Location breakdown. Headcount by city, and the remote flag split within it, which is how you find the office that is technically an office and functionally three desks.
Compensation, when salary is present. Median salary by department and a salary distribution. Median rather than mean by default, because two executives drag a mean somewhere no employee actually lives.

i. Bring these columns

Before anything else, decide who is in the file. Active employees only is the assumption this layout makes. Contractors, interns and people on long leave each need a decision, and the decision matters more than which way it goes: a headcount that includes forty contractors and a headcount that does not will differ by forty, and somebody will quote whichever one they saw first.

Then decide about salary, deliberately and preferably not alone. The rest of the dashboard is genuinely useful without it, and a file of names and pay is a different category of document from a file of names and departments.

ii. Drop the file

Drag the CSV in. Hire date is read as a date and becomes both the hiring trend and the tenure histogram. Department, title and location become groupings. The remote column is read as a boolean and splits into two groups rather than being treated as text that happens to say true.

Employee ID is treated as an identifier even though it looks numeric in many systems, which means nothing offers to sum it. That is a small thing and it prevents a specific embarrassing chart: the total of everyone's employee number, presented as if it meant something.

iii. Adjust what you need

Keep salary panels on median unless you have a specific reason to switch. If you are presenting to a wider audience, delete the compensation panels entirely rather than hoping nobody scrolls, and rebuild them for the smaller meeting from the same file. Group the tenure histogram into wider bins for a small company, where a year-by-year view is mostly single-person bars.

Export the board as an image for a board pack, or take the numbers behind any panel as CSV when the figure is going into a document that has to be checked by somebody else.

Getting your export into this shape

An HRIS export from Workday, BambooHR, Personio, Hibob or a payroll system is close to this contract in content and quite far from it in shape.

It is too wide. A default people export runs to sixty or eighty columns, including emergency contacts, tax codes, addresses and custom fields somebody added in 2019. Cut it to the eight in the contract plus anything you genuinely want as an extra breakdown. Cutting is not just tidiness here: every column you keep is personal data you are now carrying around in a file.

Names arrive in pieces. First name, last name, preferred name and sometimes a middle initial, in four columns. Concatenate them into one name, or skip the whole issue by not exporting names at all.

Salary needs the most care of any column on this site. Three specific problems. First, part-time employees are usually stored at a full-time equivalent rate, so a median that mixes them is comparing an actual salary against a hypothetical one; either use the actual paid amount or filter to full-time. Second, multi-country companies store salary in local currency, and a column holding both eighty thousand euros and eight million yen produces a distribution that is pure noise, so convert or split by country. Third, base salary is not compensation: bonus, commission and equity are separate fields, and a sales organization's real pay picture is invisible if you chart base alone. Say in the panel title which one you charted.

Departments have hierarchy. Most systems store a full path like Engineering / Platform / Data. Charting the raw path gives you forty tiny bars. Split it and keep the level you actually plan at, usually the first or second segment, and put the deeper level in a second column if you want to drill.

What this template will not do

It will not measure attrition. A snapshot of current people cannot tell you who left. That needs termination dates and a row per employment event, which is a different contract.
It will not draw an org chart. There is no manager column and no reporting line, so hierarchy is not represented anywhere.
It will not run a pay equity analysis. Comparing medians is not an equity study. A real one controls for level, location, tenure and role, and it usually needs a statistician rather than a bar chart.
It will not anonymize for you. If you leave names in the file, they are in every table and every export. Small groups stay identifiable no matter how the panel is labeled.
It will not convert currencies or normalize part-time salaries. Both have to happen before export, and neither is flagged if you forget.
It will not forecast headcount. No hiring plan, no projection. What is in the file is what you see.

Frequently Asked Questions

Why is this a column contract instead of a spreadsheet I can download?

Because a people dashboard you download is a spreadsheet full of invented employees, and turning it into your dashboard means deleting all of them and rewiring every formula around your own columns. The reusable part is the mapping: which column feeds which panel and why. Written down as a contract, that mapping applies to any HRIS export in about ten minutes, and no copy of your people data has to be created to use it.

Should I really put salaries in the file?

Only if you need the compensation panels and only if you accept what the file then is. A CSV with names beside salaries is one of the most sensitive documents a company produces, and the fact that it never leaves your browser here does not stop it sitting in your downloads folder afterwards. If you want the distribution without the exposure, drop the name column and keep employee_id. If you do not need compensation at all, leave salary out entirely and the rest of the dashboard still builds.

Can I show a salary distribution without exposing individuals?

Yes, with two changes. Remove the name column so rows are identified only by an opaque employee_id, and read the salary panels as distributions rather than rankings: the histogram and the median by department are aggregate statements, whereas a bar chart of salary by person is a payroll list with extra steps. Be careful with small departments though. A median over a group of two is arithmetic that names people.

How is tenure calculated if there is no tenure column?

From hire_date, measured against today. That is why hire_date is required and why a stored tenure column is not in the contract: a stored tenure is correct on the day it was exported and quietly wrong every day after. A date recomputes itself. If you need tenure as of a specific review date rather than today, add a column with the difference already computed and chart that instead.

My export includes people who have left. Should I filter them out?

Filter them out for a headcount dashboard, keep them for an attrition analysis, and never mix the two silently. This contract describes current people, so a file including leavers overstates every headcount panel. If your export has a status or a termination date column, keep it and filter to active before building. Attrition needs a different shape anyway, one row per employment event rather than one row per person.

What should the remote column contain?

The words true and false, which are read as a boolean and split cleanly into two groups. Yes and no work too. What does not work well is a three-way field holding remote, hybrid and onsite in a column named remote, because the name then lies about the values. If you have three arrangements, that is fine and useful, just call the column work_mode and treat it as a category rather than a boolean.

Does the file get uploaded?

No. Parsing, aggregation and drawing all happen in your browser tab, with no upload endpoint behind the page and no request carrying your rows. For an HRIS export this is the whole reason the page can be used at all: in most companies, pasting a file of names and salaries into an online chart tool would be a policy violation regardless of how good the chart was.

Can I compare pay across departments fairly?

Partly, and only with care. Median salary by department is a real comparison. It is also confounded by seniority mix, by location, and by how long people have been there, none of which the panel controls for. Engineering paying more than Support may reflect a market rate rather than a decision. Use the panel to find questions, not to answer them, and bring the title and location breakdowns alongside it.

Judge it on invented people first

Open the sample, decide whether the panels are the ones you need, then pull the export you actually want.