Last Active Filtering | Hanru Wehmeyer

Snapshot

The standard answer here was a date picker. Instead I let each institution set its own ranges for what Active, At risk and Inactive mean, A/B tested against the date picker with real admins, and now at 25.4% adoption.

Problem

Admins needed to find who was genuinely inactive, to bulk deactivate them, and who was genuinely at risk, to get in touch. The “last active” data was stagnant and binary, so neither group was easy to isolate.

RAG statuses existed, but their thresholds were fixed and invisible, 0–7 days green, 7–14 amber, 14+ red. My read was that few admins knew what the colours meant, which makes a status hard to act on.

Pass on the date picker for custom ranges

The standard answer is a date picker: pick a cut-off, filter against it. But it hands over no more control than the fixed thresholds did, you still have to know which date matters first.

The statuses were the thing admins couldn’t see inside, so the opportunity was to make those definitions editable rather than route around them: the admin sets what Active, At risk and Inactive mean, and the statuses start reflecting their own institution.

I A/B tested both in a survey with admins who actually use Genio. They preferred custom ranges, and the reason they gave was the sense of control it offered, not the filtering itself.

Let admins define what "active" means

I introduced four RAG-coded status categories (Active, At Risk, Inactive, No Data) and, critically, let admins set their own week-thresholds for each one, rather than imposing a single fixed definition of "active" across every institution.

Threshold editor using numeric stepper inputs, with a segmented colour bar above and a plain-language summary of the resulting logic. — Ideation, thresholds as numeric inputs, with the resulting logic spelled out in words beside them.

Threshold editor as a timeline with two draggable markers, and the resulting Active, At Risk and Inactive ranges shown beneath. — Ideation: the same thresholds as draggable markers on a timeline, with each range read back underneath.

The users table with a filter panel open, showing a Last Active date picker with a January 2026 calendar. — Ideation, filtering the table by a specific last-active date.

The users table with a filter panel open, showing a Filter by Last Active Status dropdown listing Green (Active), Amber (At Risk) and Red (Inactive). — Ideation, filtering by status rather than by date, which is what the thresholds make possible.

Run the prototype as scenarios, not a demo

On the customer calls I handed the prototype to the admin rather than driving it, and read out scenarios, “you want to see who’s at risk so you can contact them: set the inactive range to 2–4 weeks and filter by inactive.” That tests whether the model works under a real intent, not whether a walkthrough is persuasive.

It landed well, and surfaced what a demo wouldn’t: once admins could isolate a group they wanted to act on it, export, email, bulk deactivate. That shaped the roadmap beyond this feature.

Shipped

A Last Active filter in the users table: the four states as checkboxes, each carrying its status icon, with an Edit Ranges control that opens the editor where an admin sets the week boundaries for Active, At risk and Inactive.

The users table with the Filters panel open, showing Status and Group dropdowns and a Last Active group with Active, At risk, Inactive and No data checkboxes plus an Edit Ranges button. — Shipped: the Last Active filter, with Edit Ranges sitting next to the states it defines.

The Edit Last Active Ranges dialog, with week inputs for Active, At risk and Inactive and a reset to default option. — Shipped: the range editor: each status spelled out as a sentence that updates with the week values.

The Last Active Ranges dialog open over the users table, defining the range for each status alongside the filter panel. — Shipped, setting the ranges in context, over the table whose statuses they re-colour.

Outcome

Adoption currently sits at 25.4%*, and admins recorded and shared videos unprompted showing appreciation for the feature, validation that wasn’t solicited.

The calls also moved the roadmap: wanting to act on a filtered group, not just see it, pushed CSV export of filtered lists further up the order. A first step toward a bigger solution rather than the whole of it.

* Still growing.

Reflection

The date picker would have been defensible, and would have left the part actually blocking admins untouched: a status whose definition they couldn’t see. The useful move was doubting those fixed thresholds meant anything to the people relying on them, then A/B testing that hunch against the obvious answer instead of shipping on it.