How do you analyze Workday HR and recruiting data in Metabase?
Workday analytics turns recruiting activity into a shared view of hiring funnel health, speed, quality, and capacity. Workday is often the system of record for workers, supervisory organizations, positions, requisitions, and HR processes. To analyze Workday in Metabase, sync the right reports or APIs into a database, separate worker data from recruiting data, and build governed dashboards for headcount, hiring plan progress, requisition aging, and people operations. Metabase has no native Workday connector, so the data must land in a database or be uploaded first.
How do you connect Workday to Metabase?
Explore live HR data, then upload a snapshot
Workday MCP servers in catalogs are community or vendor-adjacent implementations. Workday access is tenant, report, and security-policy dependent, so treat MCP as a controlled exploration layer. Pair it with the Metabase CLI when you want an AI assistant to inspect Workday 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 approved Workday reports, RaaS, APIs, or a managed connector to land worker, organization, position, requisition, candidate, and application data in a database. Start with read-only, least-privilege reports and document every field that carries sensitive employee data. 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 Workday?
- 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 MCP server: Workday MCP servers in catalogs are community or vendor-adjacent implementations. Workday access is tenant, report, and security-policy dependent, so treat MCP as a controlled exploration layer. 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 Workday MCP server and scopes your team approves.
{
"mcpServers": {
"workday": {
"command": "npx",
"args": ["-y", "@mindstone/mcp-server-workday"],
"env": {
"WORKDAY_TENANT_URL": "https://your-tenant.workday.com",
"WORKDAY_CLIENT_ID": "your-client-id",
"WORKDAY_CLIENT_SECRET": "your-client-secret"
}
}
}
}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 Workday exports - each upload creates a table and a model
mb upload csv --file workday-applications.csv --collection "HR & Recruiting"
mb upload csv --file workday-jobs.csv --collection "HR & Recruiting"
mb upload csv --file workday-stage-history.csv --collection "HR & Recruiting"
# Refresh the same table later from a new export
mb upload replace <table-id> --file workday-applications.csvPrompt: build a Workday recruiting dashboard with AI
Create a polished Metabase dashboard for Workday 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 Workday 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 Workday; 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: Workday 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_workday_jobs, modeled_workday_applications,
modeled_workday_application_stage_history, modeled_workday_interviews,
modeled_workday_offers, modeled_workday_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 Workday to a warehouse?
Use approved Workday reports, RaaS, APIs, or a managed connector to land worker, organization, position, requisition, candidate, and application data in a database. Start with read-only, least-privilege reports and document every field that carries sensitive employee data. 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 Workday data model?
Most ATS and HRIS sources map onto the same recruiting analytics model:
| Concept | Workday term | Used for |
|---|---|---|
| Worker | Worker | Employee or contingent worker profile and employment status |
| Organization | Supervisory organization | Department, manager tree, location, cost center |
| Position | Position | Authorized role, FTE, job profile, open/filled status |
| Requisition | Job requisition | Hiring demand, approvals, openings, age, target start |
| Candidate | Candidate / applicant | Recruiting profile when Workday Recruiting is enabled |
| Application | Candidate application | Application status, stage, source, disposition, offer |
Which Workday 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_workday_application_stage_history
), stage_counts AS (
SELECT
s.stage_name,
s.stage_order,
COUNT(DISTINCT r.application_id) AS reached_applications
FROM modeled_workday_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_workday_applications
WHERE offer_accepted_at IS NOT NULL
GROUP BY 1
ORDER BY 1;