Fun Data Playgroundemployee data
Use casesField typesAccount← Generator

Employee sample data

A realistic HR dataset for dashboards, tutorials, pivot tables and database seeding — without lifting a single row from a real payroll system.

Generate employee data →Excel & Sheets guide

The schema

An employee table that actually exercises a dashboard needs a mix of identifiers, categories, dates and numbers. This one takes about a minute to build in the generator:

Column          Field type              Options
------------------------------------------------------------
employee_id     Row Number
full_name       Full Name               locale: any
email           Email Address           unique
job_title       Job Title
department      Custom List             Engineering, Sales, Marketing,
                                        Finance, HR, Support, Operations
hire_date       Date                    from 2015-01-01, sequential
salary          Integer                 min 38000, max 185000
is_active       Boolean
city            City
country         Country
manager_id      Integer                 min 1, max 40
performance     Custom List             Exceeds, Meets, Developing
employee_id,full_name,job_title,department,hire_date,salary,is_active
1,Elena Rossi,QA Engineer,Engineering,2015-02-14,71000,true
2,Marco Schneider,Account Executive,Sales,2015-04-03,64500,true
3,Aisha Yılmaz,Data Analyst,Finance,2015-06-21,79200,false

Choices that make the data useful

A few decisions separate a dataset that demos well from one that falls apart on the first pivot:

  • Departments as a Custom List, not a random text field. Grouping and filtering only mean something if the same seven values repeat. Repeat a value in the list to weight it — listing Engineering three times gives you a realistically large engineering team instead of seven equal departments.
  • Hire dates sequential. Set the Date field's order to sequential and headcount grows smoothly over time, which is what a hiring chart should look like. A random draw produces a jagged mess.
  • Salary as an Integer with a real range. Anchor the minimum and maximum to your actual bands. If you want a realistic long tail rather than a flat spread, use the Number (Normal Dist.) field instead.
  • Blank % on optional columns. Manager, end date and secondary email should be empty for some rows — the CEO has no manager, and a dashboard that assumes otherwise breaks on row one.

Manager hierarchies

A manager_id drawn at random points at an arbitrary row, which is fine for a shape test and wrong for an org chart — it will produce cycles, and some employee will manage themselves. For a real hierarchy, generate the managers first as a small export, then feed their IDs into a Custom List on the employee schema so every report points at somebody who exists and is senior. The two-pass technique is the same one used for foreign keys in the database guide.

Where this data goes

  • Spreadsheets and BI. Export CSV, or TSV if you want to paste straight into a sheet. Watch employee IDs with leading zeros — see the Excel guide.
  • HR product demos. Generate once with a fixed seed so every screenshot and every demo shows the same people.
  • Database seeding. SQL export gives inserts plus an optional CREATE TABLE; PostgreSQL and MySQL notes cover bulk loading.
  • Training material. A fixed seed means every student works with identical data, so an exercise answer is the same for everyone.

Why not anonymised real data

Anonymising a payroll export is harder than it looks. Salary, job title, hire date and department together re-identify people in a small company even with names stripped, and an HR dataset is exactly the kind of thing that should never sit in a demo environment or a public repository. Generating from scratch avoids the problem rather than mitigating it — there is nothing to re-identify. The methodology page covers what each field draws from.

Common questions

Is this real employee data?

No. Every value is synthetic — names are recombined from public-domain pools, emails use reserved documentation domains, and salaries are drawn from a range you set. Nothing derives from a real payroll system.

How do I get realistic department sizes?

Use a Custom List and repeat the values you want more of. Listing Engineering three times and HR once produces roughly a three-to-one split instead of an even spread.

Can I build a proper manager hierarchy?

Not in a single pass — a random manager_id creates cycles. Generate the managers first, then paste their IDs into a Custom List field on the employee schema.

How do I make salaries cluster realistically?

Use the Number (Normal Dist.) field rather than Integer. A uniform range gives you as many people at the top of the band as in the middle, which no real organisation looks like.

Can I use this dataset in a public tutorial?

Yes. The data is synthetic and safe to publish or commit. Use a fixed seed so every reader sees the same rows.

Related