Live publish for 13 June 2024.

.openpublishing.redirection.json

@@ -1035,6 +1035,11 @@
       "source_path": "power-platform/admin/onpremises-data-gateway-source-management.md",
       "redirect_url": "/power-platform/admin/wp-onpremises-gateway",
       "redirect_document_id": false
+    },
+    {
+      "source_path": "power-platform/guidance/adoption/environment-strategy.md",
+      "redirect_url": "/power-platform/guidance/white-papers/environment-strategy",
+      "redirect_document_id": false
     }
   ]
 }

power-platform/alm/environment-strategy-alm.md

@@ -51,7 +51,7 @@ should include using a test environment prior to deploying anything to the produ
 environment. This ensures that you have a place to test your app, but also
 ensures that the deployment itself can be tested. 
 
-More information: [Establishing an environment strategy for Microsoft Power Platform](../guidance/adoption/environment-strategy.md)
+More information: [Establishing an environment strategy for Microsoft Power Platform](../guidance/white-papers/environment-strategy.md)
 
 ## Multi-geographical considerations
 

power-platform/developer/cli/reference/includes/connector-init-intro.md

@@ -9,7 +9,7 @@ This example initializes a connector in the current directory.
 ```powershell
 pac connector init `
   --connection-template "OAuthAAD" `
-  --generate-script-file "contoso_script_file" `
-  --generate-settings-file "contoso_settings_file" `
+  --generate-script-file `
+  --generate-settings-file `
   --outputDirectory "contoso_Connector"
 ```

power-platform/enterprise-templates/finance/sap-procurement/administer/set-up-environments-data-policies.md

@@ -15,7 +15,7 @@ contributors:
   - Wrighttyler
 ms.reviewer: ellenwehrle
 ms.topic: how-to
-ms.date: 08/18/2023
+ms.date: 06/13/2024
 ms.custom: bap-template
 ms.service: power-platform
 ms.subservice: solution-templates
@@ -61,7 +61,7 @@ Installing, configuring, testing, and running [solutions](/power-apps/maker/data
 
 More information:
 
-- [Establish an environment strategy](/power-platform/guidance/adoption/environment-strategy)
+- [Establish an environment strategy](/power-platform/guidance/white-papers/environment-strategy)
 - [Create an environment in the Power Platform admin center](/power-platform/admin/create-environment#create-an-environment-in-the-power-platform-admin-center)
 - [Manage Microsoft Dataverse settings](/power-platform/admin/admin-settings)
 - [Microsoft Dataverse developer documentation](/power-apps/developer/data-platform/)

power-platform/guidance/TOC.yml

@@ -44,7 +44,7 @@
                 - name: Plan and manage licenses and capacity
                   href: adoption/capacity-and-licenses.md
                 - name: Establish an environment strategy
-                  href: adoption/environment-strategy.md
+                  href: white-papers/environment-strategy.md
                 - name: Manage Dataverse for Teams environments
                   href: adoption/teams-environment-strategy.md
                 - name: Manage the default environment

power-platform/guidance/adoption/admin-best-practices.md

@@ -5,7 +5,7 @@ author: manuelap-msft
 
 ms.component: pa-admin
 ms.topic: conceptual
-ms.date: 09/09/2020
+ms.date: 06/13/2024
 ms.subservice: guidance
 ms.author: mapichle
 ms.reviewer: sericks
@@ -26,7 +26,7 @@ In this section, we'll explore some best practices to follow when establishing a
 > * [Designate the Microsoft Power Platform admin role](pp-admin.md)
 > * [Manage users](../../admin/create-users.md)  
 > * [Plan and manage license and capacity](../../admin/capacity-add-on.md)
-> * [Establish an environment strategy](environment-strategy.md)
+> * [Establish an environment strategy](../white-papers/environment-strategy.md)
 > * [Manage Microsoft Dataverse for Teams environments](teams-environment-strategy.md)
    :::column-end:::
    :::column span="":::

power-platform/guidance/adoption/dlp-strategy.md

@@ -5,7 +5,7 @@ author: manuelap-msft
 
 ms.component: pa-admin
 ms.topic: conceptual
-ms.date: 09/09/2020
+ms.date: 06/13/2024
 ms.subservice: guidance
 ms.author: mapichle
 ms.reviewer: sericks
@@ -16,13 +16,13 @@ search.audienceType:
 
 Data loss prevention (DLP) policies act as guardrails to help prevent users from unintentionally exposing organizational data and to protect information security in the tenant. DLP policies enforce rules for which connectors are enabled for each environment, and which connectors can be used together. Connectors are classified as either **business data only**, **no business data allowed**, or **blocked**. A connector in the business data only group can only be used with other connectors from that group in the same app or flow. More information: [Administer Microsoft Power Platform: Data Loss Prevention Policies](../../admin/wp-data-loss-prevention.md)
 
-Establishing your DLP policies will go hand in hand with your [environment strategy](environment-strategy.md).
+Establishing your DLP policies goes hand in hand with your [environment strategy](../white-papers/environment-strategy.md).
 
 ## Quick facts
 
 - [Data loss prevention (DLP)](../../admin/wp-data-loss-prevention.md) policies act as guardrails to help prevent users from unintentionally exposing data.
 -	DLP policies can be scoped at the environment level and tenant level, offering flexibility to craft policies that are sensible and don't block high productivity.
--	Environment DLP policies cannot override tenant-wide DLP policies.
+-	Environment DLP policies can't override tenant-wide DLP policies.
 -	If multiple policies are configured for one environment, the most restrictive policy applies to the combination of connectors.
 -	By default, no DLP policies are implemented in the tenant.
 -	Policies can’t be applied at the user level, only at the environment or tenant level.
@@ -34,8 +34,8 @@ Establishing your DLP policies will go hand in hand with your [environment strat
 
 Business and non-business classifications draw boundaries around what connectors can be used together in a given app or flow. Connectors can be classified across the following groups using DLP policies:
 
-- **Business**: A given Power App or Power Automate resource can use one or more connectors from a business group. If a Power App or Power Automate resource uses a business connector, it cannot use any non-business connector.
-- **Non-business**: A given Power App or Power Automate resource can use one or more connectors from a non-business group. If a Power App or Power Automate resource uses a non-business connector, it cannot use any business connector.
+- **Business**: A given Power App or Power Automate resource can use one or more connectors from a business group. If a Power App or Power Automate resource uses a business connector, it can't use any non-business connector.
+- **Non-business**: A given Power App or Power Automate resource can use one or more connectors from a non-business group. If a Power App or Power Automate resource uses a non-business connector, it can't use any business connector.
 - **Blocked**: No Power App or Power Automate resource can use a connector from a blocked group. All Microsoft-owned premium connectors and third-party connectors (standard and premium) can be blocked. All Microsoft-owned standard connectors and Common Data Service connectors can't be blocked.
 
 The names "business" and "non-business" don't have any special meaning—they're simply labels. The grouping of the connectors themselves is of significance, not the name of the group they're placed in.
@@ -44,51 +44,51 @@ More information: [Administer Microsoft Power Platform: Connector classification
 
 ## Strategies for creating DLP policies
 
-As an administrator taking over an environment or starting to support use of Power Apps and Power Automate, DLP policies should be one of the first things you set up. This ensures a base set of policies is in place, and you can then focus on handling exceptions and creating targeted DLP policies that implement these exceptions once approved.
+As an administrator taking over an environment or starting to support use of Power Apps and Power Automate, DLP policies should be one of the first things you set up. Once a base set of policies is in place, you can then focus on handling exceptions and creating targeted DLP policies that implement these exceptions once approved.
 
 We recommend the following starting point for DLP policies for **shared user and team productivity environments**:
 
-- Create a policy spanning all environments except selected ones (for example, your production environments), keep the available connectors in this policy limited to Office 365 and other standard microservices, and block access to everything else. This policy will apply to the default environment, and to training environments you have for running internal training events. Additionally, this policy will also apply to any new environments that will be created.
-- Create appropriate and more permissive DLP policies for your [shared user and team productivity environments](environment-strategy.md#tiered-approach-to-team-and-user-productivity-environments). These policies could allow makers to use connectors like Azure services in addition to the Office 365 services. The connectors available in these environments will depend on your organization, and where your organization stores business data.
+- Create a policy spanning all environments except selected ones (for example, your production environments), keep the available connectors in this policy limited to Office 365 and other standard microservices, and block access to everything else. This policy applies to the default environment, and to training environments you have for running internal training events. Additionally, this policy also applies to any new environments that are created.
+- Create appropriate and more permissive DLP policies for your [shared user and team productivity environments](../white-papers/environment-strategy.md). These policies could allow makers to use connectors like Azure services in addition to the Office 365 services. The connectors available in these environments depend on your organization, and where your organization stores business data.
 
 We recommend the following starting point for DLP policies for **production (business unit and project) environments**:
 
 - Exclude those environments from shared user and team productivity policies.
 - Work with the business unit and project to establish which connectors and connector combinations they'll use and create a tenant policy to include the selected environments only.
-- Environment admins of those environments can use environment policies to categorize custom connectors as business-data only, if required.
+- Environment admins of those environments can use environment policies to categorize custom connectors as business-data only, if necessary.
 
-Additional to the above, we also recommend:
+We also recommend:
 
-- Creating a minimal number of policies per environment. There is no strict hierarchy between tenant and environment policies, and at design and runtime, all policies that are applicable to the environment in which the app or flow resides are evaluated together to decide whether the resource is in compliance or violation of DLP policies.  [Multiple DLP policies](../../admin/dlp-combined-effect-multiple-policies.md) applied to one environment will fragment your connector space in complicated ways, and might make it difficult to understand issues your makers are facing.  
+- Creating a minimal number of policies per environment. There's no strict hierarchy between tenant and environment policies, and at design and runtime, all policies that are applicable to the environment in which the app or flow resides are evaluated together to decide whether the resource is in compliance or violation of DLP policies.  [Multiple DLP policies](../../admin/dlp-combined-effect-multiple-policies.md) applied to one environment will fragment your connector space in complicated ways, and might make it difficult to understand issues your makers are facing.  
 - Centrally managing DLP Policies using tenant level policies, and using environment policies only to categorize custom connectors or in exception cases.  
 
-With this in place, plan how to handle exceptions. You can: 
+With a base strategy in place, plan how to handle exceptions. You can: 
 
 - Deny the request.
 - Add the connector to the default DLP policy.
 - Add the environments to the All Except list for the global default DLP and create a use case-specific DLP policy with the exception included.
 
 ## Example: Contoso's DLP strategy
 
-Let’s look at how Contoso Corporation, our sample organization for this guidance, set up their DLP policies. The setup of their DLP policies ties in closely with their [environment strategy](environment-strategy.md).
+Let’s look at how Contoso Corporation, our sample organization for this guidance, set up their DLP policies. The setup of their DLP policies ties in closely with their [environment strategy](../white-papers/environment-strategy.md).
 
 Contoso admins want to support user and team productivity scenarios and business applications, in addition to Center of Excellence (CoE) activity management.
 
-The environment and DLP strategy Contoso admins have applied here consists of:
+The environment and DLP strategy Contoso admins applied here consists of:
 
-1. A tenant-wide restrictive DLP policy that applies to all environments in the tenant except some specific environments that they have excluded from the policy scope. Admins intend to keep the available connectors in this policy limited to Office 365 and other standard micro-services by blocking access to everything else. This policy will also apply to the default environment.
+1. A tenant-wide restrictive DLP policy that applies to all environments in the tenant except some specific environments that they excluded from the policy scope. Admins intend to keep the available connectors in this policy limited to Office 365 and other standard micro-services by blocking access to everything else. This policy also applies to the default environment.
 
-1. Contoso admins have created another shared environment for users to create apps for user and team productivity use cases. This environment has an associated tenant-level DLP policy that isn't as risk-averse as a default policy and allows makers to use connectors like Azure services in addition to the Office 365 services. Because this is a non-default environment, admins can actively control the environment maker list for it. This is a tiered approach to shared user and team productivity environment and associated DLP settings.
+1. Contoso admins created another shared environment for users to create apps for user and team productivity use cases. This environment has an associated tenant-level DLP policy that isn't as risk-averse as a default policy and allows makers to use connectors like Azure services in addition to the Office 365 services. Because this environment is a non-default environment, admins can actively control the environment maker list for it. This is a tiered approach to shared user and team productivity environment and associated DLP settings.
 
-1. In addition, for the business units to create line-of-business applications, they have created development, test, and production environments for their tax and audit subsidiaries across various countries/regions. The environment maker access to these environments is carefully managed, and appropriate first- and third-party connectors are made available using tenant-level DLP policies in consultation with the business unit stakeholders.
+1. In addition, for the business units to create line-of-business applications, they created development, test, and production environments for their tax and audit subsidiaries across various countries/regions. The environment maker access to these environments is carefully managed, and appropriate first- and third-party connectors are made available using tenant-level DLP policies in consultation with the business unit stakeholders.
 
 1. Similarly, dev/test/production environments are created for Central IT's use to develop and roll out relevant or right applications. These business application scenarios typically have a well-defined set of connectors that need to be made available for makers, testers, and users in these environments. Access to these connectors is managed using a dedicated tenant-level policy.
 
-1. Contoso also has a special purpose environment dedicated to their Center of Excellence activities. In Contoso, the DLP policy for the special purpose environment will remain high touch given the experimental nature of the theory teams book. In this case, tenant admins have delegated DLP management for this environment directly to a trusted environment admin of the CoE team and excluded it from a school of all tenant-level policies. This environment is managed only by the environment-level DLP policy, which is an exception rather than the rule at Contoso.
+1. Contoso also has a special purpose environment dedicated to their Center of Excellence activities. In Contoso, the DLP policy for the special purpose environment remains high touch given the experimental nature of the theory teams book. In this case, tenant admins delegated DLP management for this environment directly to a trusted environment admin of the CoE team and excluded it from a school of all tenant-level policies. This environment is managed only by the environment-level DLP policy, which is an exception rather than the rule at Contoso.
 
-As expected, any new environments that are created in Contoso will map to the original all-environments policy.
+As expected, any new environments that are created in Contoso map to the original all-environments policy.
 
-This setup of tenant-centric DLP policies doesn't prevent environment admins from coming up with their own environment-level DLP policies, if they want to introduce additional restrictions or to classify custom connectors.
+This setup of tenant-centric DLP policies doesn't prevent environment admins from coming up with their own environment-level DLP policies, if they want to introduce more restrictions or to classify custom connectors.
 
 ![How Contoso set up their DLP policy.](media/dlp-strategy_.png "How Contoso set up their DLP policy")
 
@@ -105,7 +105,6 @@ Set up a [SharePoint site or a wiki](wiki-community.md) that clearly communicate
 - Tenant-level and key environment-level (for example, default environment, trial environment) DLP policies enforced in the organization, inclusive of lists of connectors classified as business, non-business, and blocked.
 - Your admin group’s email ID so that makers can make contact for exception scenarios. For example, admins can help makers get back into compliance editing an existing DLP policy, moving the solution to a different environment, creating a new environment and a new DLP policy, and moving the maker and resource to this new environment.
 
-Also clearly communicate your organization's [environment strategy to makers](environment-strategy.md#clearly-communicate-your-organizations-environment-strategy-to-makers).
-
+Also clearly communicate your organization's [environment strategy to makers](/power-platform/guidance/white-papers/environment-strategy#communicate-your-environment-strategy-to-your-organization).
 
 [!INCLUDE[footer-include](../../includes/footer-banner.md)]