I finally get to delete my Logic App Standard managed identity workaround, and honestly, that is a good thing.
Back in 2024, I wrote about the awkward dance required to build Logic App Standard workflows locally while still using managed identities once deployed to Azure. It worked, but it always felt like a workaround pretending to be a pattern.
TL;DR
The old dual-connection workaround for local Logic App Standard development was useful, but it should no longer be your default pattern.
The Visual Studio Code experience has matured enough that managed identity authentication after deployment can now be treated as the normal path, rather than the exception. In this post, I’ll cover what changed, what you can delete and where I would still be careful before removing existing configuration.
The original problem was never really managed identities
The original problem was a mismatch.
We wanted managed identities everywhere. Security teams wanted managed identities everywhere. Microsoft recommended managed identities everywhere.
Except locally.
That was the annoying part. The production authentication model and local development experience did not align cleanly, so we had to choose: compromise locally or create a workaround that kept production clean.
What we were solving back in 2024
In 2024, the goal was straightforward.
I wanted Logic App Standard workflows to use managed identities and role-based access control once deployed, without leaving connection strings floating around in Azure. At the same time, developers still needed a practical way to build and test those workflows locally.
The dual-connection pattern bridged that gap, but it also introduced configuration that existed largely because the tooling had not yet caught up.
Why the workaround always felt a bit wrong
Every workaround adds a small amount of drag. Not enough to hurt on day one, but enough that six months later someone asks why the project has multiple connection files and nobody remembers the original reason.
The old pattern introduced extra moving parts: duplicate connection configuration, local-only conventions, deployment assumptions and documentation that existed purely to explain a tooling limitation.
That is exactly the kind of complexity I am always happy to remove.
What changed
Microsoft has continued improving the Logic App Standard development experience in Visual Studio Code.
The current Microsoft Learn guidance for creating Standard workflows in Visual Studio Code documents a more mature local development and deployment experience. Developers can authenticate a connection during local authoring, while the deployed workflow can authenticate at runtime using its automatically enabled system-assigned managed identity.
Microsoft also provides detailed guidance on authenticating Logic App connections using managed identities, including supported connectors, identity types and role requirements.
The best workaround is the one you eventually delete.
What I would remove from new projects
If I were starting a new Logic App Standard project today, I would not automatically copy the dual-connection file pattern from my 2024 post.
I would begin with the current Visual Studio Code approach, confirm that the required connectors support managed identity authentication and validate the runtime behaviour after deployment. I would only add extra configuration if the project genuinely needed it.
In other words, do not cargo-cult the workaround. Use the simpler path unless the project proves it needs something else.
Should you rip out the old pattern?
Probably, but not as a Friday afternoon clean-up job.
If you have mature Logic App Standard projects already running happily in production, review them properly before removing anything. I would check:
- Whether deployment pipelines rely on the old file-swapping behaviour
- Whether developers still need local-only settings for specific connectors
- Whether each required connector supports the intended managed identity configuration
- Whether RBAC assignments are documented and repeatable
- Whether scoped, PIM-enabled groups could support day-to-day development access
- Whether onboarding material still tells people to use the old approach
- Whether any connection string-based artefacts can now be removed safely
I would also validate the complete deployment and authentication path in a non-production environment before changing a working production configuration.
Closing thoughts
Every now and then, a platform improvement arrives that lets you delete code rather than write more of it.
This is one of those moments.
The workaround from 2024 served its purpose. It helped teams keep production secure while the local development tooling was still catching up.
But patterns should evolve when the platform evolves. If you are starting fresh, do not reach for the workaround first. Start with the simpler model, validate it properly and only add complexity when the project genuinely earns it.
