MyProspects · Engineering Plan

Fixing "Clear Follow-ups"

Prepared by Carlile Advisors Bot · July 10, 2026 · For Tucker's approval
⏳ Awaiting your approval — nothing has been changed yet

What happened

Karen (Heston's assistant) imported Clint Coon's old spreadsheet and CRM into MyProspects. The import gave every contact a follow-up date, so Clint's dashboard now shows 828 overdue follow-ups. Every time they press "Clear Follow-ups," they get an error. Other reps have a different problem: they select a couple of rows, and the action moves all of them.

What's actually broken

1The error: the request is literally too long

When you clear follow-ups, the app writes every row's ID into a single web address and sends it. Web addresses have a maximum length. 100 rows fits. 828 doesn't — the request is rejected before anything happens.

Proven live: 800 IDs → rejected (400) 100 IDs → accepted (200)

This is why no real rep has ever successfully cleared — only our small test accounts have. It fails silently at exactly the scale where reps need it most.

2"I selected a couple, they all moved"

The call list starts with every row pre-checked, and re-checks everything each time the list refreshes. So when a rep taps two rows, they're actually un-checking those two — and the action hits all the rest. Worse: when everything is checked, the app sends no list at all ("just do everything for this date"), which can even touch rows that aren't visible on screen.

3The banner that never reaches zero

The yellow "You have N overdue" counter includes some rows the clear button isn't allowed to touch (deleted or booked contacts). So even a successful clear can leave the banner up, making it look broken.

4Duplicate merge can undo a clear

Merging duplicate contacts picks the earliest follow-up date between them — and treats "cleared" as no date at all. So merging can quietly bring a cleared follow-up back from the dead.

The fix

1Let the database do the work

Instead of mailing the database a list of 828 IDs through a web address, the app sends one instruction: "clear this user's overdue follow-ups." The database does the whole job itself, in one all-or-nothing step. Works identically for 8 rows or 8,000, and the half-finished error states disappear. Your app already uses this pattern in three other places, so it fits the codebase.

2Checkboxes behave like checkboxes

Nothing is pre-checked. Your checks stick when the list refreshes. Buttons stay disabled until you've selected something, and the action applies to exactly what you checked — never more. The banner buttons stay as the "do everything" option, clearly labeled.

3Honest banner math

The overdue counter counts exactly what the clear button can clear — so after clearing, it reads zero and goes away.

4Close the duplicate-merge hole

Merging keeps the surviving contact's follow-up state. Cleared means cleared.

Clint: should we clear his 828 by hand?

Recommendation: No — ship the fix and let him press the button

If we hand-clear his rows, we never see the fix work on the real case, and the next big import hits the same wall. Instead: fix it today, prove it on a test account at 950 rows, deploy, then tell Karen "try it now." Clint's own 828 disappearing is the final proof.

Fallback: if the fix can't ship quickly and Clint is blocked from working, I can do a one-time safe database clear for him in 5 minutes. That option stays on the table.

How we prove it works

  1. Automated testsEvery button behavior gets a test, including the ones that currently lock in the wrong behavior — those get rewritten to the correct contract.
  2. Full-scale live rehearsalLoad the internal test account with 950 fake overdue follow-ups (tagged so they're easy to remove), press the real Clear button like Karen did, confirm success in the app and the database, then delete the fakes. That's Clint's exact failure size, with margin.
  3. Regression passSmall clears, single-row reschedule/tomorrow, prospect/client toggle, mobile view — make sure nothing else changed.

Rollout

  1. Build on a branch, open a PRYou review before anything deploys.
  2. Run the test plan aboveNothing gets announced until the 950-row rehearsal passes.
  3. Deploy, then message Karen"Try it now" — and watch Clint's dashboard go to zero.

Parked (your call, later)

• Nickname / "goes-by" field for contacts  • Karen's account (safe deactivate via the existing archive function, not a hard delete)  • Import guardrail that warns before creating hundreds of same-day follow-ups

Ready when you are

Reply "Approved" on Telegram and I'll start building — branch, PR, tests, and the 950-row rehearsal. Full technical plan lives at docs/plans/2026-07-10-001 in the repo.

Carlile Advisors · internal planning document · not indexed