Search for training dashboards and you'll find lists: 8 KPIs, 13 KPIs, 17 KPIs, all in one flat pile. What none of those lists tells you is that the pile mixes two different questions. "Are my people ready?" is a question about learners. "Is my program working?" is a question about the training itself. They need different metrics, different readers, and different dashboards, and almost nobody separates them.
This article does, and it builds both where they belong: in Salesforce, next to the pipeline and the cases the training exists to improve. That location is the whole point. A dashboard that shows completion rates in a standalone LMS can't show you which reps are cleared to sell the release shipping next month. A dashboard in your CRM can, because the learning records and the revenue records share a database. The method behind the readiness score lives in the readiness hub of this series; this article owns the build.
Why flat KPI lists fail
Flat KPI lists fail because they answer two different questions with one undifferentiated pile of metrics. Completion rate, pass rate, time to complete, engagement, satisfaction: every ranked article presents them as one shopping list. But "which reps are ready for the Q4 release" and "why does the compliance course keep missing its due dates" are not the same question. The first is about people and gets read by managers weekly. The second is about the program and gets read by its owner monthly. Pour both into one dashboard and each reader scans past the half that isn't theirs.
The deeper issue is that most L&D measurement is broken before the dashboard stage. Per Brandon Hall Group's Learning Strategy Study (2021), only one-quarter of companies have a strong framework to measure success included in their learning strategy. The same 2021 study found 59% citing the inability to measure learning's impact as an obstacle to executing their strategy. Four years later the pattern holds directionally: the LinkedIn Workplace Learning Report 2025 notes that learner engagement and employee retention remain the most common ways teams measure business impact. LinkedIn urges a shift toward productivity and profit measures instead. Engagement is an input. The business pays for outputs.
The 2025 report also finds that only 36% of organizations qualify as career development champions, the segment that actually operationalizes learning. The three figures tell one story: most programs measure activity because activity is what their tools surface.
The two-lens split is the practical fix, because it forces every metric to declare its question before it earns a tile. People health carries the metrics that describe learners. Program health carries the metrics that describe the training. The rest of this article builds one dashboard per lens.
Lens 1, people health: the readiness dashboard
People health answers one question: who is ready, right now, and what exactly is blocking the ones who aren't. The unit of analysis is the person. The columns are the rep's readiness band, their team, their lifecycle context, and the specific trainings still due. The reader is a manager, and the useful dashboard names names.
In deployments I run, the version of this dashboard that changes behavior is the one crossed with the sales lifecycle and the release calendar. A product release ships, and the dashboard answers the question the launch meeting actually asks: which reps still have trainings due before they're ready, or authorized, to sell it. Readiness per rep sits in the same view as pipeline stages, filtered by the release's curriculum. Training stops being a parallel activity that HR reports on later. It becomes a visible gate in the same dashboard sales leadership reads, and a rep with two overdue modules on the new pricing is flagged before the deal, not after it.
People health in production: sales performance and learning data in one dashboard, with win rate and deal size read by readiness tier. Click the image to enlarge.
What feeds the readiness band is a method, and this article deliberately doesn't own it. The readiness hub defines the score: which signal families feed it, how they're weighted, and how the score is validated against pipeline. Here, treat the score as an input column. Whether you compute the full composite or start with something cruder, like percentage of assigned curriculum complete, the dashboard's job is the same. Put the number next to the person's revenue context and make the gap actionable.
Three components cover most teams. A table of reps grouped by readiness band, with trainings-due as a drill-down. A stacked bar of bands per team, for the manager-of-managers view. And the release view: reps carrying the affected product line, filtered to those with curriculum still open. If the last one is empty the week before launch, the launch is trained. If it isn't, you have names, not a percentage.
Lens 2, program health: the course health dashboard
Program health answers a different question: is the training itself doing its job, course by course. The unit of analysis is the course, not the learner. I call this view course health. Its vital signs: registrations, completions against due dates, average completion, average completion rate, and overdue counts by course and cohort.
In deployments I run, this is the dashboard that protects the program owner from flying blind. Each course is a row: how many learners are registered, how many completed before their due date, what the average completion looks like, and where the overdue records pile up. Read across cohorts and the diagnosis sharpens. If one team is overdue everywhere, that's a management or workload problem. If every team is overdue on one course, that course is the problem.
Which is the signature point of this lens: bad course health is a content or assignment problem, not a learner problem. A course with 200 registrations and 30% on-time completion is not evidence of 140 lazy learners. It's evidence that the course is too long, badly timed, assigned to the wrong audience, or given due dates nobody sanity-checked. The dashboard says so months before the annual content renewal, which is exactly when you want to know which courses to rebuild, retire, or reassign.
Report
One warning about the metric everyone anchors on. Completion-rate benchmarks are noisy: figures from 12% to 95% circulate depending on modality, industry, and who's selling what, and none of them describes your program. The famous 3-6% completion figure comes from open online courses, where anonymous enrollees browse for free with no deadline and no manager, as documented in Reich and Ruipérez-Valiente's "The MOOC Pivot" (Science, 2019). Citing it in a corporate context, where training is assigned, dated, and tied to a role, is a category error. So don't benchmark against the internet. Measure your own on-time completion rate against your own due dates, and manage the trend. A course moving from 55% to 70% on-time is a program improving; whether some vendor's ebook calls 70% good is irrelevant.
Building both in the native report builder
Both dashboards come out of the standard Salesforce report builder, because everything they need is a record. If your LMS is native, its enrolment and completion objects are ordinary custom objects. An enrolment carries the learner, the course, an assigned date and a due date; a completion carries a status, a score, and a completion date. Reporting on them is no different from reporting on Opportunities. Here is the build, in generic object language, so it transfers to any learning data that lives in your org as records.
Report types. You need two: enrolments with their related completion records, and enrolments with or without completions. The "with or without" variant is the workhorse, because absence is the interesting signal.
Cross filters. This is where the two lenses get their teeth. "Enrolments WITHOUT a completion" finds everyone still open. Add a field filter, "due date before TODAY", and you have the overdue report: every learner past deadline, groupable by course for program health or by rep and team for people health. You don't need predictive AI to answer who's overdue before the release ships; you need a cross filter.
Bucket fields. Buckets turn raw numbers into readable bands without touching the schema. Bucket assessment scores or a readiness percentage into ready, ramping, and at risk for the people lens. Bucket days-overdue into aging bands for the program lens.
Formula columns. The on-time completion rate is a summary formula: completions on or before the due date, divided by total enrolments, as a percentage per course row. The plain completion rate drops the date condition. Average completion and average score are standard summaries.
Dashboard components and filters. People health: the rep table by band, the stacked bands per team, the release view. Course health: the per-course table with the on-time formula, an overdue-by-cohort matrix, and a trend of on-time rate by month. Add dashboard filters on team and on release or curriculum, so one dashboard serves every manager and every launch.
Two dependencies decide whether any of this works, and both are architectural. First, the data has to exist as records in your org. If learning lives in an external platform, the dashboard is a sync project before it's a report, a trade the native versus integrated comparison walks through. Full disclosure: I build Daniwoo, a native LMS, so I hold a position here, but every step above is standard report-builder mechanics on any learning records. Second, the dashboard inherits the reliability of the writes underneath it; the tracking at scale guide covers why completions that get lost under load turn dashboards into fiction. The native reporting overview shows the finished form of both views. As standards like xAPI and cmi5 mature, richer experience data will eventually feed these same reports, but nothing in this build waits for that.
The cadence: who reads what, when
Manager weekly, program owner monthly, executive quarterly: give each lens a reader and a rhythm, because a dashboard nobody is scheduled to read is decoration. The manager reads people health weekly: who moved bands, who has trainings due before the next release, which gate is about to block which deal. The program owner reads course health monthly: which courses are trending down on on-time completion, where overdue is pooling by cohort, what to fix before renewal season. The executive reads both quarterly, joined to revenue: readiness bands against win rates, course health against the launches the quarter depended on.
Two neighbors in this series feed the cadence. Ramp time belongs on the people-health dashboard as a first-class readiness metric, and the onboarding guide covers how a finish line turns "ramped" into a reportable date. And the due dates that power every overdue cross filter have to come from somewhere. The training automation guide shows how assignment Flows stamp them from CRM events, so deadlines come from the business change that created the need, not from a spreadsheet.
FAQ
What is a training dashboard?
A training dashboard is a live, visual report of training data: who is assigned what, who completed it, when, and with what result. The useful version answers a specific reader's question rather than displaying every metric. In practice that means two dashboards: a people-health view showing readiness per learner, and a program-health view showing whether each course is working, both built from enrolment and completion records.
What KPIs measure training effectiveness?
Split them by lens. For people: readiness band per rep, curriculum coverage, assessment scores, trainings due before the next release, and ramp time for new hires. For the program: registrations per course, on-time completion rate against due dates, average completion, average score, and overdue counts by course and cohort. Effectiveness ultimately means joining either lens to business outcomes, like win rates or case resolution, in the same report.
How do you measure training completion rate?
Divide completions by assignments: learners who completed the course over learners who were assigned it, times 100. The more useful variant is the on-time completion rate, which only counts completions that landed on or before the due date. In Salesforce-style reporting, that's a summary formula on an enrolments-with-completions report, computed per course row, so every course carries its own rate.
What is a good training completion rate?
There's no honest universal number. Published benchmarks range from 12% to 95% depending on modality, industry, and the vendor doing the publishing, which makes them noise. The often-quoted 3-6% figure describes open online courses with anonymous, unassigned learners, per "The MOOC Pivot" (Science, 2019), and doesn't apply to corporate training with due dates and managers. Measure your own on-time completion rate against your own due dates, and judge the trend, not a borrowed benchmark.
How do you report on training in Salesforce?
If your learning data exists as Salesforce records, you use the standard report builder. Create report types over your LMS's enrolment and completion objects, add cross filters for open and overdue training, bucket scores into bands, and compute on-time completion rate as a summary formula. Then assemble dashboard components with filters by team and course. No export, no BI tool: the same builder your admins already use for pipeline.
What is course health?
Course health is the per-course view of program effectiveness: registrations, completions against due dates, average completion, average completion rate, and overdue counts by cohort, read as the vital signs of each course. Its core principle: a course with high enrolment and low on-time completion signals a content or assignment problem, not a learner problem. Course health tells you which courses to rebuild, retime, or retire before the annual renewal.
How do you track overdue training?
With one report: a cross filter for enrolments without a completion record, plus a field filter for due date before TODAY. Group the result by course and cohort to diagnose the program, or by learner and team to drive follow-up. Schedule or subscribe the report so owners receive it automatically, and trend the overdue count over time; a shrinking number is the health signal.
How do you know which reps are ready for a new product release?
Filter the people-health dashboard to the release's curriculum: reps carrying the affected product line, with their readiness band and any trainings still due. An empty "still due" list the week before launch means the release is trained; anything else is a named to-do list. The method behind the readiness band itself is defined in the readiness hub; the release view is that score put on a deadline.
Conclusion
One KPI pile can't answer two questions, so stop asking it to. Give the people a dashboard: readiness per rep, crossed with the sales cycle and the release calendar, so training due is a gate everyone can see. Give the program a dashboard: course health, per course and per cohort, so a failing course gets diagnosed as content or assignment, not blamed on learners. Both are ordinary reports the moment your learning data lives in your org as records, and the readiness method they share is waiting in the hub that anchors this series.
If you'd rather see both dashboards running on real data than build the first draft alone: book a demo and bring your reporting questions.
See both lenses on a live org
The dashboards in this article run on real learning records. Bring your KPIs; we'll show you which lens each one belongs to.
Book a demoAbout the author. Brice Mbouani is the founder of Daniwoo and a Salesforce engineer. He designed and built the Salesforce-native learning platform this series is drawn from, which runs in production Salesforce orgs at organizations including Remmert. The dashboards in this article are drawn from those deployments.
