13 HR Information Systems and Data Sources

13.1 Why HRIS Matters to the Metrics Programme

Every HR chart on the dashboard rests on a data layer most of its audience never sees.

An HR-metrics programme is only as credible as the systems behind it. Every chart on the dashboard, every model in the analytics layer, every disclosure to a regulator or investor traces back to an underlying data source — usually the HR Information System, often supplemented by adjacent business systems. When the data layer is reliable, the dashboard becomes a daily conversation. When it is not, the dashboard becomes a quarterly argument about whose number is right.

The HR Information System is the centre of gravity. As Michael J. Kavanagh et al. (2017) explain in their standard work on HRIS, the modern system is no longer a payroll-and-leave engine. It is a workforce platform that integrates recruitment, learning, performance, compensation, and analytics, and that exposes data through APIs to the rest of the firm. The metrics analyst depends on this platform in two ways. First, as the source of truth for most workforce numbers. Second, as the system whose definitions, refresh schedules, and access controls quietly shape what can and cannot appear on the dashboard.

The HRIS does not stand alone. As Dianna L. Stone et al. (2015) documented in their study of the influence of technology on the future of HR, the data the analyst needs to answer business questions increasingly sits outside the HRIS — in finance systems, customer-experience platforms, communication tools, sensors, and external benchmarks. The analyst’s task is no longer to extract from one system but to integrate across many, and to do so in a way that respects the boundaries of privacy, security, and statutory disclosure.

The visualisation lens runs through the data layer in a particular way. Every chart on the dashboard advertises, implicitly, the systems that produced it. A dashboard that pulls only from the HRIS is signalling one scope; a dashboard that pulls from the HRIS, the LMS, the engagement platform, and the customer-experience tool is signalling a much broader one. The audience reads the function’s data ambition through what shows up on the page, and the analyst should design that signal deliberately.

The HRIS-and-data-sources contract

Every metric on the dashboard names its source system, either as a tooltip or as part of the chart-level documentation, so that disputes can be resolved without exporting the data.
The HRIS is the system of record for workforce-state metrics; adjacent systems are the systems of record for the topics they own, and the boundary is not negotiated chart by chart.
Cross-system metrics — those that combine HRIS data with finance, customer, or operations data — are governed by a written integration agreement before they appear on the dashboard.

13.2 The Anatomy of an HRIS

A modern HRIS is a layered platform rather than a single application. Knowing the layers helps the metrics analyst find the right data quickly, anticipate the integration constraints, and design dashboards that match the system’s natural rhythm rather than fight it.

The Five Layers of a Modern HRIS

Layer	What it stores or produces	Why the analyst cares
Core records	Employee, position, organisation, contract data	Foundation for headcount, structure, and tenure metrics
Transactional modules	Recruitment, learning, performance, compensation flows	Source of activity-level metrics and funnels
Workflow and approvals	Routing, sign-off, audit trail of every change	Source of cycle-time and bottleneck metrics
Analytics and reporting	Built-in dashboards and metric definitions	Defines what counts as a metric inside the platform
Integration and APIs	Connectors to finance, learning, surveys, identity	Where cross-system metrics are made possible

The platform versus the analyst’s pages

Every modern HRIS now ships with built-in dashboards. The temptation is to treat those dashboards as the metrics programme. The discipline is to use the platform’s reports for operational visibility while building the strategic, cross-system pages outside the platform — in Power BI, Tableau, or an analytics warehouse. The platform’s dashboards are good at the first three layers. The strategic pages need access to the integration layer and to data the platform does not own.

13.3 Data Sources Beyond the HRIS

The questions a modern HR-analytics function is asked to answer rarely fit inside the HRIS alone. Productivity sits in operational systems. Customer experience sits in customer platforms. Financial outcomes sit in the ERP. Engagement sits in survey tools. The analyst’s job is to know which question lives in which system, and to assemble the right join when the question crosses the boundary.

HR Data Sources Beyond the HRIS

Source	What it adds	Common HR question it supports
Learning platform	Course completion, mastery, time spent	Capability uplift, training effectiveness
Survey and engagement platform	Engagement, eNPS, manager-rated experience	Climate, voice, response to interventions
Recruitment and ATS	Funnel stages, candidate sources, offer history	Source quality, time to fill, conversion
Performance system	Goals, ratings, calibration	Quality of hire, performance distribution
Finance and ERP	Compensation cost, programme spend, business KPIs	Cost per hire, ROI of HR programmes
Customer-experience system	Customer-rated quality, NPS, complaints	Frontline-tenure-to-quality link
Operational systems	Output, productivity, schedule adherence	Productivity per FTE, attrition impact
Identity and access	Logins, applications used, devices	Adoption of HR tools, digital experience
External benchmarks	Market-pay, industry attrition, ESG ratings	External competitiveness, peer comparison

Choosing the source for the question

The right source for an HR question is rarely the most convenient one. Operational productivity is most credibly measured in the operational system, not in a self-report survey. Pay competitiveness is most credibly measured against an external benchmark, not against an internal trend. The discipline is to follow the question to the system that owns the answer, and to negotiate access deliberately rather than to substitute a proxy because the better source is harder to reach.

13.4 Data Quality and Governance

Data quality and governance determine whether the data layer can be trusted. The metrics programme inherits whatever discipline the source systems impose, and the analyst’s role is to know where the discipline is strong, where it is weak, and how to render the difference visible to the audience that depends on the dashboard.

Six Dimensions of HR Data Quality

Dimension	What it asks	How it shows up on the dashboard
Accuracy	Is the recorded value correct	Validation rules and exception lists
Completeness	Are all required fields populated	Coverage indicators on the page
Consistency	Is the same fact recorded the same way across systems	Cross-system reconciliation reports
Timeliness	Is the data fresh enough for the decision it informs	Refresh timestamp on every page
Lineage	Where did this number come from	Source path documented in tooltips
Access control	Who can see this data and at what level	Role-based filters built into the page

Governance as a working partnership

HR data governance is rarely owned by HR alone. It runs as a partnership between HR, IT, the privacy office, the legal team, and the data-platform owners. The metrics analyst sits at the centre of that partnership and is expected to translate between technical, legal, and business languages. A dashboard that does not surface its governance — definitions, lineage, refresh, access — is a dashboard that will eventually fail an audit, even if every chart is correct.

13.5 Visualising the Data Landscape

The data layer is invisible to most of the dashboard’s audience, but it does not have to be. A small set of visualisation choices makes the data landscape legible to a curious audience without overwhelming a casual one, and signals the discipline of the function more credibly than any written charter.

Five Choices That Make the Data Layer Visible

Choice	What it shows
Source labels on charts	Each chart names its source system in a corner or tooltip
Refresh timestamp in the header	The audience knows when the page was last updated
Cross-system join indicator	Charts that join two systems carry a visible marker
Coverage badge	The page declares how complete the underlying population is
Governance tooltip	A click reveals owner, refresh cadence, and access policy

The data-landscape sketch

flowchart LR
  A[HRIS] --> Z[Analytics Warehouse]
  B[Learning Platform] --> Z
  C[Survey Platform] --> Z
  D[ATS] --> Z
  E[Performance System] --> Z
  F[Finance and ERP] --> Z
  G[Customer System] --> Z
  H[Operational Systems] --> Z
  Z --> Y[Dashboard]
  style A fill:#E8F0FE,stroke:#1A73E8
  style Z fill:#E6F4EA,stroke:#137333
  style Y fill:#F3E8FD,stroke:#8430CE

A simple data-landscape sketch like this one belongs on the dashboard’s about page, not in an internal architecture document. The audience that opens the dashboard is more likely to trust it when they can see the systems behind it laid out as a single picture, and the picture earns its place even when it is the most boring chart on the dashboard.

13.6 Hands-On Exercise: Multi-Source HR Data Integration

Aim, Scenario, Dataset, Deliverable

Aim. Combine three HR data sources into a single integrated model in Power Query, build a star schema, and surface a data-landscape page in Power BI that names each source, its refresh, and its coverage.

Scenario. You are integrating three HR systems for the first time: the HRIS, the recruitment system, and the learning platform. The audience for the resulting dashboard wants to read consolidated metrics by department and role family, with the source of every number visible.

Dataset. Three files from the HRMD dataset library, treated as if they were three separate source systems:

HRIS extract — Random HR Data (Excel).
Recruitment system extract — Recruitment Data (Excel).
Learning platform extract — Learning and Development Metrics (Excel).

Deliverable. An Integration-Model.pbix file with three connected tables, a date dimension, a star-schema model view, and a data-landscape page with source labels, refresh timestamps, cross-system join indicators, and coverage badges.

13.6.1 Step 1 — Connect to all three sources

Open Power BI Desktop. Use Home > Get Data > Excel once per file to load all three tables into Power Query. Rename the queries HRIS, Recruitment, and Learning so the model view reads cleanly.

13.6.2 Step 2 — Profile and clean each source in Power Query

Turn on View > Column quality, Column distribution, and Column profile for each table. Note empty cells, unique-value counts, and inconsistent casing. Apply minimal cleaning: trim whitespace on join keys, type dates, standardise category casing. Keep the cleaning steps visible in the Applied Steps panel as documentation.

13.6.3 Step 3 — Build the date dimension

Create a date table with New Source > Blank Query and the M expression below.

Code

Power Query M

let
    StartDate = #date(2020, 1, 1),
    EndDate = #date(2026, 12, 31),
    Days = Duration.Days(EndDate - StartDate) + 1,
    DateList = List.Dates(StartDate, Days, #duration(1,0,0,0)),
    AsTable = Table.FromList(DateList, Splitter.SplitByNothing(), {"Date"}),
    Typed = Table.TransformColumnTypes(AsTable, {{"Date", type date}})
in
    Typed

Mark the table as the date table in the model view.

13.6.4 Step 4 — Define the star-schema relationships

In the model view, connect each fact table to the date table through its primary date column. Connect HRIS to Recruitment through EmployeeID. Connect HRIS to Learning through EmployeeID. Confirm each relationship is one-to-many and that cross-filter direction is single.

13.6.5 Step 5 — Add cross-system measures

Build measures that draw on more than one source so the integration earns its place. Examples below.

Hires Trained in Ninety Days =
CALCULATE(
    DISTINCTCOUNT(Recruitment[EmployeeID]),
    FILTER(
        Learning,
        Learning[CompletionDate] <= Recruitment[Hire Date] + 90
            && Learning[Status] = "Completed"
    )
)

Cost per Productive Hire =
DIVIDE(
    SUM(Recruitment[Recruitment Cost]),
    [Hires Trained in Ninety Days]
)

Both measures rely on data from two systems and would not exist on the inside-out scorecard of either system alone.

13.6.6 Step 6 — Build the data-landscape page

Lay out a one-page about-the-dashboard view modelled on the Mermaid sketch at the end of this chapter. Place a tile for each source system showing its name, last refresh time, row count, and coverage percentage. Add a connector visual that shows which measures depend on which sources. The page sits as the second page of the dashboard, below the headline KPIs.

13.6.7 Step 7 — Set source labels and refresh timestamps

For every measure on the dashboard, set the Description to include the source-system name. Add a small text box on every page showing the last refresh time of the slowest source. The audience will read the label as proof that the integration is honest about where the data came from and when.

13.6.8 Step 8 — Publish, set refresh, and instrument

Publish the report and configure scheduled refresh for each source at the cadence agreed with the data owners. Turn on usage metrics so the team can see whether the data-landscape page is opened when audiences want to verify a number.

Connect to the Visualisation Layer

This integration model is the working data layer that later chapters will reuse. The recruitment funnel of Chapter 22, the training-effectiveness page of Chapter 27, and the responsible-investment page of Chapter 33 all depend on a multi-source model of the kind built here. Locking the model once and reusing it is what keeps definitions consistent across pages.

Files and Screen Recordings

Integration-Model.pbix and ch13-integration-walkthrough.mp4 will be attached at this point in the published edition. The screen recording walks through Steps 1 to 8 in Power Query and the Power BI model view, including the star-schema construction and the data-landscape page.

Summary

Concept	Description
Why HRIS Matters
Data layer credibility	Every chart and disclosure traces back to an underlying data source
HRIS as centre of gravity	The HRIS is the source of truth for most workforce-state metrics
Beyond-HRIS integration	Productivity, customer, finance, and engagement data sit outside the HRIS
Visualisation signals scope	The dashboard advertises which systems the function actually integrates
Source labelling discipline	Source system named on every chart prevents disputes about whose number is right
Anatomy of an HRIS
Core records	Employee, position, organisation, contract data inside the HRIS
Transactional modules	Recruitment, learning, performance, compensation flows inside the HRIS
Workflow and approvals	Routing, sign-off, audit trail layer of the HRIS
Analytics and reporting	Built-in dashboards and metric definitions in the platform
Integration and APIs	Connectors that make cross-system metrics possible
Platform versus analyst pages	Use platform reports operationally, build strategic pages outside the platform
Data Sources Beyond HRIS
Learning platform	Course completion, mastery, time spent
Survey and engagement platform	Engagement, eNPS, manager-rated experience
Recruitment and ATS	Funnel stages, candidate sources, offer history
Performance system	Goals, ratings, calibration outcomes
Finance and ERP	Compensation cost, programme spend, business KPIs
Customer-experience system	Customer-rated quality, NPS, complaints
Operational systems	Output, productivity, schedule adherence
Identity and access	Logins, applications used, devices
External benchmarks	Market-pay, industry attrition, ESG ratings
Source-for-question discipline	Follow the question to the system that owns the answer
Data Quality and Governance
Accuracy	Is the recorded value correct
Completeness	Are all required fields populated
Consistency	Is the same fact recorded the same way across systems
Timeliness	Is the data fresh enough for the decision it informs
Lineage	Where did this number come from
Access control	Who can see this data and at what level
Governance partnership	HR, IT, privacy, legal, and platform teams share governance
Visualising the Landscape
Source labels on charts	Each chart names its source system in a corner or tooltip
Refresh timestamp	The audience knows when the page was last updated
Cross-system join indicator	Charts that join two systems carry a visible marker
Coverage badge	The page declares how complete the underlying population is
Governance tooltip	A click reveals owner, refresh cadence, and access policy
Data-landscape sketch	A simple picture of all source systems feeding the warehouse