Technical Guidance Required – Microsoft Sentinel Integration with Dynamics 365 via Logic Apps / Dataverse

Use a Microsoft Sentinel incident-triggered Logic App and the current Microsoft Dataverse connector for ordinary case CRUD; use the Dataverse Web API only where the connector lacks a required case operation, authentication method, or control—most notably the CloseIncident action.

Recommended production pattern

1. Trigger from Sentinel
   • Create a playbook with the Microsoft Sentinel incident trigger.
   • Attach it to an automation rule for Incident created and, if needed, Incident updated.
   • This trigger is recommended for most incident automation and supplies incident, alert, entity, and workspace data. Microsoft explicitly identifies bidirectional ticket synchronization as a recommended playbook use case.^1^^2^
2. Create or update the Dynamics case
   • Use the current Microsoft Dataverse connector, not its legacy operations.
   • Use Add a new row against the Case (incident) table to create a case.
   • Store the Sentinel incident ARM ID, workspace ID, and incident ID in dedicated Dataverse columns. Store the Dataverse case GUID/case number back in a Sentinel tag or comment.
   • On later executions, query by this immutable correlation key and use Update a row, rather than creating another case.
   The connector is supported in Logic Apps Consumption and Standard and supports creating and updating Dynamics 365 Customer Service data.^3^
3. Close the case correctly
   • Do not close a Dynamics case by merely updating statecode or statuscode.
   • Invoke the Dataverse CloseIncident action, using the connector’s bound/unbound-action capability if it exposes the required action; otherwise call the Dataverse Web API.
   • Closing creates an incident-resolution activity and transitions the case to Resolved. It is not idempotent, so check the current state before invoking it.^4^
4. Synchronize changes back to Sentinel
   • Use a separate Dataverse-triggered workflow for relevant Case changes.
   • Use the Sentinel connector’s Update Incident action for status, owner, severity, title, description, or tags, and Add comments to incident for notes. Both operations require the Sentinel incident ARM ID.^1^

Identity and permissions

Dataverse side

For unattended server-to-server access, create a Dataverse application user associated with a Microsoft Entra service principal and assign it a custom, least-privilege security role. An application user is unlicensed, but its requests are subject to non-licensed-user limits.^5^

In Power Platform admin center → Manage → Environments → target environment → Settings → Users + Permissions:

1. Create a custom security role.
2. Grant only the privileges needed on:
   • Case (incident): Create, Read, Write, Append, Append To; Assign if ownership changes are synchronized.
   • Notes/activities: required privileges if comments become notes or activities.
   • Any queue, user, team, or custom correlation tables used by the workflow.
3. Create the application user and associate that custom role with it.^6^

For CloseIncident, the caller additionally needs prvCreateActivity, prvAppendToIncident, prvAppendActivity, prvWriteIncident, prvDeleteQueueItem, prvReadActivity, and prvWriteActivity.^4^

Managed identity

Managed identity is recommended in Logic Apps when the selected action or connector explicitly supports it, but the documented managed-identity connector lists do not include the Microsoft Dataverse managed connector. Therefore, do not assume that selecting the Dataverse connector gives generic managed-identity authentication.^7^

For Dataverse, the clearly documented general pattern is:

• Entra application/service principal
• Dataverse application user
• Custom Dataverse security role

If managed identity is a mandatory requirement, validate the exact Dataverse endpoint and Logic App SKU in a proof of concept or support request before choosing HTTP. The available documentation demonstrates managed identity mapped to a Dataverse application user for Dataverse healthcare APIs, but that scenario should not be treated as confirmation for every Dataverse Web API workload.^8^

On the Sentinel side, managed-identity authentication is documented but currently marked Preview. Assign the Logic App identity:

• Microsoft Sentinel Reader if it only receives/reads incidents.
• Microsoft Sentinel Responder or Contributor if it updates incidents or adds comments.^9^

Two-way synchronization controls

Implement these explicitly; Sentinel does not provide built-in Dynamics case synchronization:

• One immutable cross-system correlation ID.
• Field ownership rules—for example, Sentinel owns severity while Dynamics owns assignment.
• Status mapping, including invalid or non-equivalent transitions.
• A “last updated by integration” marker to prevent update loops.
• Idempotency checks for create, comment, assignment, and closure.
• Conflict handling using timestamps or version information.
• Separate retry/dead-letter handling and operational monitoring.
• Comment deduplication; avoid copying the entire history on every update.

Production constraints

• Dataverse external calls are subject to entitlement and service-protection limits. Web API throttling returns HTTP 429; honor Retry-After rather than using immediate retries.^10^
• Application-user activity consumes the tenant’s pooled non-licensed request allocation; validate expected incident, comment, retry, and polling volumes against the tenant’s Dynamics/Power Platform licensing.^11^
• Sentinel must have explicit permission to run playbooks through automation rules, and authors/operators need the corresponding Logic App and Sentinel roles.^12^
• If using Logic Apps Standard private endpoints, managed API webhook triggers such as the Dataverse trigger cannot call a private-only workflow endpoint. Account for this before selecting the networking model.^13^

The architecture uses supported Microsoft services and documented extension points, but there is no documented first-party Sentinel-to-Dynamics case-management reference solution in the cited catalog. It is therefore a supported custom integration pattern, not a turnkey integration with a blanket certification. Obtain a tenant-specific Microsoft support review if formal production-support confirmation is a governance requirement.

References

1. Supported triggers and actions in Microsoft Sentinel playbooks
2. Automate threat response with playbooks in Microsoft Sentinel
3. Connect to Microsoft Dataverse from workflows in Azure Logic Apps
4. CloseIncidentRequest Class-Definition
5. Build web applications using server-to-server (S2S) authentication
6. Use OAuth authentication with Microsoft Dataverse
7. Secure access and data for workflows in Azure Logic Apps
8. Dataverse healthcare APIs: Configure Azure Logic App with an HTTP trigger
9. Authenticate playbooks to Microsoft Sentinel
10. Service protection API limits
11. Requests limits and allocations
12. Roles and permissions in the Microsoft Sentinel platform
13. Secure traffic between Standard logic apps and Azure virtual networks using private endpoints