We're introducing event-based inactivity calculations to help organizations more accurately determine when candidates become inactive for data retention purposes. Admins can now choose which candidate and recruiter activities count as meaningful engagement. Ashby uses the most recent relevant activity to calculate a candidate's inactivity date and apply the appropriate retention rule.

Previously, candidate inactivity was primarily tied to job applications. For applicants, the inactivity period was based on when the associated job was archived. For candidates without a job application, including leads, the period began when they were added to Ashby. This meant that ongoing interactions, such as communicating with a lead outside a specific job, weren't reflected in inactivity calculations.

With event-based calculations, organizations can account for these interactions, giving teams more control over how candidate activity informs data retention and helping them align calculations with their internal policies.

Define which activities determine candidate inactivity

Admins can choose which candidate and recruiter activities reset a candidate's inactivity timer based on their organization's data retention policies. Under Data Privacy & Compliance, click Configure.

Relevant activities can include:

• Receiving a message from a candidate
• A candidate submitting a form
• A candidate completing an assessment
• Completing an interview
• Accepting or rejecting an offer
• Adding a candidate to Ashby
• Moving a candidate to a different stage
• Transferring an application

These settings apply across the organization, allowing teams to define which interactions indicate continued engagement with a candidate. This flexibility helps organizations align their retention calculations with internal policies and applicable privacy requirements.

After updating the configuration, admins can re-evaluate existing candidates to recalculate their inactivity dates based on the selected activities. This may also update their inactivity-based retention dates across the organization.

Account for engagement with leads outside a job application

Recruiters can now account for meaningful interactions with leads, even when they're not associated with a specific job. Activities like receiving a candidate message or form submission can reset the inactivity timer when configured as relevant events.

This allows teams to maintain relationships with passive candidates while ensuring ongoing engagement is reflected in data retention calculations.

Review active candidates based on their latest activity

A new Active Candidate retention rule allows organizations to identify candidates who haven't had meaningful activity within a configured retention window, even if they're associated with an active job.

These candidates can be flagged for review and potential archival, helping teams avoid retaining candidates indefinitely simply because their applications remain active.

See how candidate retention dates are calculated

Candidate profiles now provide greater visibility into how inactivity-based retention dates are determined.

Teams can see:

• The candidate's most recent relevant activity
• When that activity occurred
• The retention rule applied
• How the activity and retention rule determine the calculated date

For example, if a candidate's most recent relevant activity was a stage change, Ashby shows that event as the basis for their inactivity date. The applicable retention period is then added to determine their retention date.

If a more recent relevant activity occurs, such as receiving a new message from the candidate, Ashby updates the calculation accordingly.

This visibility helps recruiting operations, privacy, and legal teams understand how retention dates are calculated without manually reviewing a candidate's activity history.

Getting started

To configure event-based inactivity calculations, go to Admin > Data Privacy & Compliance > Configure in Ashby.

Existing customer configurations will be migrated to the event-based system. New customers will start with a default set of relevant activities, which admins can review and adjust based on their organization's policies.

Visit our help article for more information.