PR review fixes

Author: jonburchel

articles/connectors/built-in.md

@@ -106,8 +106,8 @@ You can use the following built-in connectors to perform general tasks, for exam
     :::column:::
         [![Request trigger icon][http-request-icon]][http-request-doc]
         <br><br>[**Request**][http-request-doc]
-        <br><br>[**When a HTTP request is received**][http-request-doc]: Wait for a request from another workflow, app, or service. This trigger makes your workflow callable without having to be checked or polled on a schedule.
-        <br><br>[**Response**][http-request-doc]: Respond to a request received by the **When a HTTP request is received** trigger in the same workflow.
+        <br><br>[**When an HTTP request is received**][http-request-doc]: Wait for a request from another workflow, app, or service. This trigger makes your workflow callable without having to be checked or polled on a schedule.
+        <br><br>[**Response**][http-request-doc]: Respond to a request received by the **When an HTTP request is received** trigger in the same workflow.
     :::column-end:::
     :::column:::
         [![Batch icon][batch-icon]][batch-doc]
@@ -209,7 +209,7 @@ You can use the following built-in connectors to access specific services and sy
     :::column:::
         [![Azure Logic Apps icon][azure-logic-apps-icon]][nested-logic-app-doc]
         <br><br>[**Azure Logic Apps**][nested-logic-app-doc]<br>(*Consumption workflow*) <br><br>-or-<br><br>**Workflow Operations**<br>(*Standard workflow*)
-        <br><br>Call other workflows that start with the Request trigger named **When a HTTP request is received**.
+        <br><br>Call other workflows that start with the Request trigger named **When an HTTP request is received**.
     :::column-end:::
     :::column:::
         [![Azure OpenAI icon][azure-openai-icon]][azure-openai-doc]
@@ -478,7 +478,7 @@ For more information, review the following documentation:
         <br><br>[**XML Operations**][xml-operations-doc]
         <br><br>Perform operations with XML.
         <br><br>**Compose XML with schema**: Create XML from JSON using a schema for a Standard workflow.
-        <br><br>**Parse XML with schema**: Parse XML using a schema for a Standard workflow..
+        <br><br>**Parse XML with schema**: Parse XML using a schema for a Standard workflow.
         <br><br>**Transform XML**: Convert XML using a map.
         <br><br>**Validate XML**: Validate inbound or outbound XML using a schema.
     :::column-end:::

articles/container-apps/networking.md

@@ -153,7 +153,7 @@ Different environment types have different subnet requirements:
     | /26 | 52 | 26 | 260 |
     | /27 | 20 | 10 | 100 |
 
-    <sup>1</sup> The available IP addresses is the size of the subnet minus the 12 IP addresses required for Azure Container Apps infrastructure.  
+    <sup>1</sup> The available IP addresses are the size of the subnet minus the 12 IP addresses required for Azure Container Apps infrastructure.  
     <sup>2</sup> This is accounting for apps in single revision mode.  
 
 # [Consumption only environment](#tab/consumption-only-env)
@@ -219,7 +219,7 @@ If you're using the Azure CLI with a Consumption only environment and the [platf
 User Defined Routes (UDR) and controlled egress through NAT Gateway are supported in the workload profiles environment. In the Consumption only environment, these features aren't supported.
 
 > [!NOTE]
-> When using UDR with Azure Firewall in Azure Container Apps, you need to add certain FQDN's and service tags to the allowlist for the firewall. To learn more, see [configuring UDR with Azure Firewall](./networking.md#configuring-udr-with-azure-firewall).
+> When using UDR with Azure Firewall in Azure Container Apps, you need to add certain FQDNs and service tags to the allowlist for the firewall. To learn more, see [configuring UDR with Azure Firewall](./networking.md#configuring-udr-with-azure-firewall).
 
 - You can use UDR with workload profiles environments to restrict outbound traffic from your container app through Azure Firewall or other network appliances.
 
@@ -231,10 +231,10 @@ Azure creates a default route table for your virtual networks upon create. By im
 
 #### Configuring UDR with Azure Firewall
 
-User defined routes is only supported in a workload profiles environment. The following application and network rules must be added to the allowlist for your firewall depending on which resources you're using.
+User defined routes are only supported in a workload profiles environment. The following application and network rules must be added to the allowlist for your firewall depending on which resources you're using.
 
 > [!NOTE]
-> For a guide on how to setup UDR with Container Apps to restrict outbound traffic with Azure Firewall, visit the [how to for Container Apps and Azure Firewall](./user-defined-routes.md).
+> For a guide on how to set up UDR with Container Apps to restrict outbound traffic with Azure Firewall, visit the [how to for Container Apps and Azure Firewall](./user-defined-routes.md).
 
 ##### Application rules
 
@@ -298,15 +298,15 @@ This feature is supported for both Consumption and Dedicated plans in workload p
 
 #### Considerations
 - Private endpoints on Azure Container Apps only support inbound HTTP traffic. TCP traffic is not supported.
-- To use a private endpoint with a custom domain and an *Apex domain* as the *Hostname record type*, you must configure a private DNS zone with the same name as your public DNS. In the record set, configure your private endpoint's private IP address instead of the container app environment's IP address. When configuring your custom domain with CNAME, the setup is unchanged. For more information, see [Set up custom domain with existing certificate](custom-domains-certificates.md).
+- To use a private endpoint with a custom domain and an *Apex domain* as the *Hostname record type*, you must configure a private DNS zone with the same name as your public DNS. In the record set, configure your private endpoint's private IP address instead of the container app environment's IP address. When you configure your custom domain with CNAME, the setup is unchanged. For more information, see [Set up custom domain with existing certificate](custom-domains-certificates.md).
 - Your private endpoint's VNet can be separate from the VNet integrated with your container app.
 - You can add a private endpoint to both new and existing workload profile environments.
 
 In order to connect to your container apps through a private endpoint, you must configure a private DNS zone.
 
 | Service | subresource | Private DNS zone name |
 |--|--|--|
-| Azure Container Apps (Microsoft.App/ManagedEnvironments) | managedEnvironment | privatelink.{regionName}.azurecontainerapps.io |
+| Azure Container Apps (Microsoft.App/ManagedEnvironments) | managedEnvironment | private link.{regionName}.azurecontainerapps.io |
 
 ### Environment security
 

articles/data-factory/azure-ssis-integration-runtime-express-virtual-network-injection.md

@@ -3,7 +3,7 @@ title: Configure a virtual network for express injection of Azure-SSIS integrati
 description: Learn how to configure a virtual network for express injection of Azure-SSIS integration runtime. 
 ms.subservice: integration-services
 ms.topic: conceptual
-ms.date: 10/20/2023
+ms.date: 01/08/2025
 author: chugugrace
 ms.author: chugu 
 ---
@@ -12,31 +12,31 @@ ms.author: chugu
 
 [!INCLUDE[appliesto-adf-asa-md](includes/appliesto-adf-asa-md.md)]
 > [!NOTE]
-> Express virtual network injection feature is not supported for SSIS integration runtime in below regions yet:
+> Express virtual network injection feature isn't supported for SSIS integration runtime in below regions yet:
 >
 >- Jio India West or Switzerland West
 >- US Gov Texas or US Gov Arizona
 >- China North 2 or China East 2
 
-When using SQL Server Integration Services (SSIS) in Azure Data Factory (ADF) or Synapse Pipelines, there are two methods for you to join your Azure-SSIS integration runtime (IR) to a virtual network: standard and express. If you use the express method, you need to configure your virtual network to meet these requirements: 
+When you use SQL Server Integration Services (SSIS) in Azure Data Factory (ADF) or Synapse Pipelines, there are two methods for you to join your Azure-SSIS integration runtime (IR) to a virtual network: standard and express. If you use the express method, you need to configure your virtual network to meet these requirements: 
 
 - Make sure that *Microsoft.Batch* is a registered resource provider in Azure subscription that has the virtual network for your Azure-SSIS IR to join. For detailed instructions, see the [Register Azure Batch as a resource provider](azure-ssis-integration-runtime-virtual-network-configuration.md#registerbatch) section.
 
 - Make sure that there's no resource lock in your virtual network.
 
-- Select a proper subnet in the virtual network for your Azure-SSIS IR to join. For more information, see the [Select a subnet](#subnet) section below.
+- Select a proper subnet in the virtual network for your Azure-SSIS IR to join. For more information, see the [Select a subnet](#subnet) section that follows.
 
-- Make sure that the user creating Azure-SSIS IR is granted the necessary role-based access control (RBAC) permissions to join the virtual network/subnet.  For more information, see the [Select virtual network permissions](#perms) section below.
+- Make sure that the user creating Azure-SSIS IR is granted the necessary role-based access control (RBAC) permissions to join the virtual network/subnet.  For more information, see the [Select virtual network permissions](#perms) section that follows.
 
-Depending on your specific scenario, you can optionally configure the following:
+Depending on your specific scenario, you can optionally configure the following settings:
 
-- If you want to use a static public IP address for the outbound traffic of your Azure-SSIS IR, see the [Configure a static public IP address](#ip) section below.
+- If you want to use a static public IP address for the outbound traffic of your Azure-SSIS IR, see the [Configure a static public IP address](#ip) section that follows.
 
-- If you want to use your own domain name system (DNS) server in the virtual network, see the [Configure a custom DNS server](#dns) section below.
+- If you want to use your own domain name system (DNS) server in the virtual network, see the [Configure a custom DNS server](#dns) section that follows.
 
-- If you want to use a network security group (NSG) to limit outbound traffic on the subnet, see the [Configure an NSG](#nsg) section below.
+- If you want to use a network security group (NSG) to limit outbound traffic on the subnet, see the [Configure an NSG](#nsg) section that follows.
 
-- If you want to use user-defined routes (UDRs) to audit/inspect outbound traffic, see the [Configure UDRs](#udr) section below.
+- If you want to use user-defined routes (UDRs) to audit/inspect outbound traffic, see the [Configure UDRs](#udr) section that follows.
 
 This diagram shows the required connections for your Azure-SSIS IR:
 
@@ -58,7 +58,7 @@ To enable express virtual network injection, you must select a proper subnet for
 
 To enable express virtual network injection, the user creating Azure-SSIS IR must be granted the necessary RBAC permissions to join the virtual network/subnet. You have two options:
 
-- Use the built-in *Network Contributor* role. This role comes with the _Microsoft.Network/\*_ permission, which has a much larger scope than necessary.
+- Use the built-in *Network Contributor* role. This role comes with the _Microsoft.Network/\*_ permission, which has a larger scope than necessary.
 
 - Create a custom role that includes only the necessary *Microsoft.Network/virtualNetworks/subnets/join/action* permission.
 
@@ -76,7 +76,7 @@ We recommend you configure your own DNS server to forward unresolved DNS request
 
 For more information, see the [DNS server name resolution](../virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances.md#name-resolution-that-uses-your-own-dns-server) section.
 
-At present, for Azure-SSIS IR to use your own DNS server, you need to configure it with a standard custom setup following these steps:
+Now, for Azure-SSIS IR to use your own DNS server, you need to configure it with a standard custom setup following these steps:
 
 1. Download a custom setup script main.cmd + its associated file setupdnsserver.ps1.
 
@@ -85,7 +85,7 @@ At present, for Azure-SSIS IR to use your own DNS server, you need to configure
 1. Upload main.cmd + setupdnsserver.ps1 into your own Azure Storage blob container for standard custom setup and enter its SAS URI when provisioning Azure-SSIS IR, see the [Customizing Azure-SSIS IR](how-to-configure-azure-ssis-ir-custom-setup.md) article.
 
 > [!NOTE]
-> Please use a Fully Qualified Domain Name (FQDN) for your private hostname (for example, use `<your_private_server>.contoso.com` instead of `<your_private_server>`). Alternatively, you can use a standard custom setup on your Azure-SSIS IR to automatically append your own DNS suffix (for example `contoso.com`) to any unqualified single label domain name and turn it into an FQDN before using it in DNS queries, see the [Standard custom setup samples](how-to-configure-azure-ssis-ir-custom-setup.md#standard-custom-setup-samples) section. 
+> Use a Fully Qualified Domain Name (FQDN) for your private hostname (for example, use `<your_private_server>.contoso.com` instead of `<your_private_server>`). Alternatively, you can use a standard custom setup on your Azure-SSIS IR to automatically append your own DNS suffix (for example `contoso.com`) to any unqualified single label domain name and turn it into an FQDN before using it in DNS queries, see the [Standard custom setup samples](how-to-configure-azure-ssis-ir-custom-setup.md#standard-custom-setup-samples) section. 
 
 ## <a name="nsg"></a>Configure an NSG