How do you analyze BambooHR data in Metabase?
BambooHR analytics turns recruiting activity into a shared view of hiring funnel health, speed, quality, and capacity. BambooHR is an HRIS for employee records, time off, departments, locations, and, when enabled, hiring workflows. To analyze BambooHR in Metabase, sync employee and recruiting data into a database, model workers separately from applications, and build dashboards for headcount, time off, hiring funnel, and workforce planning. Metabase has no native BambooHR connector, so the data must land in a database or be uploaded first.
How do you connect BambooHR to Metabase?
Explore live HR data, then upload a snapshot
BambooHR has registry-listed MCP servers, including API wrappers for employee records, time off, benefits, payroll-adjacent data, and BambooHR API v1 access. Pair it with the Metabase CLI when you want an AI assistant to inspect BambooHR data, export a focused CSV, and load that snapshot into Metabase as a model.
- Quick lookups like aging applications, roles at risk, or interview bottlenecks
- One-off analysis before committing to a pipeline
- Loading a focused CSV into Metabase in minutes
- Great for exploration, not governed HR reporting
- Use read-only scopes and avoid broad employee or candidate PII exports
- A CSV upload is a snapshot; stage history needs a recurring sync
Durable dashboards with recruiting history
Use the BambooHR API, a managed connector where approved, or scheduled exports to land employee, job opening, application, time off, department, and location data in a Metabase-connected database. Keep sensitive HR fields out of broad models unless a dashboard truly needs them. Then connect Metabase to that database and build governed dashboards on modeled tables.
- Recurring dashboards for leadership, recruiting ops, and hiring managers
- Time-to-hire, time-to-fill, conversion, and source-quality trends
- Joining recruiting data with headcount plan, finance, or product data
- Requires a destination database and a sync to maintain
- You own stage, status, and sensitive-field definitions
- Access controls matter because HR and candidate data is sensitive
What can you analyze from BambooHR?
- Hiring funnel — applications by stage, stage-to-stagecandidate conversion rate, drop-off, and stale applications.
- Hiring speed — time to hire,time to fill, stage aging, and requisitions over SLA.
- Source quality — qualified candidates, interviews, offers, and accepted hires by source.
- Interview operations — scheduled interviews, feedback coverage, no-shows, reschedules, and interview pass-through rate.
- Offers — offer volume, acceptance, declines, starts, and offer acceptance rate.
Which dashboards should you build?
Hiring funnel
See where applicants enter, advance, stall, and accept offers.
- Applicants by stage (funnel)
- Stage-to-stage conversion by role and source
- Median time to hire
- Open roles by age and priority
Interview operations
Keep interviews moving without turning analytics into surveillance.
- Scheduled interviews by week
- Interview pass-through by role
- No-show and reschedule rate
- Candidate wait time between stages
Hiring plan
Compare headcount targets, requisitions, accepted offers, and starts.
- Open requisitions vs. plan
- Offers accepted vs. starts by month
- Roles at risk by days open
- Capacity by recruiter and hiring team
Source quality
Rank sources by quality and conversion, not raw applicant volume.
- Qualified applicants by source
- Offer acceptance by source
- Hires per sourced candidate
- Source mix over time
How MCP and the Metabase CLI fit together
MCP is useful when an AI assistant needs to inspect live ATS data or produce a narrow export. The Metabase CLI is useful when you want that export in Metabase as a table and model. Together, they are a fast path for exploration; the pipeline route is still the right path for governed reporting.
Community / gateway MCP server: BambooHR has registry-listed MCP servers, including API wrappers for employee records, time off, benefits, payroll-adjacent data, and BambooHR API v1 access. Keep permissions read-only where possible and avoid sending broad candidate or employee data to general-purpose assistant contexts.
Set up MCP + CLI
Adapt this to the specific BambooHR MCP server and scopes your team approves.
{
"mcpServers": {
"bamboohr": {
"command": "uvx",
"args": ["mcparmory-bamboohr"],
"env": {
"SERVER_COMPANYDOMAIN": "your-subdomain",
"BASIC_AUTH_USERNAME": "your-bamboohr-api-key",
"BASIC_AUTH_PASSWORD": "x"
}
}
}
}Use uploads for snapshots and prototypes; move recurring dashboards to a warehouse-backed sync.
# Install the Metabase CLI
npm install -g @metabase/cli
# Log in (opens your browser; requires Metabase v62+)
mb auth login --url https://your-metabase.example.com
# Load BambooHR exports - each upload creates a table and a model
mb upload csv --file bamboohr-applications.csv --collection "HR & Recruiting"
mb upload csv --file bamboohr-jobs.csv --collection "HR & Recruiting"
mb upload csv --file bamboohr-stage-history.csv --collection "HR & Recruiting"
# Refresh the same table later from a new export
mb upload replace <table-id> --file bamboohr-applications.csvPrompt: build a BambooHR recruiting dashboard with AI
Create a polished Metabase dashboard for BambooHR HR and recruiting analytics.
Work end to end: get the data into Metabase if it is not there yet, then build.
Goal: Help recruiting and people leaders understand hiring funnel health, time to hire,
time to fill, source quality, interview throughput, offer acceptance, and hiring plan risk.
Step 1 - Find or load the data:
- First, search Metabase for existing BambooHR or HR models. If modeled data already
exists from a warehouse sync, use it and skip to Step 2.
- If nothing exists and an approved MCP or export route is available, pull a minimal
read-only snapshot: jobs/requisitions, candidates, applications, stage history,
interviews, offers, and sources. Load CSVs with "mb upload csv --file <file>.csv".
Step 2 - Inspect before querying:
Inspect the actual columns and PII fields first. Do not assume exact names or that
stage history exists. Only build duration and conversion cards when the timestamps
and denominators are present.
Important:
- Do not claim Metabase connects natively to BambooHR; it reads synced or uploaded tables.
- Use a least-privilege data model and exclude sensitive candidate and employee fields from broad dashboards.
- Define application status, stage order, offer extended, and offer accepted once.
- Report time to hire and time to fill as medians and p90, not plain averages.
- Keep time to hire (candidate/application lifecycle) separate from time to fill
(requisition lifecycle).
- For funnel conversion, use stage-change history. A current-stage snapshot is not enough.
- Segment by department, location, role family, source, recruiter, and hiring manager only when safe.
- Caveat any chart that is based on snapshots rather than full history.
Dashboard title: BambooHR Recruiting Overview
Sections:
1. Executive summary: open roles, applications last 30 days, median time to hire,
median time to fill, offer acceptance rate, roles over SLA.
2. Hiring funnel: applicants by stage, stage conversion, drop-off, aging by stage.
3. Time and velocity: time to hire, time to fill, time in stage, interview scheduling lag.
4. Sources: qualified applicants by source, source-to-offer conversion, accepted hires by source.
5. Operations: recruiter workload, interview volume, stale applications, upcoming starts.
Filters: Department, location, role, recruiter, hiring manager, source, date range.
Suggested models: modeled_bamboohr_jobs, modeled_bamboohr_applications,
modeled_bamboohr_application_stage_history, modeled_bamboohr_interviews,
modeled_bamboohr_offers, modeled_bamboohr_sources.
Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Keep it practical, dense, and
leadership-readable. Avoid candidate-level tables unless a permissioned ops user
explicitly needs them.How should you sync BambooHR to a warehouse?
Use the BambooHR API, a managed connector where approved, or scheduled exports to land employee, job opening, application, time off, department, and location data in a Metabase-connected database. Keep sensitive HR fields out of broad models unless a dashboard truly needs them. Then create clean Metabase models with safe names, consistent stage order, and the minimum sensitive fields each audience needs.
- Use full refresh for small reference tables like stages, jobs, users, and sources.
- Use incremental syncs for applications, interviews, offers, and stage events.
- Persist stage/status changes; without history, duration and conversion metrics become guesswork.
- Separate candidate-level operations tables from leadership dashboards.
What is the BambooHR data model?
Most ATS and HRIS sources map onto the same recruiting analytics model:
| Concept | BambooHR term | Used for |
|---|---|---|
| Employee | Employee | Employment status, department, location, manager, hire date |
| Job | Job opening | Open role, department, location, hiring team, status |
| Application | Application | Candidate-role relationship, current status, source |
| Stage event | Application status history | Recruiting funnel, conversion, time in status |
| Time off | Time off request | Balances, requests, approvals, absence trends |
| Org attribute | Department / location | Headcount segmentation and workforce planning |
Which BambooHR metrics matter most?
- Time to hire — application or candidate start to accepted offer. Report p50 and p90.
- Time to fill — requisition opened to accepted offer or start date. Keep it role-based.
- Candidate conversion rate— applicants reaching the next stage divided by applicants who reached the prior stage.
- Offer acceptance rate— accepted offers divided by extended offers.
- Source quality — late-stage, offer, and accepted-hire outcomes by source, not just applicant volume.
Example SQL
-- Stage-to-stage recruiting funnel from stage history
WITH reached AS (
SELECT DISTINCT
application_id,
stage_id
FROM modeled_bamboohr_application_stage_history
), stage_counts AS (
SELECT
s.stage_name,
s.stage_order,
COUNT(DISTINCT r.application_id) AS reached_applications
FROM modeled_bamboohr_stages s
LEFT JOIN reached r ON r.stage_id = s.stage_id
GROUP BY s.stage_name, s.stage_order
)
SELECT
stage_name,
reached_applications,
ROUND(
100.0 * reached_applications
/ NULLIF(LAG(reached_applications) OVER (ORDER BY stage_order), 0),
1
) AS step_conversion_pct
FROM stage_counts
ORDER BY stage_order;-- Median and p90 time to hire by accepted-offer month
SELECT
date_trunc('month', offer_accepted_at) AS month,
COUNT(*) AS accepted_offers,
percentile_cont(0.5) WITHIN GROUP (
ORDER BY EXTRACT(EPOCH FROM (offer_accepted_at - application_created_at)) / 86400.0
) AS median_time_to_hire_days,
percentile_cont(0.9) WITHIN GROUP (
ORDER BY EXTRACT(EPOCH FROM (offer_accepted_at - application_created_at)) / 86400.0
) AS p90_time_to_hire_days
FROM modeled_bamboohr_applications
WHERE offer_accepted_at IS NOT NULL
GROUP BY 1
ORDER BY 1;