This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(201.6, 52%, 29%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECF%3C/text%3E%3C/svg%3E)
I have been developing Logic Apps workflows which incorporates Key Vault, Database, Outlook, and so forth which some of the connectors are using managed identities. In the Azure Portal Designer all works perfectly fine, but when using Visual Studio Code managed identities is a problem. This is a known issue and documented, so the question is how many are truly developing in Visual Studio Code and how is the flows which need certain connectors like Key Vault or Database are handled. I don't see how this works without jumping through vast hoops that would impact the "day of the developer's life" to the point Logic Apps is not viable. If a developer can't easily develop in Visual Studio Code in order to comply with CI/CD then they are likely to find alternatives.
An Azure service that automates the access and use of data across clouds without writing code.
Thank you for the response. Since we have strict security policies using connection strings is not viable. We already use parameterize for our database and there is no desire for creating duplicate workflows. There should be no reason to do this. As for the DB the security policy is very strict so using MFA locally is looked down upon. How many others out there have encountered the same issue or is the suggestion Siddhesh is stating the path taken by most?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(19.2, 14.000000000000002%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESD%3C/text%3E%3C/svg%3E)
I understand if there are strict security policies, You can test your development in another logic app in another subscription as well that is your rnd or nonprod subscription or Logic app and then push the changes to the Prod Logic app.
Most devs i’ve worked with don’t fight mi in vscode at all. the local runtime just can’t replay those chained auth hops the portal hides. we shape the flow with light stubs, then let a tiny sandbox run the real mi path so ci/cd stays clean and no one loses a whole day to tooling.
so the stubs are created in the portal designer? not sure how this flows with the ci/cd. any chance you could provide a high level on this. So, if I have a workflow which needs to pull information from a database which the API Connections is configured using MI, what are you doing to overcome this issue in VSC?
Do the devs create their workflows in VSC and if so how are they adding the actions where MI is involved when the workflow is deployed to the azure logic apps resource? can you expand on the light stubs? I assume you are referring to the unit test template.
It would be good if Microsoft allowed the ability to disable certain actions (pathways) and still be part of the flow. Other alternatives is to have duplicate actions with one being MI and the other being OAuth, but that is a bad design.
“light stubs” I just meant tiny local mocks. nothin in the portal, sry. in VSC we keep the real MI actions in the JSON, but swap the MI auth hop w/ a no‑op mock so the local runtime doesn’t break and CI/CD still ships the real MI path. if I’m off, sorry. wish this help
We are configured with multiple subscriptions dedicated to development, QA, and production environments. I have an alternative solution, which—while not ideal, as it may inconvenience developers—is less intrusive and still maintains all required security policies. It will also support the existing CI/CD pipeline.
Proposed high level alternative:
It would be nice if Microsoft followed similar products like Mulesoft AnyPoint, Software AG webMethods, and others which are more developer friendly. Using Logic Apps seems to require many hoops and even the CI/CD is unnecessarily complex in my opinion.
Thank you for reaching out to Microsoft Q&A.
Managed Identities will only work via Azure resource as it is a system assigned or user assigned identity.
For local development using Visual Studio Code, You can use your Azure user account to for authenticating with the connector and add your user account in Key vault access policy or Provide Key vault administrator rbac roles, For database you can use Connection string or Microsoft Entra MFA login locally.
You can create separate workflow for local development and managed identity workflow for Prod related Azure development and parameterize it to change.
You can test your development in another logic app in another subscription as well that is your rnd or nonprod subscription or Logic app and then push the changes to the Prod Logic app.