Everything I could decide myself is decided. What's left needs
you. Each one carries the recommendation of the session that raised it — if you
agree, pick it and press Done. A model's opinion, where there is one, appears on the card
as a receipt line; cards with no receipt were never put to a model. "I'm not sure" is a real answer and becomes work for me.
You don't need to open the session — pressing Done sends your answer back and it picks up.
1Property appfolio-45 (The Willows, isTest=true, org_sandbox) emailIntegration is a personal Microsoft account (propflowaicalendar@outlook.com) shared by the inbox token refresh path and the calendar token refresh path. Token refresh started failing 2026-09-21T07:26 UTC with 400 invalid_grant / AADSTS70000 'User account is found to be in service abuse mode' - a Microsoft-side account lockout, not a code bug. 22+ occurrences by 08:56 UTC across the inbound email Lambda, the lead-received-outbox-drain cron, and the outlook webhook handler. Recovery requires a human to sign into propflowaicalendar@outlook.com, clear Microsoft's abuse-mode verification challenge, and reconnect the integration through the admin UI's Outlook connect flow to mint a fresh token pair.
In plain terms. Our test mailbox for the Willows test property got flagged by Microsoft for suspicious activity and can no longer log in. Nightly test runs that check tour scheduling and email handling use this mailbox and have been failing quietly since this morning. Do we reconnect it now, or leave it broken since it only affects our own tests, not real customers?
The session raising this recommends: Reconnect it now Nightly tests for tour scheduling and email handling have been silently failing since this morning; reconnecting is the only fix and needs a human sign-in. Tried first, unsuccessfully: Confirmed via the raw Sentry error (AADSTS70000 service abuse mode) instead of assuming a code bug; checked the property record - isTest=true, org_sandbox, so no live customer is affected; checked for an existing open decision on this cause and found none; ruled out a PR because the block is on Microsoft's side and needs an interactive sign-in Smith has no credentials or browser access for.