Why can't you run a Sentinel playbook manually from the Defender portal, and what works cross-tenant?

Reviewed by ContraForce team · Updated 2026-09-04

> Microsoft Sentinel automation rules can run a playbook that lives in a different tenant under an Azure Lighthouse architecture, so cross-tenant automation does work when it is triggered by a rule. What the Defender portal does not support is running a playbook manually on an alert or on an entity. Manual runs on an incident are supported.

What actually works cross-tenant today?

Microsoft documents that a Sentinel automation rule can invoke a playbook residing in a different Microsoft Entra tenant, which is the multitenant Azure Lighthouse arrangement a service provider runs. The playbook is authored once in the provider tenant and triggered by rules operating on customer workspaces.

The caveat Microsoft attaches is about permissions rather than capability: Sentinel needs explicit permission to run playbooks in the tenant where they live, granted in that tenant. It is a configuration step, not a boundary.

So the common framing that centrally-authored playbooks cannot run cross-tenant is too strong. Rule-triggered automation works.

What is not supported in the Defender portal?

The gap is manual invocation, and it is specific. Microsoft lists procedures that are not currently supported in the Defender portal, and among them: "Running a playbook manually on an alert isn't supported in the Defender portal." Manual runs on an entity are listed the same way.

Running a playbook manually on an incident is supported. The incident details pane carries a Run playbook panel listing the related playbooks for that incident.

Why does this matter for a provider consolidating onto the Defender portal?

Sentinel is converging into the Defender portal, and the analyst working a queue there loses two escalation paths that exist in the Azure portal. An analyst who wants to fire an enrichment or containment playbook against a single suspicious entity mid-investigation cannot do it from the console they are working in.

The workaround is to model the action as an incident-level playbook, or to keep an Azure portal session open alongside the Defender one. Both work. Both mean the response path depends on which console the analyst happens to be in, which is the kind of inconsistency that produces different handling of the same alert on different shifts.

How do you make response behave the same way in every tenant?

Every option above ties the available response to the console and to per-tenant configuration. An alternative is to hold the response logic in the operating layer rather than in either portal, so the same action is available on the same evidence regardless of where the analyst is working and which customer they are working in.

ContraForce runs response through Gamebooks that execute against the connected vendor, with approval gates deciding what an agent may do unattended. The response set does not change between an alert, an entity and an incident, and it does not change between customers, because it is defined once in the platform rather than configured per workspace.

Sources

• Automate threat response with playbooks in Microsoft Sentinel
• Microsoft Sentinel in the Microsoft Defender portal
• Microsoft Defender multitenant management requirements