Restrict users from creating PowerApps in default environment

[sayatan]

As it has been described in the Environments Overview article, "Whenever a new user signs up for PowerApps, they are automatically added to the Maker role of the default environment". Which gives all the users the authority to create apps in this default environment and the admin literally has no way to restrict users from doing so. Which can be a nightmare in bigger enterprises from governance prespective.

Like in all other environments,the admin should have power to grant or restrict users App Maker role in default environment as well.

[Hayes3d]

For all of the IT people who want to block the business, I would have to ask, what is the issue with allowing people to create a custom PowerApp for a SharePoint list? If the business has to constantly ask permission from IT to do things, they will go completely around it. Now you have to be reactive to Shadow IT which you would have no idea is happening.

Also, once they get access...now they can create as many "apps" as they want. You can't limit them, how will you manage that in a year or 3? So instead of always saying "No", find out how to say "Yes, but let me show you the ropes" and have governance around the tool. Going to need that anyways to ensure your organization stays within the rails of what you would allow.

You also state that users would get annoyed if their app is turned off due to governance. So they have to go through your red tape, get access to create, they create their app. Oh, now they want to create another one, now more complex. So they create that one; and another; and another; wow they are on a roll. They are sharing their apps with everyone. Without governance in place to shut those off...you will soon have the wild-west. You can't give them access to just create a single app. So now you have to use the governance app anyways to enforce your policies...

Empower your users, don't block them from something they may find passionate and may find solutions to business problems that create value for your organization.

[ryanrussell9]

Hello @Hayes3d, 

The issue at hand is not about blocking everyone outside of IT from creating Power Apps. The issue, there is no differentiating factor between someone who creates an app and someone who will just use 'play' an app in the default environment. All Power App licences users have the same security role.If everyone is a developer and can share their own version of an app, would this really add or prohibit value?

Think of it this way, would you want everyone in the accounting department to create there own version of a expense reporting app or have people in the accounting department identified as a developer(s) or user(s) working together to create one version of the expense reporting app? The former is the default environment (wild wild west) and the latter is any other environment with specific security roles (Environment Maker, Common Data Service User, etc..). Citizen development makes total sense, but everyone is not meant or should be a citizen developer. 

[Hayes3d]

You seem to have the idea that everyone wants to be a citizen developer, that is not the case. So you won't have everyone in accounting creating the same app. Only a few who have the capable mindset of developing one. We have an organization of 38,000 people and we have it open to all. How many people have created apps? 49 people in 2 years. You are trying to create security and policies based on assumptions, not real world metrics.

Some people create test apps, but using the governance solution it identifies apps that are not in use and will archive them automatically via automation. The apps that are actually shared with more than 15 users or 1 AD group (or whatever other governance you determine is needed) are locked so that you an determine if the app is business critical or just for a few people to leverage occasionally. If business critical, you move it into that secured environment.

If you really want to have a successful Power Platform:

• Use the open environment for people to test or create an environment called "SandBox" and allow everyone to be a maker there. Tell people to only use that environment. If someone creates something elsewhere, ask them to move it. They learn quick.
• Install the COE and setup the automation for governance and policies.
• Create a centralized team to create, evangelize, demonstrate wins using the Power Platform
• When you have a business critical app, which most likely needs 24/7 support, move it to a centralized dev/qa/prod environments that you own. They can leverage dev, you control QA and Prod.

To succeed with innovation, you need to be first to market. The business knows the market and what they need. Let them try.

[tharford]

I am one of those 'citizen developers' and would still advocate having the ability to control who has Makers rights on ALL Environments. Nobody wants to prevent innovation or creativity.

There is a fear that things will get out of control if we enable (our already paid for) PowerApps licenses to the whole organisation. That might be irrational and not based on any study of the actual potential impact, but it is real - I am being prevented from sharing a very useful App because we misunderstood that doing so would enable all users to create Apps in the Default Env.

Large and mature organisations have the infrastructure to be able to put groups in place to manage content, develop policy and monitor compliance. Not everyone can. Allowing Admin to scale up Maker rights across the organisation would allow users like me to deliver some benefit whilst the organisation as a whole learns. 

The end point should (could) very well be the same (all users creating Apps with Policy to control etc) but the route to get there is blocked at the moment.

[Hayes3d]

I don't disagree, I'm not going to give the ability to my entire organization to be a "Maker" on all environments. They just have access to the default environment for the majority of their testing.

I created other environments for different departments with QA and Prod. Those are managed environments by their department SME for the Power Platform. That way there is consistency for their users. I generate reports for them weekly, via automation, into who is creating what in their environments and the default environment by department. The COE captures that info based of the AD User!!! (really awesome)

And while we have 38,000 people in my org, I am the only one managing the entire PowerApps platform. It can be done. On top of that, I am developing multiple apps and I am also Tier 3 support for the O365 Team. So I am stretched and this year I will be expanding a bit with others taking on some of the support. But the COE tool that Microsoft developed with the community is what makes that happen. And again, I am the only one currently in that tool. It's possible for you to do as well, but it has a steep learning curve to understand all that it has to offer. I installed it over the weekend.

What is interesting is the "fear" of the citizen developer is exactly what my director said as well. My response to that is, I have been working with SharePoint for over 13 years. During that time, at 4 different organizations, I have seen a lot and had to support things I did not develop: InfoPath forms, SharePoint Designer workflows, Access Databases, Excel macros, Nintex Forms, Nintex workflows, custom search configuration centers, custom SharePoint sites and webparts, you name it. That was my experience with "citizen developers" and it was everywhere, business critical, and no insight into any of it happening. Just constant reaction when something broke. So this "new" citizen developer is not really new...The difference is using the COE I have visibility to all of it, so I can setup policies and automation to manage it before something breaks that is business critical and I get a call at 2 am because someone's stuff broke that they developed.

Maybe what is needed, is an overview of the COE and then possibly address any of your concerns? You can then take that to management and have discussions with them to alleviate their apprehension? If there is enough interest, I could talk to some contacts at Microsoft to see if they would create an online video for this. Or if just a few people I could setup an online meeting after my work hours (3pm CST) and we could discuss? I can't show our environment, so I might have to create a test environment and it would take me a bit to setup, but I could get it done over the next couple of weeks. 

[NewcombR]

The problem here is that the default environment isn’t contained. You can do the best practices for ALM all day long, using separate environments for Dev, Test, QA, and Production. Users in those environments can be locked down... sure.  But nothing stops the user from making an app in the default environment that conflicts with the production line apps.

Consider CDS. 

Let’s say you have a critical business application on a production CDS environment.  It has go line through rigorous business analysis, testing and is in daily use in production by thousands of users.

A “citizen developer” decided he wants to do something like create a Flow or a Power App in the default environment that connects to the production environment where he or she is a user.  Let’s say it causes a critical issue in the production environment.

a) where do you troubleshoot?  You might spend hours looking over the actual solution that was developed..,. And cant find anything because the problem is in the default environment,  not the production environment.

b). If you do isolate where the problem occurred in the default environment, how do you stop the user from doing it again?  You can’t revoke their ability to create apps or flows in the default environment.  You can’t revoke their license because the user has to use the mission critical business app in production.

[Anonymous]

@Hayes3d  "But the COE tool that Microsoft developed with the community is what makes that happen. And again, I am the only one currently in that tool. It's possible for you to do as well, but it has a steep learning curve to understand all that it has to offer. "

Quick comment on the CoE tool. Any modifications to the CoE tool have to be exported / imported and then customized.  The solution is read-only.  This allows for the easy update of the Core components.  The problem with this is you are inherently creating technical debt you have to maintain. In addition, organizations that are single threaded with administration of their Power Platform should reconsider the amount of risk exposure they're comfortable with. Depending on the connectors in DLP policies, how security is configured, there can be serious risk of exposure to proprietary data.

[Hayes3d]

I do have to partially agree with @Anonymous , the COE solution is a managed solution. That means that it can be installed and you cannot make many modifications to it other than what is allowed via properties, data in the CDS, etc. When an newer version is deployed, you can easily upgrade it without needing to do any regression testing. This is what I would call the "Easy Button".

Every organization does this, they purchase software to solve an issue rather than create it from scratch.

But, you can modify the COE solution a few ways. If it is managed, you can take the Flows and duplicate them, modify them, whatever you need to do. But when a new version comes out you may have to upgrade the solution, duplicate the flow again and make changes as necessary. Option #2, which I would not recommend unless you have an experienced team to make all of the changes, deploy it as an unmanaged solution and keep it updated manually. Can be much more time consuming but you have greater flexibility.

I would also keep in mind, the COE solution takes input for new features so you don't have to make changes if the requirements are more general in nature and not super specific.

Regarding security, exposing proprietary data is easy a multitude of ways and not specific to just the Power Platform. DLP policies are helpful, but restricting access to the data appropriately is the proper way to secure the data. Also categorizing the data, auditing data, encryption, etc...so many other things should be in place. This is not new. Security is a concern for every organization and a specific group in each organization should be setting policies, guidelines, best practices.