Using environments within Power

Automate
Benefits
Environments provide the following benefits:

 Data locality: Environments can be created in different regions and they're

bound to that geographic location. When you create a flow in an environment,
that flow is routed to all datacenters in that geographic location. This also
provides a performance benefit.

If your users are in Europe, create and use the environment in the Europe
region. If your users are in the United States, create and use the environment in
the U.S.

 Important

If you delete the environment, then all flows within that environment are also
deleted. This applies to any items you create in that environment, including
connections, gateways, Power Apps, and more.

 Data loss prevention: As an Administrator, you don't want flows that get data
from an internal location (such as OneDrive for Business or a SharePoint list that
contains salary information), and then post that data publicly (such as
to Twitter). Use data loss prevention to control which services can share data
within your Power Automate deployment.

For example, you can add the SharePoint and OneDrive for Business services to

a business data only policy. Any flows created in this environment can
use SharePoint and OneDrive for Business services. However, they won't be able
to share data with other services that aren't included in the business data only
policy.

 Note

Data loss prevention is available with some license skus, including the P2
license.

 Isolation boundary for all resources: Any flows, gateways, connections,

custom connectors, and so on reside in a specific environment. They don't exist
in any other environments.
  Common Data Service: Here are your options if you want to create a flow
that inserts data into a service:

o Insert data into an Excel file, and store the Excel file in a cloud storage
account, such as OneDrive.

o Create a SQL Database, and then store your data in it.

o Use Common Data Service to store your data.

Every environment can have a maximum of one database for your flows in
Common Data Service. Access to Common Data Service depends on the
license you've purchased; Common Data Service isn't included with the Free
license.

Limitations
Although environments provide many benefits, they also introduce new limitations.
The fact that environments are an isolation boundary means that you can never have
resources that reference resources across environments. For example, you may not
create a custom connector in one environment and then create a flow that uses that
custom connector in a different environment.

Use the default environment

The Default environment is shared by all users and any user can create flows in
the Default environment.

 Tip

If you're a Preview user, all existing flows reside in the default environment.
A Preview user is someone who was using Power Automate before its release to
General Availability (GA).

The admin center

Administrators use the admin center to create and manage environments. Here are
the two ways to open the admin center:

Option 1: Select Settings

1. Sign in to flow.microsoft.com.

2. Select the Settings gear, and choose Admin Center from the list:

 3. The administrator center opens.

Option 2: Open admin.flow.microsoft.com

Go to admin.flow.microsoft.com, and sign-in with your work account.

Create an environment
1. In the Power Automate admin center, select Environments. You'll see all
existing
environments: 
2. Select New environment and then provide the required information:

TABLE 1

Property Description

Environment Enter the name of your environment, such as Human Resources, or Europe flows.
Name

Region Choose the location to host your environment. For the best performance, use a region
closest to your users.

Environment Type Choose an environment type based upon your license: Production or Trial.

3.

4. Click Create environment.

5. You now have an option to Create database or Skip.

6. If you choose to Create Database, you will be prompted for

a Currency and Language for the Database. In addition, you can also choose to
have sample apps and data deployed.
You can now add users to the environment.

Manage your existing environments

1. In the Power Automate admin center, select Environments:

2. Select an environment to open its properties.

3. Use the Details tab to view additional information about an environment,

including who created the environment, its geographic location, and more:
4. Select Security.

If you did not select Create Database in previous steps, in Environment roles,

there're two options: Environment Admin and Environment Maker:

A Maker can create new resources such as flows, data connections, and

gateways in an environment.

 Note

A user doesn't need to be a Maker to edit resources in an environment. Each

Maker determines who can edit their resources by granting permissions to
users who aren't environment Makers.
 An Admin can create data loss prevention policies and perform other
administrative tasks, such as create environments, add users to environments,
and assign admin/maker privileges.

1. Select the Environment Maker role, and then

select Users: 

2. Enter a name, email address, or user group that you'd like to give
the Maker role.
3. Select Save.

5. Within Security, select User Roles:

Any existing roles are listed, including the options to edit or delete the role.

Select New role to create a new role.

6. Within Security, select Permission Sets:

 You'll see all existing permission sets and options to edit or delete roles.

Select New permission set to create a new permission set.

7. If you did choose to Create Database, to store your data, this database is part
of Common Data Service. When you click on the Security tab you will be
prompted to navigate to the Dynamics 365 instance management
center where role-based security can be
applied. 

8. Select the user from the list of users in the environment /

instance. 

9. Assign the role to the user.

 Note

Users or groups assigned to these environment roles are not automatically given
access to the environment’s database (if it exists) and must be given access
separately by a Database owner.

Database security

The ability to create and modify a database schema and to connect to the data
stored within a database that is provisioned in your environment is controlled by the
database's user roles and permission sets. You can manage the user roles and
permission sets for your environment's database from the User
roles and Permission sets section of the Security tab.
Data loss prevention (DLP) policies
This document introduces you to data loss prevention policies, which help protect
your organizational data from being shared with a list of connectors that you define.

What's a data loss prevention policy?

An organization's data is critical to its success. Its data needs to be readily available
for decision-making, but it needs to be protected so that it isn't shared with
audiences that shouldn't have access to it. To protect this data, Power Automate
provides you with the ability to create, and enforce policies that define which
consumer connectors can access and share business data. These policies that define
how data can be shared are referred to as data loss prevention (DLP) policies.

Why create a DLP policy?

You create DLP policy to clearly define which consumer connectors may access and
share your business data. For example, an organization that uses Power Automate
may not want its business data in SharePoint to be automatically published to its
Twitter feed. To prevent this, you create a DLP policy that blocks SharePoint data
from being used as the source for tweets.

Benefits of a DLP policy

 Ensures that data is managed in a uniform manner across the organization.
 Prevents important business data from being accidentally published to connectors
such as social media sites.

Managing DLP policies

Prerequisites for managing DLP policies

 Either environment admin or tenant admin permissions.

You can learn more about permissions in the environments article.

 A Power Automate P2 license.

Create a DLP policy

Prerequisites for creating DLP policies

To create a DLP policy, you must have permissions to at least one environment.
Follow these steps to create a DLP policy that prevents data in your company’s
SharePoint site from being published to Twitter:

1. Sign into the Power Automate Admin center (Admin center).

2. Select the Data Policies tab, and then select the New policy link:

3. Select the Data groups tab.

4. Enter the name of the DLP policy as Secure Data Access for Contoso in
the Data Policy Name label at the top of the page:

5. Select the environment on the Environments tab.

 Note

As an environment admin, you can create policies that apply to only a single
environment. As a tenant admin, you can create policies that apply to any
combination of environments:

6. Select the Data groups tab:

7. Select the Add link located inside the Business data only group box:

8. Select the SharePoint and Salesforce connectors from the Add

connectors page:

9. Select the Add connectors button to add the connectors that can share

business data.

10. Select Save Policy in the top right corner of the screen.

11. After a few moments, your new DLP policy will be displayed in the data loss
prevention policies list:
 12. Optional Send an email or other communication to your team, alerting them
that a new DLP policy is now available.

Congratulations, you've now created a DLP policy that allows app to share data
between SharePoint and Salesforce and blocks the sharing of data with any other
services.

 Note

Adding a service to one data group automatically removes it from the other data
group. For example, if Twitter is currently located in the business data only data
group, and you don't want to allow business data to be shared with Twitter, simply
add the Twitter service to the no business data allowed data group. This will
remove Twitter from the business data only data group.

Data sharing violations

Assuming you've created the DLP policy outlined above, if a user creates a flow that
shares data between Salesforce (which is in the business data only data group) and
Twitter (which is in the no business data allowed data group), the user will be
informed that the flow is suspended due to a conflict with the data loss prevention
policy you created.

If your users contact you about suspended flows, here a few things to consider:

1. In this example, if there's a valid business reason to share business data

between SharePoint and Twitter, you can edit the DLP policy.

2. Ask the user to edit the flow to comply with the DLP policy.

3. Ask the user to leave the flow in the suspended state until a decision is made
regarding the sharing of data between these two entities.
Find a DLP policy
Admins

Admins can use the search feature from the Admin center to find specific DLP
policies.

 Note

Admins should publish all DLP policies so that users in the organization are aware of
the policies prior to creating flows.

Makers

If you don't have admin permissions and you wish to learn more about the DLP
policies in your organization, contact your administrator. You can also learn more
from the maker environments article

 Note

Only admins can edit or delete DLP policies.

Edit a DLP policy

1. Launch the Admin center.

2. In the Admin center that launches, select the Data polices link on the left side.

3. Search the list of existing DLP policies and select the edit button next to the
policy you intend to edit.

4. Make the necessary changes to the policy. You can modify the environment or
the services in the data groups, for example.

5. Select Save Policy to save your changes.

 Note
DLP policies created by tenant admins can be viewed by environment admins but
cannot be edited by environment admins.

Delete a DLP policy

1. Launch the Admin center.

2. Select the Data polices tab on the left side.

3. Search the list of existing DLP policies, and then select the delete button next
to the policy you intend to delete:

4. Confirm that you really want to delete the policy by selecting

the Delete button:

DLP policy permissions

Only tenant and environment admins can create and modify DLP policies. Learn more
about permissions in the environments article.

Custom and HTTP connectors

Custom and HTTP connectors must be added to DLPs using either a Power Automate
template or a PowerShell.

 Tip

You can't downgrade from schema version 2018-11-01. HTTP support cannot be
removed from a policy. If you attempt to remove HTTP support, the DLP policy might
be corrupted. Further, if a DLP policy is updated to support HTTP connectors, current
flows using these HTTP capabilities might be shut off.

Here are the HTTP connectors that you can add to a policy:

 HTTP (and HTTP + Swagger)

 HTTP Webhook
 HTTP Request

Add connectors custom and HTTP connectors with

templates
To add a custom connector to a policy using a template, enter the policy name, the
group to which to add the connector, and the connector’s name, ID, and type. Run
the flow once to add the custom connector to the policy and group given.

To add the HTTP connectors to an existing policy via the template, enter the name of
the policy you’d like to add them to and then run the flow.

Add custom and HTTP connectors with PowerShell

To add support for custom connectors and/or HTTP connectors to a policy using the
PowerShell, download and import the latest Power Apps PowerShell scripts and then
use these cmdlets: ‘New-AdminDlpPolicy’, ‘Set-AdminDlpPolicy’, ‘Add-
CustomConnectorToPolicy’, and ‘Remove-CustomConnectorFromPolicy’ to modify
the policy. Use the ‘Get-Help -detailed’ cmdlet as a reference.

 Important

Use the schema version 2018-11-01 when creating or updating a DLP policy to
include HTTP connectors. Adding HTTP support using the template or PowerShell will
only affect the specified policy. New policies created via the Admin Center will not
contain the HTTP connectors.
Data groups

What is a data group?

Data groups are a simple way to categorize services within a data loss prevention
(DLP) policy. The two data groups available are the Business data only group and
the No business data allowed group. Organizations are free to determine which
services are placed into a particular data group. A good way to categorize services is
to place them in groups, based on the impact to the organization. By default, all
services are placed into the No business data allowed data group. You manage the
services in a data group when you create or modify the properties of a DLP policy
from the admin center.

How data is shared between data groups

Data cannot be shared among services located in different groups. For example, if
you place SharePoint and Salesforce in the Business data only group and you place
Facebook and Twitter in the No business data allowed group, you cannot create a
flow that moves data between SharePoint and Facebook. While data cannot be
shared among services in different groups, you can share data among the services
within a specific group. So, going back to the earlier example, since SharePoint and
Salesforce were placed in the same data group, flows that your end users create can
share data between SharePoint and Salesforce. Similarly, end users can create flows
and Power Apps that share data between Facebook and Twitter. The key point is that
services in a specific group can share data, while services in different groups cannot
share data.

Additionally, one data group must be designated as the default group. Initially,

the No business data allowed group is the default group and all services are in the
data group. An administrator can change the default data group to the business
data only data group. Note any new services that are added to flow will be placed in
the designated default group. For this reason, we recommend you keep the No
business data allowed as the default group and manually add services into
the Business data only group after your organization has evaluated the impact of
allowing business data to be shared with the new service.

Add services to a data group

In this walk-through, we'll add SharePoint and Salesforce to the business data
only data group of a data loss prevention (DLP) policy.

1. Select the + Add link located inside the Business data only group box of a DLP
policy:

2. Select SharePoint and Salesforce then select Add services to add both to the
business data only group:
 3. Select Save Policy from the menu at the top:

4. Notice that both SharePoint and Salesforce are now in the business data only group:

In this walk-through, you've added SharePoint and Salesforce to the business data

only data group of a DLP policy. If a person who is part of the DLP policy's
environment creates an app that shares data between SharePoint or Salesforce and
any service in the No business data allowed data group, the app will not be allowed
to run.

Remove services from a data group

Since all services must be in one of the available data groups, to remove a service
from a specific group, simply add the service to another group then save the policy.

Change the default data group

In this walk-through, we will change the default data group from the no business
data allowed data group to the business data only data group.

Important any new services that are added to flow will be placed in the
designated default group. For this reason, we recommend you keep the No business
data allowed as the default group and manually add services into the Business data
only group.

1. Select the ... located at the top right corner of the data group you wish to designate
as the default data group:
 2. Select Set as default group:

3. Select Save Policy from the menu at the top:

4. Notice the data group is now designated as the default data group:

Sharing and connectors admin analytics

reports
Organizations need insights into how apps are used and who's using them. The
Admin analytics sharing and connectors reports provide insight into how Power
Automate is being used within your tenant.

From a sharing perspective, you can learn who your app champions are and then
empower them to provide even more automated solutions for your organization. The
connectors report identifies Microsoft, third-party, and custom connectors that are in
use within your organization.
View shared flows reports
1. Sign in to the Power Platform Admin Center.

2. Select Analytics from the navigation bar on the left.

3. Select the Shared tab and view the list of flows that are shared in your
organization.

View connectors report

 1. Sign in to the Power Platform Admin Center.

2. Select Analytics from the navigation bar on the left.

3. Select the Connectors tab and view the list of connectors in use in your

organization.

Filter views
The results in these reports are based on the environment you've selected. To change
the environment:

1. Select the Change Filters link.

2. Select the Environment and the Time Period for which you're interested in

viewing reports.

3. Select the Apply button.
Respond to DSRs for Power Automate customer data
A data subject's formal request to a controller to take an action on their personal
data is called a Data Subject Rights (DSR) request. GDPR defines personal data
as any data that relates to an identified or identifiable natural person. The GDPR
gives people (known as data subjects) rights to manage the personal data that's
collected by an employer, agency, or organization (known as the data controller or
the controller). These rights include:

 Obtaining copies of personal data.

 Requesting corrections to personal data.
 Restricting processing of personal data.
 Deleting personal data.
 Receiving personal data in an electronic format so that it can be moved to another
controller.

Microsoft provides products, services, and tools to help controllers find and act on
personal data when responding to DSRs requests for data that lives in the cloud.

Here’s an overview of the processes outlined in this guide:

1. Discover: Use search and discovery tools to easily find customer data that
may be the subject of a DSR request. If you determine that the documents you
collect meet your controller guidelines for taking action, you can perform one
or more of the DSR actions described in the following steps. Alternatively, you
may determine that the request doesn’t meet your controller guidelines for
responding to DSR requests.
2. Access: Retrieve personal data that resides in the Microsoft cloud and, if
requested, make a copy of it so that can be available to the data subject.

3. Rectify: Make changes or implement other requested actions on the personal

data, where applicable.

4. Restrict: Restrict the processing of personal data, either by removing licenses

for various online services or turning off the desired services where possible.
You can also remove data from the Microsoft cloud and retain it on-premises or
at another location.

5. Delete: Permanently remove personal data that resides in Microsoft's cloud.

6. Export: Provide an electronic copy (in a machine-readable format) of personal

data.