How do you analyze 100Hires recruiting data in Metabase?

Adapt this to the specific 100Hires MCP server and scopes your team approves.

{
  "mcpServers": {
    "100hires": {
      "url": "https://mcp.100hires.com/mcp"
    }
  }
}

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 100Hires exports - each upload creates a table and a model
mb upload csv --file 100hires-applications.csv --collection "HR & Recruiting"
mb upload csv --file 100hires-jobs.csv --collection "HR & Recruiting"
mb upload csv --file 100hires-stage-history.csv --collection "HR & Recruiting"

# Refresh the same table later from a new export
mb upload replace <table-id> --file 100hires-applications.csv

Create a polished Metabase dashboard for 100Hires 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 100Hires 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 100Hires; 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: 100Hires 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_100hires_jobs, modeled_100hires_applications,
modeled_100hires_application_stage_history, modeled_100hires_interviews,
modeled_100hires_offers, modeled_100hires_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.

-- Stage-to-stage recruiting funnel from stage history
WITH reached AS (
  SELECT DISTINCT
    application_id,
    stage_id
  FROM modeled_100hires_application_stage_history
), stage_counts AS (
  SELECT
    s.stage_name,
    s.stage_order,
    COUNT(DISTINCT r.application_id) AS reached_applications
  FROM modeled_100hires_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_100hires_applications
WHERE offer_accepted_at IS NOT NULL
GROUP BY 1
ORDER BY 1;