soar playbook trigger failed after the logic app connector lost its defender permissions mid-campaign

TL;DR

Fix the identity, not the playbook: open the Logic App API connection for Defender, check whether its sign in has expired or its account lost the Defender roles, reauthorise the connection with an account or managed identity that holds the needed permissions, and test the trigger with a controlled incident. Connector connections decay quietly as passwords rotate, staff leave, and conditional access tightens, and the campaign only notices when the automation that should fire does not.

soar playbook trigger failed after the logic app connector lost its defender permissions mid-campaign

Use this when

• Defender incidents are created but the SOAR playbook runs stopped starting at a specific time.
• Logic App run history shows trigger failures with authorisation or forbidden errors.
• A staff change, password rotation, or policy change happened around the same time.

Not for this skill when

• Playbooks start and then fail mid run on an action. That is an action permission or logic problem inside the run.
• No incidents are being created upstream. Fix detection first; the playbook has nothing to trigger on.

Steps

1. Open the failed trigger history and read the exact authorisation error and the identity the connection claims to use. 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: the failing identity and error are recorded from the trigger log
2. Check that identity in the directory and in Defender role assignments: is it enabled, licensed as needed, and still holding the roles the actions require. 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 identity role state is confirmed, including any missing assignment
3. Repair the connection by reauthorising it, or migrate it to a managed identity with the documented Defender permissions where supported. 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 connection shows a valid, connected state after repair
4. Fire a controlled test incident and watch the playbook trigger and complete its first actions. 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: the test incident starts the playbook and its early actions succeed
5. Add a daily synthetic check or an alert on trigger failures so the next decay is caught in hours. 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 alert exists and a test failure notification is received

Why it happens

Automation identities are accounts in everything but name: they expire, get rotated, lose roles during cleanups, and fall foul of new access policies. Because a healthy playbook is silent, a dead trigger is usually discovered by a human noticing a campaign had no automated response, days later. The connection layer is also owned by nobody in many teams, built once by a consultant and never revisited, which is why a permissions check belongs in every trigger investigation before anyone edits playbook logic.

Variants and edge cases

soar playbook trigger failed logic app connector lost defender permissions

The exact mid campaign trigger failure wording.

logic app defender connection authorisation expired playbook not triggering

The connection expiry variant.

defender incident no playbook run connector forbidden 403 fix identity

The error code variant analysts search from run history.

Compatibility: Microsoft Sentinel and Defender Logic Apps connectors, managed identities, Defender role based access.

Edge cases to check:

• Prefer managed identities for new playbooks so there is no password or personal account to decay.
• Document which roles each playbook connection needs; role reviews can then spare them deliberately instead of removing them blindly.

Provenance

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