This document reviews how to maintain a high level of data quality in your ATS by utilizing Ashby reports, dashboards and alerts. The options for long term data quality are presented, along with a summary of the most common challenges and a data quality checklist.

Historically, maintaining data quality within your ATS has been a major challenge due to the lack of visibility into the underlying data. Ashby’s native reporting capabilities make insight into the quality of your ATS data readily available. The goal of this article is to first review some of the most common challenges in ATS data and present the recommended reporting solutions.

Long term health and data quality is fundamentally about data visibility. Easy review of your data allows you to know when and what data issues are at hand. This, in turn, permits designing easy resolution steps and alerts.

In the absence of data visibility, quality issues are subject to one-off discoveries at the time of trying to run a report, with the outcome being a slow accumulation of ever more issues that are hard to identify and resolve, followed by a decrease in trust in the data overall. This eventually results in a data-less culture, subject to a “garbage in, garbage out” sentiment.

With Ashby you have the following tools to maintain data quality:

The above options can be used individually or in combination, depending on the scope of your needs and size of your team.

Below is a summary review of the most common data quality challenges we’ve seen.

You can define stale candidates according to your team’s process, but a general example would be categorizing any candidate that has been in process but has not had an activity for 30+ days as stale. The easiest way to select for this is by using NOT logic applied to any activity-related field, like so:

Your particular selection may vary, or use other fields of interest or even filter down to specific stages or jobs. The key breakthrough is beginning to get an easy selection non-compliant records, after which you can begin grouping or refining the results to be more actionable or reveal insights about your process.

Below are some examples of how to further refine your stale candidates to gain insight into what may be happening.

Stale candidates by stage group

Here you can see stale candidates by their application’s current stage group. This reveals that the application review process is a significant contributor, but that there are candidates that have been inactive 30+ days all the way down to the final rounds!

Stale candidates on open jobs

When grouping by open jobs you may find that there are a small subset of jobs that have a disproportionate number of stale candidates. One response here would be to review the hiring team or review capacity and load balancing.

Stale candidates by source type

You can easily review the stale candidate selection by source type too. The plan of action may vary here, but seeing that many candidates are stale from direct inbound application may suggest review process adjustments, while noting that 50+ referrals are stale may inform a higher urgency SLA process for referrals.

Stale candidates by recruiter

For load balancing and team management, you can review stale candidates by their assigned recruiter. This could be filtered down by stage group, to identify in-process candidates, or used to identify that most stale candidates have no recruiter assigned at all. More on this latter point below.

More advanced reporting on stale candidates

The above examples are single slices of data, but Ashby does permit multiple groupings to give more insight. In this example you can see stale candidates by their department and stage group, revealing which departments have the greatest volume but also how far in process the stale candidates are.

Another common data quality challenge is finding active candidates on jobs that have been closed. These candidates should be dispositioned, but the real goal is to understand why and when this happens. This basic filter selection will identify all active applications on closed jobs:

With this selection in place, similar to the many variations on stale candidate review you can create reports that identify sources, owners or patterns in this case. This example report identifies which closed jobs have the most active applications:

Some teams opt to schedule candidate interviews outside of their ATS. This is most common at the top of funnel (initial calls, initial screens), but can be a critical set of data to track to see if upstream activity is feeding into downstream results.

How to assess this will depend on your teams expectations, but the simplest way to get a top-level summary is to create a count over time by week of scheduled interviews per stage group. This way if you see numbers that are definitively too low you can investigate further.

Additionally, you could use the Interview Load template report, or segmentation reports to look at interview records in more detail. See these examples in our report catalogues: Report Catalog: Templates, Report Catalog - Essentials and Report Catalog - Advanced.

Across candidate, jobs, applications and all the other ATS-based records, there is a ton of information to manage. It’s not uncommon to see candidates with no recruiter assigned, or missing custom field values. Ashby can facilitate managing this by identifying non-compliant records easily via filters.

The general recommendation here is to use filter selections for “is empty/unassigned” to identify records with no value.

In this example we can select for all applications that have no source and group by the responsible recruiter to distribute responsibility for updating the application records.

Common missing fields to review

The most common fields your team may want to establish data quality reporting for are the following:

Your team’s process may vary on some of these fields being present, so it may make sense to add an additional filter. For example, you may want to review data quality specifically for hired candidates more carefully. This would involve checking offer letter details, hiring team information and so on. Here we see a list of hires with no hiring manager on record, by department:

Your ATS may permit assigning an owner to related records, such as a Job’s recruiter or a Candidate’s recruiter. This ownership can often diverge, creating uncertainty.

Ashby permits easily reporting on the fields and ownership associated with either the job or a candidate’s application. At the bare minimum, your team may want to maintain awareness by reporting on both, but a diagnostic report can be made that groups all application’s by their job’s owner first with a second grouping on the application’s owner:

The results, after some additional filter options are added per your need, may look like this:

In this view, we see Chastity Okuneva (bright pink) has ownership over almost all applications on Job’s owned by other recruiters. Conversely, Tevin (teal), is the owner of 96% of their job’s applicants.

Your ATS may have a complex data model that permits setting fields such as departments or hiring managers on multiple distinct objects, e.g. the Job Posting may have a department while the associated Requisition may have a different department. Similar to the above example with recruiter ownership on Jobs and Applications, you should consider this across other objects where it may apply.



Once you’ve identified the critical reports of interest to your team, the recommendation is to compose your reports into respective dashboards. Some data quality issues are best dealt with immediately or at a weekly review, which is a perfect fit for Ashby’s Alerts. In addition, once you’ve setup your reports and dashboards, you’ll want to ensure they are pinned to your team’s home page for easy access. The below references cover all of these topics in greater detail:

At a high level the above examples can be summarized in a check list you may want to review with your team. Based on your priorities you may not want to address all of these at once.