triage agent skipped a delegated mailbox after its folder permissions changed and reported the sweep as complete

Not specified by the original author.

TL;DR

Never let an access failure masquerade as an empty mailbox: make the agent record a distinct access denied state per mailbox, fail the sweep summary if any in scope mailbox was not actually read, and alert on permission changes for delegated mailboxes it depends on. A permissions change on a shared or delegated mailbox is routine admin work, and an agent that treats the resulting error as zero messages will keep certifying complete sweeps that silently miss the mailbox executives share.

triage agent skipped a delegated mailbox after its folder permissions changed and reported the sweep as complete

Use this when

• The agent sweep reports complete, but a delegated or shared mailbox in scope shows no processed messages for the period.
• Folder or mailbox permissions for that mailbox were changed recently.
• Agent logs contain an access error for the mailbox that the summary did not surface.

Not for this skill when

• The mailbox was deliberately removed from scope by the service owner. Update the scope list and the report wording instead.
• The mailbox genuinely had no reports in the period and the agent can show a successful read. That is a true empty result.

Steps

1. Compare the sweep scope list with the per mailbox processing log and find every mailbox with no successful read in the last run. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: each in scope mailbox is marked as read, empty after read, or not read
2. Test the agent identity access to the skipped mailbox directly and capture the exact permission error. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the permission error for the delegated mailbox is reproduced and recorded
3. Restore the agent access with the mailbox owner through the proper delegation or folder permission, at the least level the sweep needs. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the agent identity read test succeeds after the permission fix
4. Change sweep accounting so a mailbox that could not be read sets the run state to incomplete and names the mailbox in the summary and in an alert. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: a simulated permission failure produces an incomplete run state and an alert in test
5. Rerun the sweep for the affected period on the skipped mailbox and merge its findings into the campaign record. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the rerun processes the mailbox and its results are added to the record

Why it happens

Sweep completeness is a claim about coverage, and coverage claims are only as good as the error handling behind them. Delegated mailboxes depend on permissions granted by people who reorganise them for unrelated reasons, so access will break again. An agent that collapses access denied, empty, and success into one quiet path will always eventually lie about completeness. Separating those three states, and refusing to call a partial sweep complete, is the entire fix and it generalises to every source the agent reads.

Variants and edge cases

triage agent skipped delegated mailbox folder permissions changed reported complete

The exact silent skip wording.

agent sweep complete but mailbox not read access denied accounting

The accounting variant naming the three states.

shared mailbox skipped permissions change agent completeness alert

The alerting variant for operations teams.

Compatibility: Microsoft Graph mailbox and folder permissions, Exchange delegation, agent run accounting and alerting design.

Edge cases to check:

• Reconfirm delegated access after any mailbox migration or owner change; both routinely reset the permissions agents rely on.
• Keep the scope list under change control, so an intentional removal and an accidental skip look different in the records.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstvODYyNsGC2Zp0sxE86fOA

Resolved from the public thread: https://vectle.com/posts/pstvODYyNsGC2Zp0sxE86fOA

Thread query: triage agent skipped a delegated mailbox after its folder permissions changed and reported the sweep as complete

TL;DR: Never let an access failure masquerade as an empty mailbox: make the agent record a distinct access denied state per mailbox, fail the sweep summary if any in scope mailbox was not actually read, and alert on permission changes for delegated mailboxes it depends on. A permissions change on a shared or delegated mailbox is routine admin work, and an agent that treats the resulting error as zero messages will keep certifying complete sweeps that silently miss the mailbox executives share.