Restrict creation of new Power Platform environments to admins only

A person buried under a pile of boxes

Note: This post applies to traditional environments, not Dataverse for Teams environments. Thanks to Loryan Strant for adding that clarification.

As long as someone in your organization is on a Power Apps or Power Automate per-user plan, they may have permission to create their own environment (unless you’ve already limited it previously in your organization). These environments can be used and shared by Dynamics 365, Power Apps portals and apps, and Power Automate flows. Environments can house multiple Dataverse tables (which can also be provisioned by a power user with appropriate licensing). Power Platform apps and Dynamics 365 can then connect to, read from, and write to these tables which would likely be shared across multiple applications/processes.

For example, if Megan Bowen is licensed on a Power Apps per-user plan she would, by default, be able to create new environments as she wished. And with the right training and deployed best practices, this may not be an issue. But if training isn’t provided and users are creating environments left and right, it may be time to limit who can create them (regardless of their licensing) until proper training and governance can be deployed.

So if you wish to manage environments centrally and prevent environment sprawl, you will want to limit the ability of users in your organization so they can’t create their own environments. Doing this may slow their individual productivity, but could also prevent duplicated efforts, inconsistent data organizationally, scattered naming conventions, and more. As long as you replace this restriction with a formal and effective governance policy, request form, etc. it will minimize disruption to your colleagues’ productivity.

Ready to do this? Let’s go over the steps to limit Microsoft Power Platform environment creation and management.

Limit new environment creation via the Power Platform admin center

As a Power Platform admin, sign in to the Power Platform admin center.

Choose the Settings gear in the upper right corner and choose Power Platform settings.

Click to enlarge

Then change Who can create production and sandbox environments to Only specific admins. As seen in the tooltip in the following screenshot, this limits creation to:

  • Global admins
  • Dynamics 365 service admins
  • Power Platform service admins and
  • Delegated admins

Click Save and you’re finished!

Note that this doesn’t remove existing environments or limit the abilities of their creator(s) to continue managing pre-existing environments. This setting will only apply to new environments and prevent additional unwanted sprawl.

Prefer to restrict environment creation and management via PowerShell? Check out this documentation.

Restrict who can install on-premises data gateways for the Power Platform

Data gateways allow users to connect online services, such as Power BI service, Power Automate, and Power Apps to on-prem data sources such as SQL databases, SharePoint server lists and libraries, and network shares.

As you can imagine, you wouldn’t want everyone installing their own individual gateways throughout your organization. Managing and sharing those centrally is much more efficient (and secure). You can manage who is allowed via the Power Platform admin center at admin.powerplatform.microsoft.com.

Note: You must be one of these roles to restrict gateway installers:

  • Azure AD Global administrator
  • Office 365 Global admin
  • Power BI service administrator

Restricting installations does not impact gateway administration. You can assign and re-assign users to administer and use gateways at any time. The following steps are strictly to manage who is able to install an enterprise gateway on a machine.

1. Go to the Power Platform admin center

2. Click “Data gateways”

3. Click “Manage gateway installers”

4. Toggle “On” the Restrict users in your organization from installing gateways

Click to enlarge

5. Add authorized users.

In just a few clicks, you’ve enabled better management of enterprise access to on-premises data sources for scheduled data refreshes, apps, and flows.

Click to enlarge

Show/hide fields conditionally in PowerApps forms based on dropdown selection

I’m working on digitizing a form to improve the user experience and our data collection and availability efforts. I decided to do this one in PowerApps as we begin to pivot organizationally toward the modern experience.

During building this particular form, I needed to hide fields unless the user indicated “Yes” to corresponding dropdown fields. Here’s the end-result:

Click to enlarge

To get this to work we have to do three steps:

  1. Initialize variables for visibility
  2. Set the conditional fields’ visibility to the new variables
  3. Set the dropdown to toggle the related variable

Initialize variables for visibility

First we need to tell our app that we’ll be using true/false variables to indicate the visibility of our conditional fields. We do this from the OnVisible property (2) of the Form Screen (1).

Click to enlarge

The formula itself should be as follows (3). Use a semi-colon between each UpdateContext function to add additional variables. I’m using aVisible, bVisible, etc.

UpdateContext({aVisible: false});UpdateContext({bVisible: false});UpdateContext({cVisible: false})

So in your documentation you might note something like:

VariableDefault stateChanged byHides/Shows
aVisiblefalse (hidden)BAARequired
(dropdown)
BAAEffectiveDate
bVisiblefalse (hidden)ConflictsOfInterest
(dropdown)
Conflicts…Completed
cVisiblefalse (hidden)DataSecurityRisk
(dropdown)
DataSec…Completed

Note: You can use the same variable more than once to show/hide multiple fields based on one dropdown.

Set the conditional fields’ visibility to the new variables

Now we need to assign these variables to the DataCards for each field we wish to hide.

From the Tree View panel, select the DataCard (not the DataCardValue within/beneath it) for the field you wish to hide (1). Then go to its Visible property (2). Finally, set the property’s function to the variable you initialized for it (3). In this example I decided I would use “cVisible” for “DataSecurityRiskCompleted”.

Click to enlarge

Repeat the steps above, assigning variables to each field you want to hide until a dropdown is changed to the triggering value.

Set the dropdown to toggle the related variable

The last step is to tell the variables we established to change based on a dropdown.

First select the DataCardValue (not the DataCard) within the data card (1).

Then select the OnChange property (2) and set the function to the following (3):

Switch(DataCardValue46.Selected.Value,"Yes",UpdateContext({cVisible: true}),UpdateContext({cVisible: false}))
Click to enlarge

Repeat for each dropdown that should serve as a trigger for conditional fields. Now, when I publish my app, changing “Data Security Risk” to “Yes” will change the default false visibility of DataSecurityRiskCompleted to true. If I change the dropdown to “No” again, it will hide the related field again.

Intro to conditional formatting & rules/validation when customizing SharePoint new item forms with PowerApps in Office 365

2018-01-13_17-23-37.gif
This post will introduce you to some basic conditional formatting, rules & validation ideas you can implement today in your customized SharePoint forms using PowerApps. And don’t worry – if you start making changes to your form and don’t want to keep them, you can easily switch back to the original SharePoint form.

Continue reading “Intro to conditional formatting & rules/validation when customizing SharePoint new item forms with PowerApps in Office 365”

Reverting to default SharePoint new item form instead of PowerApps custom form

Maybe you’ve made a PowerApps customized form but want to switch back to the original SharePoint new item form. Here’s how:

Continue reading “Reverting to default SharePoint new item form instead of PowerApps custom form”