Blog: Tenancy Statuses Now Update Themselves — Here's Why That Matters
Tenancy Statuses Now Update Themselves — Here's Why That Matters
Release v0.1.250
One of those bugs that hides in plain sight: a tenancy starts, time passes, and the platform still thinks it hasn't begun. From v0.1.250, that's fixed — and the implications ripple through the entire check-out workflow.
What Was Happening
Every tenancy has a status field: upcoming, active, ended, or disputed. Until now, that field was set once — at creation — and never automatically revisited.
The result? A tenancy whose startDate was last month could still be labelled upcoming. An agent looking at their dashboard work queue would never see it, because that queue only surfaces active tenancies approaching their end date. The tenancy was effectively invisible to the platform's automation.
An agent would have to notice the discrepancy manually, update the status by hand, and only then would the system begin doing what it should have been doing all along — sending reminders, surfacing the check-out task, preparing for deposit release.
In a busy lettings operation, that's an easy thing to miss. And a missed check-out is a compliance risk.
What's Changed
We've extended the platform's existing daily Inngest cron job — deadline-reminders — with a new status reconciliation step. Every day, it scans every tenancy and applies two simple rules:
upcoming→activeif the start date is today or has already passed.active→endedif the end date has passed and there is no open deposit release.
That second rule includes a deliberate safeguard. If a deposit is still being negotiated when the end date arrives, the tenancy stays active. Nothing gets closed out from under an in-progress financial settlement.
Each transition also fires the appropriate notifications — so landlords, agents, and tenants are kept in the loop automatically, without anyone needing to push a button.
Why the Deposit Guard Matters
The active → ended transition only fires when there is no open deposit release. This is not a minor detail.
Deposit deductions are often agreed in the days or weeks after a tenancy physically ends. The tenant has left, the keys are handed back, but the financial settlement is still being negotiated. If the system closed the tenancy the moment the end date passed, it could interfere with that process — cutting off access to evidence, disrupting notification flows, or creating a false sense of finality before both sides have agreed.
By holding the tenancy in active until the deposit release is resolved, the platform ensures that every party can complete the process properly, regardless of how long it takes.
What Agents Will Notice
The most immediate difference is in the dashboard work queue. Because the queue only shows active tenancies, any tenancy that was stuck in upcoming was silently absent. From today's daily run onwards, those tenancies will be correctly promoted and will appear in the queue as they should.
For most operations, this will feel like things have simply started working as expected. For a few, it may surface a backlog of tenancies that should have been in the check-out workflow weeks ago — now is a good time to review them.
No Action Required
This runs automatically. There is nothing to configure, no feature flag to enable, no migration to run. The reconciliation step is part of a cron job that already runs daily. From v0.1.250 onwards, tenancy statuses stay accurate without any manual intervention.