Dentolize · Churned Leads Rejoin Renewal — Walkthrough
On this pageFirst, the reassuranceQuestions you will actually getWhere to lookEscalation triggersWhat to say if asked whether churned customers are "automatically won back"Related reading

For Support

First, the reassurance

No clinic user is affected by this change. Nothing in the clinic app changes. No screen, no permission, no data a customer can see. If a clinic raises a ticket during this release window, this PR is almost certainly not the cause.

The "leads" in this change are Dentolize's own customer records on an internal sales board, not the lead-management feature clinics use. If a customer asks about their leads, this page is not relevant — nothing about the customer-facing lead module changed.

Everyone who could plausibly ask you about this change is an internal colleague: sales, account management, or admin panel users.

Questions you will actually get

"Why did this account suddenly move to Renewal on its own?"

The renewal automation runs at 04:00 every third day and moves a card into Renewal when all of these hold:

  • the customer is on an annual plan (monthly is never auto-moved),
  • their subscription expiry falls inside the window (roughly four to eight weeks out),
  • and the card is not already in the Renewal pipeline.

Before this PR, cards in the Churned column were exempt. Now they are not. So the most likely answer to "why did this churned account move" is: because this change shipped, and its annual subscription is coming due.

Check the card's timeline. An automated move writes a StageTimeline entry authored by the system user, so you can distinguish it from a human drag at a glance.

"Why did a whole batch of churned cards change colour on the same day?"

Because their scores had been frozen — sometimes for months — and the first run after deploy recalculated all of them at once. It is a backlog clearing, not a real-world event. Tell people to read the second run's changes as signal.

"This account shows Working Low but they're barely using it. Is the score broken?"

Probably not. Working Low means one to ten of seventeen activity signals fired in the last five days. One is enough. A clinic that did nothing but message support scores 1 and lands in Working Low.

The at-risk tag is Not Working — zero signals. Working requires eleven or more, which is a high bar most healthy clinics never reach.

"Two cards both say 10 / 10 but have different tags."

Expected, and confusing by design. The stored score is capped at 10 but the tag is chosen from the uncapped count (0–17). So a card with a raw score of 10 gets Working Low, and one with a raw score of 14 gets Working — and both display 10 / 10. The tag is the more precise signal. This is pre-existing behaviour, not new here.

"The ordering of cards in the Churned column keeps resetting."

Known defect. When a card leaves a column, the automation shifts the position of every remaining card in that column, not just the ones below it. Manual ordering in a column that the automation moves cards out of will not survive. Since Churned is now a source column for the first time, this will start being noticeable there.

Route to engineering with a reference to Stage Move Mechanics and Known Defects. It is not caused by this PR but is made more visible by it.

"The Total number on the Jobs page dropped."

Expected, and harmless. That column counts how many companies the job fetched. It used to include disabled accounts; now it counts only live ones. The amount of work done is unchanged — disabled accounts were always skipped, just later in the process. See Change 2.

"A column's card count doesn't match the number of cards in it."

This one is worth escalating. The automation updates column counters with six separate writes and no transaction, so a crash mid-move can leave a counter out of step. Nothing repairs it automatically, and a wrong counter causes duplicate positions on future card creation — so it compounds.

Gather: which column, what the counter says, how many cards are actually there, and the last run time and error from the Jobs page. Then escalate.

Where to look

What you needWhere
Did the job run? Did it fail?Admin → Jobs, /ZROYKuKEVCvQykPlS4kP/jobs
A customer's subscription expiry, reference ID, unused featuresAdmin → Companies → the company, /ZROYKuKEVCvQykPlS4kP/company/:id
Which accounts look dormantAdmin → Not Working Companies, /ZROYKuKEVCvQykPlS4kP/notWorking
The card itself, its score, tags, notes, timelineDentolize's own tenant, Leads board

The Jobs page shows, per job: whether it is running, when it started, how long it took, the total scanned, and the last error. See the Feature Tour for what it looks like.

Escalation triggers

Escalate to engineering, don't troubleshoot, if you see any of these:

  • The Jobs page shows companyLeadCron stuck as running. The lock has no expiry — if the

process died mid-run, the job will never start again until the cron process is restarted. This is a silent-failure mode: no error, no alert, the job just stops happening.

  • An error string on the companyLeadCron row. The whole run aborts on the first

exception, so every company after the failure point was skipped that cycle. Note that companies are processed latest-expiry-first, meaning the most urgent renewals are processed last and are the first to be dropped.

  • Column counters disagreeing with card counts (see above).
  • A card that moved to Renewal but whose subscription is monthly — that should be

impossible and indicates a real bug.

What to say if asked whether churned customers are "automatically won back"

They are not. The automation moves a card on an internal board so a human can decide to make a call. It sends nothing to the customer, changes no subscription, and takes no billing action.

Also be careful: whether churned cards move to Renewal at all depends on how the board's pipelines are configured, and that has not been confirmed. The scoring and note updates happen regardless. See For Quality.