Merge pull request #2845 from MicrosoftDocs/master

taking changes to live

Author: mduelae

powerapps-docs/developer/common-data-service/build-tools-tasks.md

@@ -32,7 +32,7 @@ The Power Apps checker task runs a static analysis check on your solution(s) aga
 
 | **Parameters** | **Description** |
 | --- | --- |
-| Power Apps checker service  |   Select the service endpoint for Power Apps checker. The service   endpoint is defined under **Service Connections** in **Project Settings**.  **NOTE:** The service connection type that must be used for this specific task only is ‘Power Apps Checker,’ which is a service principals connection. More information on how to configure Service Principals before you can use the  task is available [here](https://aka.ms/buildtoolsconnection).  |
+| Power Apps checker service  |   Select the service endpoint for Power Apps checker. The service   endpoint is defined under **Service Connections** in **Project Settings**.  **NOTE:** The service connection type that must be used for this specific task only is ‘Power Apps Checker,’ which is a service principals connection. More information on how to configure Service Principals before you can use the  task is available [here](build-tools-tasks#configure-service-connection-for-power-apps-checker).  |
 | Location of file to analyze  | Specify whether to reference a local file or a reference file from a Sas url. 
 | Local files to analyze/Sas uri for file to analyze |  Specify the path and file name of the zip files to analyze.   Wildcards can be used. For example, **\*.zip   for all zip files in all sub folders. You can choose to specify the files   directly or reference a File from a Sas uri.   |
 |  Rule set |   Specify which ruleset to apply. The following two rulesets are available:  **Solution Checker:** This is the same ruleset that is run from the [Maker Portal](https://make.powerapps.com/).    **AppSource:** This is the extended ruleset that is used to certify an application before it can be published to [AppSource](https://appsource.microsoft.com/).   |

powerapps-docs/developer/model-driven-apps/clientapi/reference/formContext-data-process/setActiveProcessInstance.md

@@ -28,7 +28,7 @@ search.app:
 
 |Name|Type|Required|Description|
 |--|--|--|--|
-|processInstanceId|String|Yes|The Id of the process instance to set as the active instance.|
+|processId|String|Yes|The Id of the process instance to set as the active instance.|
 |callbackFunction|Function|No|A function to call when the operation is complete. This callback function is passed one of the following string values to indicate whether the operation succeeded:<br/>- **success**: The operation succeeded.<br/>- **invalid**: The processInstanceId isn’t valid or the process isn’t enabled.|
 
 ### Related topics

powerapps-docs/maker/TOC.yml

@@ -1597,9 +1597,7 @@
       - name: Best practices
         href: ./common-data-service/solution-best-practices.md        
       - name: "How to"
-        items:
-        - name: Create solution patches
-          href: ./common-data-service/solution-patches.md      
+        items:     
         - name: Create a solution
           href: ./common-data-service/create-solution.md
         - name: Update or upgrade solutions

powerapps-docs/maker/canvas-apps/functions/function-navigate.md

@@ -7,7 +7,7 @@ ms.service: powerapps
 ms.topic: reference
 ms.custom: canvas
 ms.reviewer: tapanm
-ms.date: 04/30/2020
+ms.date: 05/07/2020
 ms.author: gregli
 search.audienceType: 
   - maker
@@ -22,7 +22,7 @@ Changes which screen is displayed.
 
 Most apps contain multiple screens.  Use the **Back** and **Navigate** function to change which screen is displayed. For example, set the **[OnSelect](../controls/properties-core.md)** property of a button to a formula that includes a **Navigate** function if you want to show a different screen when a user selects that button. In that formula, you can specify a visual transition, such as **Fade**, to control how one screen changes to another.  
 
-**Back** and **Navigate** change only which screen is displayed. Screens that aren't currently displayed continue to operate behind the scenes. You can build formulas that refer to properties of controls on other screens. For example, a user can change the value of a slider on one screen, navigate to a different screen that uses that value in a formula, and ascertain how it affects what happens in the new screen. The user can then navigate back to the original screen and confirm that the slider has retained its value.
+**Back** and **Navigate** change only which screen is displayed. Screens that aren't currently displayed continue to operate behind the scenes. You can build formulas that refer to properties of controls on other screens. For example, a user can change the value of a slider on one screen, navigate to a different screen that uses that value in a formula, and determine how it affects what happens in the new screen. The user can then navigate back to the original screen and confirm that the slider has kept its value.
 
 [Context variables](../working-with-variables.md#use-a-context-variable) are also preserved when a user navigates between screens. You can use **Navigate** to set one or more context variables for the screen that the formula will display, which is the only way to set a context variable from outside the screen. You can use this approach to pass parameters to a screen. If you've used another programming tool, this approach is similar to passing parameters to procedures.
 
@@ -43,7 +43,7 @@ In the first argument, specify the name of the screen to display.
 | **ScreenTransition.UnCover** | The current screen slides out of view, moving right to left, to uncover the new screen. | ![screen transition uncover animation](media/function-navigate/uncover.gif) |
 | **ScreenTransition.UnCoverRight** | The current screen slides out of view, moving left to right, to uncover the new screen. | ![screen transition uncover right animation](media/function-navigate/uncoverright.gif) |
 
-You can use **Navigate** to create or update context variables of the new screen. As an optional third argument, pass a [record](../working-with-tables.md#records) that contains the context-variable name as a [column](../working-with-tables.md#columns) name and the new value for the context variable.  This record is the same as the record that you use with the **[UpdateContext](function-updatecontext.md)** function.
+You can use **Navigate** to create or update [context variables](../working-with-variables.md#use-a-context-variable) of the new screen. As an optional third argument, pass a [record](../working-with-tables.md#records) that contains the context-variable name as a [column](../working-with-tables.md#columns) name and the new value for the context variable.  This record is the same as the record that you use with the **[UpdateContext](function-updatecontext.md)** function.
 
 Set the **[OnHidden](../controls/control-screen.md)** property of the old screen, the **[OnVisible](../controls/control-screen.md)** property of the new screen, or both to make additional changes during the transition. The **App.ActiveScreen** property will be updated to reflect the change.
 
@@ -65,13 +65,13 @@ When the **Back** function runs, the inverse transition is used by default. For
 
 **Back**( [ *Transition* ] )
 
-* *Transition* - Optional. The visual transition to use between the current screen and the previous screen. Refer to the list of valid values for this argument earlier in this topic. By default, the transition through which a screen returns is the inverse of the transition through which it appeared.
+* *Transition* - Optional. The visual transition to use between the current screen and the previous screen. Refer to the list of valid values for this argument earlier in this article. By default, the transition through which a screen returns is the inverse of the transition through which it appeared.
 
 **Navigate**( *Screen* [, *Transition* [, *UpdateContextRecord* ] ] )
 
 * *Screen* - Required. The screen to display.
-* *Transition* - Optional.  The visual transition to use between the current screen and the next screen. See the list of valid values for this argument earlier in this topic. The default value is **None**.
-* *UpdateContextRecord* - Optional.  A record that contains the name of at least one column and a value for each column. This record updates the context variables of the new screen as if passed to the **[UpdateContext](function-updatecontext.md)** function.
+* *Transition* - Optional.  The visual transition to use between the current screen and the next screen. See the list of valid values for this argument earlier in this article. The default value is **None**.
+* *UpdateContextRecord* - Optional.  A record that contains the name of at least one column and a value for each column. This record updates the [context variables](../working-with-variables.md#use-a-context-variable) of the new screen as if passed to the **[UpdateContext](function-updatecontext.md)** function.
 
 ## Examples
 
@@ -120,4 +120,4 @@ When the **Back** function runs, the inverse transition is used by default. For
 
 ### See also
 
-[Add screen context variables](../add-screen-context-variables.md)
+[Using context variables](../working-with-variables.md#use-a-context-variable)

powerapps-docs/maker/portals/configure/enable-multiple-language-support.md

@@ -6,7 +6,7 @@ manager: kvivek
 ms.service: powerapps
 ms.topic: conceptual
 ms.custom: 
-ms.date: 11/04/2019
+ms.date: 04/30/2020
 ms.author: tapanm
 ms.reviewer:
 ---
@@ -18,7 +18,7 @@ Business is not confined to a single region or a language. A single portal can d
 
 To enable multiple languages for a portal, follow these steps:
 
-1. [Enable languages in a Common Data Service environment.](https://technet.microsoft.com/library/dn832148.aspx)  
+1. [Enable languages in a Common Data Service environment.](https://docs.microsoft.com/power-platform/admin/enable-languages)  
 2. Go to **Portals** > **Website** > **Websites**.
 3. Select the website to add language support to.
 4. In the **Supported Languages** section under the **General** tab, select **New Website Language**.

powerapps-docs/maker/portals/configure/websites.md

@@ -6,20 +6,20 @@ manager: kvivek
 ms.service: powerapps
 ms.topic: conceptual
 ms.custom: 
-ms.date: 11/14/2019
+ms.date: 04/30/2020
 ms.author: tapanm
 ms.reviewer:
 ---
 
 # Manage websites
 
-A website is the core entity of portals application. A portal application selects a single Website record, and this determines what portal entities – [web pages](web-page.md), [web files](web-files.md), [web roles](create-web-roles.md), [content snippets](customize-content-snippets.md), etc. – are applicable to this application.
+A website is the core entity of portals application. A portal application selects a single Website record, and this determines what portal entities such as [web pages](web-page.md), [web files](web-files.md), [web roles](create-web-roles.md), and [content snippets](customize-content-snippets.md) are applicable to this application.
 
 With a website providing an application scope, multiple distinct portal applications can be connected to a single organization.
 
 > [!NOTE]
 > Determination of which website record a given portal application is bound to is usually by the website's name, specified in the configuration of the portal deployment.
-However, it is also possible to control this by URL path prefix (see the descriptions of Parent Website and Partial URL under [website attributes](#website-attributes)), or by ___domain, using website bindings.
+However, it is also possible to control this by ___domain name or website bindings.
 
 ## Manage websites
 
@@ -41,12 +41,15 @@ Websites are created when you create a new portal. However, advanced website man
 ### Website attributes
 
 |Name|Description|
-|-----|----------|
+|-|-|
 |Name|The descriptive name of the website. This field is required.|
+| Default Language | Default language for the selected portal. Before you change the default language, you must: <br> - [Add the language in Common Data Service environment](https://docs.microsoft.com/power-platform/admin/enable-languages). <br> - [Add the language in Supported Languages](enable-multiple-language-support.md) section for Websites record.
+| Owner | The owner contact record for the selected Websites record.
 |Primary Domain Name|The primary ___domain name of the portal to which this website record will be added.|
-|Parent Website|The parent website of the website. This field can generally be ignored, except in certain advanced portal configurations in which a single portal application is bound to one master website at the application root path, with one or more child websites available at specific sub-paths.|
-|Partial URL|The root URL path segment for all URLs generated for portal entities related to this website.<br>For example, if a portal application is deployed to be available at the root of the ___domain example.com, and this attribute has no value, a request to `http://example.com/` will render the Home web page of the application website (as the Home web page is required to have its Partial URL set to "/").<br>If this attribute is set to the value "my-website", the Home Web Page will instead have a URL of `http://example.com/my-website/`, and all pages in the website will have the same "/my-website/" path prefix.<br>In most portal configurations, this field can be ignored and left blank.<br>Partial URL values are used as URL path segments. As such, they should not contain illegal URL path characters, such as "?", "#", "!", "%". Since portal URLs are generated by joining together Partial URL values with slashes ("/"), they should also not generally contain slashes.<br>Recommended practice would be to restrict Partial URL values to letters, numbers, and hyphens or underscores. For example: "press-releases", "Users_Guide", "product1".|
-|||
+|Parent Website\*|The parent website of the website. This field can generally be ignored, except in certain advanced portal configurations in which a single portal application is bound to one master website at the application root path, with one or more child websites available at specific sub-paths. <br>\* Only for backward compatibility, not to be used for new or existing portals. |
+| Header and Footer Templates | The [Web templates for headers and footers](../liquid/store-content-web-templates.md#web-templates-as-page-templates) overriding global headers and footers.
+| Supported Languages | The [supported languages](enable-multiple-language-support.md) for the selected Websites record.
 
 ### See also
+
 [Website bindings](website-bindings.md)

powerapps-docs/user/merge-duplicate-records.md

@@ -38,7 +38,7 @@ Common Data Service includes duplicate detection rules for accounts and contacts
 > [!NOTE]
 >  If available on your system, you may also be able to check for duplicates of other record types, in addition to contacts and accounts. Check with your system administrator. [Find your administrator or support person](find-admin.md)  
   
-## Merge duplicate records  
+### How to merge duplicate records  
 
 1. Select the duplicate records, and then select **Merge**.  
 
@@ -51,11 +51,22 @@ Common Data Service includes duplicate detection rules for accounts and contacts
    > [!div class="mx-imgBorder"] 
    > ![Dialog box for merging records](media/merge-records-dialog.png "Dialog box for merging records")  
   
-> [!NOTE]
->  There are a few situations when duplicates may be found:  
-> 
-> - When a record is created or updated.  
->   - When  you're using Dynamics 365 for Outlook and you go from offline to online.  
->   - When you import data using the Import Data wizard.  
-> 
->   Duplicates aren't detected when you merge records, save an activity as completed, or change the status of a record, such as activating or reactivating a record.  
+
+There are a few situations when duplicates may be found:  
+
+- When a record is created or updated.  
+- When  you're using Dynamics 365 for Outlook and you go from offline to online.  
+- When you import data using the Import Data wizard.  
+- Duplicates aren't detected when you merge records, save an activity as completed, or change the status of a record, such as activating or reactivating a record.
+
+> [!IMPORTANT]
+>  If a field or control matches any of the following conditions, it will not show up in the merge dialog:  
+>   - The containing section is invisible in form descriptor or form XML regardless whether the section shows up in runtime. It is possible to show it using the client API.
+>   - The control does not have a class property.
+>   - The attribute's metadata `ValidForUpdate` is False.
+>   - The control is **Quick Form Collection Control** or **Reference Panel Quick Form Collection Control**.
+>   - The attribute's metadata `ValidForUpdate` is False. 
+>   - The attribute is `Picklist` or `MultiSelectPickList` and it has either a parent picklist or child picklist attribute.
+>   - The attribute is ` parentaccountid` on the Account entity; this is a system setting and cannot be changed. 
+>   - The attribute is ` parentcustomerid` on the  Contact Entity; this is a system setting and cannot be changed
+