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.emailIntegration on appfolio-45 (The Willows, isTest=true) fails to refresh: AADSTS70000 'User account is found to be in service abuse mode', via the Outlook webhook token-refresh path (agents/clara/lib/email/inbox-client.ts refreshEmailAccessToken). Sentry issues JAVASCRIPT-NEXTJS-1A1/1A2/1A3/1A4: 25 events between 07:26 and 08:59 today, still growing. No code fix available -- Microsoft has locked this specific O365 account and only they (or the account owner) can lift it. The generic email-integration disconnect route restricts severing any mailbox to PropFlow staff only, per Fede's 2026-09-16 ruling ('anything that breaks integrations makes me nervous'), so I'm not unilaterally clearing this even though the property is test-only.
In plain terms. Should we disconnect a broken test email inbox, or leave it alone for now?
One of our test properties (not a real customer) has an email inbox connected through Microsoft. Microsoft has locked that account for looking like abuse, so every test email now fails and creates an error alert -- it's happened about 25 times in under two hours. No tenant or customer is touched by this, it's purely internal test setup. Disconnecting is easy to undo later, but our own rule says only staff should sever a mailbox connection, so I'm asking rather than just doing it.
The session raising this recommends: Disconnect the test inbox now Zero customer impact and the account is externally locked, so staying connected only keeps generating alerts for no benefit. Tried first, unsuccessfully: Confirmed via Sentry (25 events across 4 issues since 07:26) and the repo (data/properties.json confirms isTest=true, inbox-client.ts is the failing path, org-connect.ts shows the established revoked-grant pattern) that this is test-property-only, externally caused by Microsoft, and that severing a mailbox is staff-gated by explicit policy rather than something to do unilaterally.