Azure Logic Apps with Managed Identity for D365 Commerce Integrations

Storing credentials in Logic App connections is a security and operational problem. Every secret has an expiry, every rotation risks a production outage, and every developer who touched the connection now knows a credential that belongs in Key Vault. Managed Identity solves all three problems at once.

What Managed Identity gives you

When you assign a System-assigned Managed Identity to a Logic App, Azure creates a service principal automatically and ties its lifecycle to the Logic App resource. You never see a password. You never rotate a secret. Azure handles the token issuance internally.

For D365 F&O integrations specifically, this means your Logic App can call OData endpoints using the same AAD token flow that D365 uses internally — no application registrations, no client secrets in your connection strings.

Setting it up

1. Enable System-assigned identity

In the Logic App resource → Identity → System assigned → toggle to On. Note the Object ID that appears — you'll need it.

2. Grant access in D365 F&O

Navigate to System administration → Azure Active Directory applications and add a new record:

| Field | Value | |---|---| | Client ID | The Object ID from step 1 | | Name | Logic App — [your app name] | | User ID | A dedicated service account with appropriate roles |

3. Call the OData API using HTTP + Managed Identity

In your Logic App, use the HTTP action (not the D365 connector — it doesn't support Managed Identity). Configure it as follows:

{
  "method": "GET",
  "uri": "https://YOUR_D365_INSTANCE.operations.dynamics.com/data/Customers",
  "authentication": {
    "type": "ManagedServiceIdentity",
    "audience": "https://YOUR_D365_INSTANCE.operations.dynamics.com"
  }
}

The audience must match your D365 instance URL exactly — trailing slash matters and will cause a 401 if wrong.

Handling pagination

D365 OData responses are paginated at 10,000 records by default. The response includes an @odata.nextLink property when more pages exist. Handle this with a Until loop in Logic Apps:

1. Initialize a variable nextLink to your initial URL
2. Loop until nextLink is empty
3. In each iteration, call the URL in nextLink
4. Update nextLink from @odata.nextLink in the response (empty string if absent)
5. Process the value array from each page

Error handling patterns

Logic Apps have a useful but easy-to-miss feature: run after configuration on actions. Set your error-handling action to run after the HTTP call with status Failed, TimedOut, or Skipped, and you get structured error handling without try/catch complexity.

For D365 specifically, watch for:

• 401 Unauthorized: usually an audience mismatch or the MI not granted in D365 AAD apps
• 429 Too Many Requests: D365 OData has throttling limits — add a delay and retry
• 503 Service Unavailable: D365 maintenance windows; use exponential backoff

Secrets that do need Key Vault

Managed Identity handles the D365 authentication beautifully, but you'll still have other secrets — webhook signing keys, third-party API keys, SFTP passwords. For these, wire up Key Vault using the same Managed Identity:

Grant the Logic App's MI the Key Vault Secrets User role on your Key Vault, then retrieve secrets inline with the Key Vault connector using Managed Identity authentication. No credentials anywhere.

The combination of Managed Identity for D365 OData calls and Key Vault for remaining secrets gives you a zero-credential integration architecture. If you're migrating existing Logic Apps with stored credentials or building a new integration layer against D365, this pattern is worth the initial setup investment.