The Hidden Reason Your Sentinel Playbook Won't Show Up in Automation Rules (It's Not RBAC)

If a Logic App using the native Microsoft Sentinel incident trigger doesn't show up in the "Run playbook" picker of an Automation Rule — even though permissions, region, and connection are all correct — check the internal action name of the trigger in the JSON code view. If the Logic App was created while the Azure portal was set to a non-English language, the designer may generate a localized action name instead of the expected Microsoft_Sentinel_incident, and the playbook won't be picked up.

Environment

Microsoft Sentinel (Log Analytics workspace)
Logic Apps (Consumption plan)
Trigger: native Microsoft Sentinel connector, "Incident" trigger (/incident-creation path)
Authentication: system-assigned Managed Identity
Same subscription, resource group, and region as the Sentinel workspace

Problem

Two Logic Apps, both triggered by the native Microsoft Sentinel incident trigger, both using a system-assigned managed identity with the Microsoft Sentinel Responder role granted on the workspace. Same subscription, same resource group, same region.

Only one of the two appeared in the "Run playbook" dropdown when configuring an Automation Rule in Sentinel. The other was simply absent — no error message, no warning, nothing in the run history to explain it.

Investigation

The usual suspects were checked and ruled out one by one:

API connection health — one azuresentinel connection was indeed in an "Error" state, but it turned out not to be the one referenced by the affected trigger.
Managed identity RBAC — the Microsoft Sentinel Responder role was correctly assigned to the Logic App's managed identity on the Sentinel workspace.
User's own RBAC/PIM role — the Logic App Contributor role (required for the account configuring the Automation Rule to even see the resource) was active via PIM at the time of testing.
Region/subscription/resource group — identical for both Logic Apps.
Trigger type — both used the native "Incident in Microsoft Sentinel" trigger added through the visual designer, not a generic HTTP trigger or a deprecated connector.

Every documented requirement was met. The playbook was still invisible.

Root Cause

Comparing the raw JSON (Logic app > Development tools > Code view) revealed the actual difference.

Working Logic App (visible in the picker):

"triggers": {
  "Microsoft_Sentinel_incident": {
    "type": "ApiConnectionWebhook",
    "inputs": {
      "body": { "callback_url": "@{listCallbackUrl()}" },
      "path": "/incident-creation"
    }
  }
}

Broken Logic App (invisible in the picker):

"triggers": {
  "Incident_dans_Microsoft_Sentinel": {
    "type": "ApiConnectionWebhook",
    "inputs": {
      "body": { "callback_url": "@listCallbackUrl()" },
      "path": "/incident-creation"
    }
  }
}

The connector type and the path (/incident-creation) are identical. The one meaningful structural difference is the trigger's action name: Microsoft_Sentinel_incident versus Incident_dans_Microsoft_Sentinel.

The second Logic App's trigger had been added while the Azure portal was set to French. The designer generated a localized action name instead of the canonical English one.

Everything points to Sentinel's playbook discovery mechanism scanning Logic App definitions for that exact canonical action name (Microsoft_Sentinel_incident) to identify a resource as a valid Sentinel playbook — rather than relying solely on the connector type or the webhook path, as one would reasonably expect.

Fix

Renaming the trigger's action key in the JSON to the canonical name was enough:

"triggers": {
  "Microsoft_Sentinel_incident": {
    ...
  }
}

No permission, connection, or region change was required — only this rename.

Takeaways

The Sentinel Automation Rule playbook picker appears to depend on the exact trigger action name, not just its type or functional behavior — a dependency that isn't documented anywhere in the official Microsoft docs as of this writing.
The Azure portal's display language at the time a trigger is added has a direct impact on that Logic App's compatibility with Sentinel Automation Rules.
A playbook can be fully functional (running without errors when triggered manually or through an older automation mechanism) while still being invisible in the newer Automation Rule selector — which makes this particular issue easy to miss, since nothing explicitly flags it.

Recommendations

Temporarily switch the Azure portal to English (Portal settings > Language and region) before adding a Sentinel trigger to a Logic App, if your team usually works in another language.
If an existing Logic App won't show up despite an otherwise correct configuration, check the trigger's action name in the JSON code view first — it's a 30-second check that can save hours of RBAC/connection troubleshooting.
Document this in your internal runbooks if your team works in a localized portal — this kind of detail is easy to lose and can cost significant troubleshooting time down the line.

Has anyone else run into similar localization-related quirks in Sentinel or Logic Apps? Would be curious to hear about other cases in the comments.

Forum Discussion