Playbook trigger initiation issue

Question

Hello community,

I migrated a Microsoft Sentinel Logic App playbook to a target tenant. The workflow contains the trigger “When a response to an Azure Sentinel alert is triggered.” I configured the Sentinel API connection in the target tenant, and the connection appears to be connected in the Logic App designer.

However, the trigger is not getting initiated when expected.

Could someone help me troubleshoot this issue?

1. What are the common reasons a Microsoft Sentinel Logic App trigger remains in the “Not initiated” state after tenant-to-tenant migration?
2. How can I verify whether the Sentinel trigger subscription or webhook registration is active in the target tenant?
3. Are additional permissions, service principal configuration, or Sentinel playbook permissions required for the trigger to fire?
4. How can I confirm that the playbook is correctly associated with the target Sentinel workspace and that the trigger is receiving events?
5. What troubleshooting steps should I follow to identify the root cause without recreating the entire Logic App?

Any guidance on the recommended troubleshooting procedure would be appreciated.

Answer 1

After migration, reselect the playbook in the target workspace’s automation rule, grant Microsoft Sentinel access to the playbook’s resource group, and save both the rule and Logic App to establish the target-tenant binding.

1. Rebind the migrated playbook

A migrated Logic App can retain a valid-looking API connection while the target workspace’s automation rule still references the old playbook ARM resource ID.

1. In the target workspace, open Microsoft Sentinel → Configuration → Automation.
2. Edit the automation rule expected to start this playbook.
3. Under Actions, remove the existing Run playbook entry if it references the migrated or unavailable instance.
4. Add Run playbook again and select the playbook deployed in the target tenant.
5. If it is unavailable or grayed out, select Manage playbook permissions, select its resource group, and apply the permission.
6. Save the automation rule.
7. Open the Logic App designer, verify the Sentinel trigger still has its original name, and select Save.

Microsoft explicitly recommends reselecting and saving a relocated playbook when the playbook cannot be found or its ARM ID is invalid. Renaming a Sentinel trigger is unsupported because Sentinel integrations depend on its original name.^1^^2^

2. Validate the trigger/event combination

Determine exactly how the playbook is expected to start:

• Automatic incident response: Prefer the Microsoft Sentinel incident trigger and attach it to an automation rule using When incident is created or When incident is updated.
• Alert trigger: This trigger is intended for individual alerts and has limitations. It cannot automate alerts generated by Microsoft security analytics rules. Confirm the test alert originates from a supported scheduled analytics rule and that an alert—not merely an incident update—is being generated.^2^
• Manual test: Run the playbook from a real alert or incident matching its trigger type. The playbook offered by Sentinel must start with the corresponding Sentinel Alert or Incident trigger.

Also check Automation → Active playbooks. Confirm that:

• Status is Enabled.
• Trigger kind is Microsoft Sentinel Alert.
• The playbook is visible under the target subscription filter.

A trigger kind of Not initialized means Sentinel did not identify Sentinel components in the workflow definition, even if the designer appears to contain a trigger.^3^

3. Validate both permission layers

The API connection’s Connected/Ready state alone does not prove that Sentinel can invoke the Logic App or that the connection identity can access the target workspace.

Sentinel invoking the playbook

For automatic execution, the Microsoft Sentinel service account needs Microsoft Sentinel Automation Contributor on the resource group containing the playbook. Granting this requires Owner or User Access Administrator. The administrator configuring the playbook also needs the documented Sentinel and Logic Apps roles.^4^

Connector identity accessing the workspace

Identify whether the Sentinel API connection uses a managed identity, service principal, or user account. In the target workspace, assign that identity:

• Microsoft Sentinel Reader to receive trigger data and use read actions.
• Microsoft Sentinel Responder or Contributor if the workflow updates incidents or performs other write actions.

For managed identity, use Sentinel → Settings → Workspace settings → Access control (IAM) and assign the role to the target Logic App. For a service principal, assign the workspace role to the target tenant’s enterprise application, and verify that the connection contains the target tenant ID and current credentials.^5^

4. Check subscription and execution evidence

Saving or reenabling a webhook-based workflow causes it to subscribe by registering a callback URL. Disabling the workflow or trigger invalidates that subscription.^6^

Then inspect:

1. Logic App → Trigger history:
   • No entries: Sentinel never invoked the trigger; concentrate on rule association, trigger compatibility, permissions, or access restrictions.
   • Failed entry: open its inputs and outputs for the exact authentication or callback error.
   • Successful entry without a completed run: inspect Run history and downstream actions.^7^
2. Enable Sentinel health monitoring, then query the target workspace:

SentinelHealth
| where TimeGenerated > ago(24h)
| where OperationName in ("Automation rule run", "Playbook was triggered")
| project TimeGenerated, OperationName, SentinelResourceName,
          Status, Description, ExtendedProperties
| order by TimeGenerated desc

Common results identify invalid ARM IDs, missing Sentinel permissions, invalid connection credentials, disabled workflows, unsupported trigger types, resource locks, network/access restrictions, and throttling.^1^

If Sentinel reports success but no Logic App execution details appear, enable Logic App diagnostic settings, send them to the target Sentinel workspace, and correlate SentinelHealth with AzureDiagnostics. If neither service records an attempt after a controlled test event, collect the automation-rule details, playbook ARM ID, trigger history, correlation time, and a browser HAR trace before opening an Azure support request.

---

References

1. Monitor the health of your automation rules and playbooks
2. Supported triggers and actions in Microsoft Sentinel playbooks
3. Create and manage Microsoft Sentinel playbooks
4. Automate and run Microsoft Sentinel playbooks
5. Authenticate playbooks to Microsoft Sentinel
6. Schema reference guide for trigger and action types in Azure Logic Apps
7. Troubleshoot and diagnose workflow failures in Azure Logic Apps