How to Build an Employee Database and HR System in Airtable

Most HR software is built for HR departments. Most companies under 100 people don't have an HR department — they have an office manager, an ops lead, or a founder doing HR on the side, and a graveyard of spreadsheets nobody trusts. Airtable is the right tool for exactly this situation: structured enough to be a real employee database, flexible enough to match your actual policies, and cheap enough that you're not paying per-employee pricing for software you use twice a week.

This guide is the full build: an airtable employee database at the core, onboarding checklists that generate themselves, PTO tracking with accrual formulas, a performance review cycle, an org chart, a Softr self-service portal, and Make automations to glue it together. It also covers, honestly, where Airtable falls short for human resources work and when a dedicated HRIS earns its price tag.

When Airtable Wins for HR (and When It Doesn't)

Be honest about the fit before you build. An airtable hr setup beats BambooHR, Rippling, and Personio when:

• You have under ~50–75 employees and no dedicated HR ops team.
• Your needs are directory, onboarding, PTO, reviews — not payroll or benefits administration.
• Your policies are custom enough that rigid HRIS workflows fight you.
• You're already running operations in Airtable and want HR connected to the same source of truth.

A dedicated HRIS wins when you need:

• Payroll and benefits administration. Airtable will never file your taxes. BambooHR runs roughly $10–25 per employee/month depending on tier; Rippling starts around $8 per employee/month with per-module add-ons for payroll, benefits, and IT management; Personio dominates the European mid-market with quote-based pricing.
• Compliance out of the box — I-9/right-to-work document workflows, e-signatures, retention rules, audit trails.
• Strict field-level security without workarounds. More on this below, because it's the single biggest limitation.
• Scale. Past 100–150 employees, the per-employee HRIS price becomes worth it for the admin time it saves.

The cost math at small scale strongly favors Airtable. A 40-person company pays an HRIS $400–1,000/month. The same company runs this entire build on Airtable Team (~$20/seat for the 3–8 people who need edit access) plus optionally Softr (from $49/month, priced by app users rather than per seat — though a 40-person portal needs the $139/month Professional tier, since Basic caps at 20 app users) — call it $150–300/month all-in.

The Honest Section: Sensitive Data and Permissions

Read this before you put a single salary in a base.

Airtable has no field-level viewing permissions. Paid plans do offer field editing permissions — you can lock a field so only specific collaborators can change it — but nothing restricts who can see a field. Visibility operates at the base, table, and interface level only. Anyone with collaborator access to your HR base can see every field on every record — compensation, home address, emergency contacts, performance notes. Hiding fields in a view does not secure them; anyone can create a new view or expand a record.

The workable patterns, in order of preference:

1. Two-base architecture. Base 1 is the directory — name, title, department, manager, work email, start date, photo. Safe for any manager to access. Base 2 is HR-confidential — salary, compensation history, disciplinary records, personal data — shared only with HR admins, linked to Base 1 by employee ID via sync. This is the pattern we deploy for every client.
2. Interface-only access. Share Interfaces (not the base) with managers and employees. Interfaces expose only the fields you place on them, which gives you effective field-level control. See our Airtable permissions guide for the full model.
3. Portal-only access for employees. Employees never touch Airtable at all — they see a Softr portal with row-level rules (each person sees only their own records). Covered in Step 7.

On GDPR: Airtable signs Data Processing Agreements and supports data subject access requests, so a compliant setup is achievable — but EU data residency and detailed audit logs are gated behind Enterprise plans. If you're EU-based and processing employee personal data at scale, factor that in, document your lawful basis, and set a deletion policy for departed employees. For the broader security picture, see is Airtable safe?

If any of this is a dealbreaker for your compliance posture, that's a legitimate reason to pay for a dedicated HRIS. For most small companies, the two-base pattern plus portal access is proportionate and defensible.

Step 1: The Schema

Five core tables, plus two optional ones.

Employees table fields

Two non-obvious decisions that save you later:

• Never delete former employees. Set Status to Former and fill End Date. You'll need their records for references, rehires, and data-retention questions.
• One Status field drives everything. Automations trigger on Status changes (Hired → onboarding kicks off; Offboarding → exit checklist), and every view filters on it.

Salary, compensation history, and disciplinary notes do not go on this table — they go in the separate HR-confidential base described above.

Step 2: Directory Views

The same Employees table serves different audiences through views:

• Active Directory (Gallery view) — filter Status = Active, photo as cover, showing title, department, email. This is the view people actually open daily.
• By Department (Grid) — grouped by Department, for headcount at a glance with a count summary per group.
• Starting Soon (Grid) — filter Status = Hired or Onboarding, sorted by Start Date. The HR working view for the next 30 days.
• Anniversaries (Calendar) — date field Start Date. Work anniversaries and probation-end dates in one place.
• Offboarding (Grid) — filter Status = Offboarding, with the exit checklist fields visible.

Step 3: Onboarding Checklists That Generate Themselves

This is the highest-value automation in the entire airtable hr build. The failure mode of manual onboarding is consistency: hire #7 gets a laptop on day one and hire #8 doesn't, because someone forgot to copy a checklist.

Task Templates table

Build your master checklist once:

A real checklist has 20–35 tasks. Don't skimp: include pre-start items (offer paperwork, equipment order, accounts provisioned at offset −7 to −2), week one (orientation, system walkthroughs, intro meetings), and the often-forgotten tail (30/60/90-day check-ins at offsets 30, 60, 90).

The generation automation

Trigger: Employee record updated, Status changes to "Hired."

With native Airtable Automations you can do this with a "Find records" step on Task Templates (filter Active = checked) plus a repeating group that creates an Onboarding Tasks record per template. With employee onboarding airtable builds we usually do this in Make instead, because Make handles the per-record iteration and date math more cleanly:

1. Webhook or Watch Records — fires when Status becomes Hired.
2. Search Records — pull all active Task Templates.
3. Iterator — loop over each template.
4. Create Record in Onboarding Tasks — copy task name, category, owner, instructions; link to the employee; set Due Date = Start Date + Day Offset days.
5. Notifications — Slack message to the IT channel for IT-category tasks, email to the hiring manager with a link to the new hire's checklist view, calendar invite for the day-one orientation.

The Onboarding Tasks table needs: Task Name, Employee (linked), Category, Owner, Due Date, Status (To Do / In Progress / Done / Blocked), Done Date. Add a rollup on Employees counting incomplete tasks — when it hits zero, an automation flips Status from Onboarding to Active and posts a welcome message.

The same pattern in reverse handles offboarding: a second template set (revoke access, collect equipment, exit interview, final payroll) triggered when Status changes to Offboarding. Offboarding is where companies get burned — a former employee with live system access is a security incident waiting to happen, and a checklist with an owner per task is the fix.

This is the same template-library pattern we use for client onboarding — see automate client onboarding with Airtable and Make for a deeper walkthrough of the Make scenario mechanics.

Step 4: PTO Tracking and Accruals

PTO is where spreadsheets fail hardest: balances drift, approvals live in email, and nobody can see who's out next week.

PTO Requests table

For policies that count workdays only, swap the formula for WORKDAY_DIFF({Start Date}, {End Date}), which excludes weekends and accepts a holiday list. Our date formulas guide covers the variants.

The accrual formula

On the Employees table, Accrued PTO for a monthly-accrual policy:

MIN(
  ROUND(
    DATETIME_DIFF(TODAY(), {Start Date}, 'months') * ({Annual PTO Allowance} / 12),
    1
  ),
  {Annual PTO Allowance}
)

Reading it: total months of tenure times the monthly rate (a 20-day allowance accrues at 1.67 days/month), capped at the annual allowance — so anyone past their first anniversary simply shows the full allowance, which is correct as long as you reset carryover and usage each year. For calendar-year accrual rather than anniversary-year, measure from January 1:

DATETIME_DIFF(TODAY(), DATETIME_PARSE(YEAR(TODAY()) & '-01-01'), 'months') * ({Annual PTO Allowance} / 12)

PTO Used is a rollup on Employees over linked PTO Requests: rollup field on Days Requested with aggregation SUM(values), conditioned on Status = Approved. Then:

{Accrued PTO} + {PTO Carryover} - {PTO Used}

That's PTO Balance, always current, never manually updated. If your policy grants the full allowance upfront on January 1 (grant-based rather than accrual-based), skip the accrual math and set Accrued PTO equal to the allowance — simpler is better if your policy allows it.

The approval workflow

1. Employee submits a request via form or portal (Step 7).
2. Automation notifies the Approver (looked up from the Manager field) by email or Slack with the dates, type, and the employee's current balance.
3. Manager sets Status to Approved or Denied — from an Interface button, not by digging in the base.
4. Automation notifies the employee of the decision, and approved leave appears on a shared PTO Calendar view (Calendar view on PTO Requests, filter Status = Approved, colored by Type).

Add a guardrail automation: if Days Requested exceeds PTO Balance, flag the request and copy HR. The general pattern is in our approval workflow guide.

Step 5: Performance Review Cycles

The goal isn't to replicate Lattice — it's to make sure review cycles actually happen and are written down.

Reviews table

The cycle automation

Launching a cycle is the same template trick as onboarding: an automation (scheduled, or button-triggered) finds all Active employees and creates one Review record each with the Cycle and Due Date set. Then:

• Notify each employee to complete their self-assessment (via a prefilled form or the portal).
• When Status moves to Manager Review, notify the reviewer.
• Weekly digest to HR of overdue reviews, grouped by manager — public visibility of laggards is the only thing that reliably closes review cycles.

For 360 feedback, add a separate Feedback table (one record per peer response, linked to the Review) so multiple peers can submit without overwriting each other. Keep written reviews in the restricted base or behind interface permissions — performance notes are sensitive data.

Step 6: The Org Chart

The airtable org chart is nearly free once your schema is right, because the Manager self-link from Step 1 already encodes the hierarchy.

Option A: the Org Chart extension (the standard answer). Add the Org Chart extension from the marketplace, point it at the Employees table and an "Active only" view, and set the Manager field as the relationship (type: Parent). Configure the Photo attachment field as the cover image and add Job Title and Department as secondary fields. The chart re-renders automatically every time a reporting line changes — reorgs stop requiring a slide deck. Two practical notes: extensions require a paid plan, and people excluded from the source view (former employees, contractors if you choose) simply don't appear, so filtering is your control mechanism.

Option B: Interface org chart. Airtable's interface extensions now include an org chart component (Airtable publishes one openly) that renders the same Manager hierarchy inside an Interface, which is the better option if your team lives in Interfaces rather than the data layer.

Option C: external rendering. For a public-facing or intranet org chart, pull the Employees table via API into a charting library, or display a grouped directory in Softr. Honestly, most companies under 100 people need Option A and nothing more.

One data-quality rule: exactly one person (the CEO) should have an empty Manager field. Add a view filtered to Manager is empty AND Status = Active — if it ever shows more than one record, your hierarchy is broken and the chart will fragment.

Step 7: Employee Self-Service with Softr

Here's the economic and practical unlock: employees should never need Airtable seats, and they should never email HR to ask "how many vacation days do I have left?"

Softr sits on top of your Airtable base and gives every employee a logged-in portal where they see only their own data. Pricing starts at $49/month for the Basic plan (up to 20 app users; $139 Professional covers 100, $269 Business covers 2,500), priced by app-user tiers rather than per seat — which is exactly the right shape for an employee portal.

Portal pages to build

1. My Profile — the employee's own directory record, with editable fields limited to phone, address, and emergency contact. Self-service data updates with zero HR involvement.
2. My PTO — current balance (from the formula fields), request history with statuses, and a "Request Time Off" form that creates a PTO Requests record. This page alone eliminates the majority of HR email traffic.
3. Team Directory — the Active Directory gallery: photos, titles, departments, emails. Deliberately exclude personal fields.
4. My Onboarding — for new hires, their own checklist with the culture/HR tasks they personally own.
5. My Reviews — self-assessment form during cycles, and completed reviews if your culture shares them.
6. Company Hub — policies, handbook, holiday calendar, announcements.

The critical configuration

Softr's row-level conditional filters do the security work: on every "my data" list, filter Logged-in user's email = Employee → Work Email. That single rule turns one shared base into a thousand personal views. Test it by logging in as two different test employees before launch — a misconfigured filter here is a privacy incident, not a bug.

Use Softr groups for the manager layer: managers additionally see a "Pending Approvals" page (PTO requests where Approver = them, Status = Submitted) with approve/deny buttons writing back to Airtable. Now the entire PTO workflow runs without anyone but HR ever opening Airtable itself. The mechanics are the same as our client portal build — swap clients for employees.

Comparison: Airtable HR Stack vs Dedicated HRIS

The honest summary: Airtable is the better system of record and workflow engine at small scale; an HRIS is the better compliance and payroll machine. Companies cross over somewhere between 50 and 100 employees — and the ones that built clean Airtable data migrate in days, not months.

Common Mistakes

Mistake 1: Salary in the main base. The most common and most damaging error. No field-level permissions means every collaborator sees it. Two-base architecture from day one.

Mistake 2: Deleting former employees. You lose PTO history, review records, and your ability to answer reference and legal questions. Status = Former, never delete.

Mistake 3: Manual onboarding checklists. If a human copies the checklist, a human forgets the checklist. The template-generation automation is an afternoon of work and pays for itself on the second hire.

Mistake 4: Accrual formulas that don't match the written policy. If your handbook says accrual pauses during unpaid leave, or carryover caps at 5 days, the formula must say so too. The PTO balance in Airtable is only authoritative if it implements the actual policy.

Mistake 5: Giving every employee a paid Airtable seat. Employees need forms, Interfaces, or a portal — not base access. This mistake costs real money and creates real privacy exposure simultaneously.

Mistake 6: No offboarding workflow. Onboarding gets built because it's pleasant; offboarding gets skipped because it isn't. The access-revocation checklist matters more.

Troubleshooting

PTO balance looks wrong. Check the rollup condition — it must include only Status = Approved requests. Then check whether the request-days formula counts calendar days while your policy counts workdays.

Org chart shows disconnected fragments. Someone has an empty Manager field who shouldn't, or a manager link points to a record filtered out of the source view. Use the "Manager is empty" audit view.

Onboarding automation creates tasks with no due dates. The Start Date was empty when Status flipped to Hired. Make the automation (or a validation view) check Start Date is filled before generating.

Employees see each other's data in Softr. The list block is missing the logged-in-user email filter, or employee Work Email values don't match their Softr login emails exactly. Audit both.

Approval notifications going to the wrong person. The Manager link is stale after a reorg. Reporting-line changes must update the Employees table first — the org chart doubles as your audit view.

Next Steps

A working employee database compounds: once Employees is the source of truth, it links to everything else you run in Airtable — project staffing, asset tracking, capacity planning, expense approvals. The natural extensions:

• Recruiting pipeline — an Applicants table that converts to an Employee record on hire, triggering onboarding automatically. See our HR and recruiting solutions.
• Document generation — offer letters and contracts generated from employee data (see generating PDFs from Airtable).
• Deeper automation — Slack birthday/anniversary posts, probation-end reminders, headcount dashboards. Start with the Airtable automation guide.

If you'd rather have this built, audited for the permissions pitfalls, and handed over working — including the Softr portal and Make scenarios — get in touch. HR systems are one of the most common builds we deliver, and the second-most common thing we fix after someone builds one with salaries in the main base.