Power Platform DLP Policies determine which data connectors can be used by apps & flows in an environment and which connectors are blocked. They are essential to put in place for every environment. DLP Policies prevent makers from accidentally exposing data to 3rd party services that should not have it. In this article I will share 8 Power Platform DLP Policy best practices and help you build a strategy to prevent data-leakage.

Table of Contents
1. Safeguard The Default Environment With A Restrictive DLP Policy
2. Set A Power Platform DLP Policy For Each New Environment
3. Fine-Tune Connector Endpoints And Actions
4. Use A Shared Power Platform DLP Policy For DEV-TEST-PROD Environments
5. Check Before Changing The DLP Policy For An Existing Environment
6. Create A Blanket Power Platform DLP Policy For The Entire Tenant
7. Update The Governance Error Message With An Admin Contact
8. Do Not Use Power Platform DLP Policy Resource Exemptions

1. Safeguard The Default Environment With A Restrictive DLP Policy

All users with a standard Power Apps/Power Automate license have access to the default environment with the Environment Maker role assigned. Many arrive at the default environment with no prior-training. They cannot be blocked from creating apps or flows so it is important to restrict their capabilities.

Move all non-blockable connectors to the business category.

Then move all blockable connectors to the blocked category.

Set the default group for the default environment to blocked. Any new connectors will automatically blocked unless they are non-blockable.

Apply the DLP Policy to only the default environment.

2. Set A Power Platform DLP Policy For Each New Environment

Every environment should have a DLP Policy in place before makers start to use it. When a new environment is requested, start by moving all non-blockable connectors to the business category. Then work with the environment owner to identify any additional connectors that are required (example: Salesforce, SQL Server, etc.) and move them to business as well. Move the remaining connectors to blocked.

Set the default group for the new environment to blocked.

3. Fine-Tune Connector Endpoints And Actions

All blockable connectors can specific actions blocked while allowing others. Others can also allow or deny specific endpoints. Consider limiting usage whenever moving a blockable connector into the business category.

In this example, the SQL Server connector is only allowed to access one endpoint. The idea of what an endpoint is differs for each connector (example: HTTP, Dataverse, Blob Storage, etc.).

Consider granting read-only access to a datasource using connector actions when users do not have a requirement to insert, update or delete data.

4. Use A Shared Power Platform DLP Policy For DEV-TEST-PROD Environments

New apps and flows should be created in a development environment. Then, they should undergo testing in a test environment and finally be released into a production environment. Include dev, test and prod environments in the same policy to ensure they are always subject to the same conditions.

5. Check Before Changing The DLP Policy For An Existing Environment

If a data policy changes after apps & flows have already been developed, it runs the risk of breaking them. The Power Platform Center Of Excellence Starter Kit includes a useful Power Apps app named DLP Editor. Run an impact analysis before switching the data policy to see which specific apps & flows will break. Then inform their creators and find a resolution.

6. Create A Blanket Power Platform DLP Policy For The Entire Tenant

A tenant-wide DLP Policy should be created for the sole purpose of blocking any potentially dangerous connectors in all environments. Do not be overly restrictive here. Blocking too many connectors at the tenant level will harm makers and make administration harder. Only block individual connectors on a case-by-case basis.

The blanket DLP policy will stack on top of the individual environment DLP policies. When one DLP Policy allows a connector and the other DLP Policy blocks a connector, the most restrictive policy wins.

Move all connectors to the business category.

Move individual connectors identified as risky into the blocked category.

Set the default group to business. Any new connectors added will automatically appear in the business category.

Choose add all environments when defining the scope.

7. Update The Governance Error Message With An Admin Contact

When a maker saves an app or flow that is not DLP Policy compliant they will receive a governance error message. Use PowerShell cmdlets to update the governance message and let makers know who they should contact to resolve the issue.

This PowerShell script was used to create the message above. Consider setting up a Microsoft Form and linking it in the governance message to collect requests for DLP Policy changes.

New-PowerAppDlpErrorSettings -TenantId 'TenantId' -ErrorSettings @{  
  ErrorMessageDetails = @{ 
    enabled = $True  
    url = "https://contoso.org/governanceMaterial" 
  } 
  ContactDetails= @{  
    enabled = $True 
    email = "admin@contoso.com" 
  } 
}

8. Do Not Use Power Platform DLP Policy Resource Exemptions

Apps and flow can be exempted from DLP Policies using these PowerShell cmdlets. Do not grant exemptions. If a resource requires a different DLP Policy consider moving it into another environment.

Questions?

If you have any questions or feedback about 8 Power Platform DLP Policy Best Practices please leave a message in the comments section below. You can post using your email address and are not required to create an account to join the discussion.

The post 8 Power Platform DLP Policy Best Practices appeared first on Matthew Devaney.

Setting up a Power Platform environment the wrong way can have serious consequences. This includes data-loss with no recovery from backups, lack of security that allows undesired users into the environment, and poor performance that hurts end-users efficiency. In this article I will show you how to properly setup

Table of Contents
1. Picking The Incorrect Region
2. Choosing The Wrong Environment Type
3. Forgetting To Enter An Environment URL
4. Failing To Apply A Security Group
5. Missing Security Roles Assignment To Users
6. Neglecting The Setup Of Data Policies
7. Delaying Applying Power Platform Licenses

1. Picking The Incorrect Region

You only have one chance to select the proper region. If you choose the wrong one, there is no way to change it. The only way forward is to create another new environment and start again.

The environment’s region matters because it determines which datacenter your Power Apps, Power Automate flows and your data lives in. Choose the datacenter closest to your users to deliver the best performance. Also consider data sovereignty – data stored outside of your home country will be subject to the laws where it is stored.

2. Choosing The Wrong Environment Type

The default environment type Sandbox enables the Reset action which deletes all data & customizations within the environment and restores it to factory settings. You cannot perform a restore to recover lost data or customizations because the environment backups get deleted too. It is critical that you make sure the environments used for production do not have the type Sandbox.

This mistake can be easily fixed by opening the environment in the Power Platform Admin Center and pressing the Convert To Production action.

3. Forgetting To Enter An Environment URL

Changing the environment URL after initial environment setup has the potential to break Power Automate flows and other customizations. For example, a Power Automate flow that uses the environment URL stored in an environment variable would begin to fail.

To update the environment URL after an environment is created go to Power Platform Admin center and Edit the environment settings.

4. Failing To Apply A Security Group

An environment with no security group allows the system administrator to assign roles and share apps & flows with any user in the tenant. Only developers should be allowed in the development environments to ensure no customizations are broken. Likewise, only authorized users should be allowed in the production environment to make certain no sensitive data is leaked.

To update the Security group go to Power Platform Admin center and Edit the environment settings.

5. Missing Security Roles Assignment To Users

Users cannot run apps in an environment until they are assigned at least a Basic User security role. Developers require an Environment Maker role or System Customizer role to create new resources and view data. Additional custom security roles may be required as well. Do not assume that because a user appears in the environment’s Users list that they have a security role.

To assign a security role to a user, open the Users menu, select a user and then click Manage Security Roles.

6. Neglecting The Setup Of Data Policies

Data policies define which connectors are enabled or blocked and which connectors can be used with one another. By default all connectors can be used with no limitations. Your organization’s private data can be sent to 3rd party online services and consumed by their APIs.

If proper data policy for the environment is unknown upon creation consider move all Microsoft connectors to the business category while leaving the others in the non-business category. This will prevent Microsoft connectors from interacting with 3rd party APIs. Consider blocking the HTTP connector until you have a good reason to enable it. The HTTP connector can access any API on the internet.

Also, if you decide to enact a data policy after apps & flows have already been developed, you run the risk of breaking them. The Power Platform Center Of Excellence Starter Kit includes a useful Power Apps app named DLP Editor. You can run an impact analysis before changing the data policy to see which specific apps & flows will break. Then you would inform their creators and find a resolution.

7. Delaying Applying Power Platform Licenses

Developers and end-users alike cannot use being using premium apps, flows and other services without Power Platform licensing. Per app and per flow licenses must be added to the environment as an add-on within the Capacity menu. The sames goes for AI Builder credits and Power Pages capacity.

Per user licenses are assigned to a user account and do not need to be assigned to each new environment created.

Questions?

If you have any questions or feedback about 7 Mistakes To Avoid When Creating A Power Platform Environment please leave a message in the comments section below. You can post using your email address and are not required to create an account to join the discussion.

The post 7 Mistakes To Avoid When Creating A Power Platform Environment appeared first on Matthew Devaney.