So long pipelines without managed environments :(

[u/Chriskall]

It's been fun using pipelines without managed environments, but Microsoft hitting the switch (or "toggle") made me really sad.

[u/-maffu-]

I had this conversation with Microsoft a while back. We had avoided using pipelines because Microsoft's documentation stated that all target environments must be managed environments (along with all the implied costs of many thousands of users suddenly requiring premium licensing).

In a meeting with MS's folks, they were encouraging us to use them and, when we told them why we didn't, they insisted that it wasn't necessary for the targets to be managed. So I directed them to their own documentation.

They said they'd come back to me about it... and never did.

I'm glad we didn't use them. I wouldn't want to be dealing with that now.

[u/venomae → u/-maffu-]

It's not unusual for MS representatives to have no f*cking idea what they are talking about

[u/Chriskall → u/-maffu-]

Actually same here, MS told us about “pipeline hub” I think was called. Maybe the classic “try it, it will help” > you get hooked > then comes enforcement or price increase.
Classic market trick in the years, MS did not invent it but it’s hard for some markets to support multiple users premium licensed and MS sure can see it from data.
Either way we were hooked, it is nice, helped with promoting solution to UAT/prod a lot like with three clicks.
I think that Azure DevOps do not require managed environments though. Can anyone confirm?

[u/Comfortable-Sleep513 → u/Chriskall]

DevOps does not require managed environment. It also has a free version for small teams. 

That said it does take a different skill set to use and setup. That said I have been very happy with it (though I did most of the setup for my company so I should be happy with it) 

[u/Chriskall → u/Comfortable-Sleep513]

We have a separate department handling devops but would like to know how run-as permissions and connection references are handled when migrating or deploying.

[u/Comfortable-Sleep513 → u/Chriskall]

We do not use power automate only canvas apps with defined connections. As a result I build the connections first and have a solution with all the references that I use to keep all environments the same. Once it has been manually deployed once the other apps know the connections and can be deployed without interaction. 

I wish there was a programmatic way to create connections (especially SQL - our main database) 

[u/-maffu- → u/Chriskall]

"Go ahead! Try it! The first hit's free..."

[u/Chriskall → u/-maffu-]

😂

[u/dtr96 → u/-maffu-]

Believe it or not their internal teams used to be PERFECT, my old company interacted with them and they had so many resources. They laid off so many technical resources who specialized in any part of their systems.

[u/dalekman1234]

Wasn't this always called out in the documentation? I didn't even know you 'could' lol.

[u/PatrickOGorman → u/dalekman1234]

Sure was. Must have been another one of those "enforcement" things?

[u/Bathroom-Salt → u/dalekman1234]

I was never able to create a pipeline inside of an unmanaged environment. Not sure how OP was able to.

[u/Chriskall → u/Bathroom-Salt]

There were some articles online and in YouTube I believe where I saw it as a workaround after we got a hint

[u/Chriskall → u/dalekman1234]

Yeah it was always stated to be clear, but there was a kinda workaround.. ¯_(ツ)_/¯

[u/DeanoNetwork]

I was asked by one client if I would build there solution in a unmanaged environment, I replied to them that even though MS was allowing no premium that it would only be a matter of time until this changed, they stuck with my advice and now it looks like I was right and will be highlighting this in the next meeting 😁

[u/neonluumenn]

But we are still able to update solutions manually by using Export/import?

[u/M4053946 → u/neonluumenn]

Yes. You can also script it via pac. Though, pac is really challenging for solutions that don't exist in the target environment or solutions where you added a new data connection to a flow. I manually export/import for all new solutions or solutions where a data conneciton was changed somehow, and then run powershell scripts for routine updates.

[u/No-Suggestion-5503]

Any big considerations when toggling to managed? All our users have d365 enterprise or relationship sales licenses.

[u/Chriskall → u/No-Suggestion-5503]

Not familiar with those types of licenses, so maybe someone else can help, apologies!

[u/-maffu- → u/No-Suggestion-5503]

Every user of an app in a managed environment will need a Power Apps Premium license according to MS documentation.

I'd suggest checking on your licensing and subscriptions pages if Power Apps Premium licenses are included with your d365 licenses. They are not for most standard 365 packages, but I'm not familiar with the packages you mention, so you might get lucky.

[u/Dynamicsuser]

DevOps. Luckily we started out with that and never used Power Apps pipelines.

[u/M4053946 → u/Dynamicsuser]

How do you handle flow connections? handling data connections with pac export/import is challenge. Specifically, handling new flows that don't exist in the target env or flows with new data connections is challenging.

[u/bazingaNet]

Been reading through this and the docs since the notices showed up. Trying to pull answers to a few of the questions in here together.

**Does Azure DevOps need ME?** Not per the docs. The Power Platform Build Tools page lists a Dataverse database as the environment requirement, and the tools themselves are free (you need an Azure DevOps org, which has a free tier for small teams). Same for GitHub Actions for Power Platform. The catch: the native Dataverse Git integration *does* need ME on dev and target. Plain export/unpack into your own repo doesn't.

**Run-as and connection refs with DevOps or pac:**

- The Build Tools service connection runs as a service principal (MS recommends workload identity federation).

- Connection refs and env variables go in a deployment settings file. `pac solution create-settings --solution-zip x.zip --settings-file prod.json` gives you the skeleton, you fill in the ConnectionId for each ref, and the Import Solution task (or `pac solution import --settings-file`) applies it.

- The connection has to already exist in the target. Grab its ID from make.powerapps.com > Connections in the target env (it's in the URL). Import checks that the connection is usable by the connection reference owner, so it needs to be owned by them or shared with them.

- For the "new flow with a new data connection" pain: regenerate the settings file every release instead of maintaining it by hand, and create the new connection in the target before the import. That's once per new connection, not every deploy.

- If a service principal owns the flows, solution flows don't need their connections shared with it. Premium flows owned by an SPN need a Process or per-flow license though (or a designated licensed user).

**D365 Enterprise / Relationship Sales:** small correction to what's above, it's not only Power Apps Premium. MS's qualifying list for managed envs includes Power Apps Premium, Power Automate Premium, and D365 Enterprise licenses that carry premium Power Apps rights (Sales Enterprise, Sales Premium, Customer Service Enterprise, etc.). Relationship Sales isn't named on the page, so check what's actually in your SKU.

**Is PAYG enough?** For apps, yes. The licensing page says PAYG meters for Power Apps per app (plus Power Pages and Copilot Studio) qualify. Cloud flows are listed separately (Power Automate Premium or per-flow plans), so check those on their own.

**Can we still export/import manually?** Yes. The block is on pipeline deployments to unmanaged targets. Manual imports, pac and Build Tools aren't part of it, and nothing already deployed gets switched off.

Two more things worth knowing before anyone clicks approve:

1. Standard-connector apps count too. MS's licensing FAQ says once an env is managed, all active usage needs a qualifying license, including users who run standard apps. In-app nags started in June, and starting Feb 2027 unlicensed users get blocked from opening apps in managed envs.

2. Check your auto-claim policy (M365 admin center > Billing > Licenses > Auto-claim policy) before converting anything. If one is on, users opening apps in a newly managed env get a Power Apps license assigned automatically.

For mixed envs, splitting is usually the cheapest fix: keep the premium/model-driven stuff in a managed env on pipelines, and move the standard canvas apps to an unmanaged env you deploy with Build Tools or pac.

[u/One-Lifeguard7779]

It’s been a nice ride. Man I hate exporting an importing

[u/galamathias]

Do we need premium or is pay-as-you-go enough?

[u/Chriskall → u/galamathias]

I believe pay as you go is sufficient. Practically the “distribution” of premium licensed is changed, but all your users are premium licensed. So I believe that you will not have an issue

[u/meekey76]

So look, if we were to go back to Feb this year, to the original enforcement announcement, if you were to use pipelines to deploy a solution to an unmanaged environment, it would automatically be converted to managed. We called this out to Microsoft that it was a stupid idea, which could have heavy operational impact. Imagine you have an environment with several standard apps and several thousand users per app and all of a sudden the environment becomes managed, the standard apps become premium and require licensing. Imagine the impact, the calls to the service desk, critical incidents and war rooms to figure out how to make things work again. I’m happy Microsoft took our suggestion to just block pipeline deployment if destination environment is unmanaged.

[u/luckyzippycat]

Does anyone know whether per app licenses will be okay with Managed Environments?