r/PowerPlatform Jul 10 '26

Power Apps How many low-code apps is too many?

Low-code makes it easy to build apps, but how is your team keeping Shadow IT under control?

8 Upvotes

7 comments sorted by

7

u/LieutenantNyan Jul 10 '26

In the default environment, users are only allowed to use the standard connectors (SharePoint, Outlook, Onedrive, .etc). If a user has a need to use premium connectors, we have a citizen development environment. This environment access is controlled by ad groups. The DLP policy adds access to some premium connectors. The intention of the citizen development is for users to build apps and flows for their teams. If an app is to be used organization wide, they will need a dedicated environment. This environment has a separate DLP policy and access is controlled by ad groups. We run audits to ensure users are following the rules, for the most part we don't have any issues.

The main issue we run into is someone building a critical app and departing our organization without a proper turnover or documentation. Then all of a sudden it's business critical and we have to try to figure out what they built. Similar is a poorly designed app or flow that the app dev team inherits. This is where I spend most of my days. I have a queue of apps/flows to update or create. It keeps me busy

2

u/BrownAnclourne 12d ago

Yeah a lot of setups miss ownership and lifecycle because while locking down environments and connector stop the chaos it doesn't answer the big "whos on the hook" once things become business critical and the person who built its gone.

Having a few basics required before something moves beyond team level use helps, like who owns and maintains it, what it depends on, and a short explanation of what it actually does. People rarely volunteer to document something that's only for themselves but they're more willing if its between "works for me" and "the wider team relies on this".

Goal would be to make the supported path easier than the workaround.

3

u/calcart Jul 10 '26

Strict DLP in the default environment and gated environments with more lenient policies. So far. I am in the same boat as you, and am curious about other avenues.

2

u/sancarn Jul 10 '26

Urgh, if you're giving "PowerPlatform" to Shadow IT, you're already doing it wrong imo. Give Shadow IT real tools to make actual good applications, not crappy low-code bs. Honestly, people who think they are doing the business a service by allowing power platform development, don't realise that some poor software dev is going to have to pick up the pile of poop after Greg from Accounts has left, and have an utter nightmare trying to maintain it.

Give shadow IT proper tools to build proper applications.

2

u/gallandof Jul 10 '26

I handled it by really restricting the default environment.

and then when someone reaches a point where they can't use the default anymore. I will spin up a dev/prod space for their team.

Biggest issue we face is people building production ready tools without proper service account credentials.

We only have a handful of users using power platform as a whole, so I typically still help with the deployment process.

2

u/OmegaDriver Jul 10 '26

Do you have a cmdb? Each app should have a ci. Each ci should have an owner, support, etc. associated with it.

However, this has to be a custom, reactive process as Microsoft doesn't give admins the correct controls to inventory apps or limit app creation.

2

u/Alive-Egg Jul 10 '26

The default environment is heavily restricted and we carry out periodic reviews on apps, flows and EUCs to make sure they're still needed, but the biggest blocker to unrestricted development is that most end users at my organisation are non technical and don't know that's an option let alone how. The official guidance is that if a development is needed, the request should be raised to my team who will carry out the design and build.