Acrolinx improvements

Author: jonburchel

articles/data-factory/concepts-data-redundancy.md

@@ -8,16 +8,16 @@ ms.date: 10/03/2024
 ms.subservice: data-movement
 ---
 
-# **Azure Data Factory data redundancy**
+# Azure Data Factory data redundancy
 
 Azure Data Factory data includes metadata (pipeline, datasets, linked services, integration runtime, and triggers) and monitoring data (pipeline, trigger, and activity runs). 
 
-In all regions (except Brazil South and Southeast Asia), Azure Data Factory data is stored and replicated in the [paired region](../reliability/cross-region-replication-azure.md#azure-paired-regions) to protect against metadata loss. During regional datacenter failures, Microsoft may initiate a regional failover of your Azure Data Factory instance. In most cases, no action is required on your part. When the Microsoft-managed failover has completed, you'll be able to access your Azure Data Factory in the failover region.
+In all regions (except Brazil South and Southeast Asia), Azure Data Factory data is stored and replicated in the [paired region](../reliability/cross-region-replication-azure.md#azure-paired-regions) to protect against metadata loss. During regional datacenter failures, Microsoft might initiate a regional failover of your Azure Data Factory instance. In most cases, no action is required on your part. When the Microsoft-managed failover has completed, you are able to access your Azure Data Factory in the failover region.
 
 Due to data residency requirements in Brazil South, and Southeast Asia, Azure Data Factory data is stored on [local region only](../storage/common/storage-redundancy.md#locally-redundant-storage). For Southeast Asia, all the data are stored in Singapore. For Brazil South, all data are stored in Brazil. When the region is lost due to a significant disaster, Microsoft won't be able to recover your Azure Data Factory data.  
 
 > [!NOTE]
-> Microsoft-managed failover does not apply to self-hosted integration runtime (SHIR) since this infrastructure is typically customer-managed. If the SHIR is set up on Azure VM, then the recommendation is to leverage [Azure site recovery](../site-recovery/site-recovery-overview.md) for handling the [Azure VM failover](../site-recovery/azure-to-azure-architecture.md) to another region.
+> Microsoft-managed failover doesn't apply to self-hosted integration runtime (SHIR) since this infrastructure is typically customer-managed. If the SHIR is set up on Azure VM, then the recommendation is to use [Azure Site Recovery](../site-recovery/site-recovery-overview.md) for handling the [Azure VM failover](../site-recovery/azure-to-azure-architecture.md) to another region.
 
 
 
@@ -28,7 +28,7 @@ To ensure you can track and audit the changes made to your metadata, you should
  Learn how to set up [source control in Azure Data Factory](./source-control.md). 
 
 > [!NOTE]
-> In case of a disaster (loss of region), new data factory can be provisioned manually or in an automated fashion. Once the new data factory has been created, you can restore your pipelines, datasets and linked services JSON from the existing Git repository. 
+> If there is a disaster (loss of region), new data factory can be provisioned manually or in an automated fashion. Once the new data factory has been created, you can restore your pipelines, datasets, and linked services JSON from the existing Git repository. 
 
 
 

articles/data-factory/continuous-integration-delivery-resource-manager-custom-parameters.md

@@ -20,22 +20,22 @@ If your development instance has an associated Git repository, you can override
 
     To handle custom parameter 256 limit, there are three options:    
 
-    * Use the custom parameter file and remove properties that don't need parameterization, i.e., properties that can keep a default value and hence decrease the parameter count.
-    * Refactor logic in the dataflow to reduce parameters, for example, pipeline parameters all have the same value, you can just use global parameters instead.
+    * Use the custom parameter file and remove properties that don't need parameterization, that is, properties that can keep a default value and hence decrease the parameter count.
+    * Refactor logic in the dataflow to reduce parameters, for example, pipeline parameters all have the same value. You can just use global parameters instead.
     * Split one data factory into multiple data factories.
 
-To override the default Resource Manager parameter configuration, go to the **Manage** hub and select **ARM template** in the "Source control" section. Under **ARM parameter configuration** section, click **Edit** icon in "Edit parameter configuration" to open the Resource Manager parameter configuration code editor.
+To override the default Resource Manager parameter configuration, go to the **Manage** hub and select **ARM template** in the "Source control" section. Under **ARM parameter configuration** section, select **Edit** icon in "Edit parameter configuration" to open the Resource Manager parameter configuration code editor.
 
 :::image type="content" source="media/author-management-hub/management-hub-custom-parameters.png" alt-text="Manage custom parameters":::
 
 > [!NOTE]
-> **ARM parameter configuration** is only enabled in "GIT mode". Currently it is disabled in "live mode" or "Data Factory" mode.
+> **ARM parameter configuration** is only enabled in "GIT mode". Currently it's disabled in "live mode" or "Data Factory" mode.
 
 Creating a custom Resource Manager parameter configuration creates a file named **arm-template-parameters-definition.json** in the root folder of your git branch. You must use that exact file name.
 
 :::image type="content" source="media/continuous-integration-delivery/custom-parameters.png" alt-text="Custom parameters file":::
 
-When publishing from the collaboration branch, Data Factory will read this file and use its configuration to generate which properties get parameterized. If no file is found, the default template is used.
+When publishing from the collaboration branch, Data Factory reads this file and use its configuration to generate which properties get parameterized. If no file is found, the default template is used.
 
 When exporting a Resource Manager template, Data Factory reads this file from whichever branch you're currently working on, not the collaboration branch. You can create or edit the file from a private branch, where you can test your changes by selecting **Export ARM Template** in the UI. You can then merge the file into the collaboration branch.
 
@@ -61,7 +61,7 @@ The following are some guidelines to follow when you create the custom parameter
 
 ## Sample parameterization template
 
-Here's an example of what an Resource Manager parameter configuration might look like.  It contains examples of a number of possible usages, including parameterization of nested activities within a pipeline and changing the defaultValue of a linked service parameter.
+Here's an example of what a Resource Manager parameter configuration might look like.  It contains examples of many possible usages, including parameterization of nested activities within a pipeline and changing the defaultValue of a linked service parameter.
 
 ```json
 {
@@ -156,7 +156,7 @@ Here's an explanation of how the preceding template is constructed, broken down
 
 ### Pipelines
 
-* Any property in the path `activities/typeProperties/waitTimeInSeconds` is parameterized. Any activity in a pipeline that has a code-level property named `waitTimeInSeconds` (for example, the `Wait` activity) is parameterized as a number, with a default name. But it won't have a default value in the Resource Manager template. It will be a mandatory input during the Resource Manager deployment.
+* Any property in the path `activities/typeProperties/waitTimeInSeconds` is parameterized. Any activity in a pipeline that has a code-level property named `waitTimeInSeconds` (for example, the `Wait` activity) is parameterized as a number, with a default name. But it won't have a default value in the Resource Manager template. It is a mandatory input during the Resource Manager deployment.
 * Similarly, a property called `headers` (for example, in a `Web` activity) is parameterized with type `object` (JObject). It has a default value, which is the same value as that of the source factory.
 
 ### IntegrationRuntimes
@@ -170,16 +170,16 @@ Here's an explanation of how the preceding template is constructed, broken down
 
 ### LinkedServices
 
-* Linked services are unique. Because linked services and datasets have a wide range of types, you can provide type-specific customization. In this example, for all linked services of type `AzureDataLakeStore`, a specific template will be applied. For all others (via `*`), a different template will be applied.
-* The `connectionString` property will be parameterized as a `securestring` value. It won't have a default value. It will have a shortened parameter name that's suffixed with `connectionString`.
+* Linked services are unique. Because linked services and datasets have a wide range of types, you can provide type-specific customization. In this example, for all linked services of type `AzureDataLakeStore`, a specific template is applied. For all others (via `*`), a different template is applied.
+* The `connectionString` property is parameterized as a `securestring` value. It won't have a default value. It has a shortened parameter name that's suffixed with `connectionString`.
 * The property `secretAccessKey` happens to be an `AzureKeyVaultSecret` (for example, in an Amazon S3 linked service). It's automatically parameterized as an Azure Key Vault secret and fetched from the configured key vault. You can also parameterize the key vault itself.
 
 ### Datasets
 
 * Although type-specific customization is available for datasets, you can provide configuration without explicitly having a \*-level configuration. In the preceding example, all dataset properties under `typeProperties` are parameterized.
 
 > [!NOTE]
-> If **Azure alerts and matrices** are configured for a pipeline, they are not currently supported as parameters for ARM deployments. To reapply the alerts and matrices in new environment, please follow [Data Factory Monitoring, Alerts and Matrices.](./monitor-metrics-alerts.md)
+> If **Azure alerts and matrices** are configured for a pipeline, they aren't currently supported as parameters for ARM template deployments. To reapply the alerts and matrices in new environment, follow [Data Factory Monitoring, Alerts, and Matrices.](./monitor-metrics-alerts.md)
 > 
 
 ## Default parameterization template
@@ -331,7 +331,7 @@ Below is the current default parameterization template. If you need to add only
 
 ## Example: Parameterizing an existing Azure Databricks interactive cluster ID
 
-The following example shows how to add a single value to the default parameterization template. We only want to add an existing Azure Databricks interactive cluster ID for a Databricks linked service to the parameters file. Note that this file is the same as the previous file except for the addition of `existingClusterId` under the properties field of `Microsoft.DataFactory/factories/linkedServices`.
+The following example shows how to add a single value to the default parameterization template. We only want to add an existing Azure Databricks interactive cluster ID for a Databricks linked service to the parameters file. This file is the same as the previous file except for the addition of `existingClusterId` under the properties field of `Microsoft.DataFactory/factories/linkedServices`.
 
 ```json
 {

articles/data-factory/cross-tenant-connections-to-azure-devops.md

@@ -10,13 +10,13 @@ ms.date: 01/05/2024
 
 # Cross-tenant connections to Azure DevOps
 
-This document covers a step-by-step guide for configuring Azure DevOps account in another tenant than the Azure Data Factory.  This is useful for when your Azure DevOps is not in the same tenant as the Azure Data Factory.
+This document covers a step-by-step guide for configuring Azure DevOps organization in another tenant than the Azure Data Factory.  This is useful for when your Azure DevOps isn't in the same tenant as the Azure Data Factory.
 
 :::image type="content" source="media/cross-tenant-connections-to-azure-devops/cross-tenant-architecture-diagram.png" alt-text="Shows an architectural diagram of a connection from Azure Data Factory to Azure DevOps in another tenant.":::
 
 ## Prerequisites
 
-- You need to have an Azure DevOps account in another tenant than your Azure Data Factory. 
+- You need to have an Azure DevOps organization in another tenant than your Azure Data Factory. 
 - You should have a project in the above Azure DevOps tenant. 
 
 ## Step-by-step guide
@@ -33,7 +33,7 @@ This document covers a step-by-step guide for configuring Azure DevOps account i
 
    :::image type="content" source="media/cross-tenant-connections-to-azure-devops/cross-tenant-sign-in-confirm.png" alt-text="Shows the confirmation dialog for cross tenant sign in.":::
 
-1. Choose a different account to login to Azure DevOps in the remote tenant.
+1. Choose a different account to log in to Azure DevOps in the remote tenant.
 
    :::image type="content" source="media/cross-tenant-connections-to-azure-devops/use-another-account.png" alt-text="Shows the account selection dialog for choosing an account to connect to the remote Azure DevOps tenant.":::
 
@@ -49,6 +49,6 @@ This document covers a step-by-step guide for configuring Azure DevOps account i
 
 While opening the Azure Data Factory in another tab or a new browser, use the first sign-in to log into to your Azure Data Factory user account.
 
-You should see a dialog with the message _You do not have access to the VSTS repo associated with this factory._  Click **OK** to sign in with the cross-tenant account to gain access to Git through the Azure Data Factory.
+You should see a dialog with the message _You don't have access to the VSTS repo associated with this factory._  Select **OK** to sign in with the cross-tenant account to gain access to Git through the Azure Data Factory.
 
 :::image type="content" source="media/cross-tenant-connections-to-azure-devops/sign-in-with-account-with-repository-access.png" alt-text="Shows the sign-in prompt to associate a VSTS repo with a cross-tenant Azure Data Factory.":::