<aside> đź’ˇ 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.
</aside>
Section overview:
<aside> 💡 Ashby has a standard “Data Quality” example dashboard to help get you started. If you’d like to see what this looks like, reach out to your dedicated Success Manager or Ashby Support.
</aside>
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.
<aside> 🧠In the case of managing a large team, assignment to individual owners can be incorporated to almost all reports and dashboards, permitting a distribution of responsibility. This is one way Ashby can facilitate creating an ownership culture of data quality.
</aside>
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: