Logic Apps Standard managed identity connectors is a practical implementation topic for integration teams that need secure, observable delivery rather than a proof of concept. Secrets in a workflow connection are easy to create and hard to own. A managed identity changes the question from who knows the credential to which workload is allowed to act. This guide uses that model to connect a Logic Apps Standard workflow to an Entra-protected Azure resource without placing a password, client secret or connection string in the workflow definition.

Scope

This guide covers the technical implementation, the control points and the operational handover. Before building, name the system owner, the support owner, the business identifier and the expected failure route. Without those four items, the integration is not ready for production.

Step-by-step implementation

• Decide whether the app needs a system-assigned identity, which follows the lifecycle of the Logic Apps Standard app, or a user-assigned identity, which can be shared deliberately by multiple workloads. Do not choose sharing merely to reduce the number of identities; use it when the shared operational ownership is real.
• Enable the identity on the Logic Apps Standard resource. Then grant the smallest Azure RBAC role, or the data-plane permission, at the narrowest resource scope that lets the workflow perform its exact action. Management-plane Contributor is almost never the answer for a connector that reads or sends data.
• Create or update the connector connection in a way that explicitly selects managed identity. Keep the connection resource, workflow and role assignments in infrastructure-as-code so a new environment has the same security posture as the first one.
• Deploy to a non-production environment and run a real action, not only a connection test. Verify the identity in Azure sign-in or diagnostic evidence, verify the target audit trail, and deliberately remove a required permission to prove that failure is understandable.

Technical choices

Version the contract, configuration and deployment artefacts together. Pass one correlation identifier from the originating business event through every boundary. Azure logs, Boomi logs and the target-system record must be searchable on that identifier.

Separate temporary platform failures from invalid data and access failures. Do not retry a document that is structurally wrong or unauthorised. Send it to a visible exception route, assign an owner and record the repair action.

Release one controlled slice first. Test the expected load, a dependency timeout, a permission failure, duplicate delivery, rollback and restart recovery. Record the result in the runbook. One successful manual test is not release evidence.

Operations

Before production, walk through one message with the developer, support owner and business owner. At each boundary record the evidence, expected response time, responsible person and recovery action. This is the minimum operational handover.

Monitor the customer result, not only the platform. A successful connector call does not prove that an order was accepted or a customer was updated. Use a small reconciliation check where the target system cannot provide that confirmation directly.

Test routine changes: rotate an identity, deploy a compatible contract change, restore the previous release and repair an invalid message using the documented procedure. If a step needs tribal knowledge, automate or document it before the next release.

Risks and controls

• A successful deployment can hide an over-privileged role assignment. Review the action the connector performs and look for a data-plane role that is narrower than a general resource role.
• Identity does not solve network reachability. Private endpoints, DNS, firewall rules and outbound routing remain part of the connection design.
• A user-assigned identity can survive an app replacement. That is useful only when its lifecycle and access review have a named owner.

Production checklist

• Named product and operational owner confirmed.
• Least-privilege identity and network path verified in every environment.
• Correlation, metrics and failure evidence are searchable.
• Invalid, duplicate and dependency-outage cases have been tested.
• Rollback and repair steps are written before go-live.

Frequently asked questions

Can I start with a proof of concept?

Yes, but write down which parts are deliberately temporary. A production release needs the same essentials: identity, network route, contract version, monitoring, failure ownership and deployment evidence. Converting an undocumented proof of concept under time pressure is where most integration risk appears.

Where does Boomi fit in?

Boomi can own application connectivity, mapping and process orchestration where that is its strength, while Azure owns the cloud-native boundary and operational services described here. The important rule is that every responsibility has one primary owner and that correlation and recovery cross the platform boundary.

What should I monitor?

Measure completed business outcomes, end-to-end latency, failure rate by category, queue or workflow age, retry volume and unresolved exceptions. Platform availability alone does not show whether an order, customer update or service notification actually reached a correct result.

Source and next step

This independent guide was prompted by an update in the Azure Integration Services Blog. Apply the approach first to one owned integration, capture the evidence, then use that release pattern for the next flow.