Draft updates

Author: ecfan

articles/logic-apps/create-single-tenant-workflows-azure-portal.md

@@ -61,13 +61,15 @@ In single-tenant Azure Logic Apps, workflows in the same logic app resource and
 
 * To deploy your Standard logic app resource to an [App Service Environment v3 (ASEv3) - Windows plan only](../app-service/environment/overview.md), you have to create this environment resource first. You can then select this environment as the deployment location when you create your logic app resource. For more information, review [Resources types and environments](single-tenant-overview-compare.md#resource-environment-differences) and [Create an App Service Environment](../app-service/environment/creation.md).
 
+* To enable communication from your Standard logic app workflows to a private endpoint on a Premium integration account, you must have an existing Azure virtual network. Both your logic app and virtual network must use the same Azure region. For more information, see [Create a virtual network](../virtual-network/quick-create-portal.md).
+
 * Starting mid-October 2022, new Standard logic app workflows in the Azure portal automatically use Azure Functions v4. Throughout November 2022, existing Standard workflows in the Azure portal are automatically migrating to Azure Functions v4. Unless you deployed your Standard logic apps as NuGet-based projects or pinned your logic apps to a specific bundle version, this upgrade is designed to require no action from you nor have a runtime impact. However, if the exceptions apply to you, or for more information about Azure Functions v4 support, see [Azure Logic Apps Standard now supports Azure Functions v4](https://techcommunity.microsoft.com/t5/integrations-on-azure-blog/azure-logic-apps-standard-now-supports-azure-functions-v4/ba-p/3656072).
 
 ## Best practices and recommendations
 
 For optimal designer responsiveness and performance, review and follow these guidelines:
 
-- Use no more than 50 actions per workflow. Exceeding this number of actions raises the possibility for slower designer performance. 
+- Use no more than 50 actions per workflow. Exceeding this number of actions raises the possibility for slower designer performance.
 
 - Consider splitting business logic into multiple workflows where necessary.
 
@@ -135,22 +137,30 @@ More workflows in your logic app raise the risk of longer load times, which nega
    | **Storage type** | Yes | - **Azure Storage** <br>- **SQL and Azure Storage** | The storage type that you want to use for workflow-related artifacts and data. <br><br>- To deploy only to Azure, select **Azure Storage**. <br><br>- To use SQL as primary storage and Azure Storage as secondary storage, select **SQL and Azure Storage**, and review [Set up SQL database storage for Standard logic apps in single-tenant Azure Logic Apps](set-up-sql-db-storage-single-tenant-standard-workflows.md). <br><br>**Note**: If you're deploying to an Azure region, you still need an Azure storage account, which is used to complete the one-time hosting of the logic app's configuration on the Azure Logic Apps platform. The workflow's state, run history, and other runtime artifacts are stored in your SQL database. <br><br>For deployments to a custom location that's hosted on an Azure Arc cluster, you only need SQL as your storage provider. |
    | **Storage account** | Yes | <*Azure-storage-account-name*> | The [Azure Storage account](../storage/common/storage-account-overview.md) to use for storage transactions. <br><br>This resource name must be unique across regions and have 3-24 characters with only numbers and lowercase letters. Either select an existing account or create a new account. <br><br>This example creates a storage account named **mystorageacct**. |
 
-1. On the **Networking** tab, you can leave the default options for this example.
-
-   For your specific, real-world scenarios, make sure to review and select the appropriate options. You can also change this configuration after you deploy your logic app resource. For more information, see [Secure traffic between Standard logic apps and Azure virtual networks using private endpoints](secure-single-tenant-workflow-virtual-network-private-endpoint.md).
+1. On the **Networking** tab, you can leave the default options for the example. However, for your specific, real-world scenarios, make sure to review and select the following appropriate options. You can also change this configuration after you deploy your logic app resource. For more information, see [Secure traffic between Standard logic apps and Azure virtual networks using private endpoints](secure-single-tenant-workflow-virtual-network-private-endpoint.md).
 
    | Enable public access | Behavior |
    |----------------------|----------|
-   | **On** | Your logic app has a public endpoint with an inbound address that's open to the internet and can't access an Azure virtual network. |
+   | **On** | Your logic app has a public endpoint with an inbound address that's open to the internet and can't access an Azure virtual network. <br><br>To enable communication between a Standard logic app and a private endpoint on a Premium integration account, select this option, but make sure to also set **Enable network injection** to **On**. |
    | **Off** | Your logic app has no public endpoint, but has a private endpoint instead for communication within an Azure virtual network, and is isolated to that virtual network. The private endpoint can communicate with endpoints in the virtual network, but only from clients within that network. This configuration also means that logic app traffic can be governed by network security groups or affected by virtual network routes. |
 
-   To enable your logic app to access endpoints in a virtual network, make sure to select the appropriate option:
+   The following settings control Standard logic app access to endpoints in a virtual network:
 
    | Enable network injection | Behavior |
    |--------------------------|----------|
-   | **On** | Your logic app workflows can privately and securely communicate with endpoints in the virtual network. |
+   | **On** | Your logic app workflows can privately and securely communicate with endpoints in the virtual network. <br><br>To enable communication between a Standard logic app and a private endpoint on a Premium integration account, select this option, which also makes the **Virtual Network** section available. For **Virtual Network**, select the Azure virtual network to use. This choice makes the **Inbound access** and **Outbound access** sections available. |
    | **Off** | Your logic app workflows can't communicate with endpoints in the virtual network. |
 
+   The following sections appear after you select a virtual network when **Enable network injection** is set to **On**.
+
+   **Inbound access**
+
+   - **Enable private endpoints**: Applies to private endpoints on your Standard logic app and is available only when **Enable public access** is set to **Off**.
+
+   **Outbound access**
+
+   - **Enable VNet integration**: To enable communication between a Standard logic app and a private endpoint on a Premium integration account, select **On** and the subnet to use.
+
 1. If your creation and deployment settings support using [Application Insights](../azure-monitor/app/app-insights-overview.md), you can optionally enable diagnostics logging and tracing for your logic app workflows.
 
    1. On the **Monitoring** tab, under **Application Insights**, set **Enable Application Insights** to **Yes** if not already selected.

articles/logic-apps/enterprise-integration/create-integration-account.md

@@ -193,7 +193,7 @@ To read artifacts and write any state information, your Premium integration acco
 
 <a name="set-up-private-endpoint"></a>
 
-## Set up private endpoint for Premium integration account
+## Set up private endpoint for Premium integration account (Preview)
 
 To create a private connection between your Premium integration account and Azure services, you can [set up a private endpoint for your integration account](#set-up-private-endpoint). A [private endpoint](../../private-link/private-endpoint-overview.md) is a network interface that uses a private IP address from your Azure virtual network. This way, traffic between your virtual network and Azure services stays on the Azure backbone network and never traverses the public internet. Private endpoints ensure a secure, private communication channel between your resources and Azure services by providing the following benefits:
 
@@ -207,6 +207,10 @@ To create a private connection between your Premium integration account and Azur
 
 - Saves on costs by reducing extra network infrastructure and avoiding data egress charges through public endpoints.
 
+### Limitations
+
+Only Standard logic app workflows can use private endpoints on a Premium integration account.
+
 ### Best practices for private endpoints
 
 - Carefully plan your virtual network and subnet architecture to accommodate private endpoints. Make sure to properly segment and secure your subnets.
@@ -219,7 +223,7 @@ To create a private connection between your Premium integration account and Azur
 
 - Regularly monitor network traffic to and from your private endpoints. Audit and analyze traffic patterns by using tools such as Azure Monitor and Azure Security Center.
 
-### Create and use a private endpoint
+### Create a private endpoint
 
 Before you start, make sure that you have an [Azure virtual network](../../virtual-network/quick-create-portal.md) defined with the appropriate subnets and network security groups to manage and secure traffic.
 
@@ -241,7 +245,7 @@ Before you start, make sure that you have an [Azure virtual network](../../virtu
 
    | Property | Value |
    |----------|-------|
-   | **Connection method** | **Connect to an Azure resource in my directory** |
+   | **Connection method** | - **Connect to an Azure resource in my directory**: Creates a private endpoint that is *automatically approved* and ready for immediate use. The endpoint's **Connection status** property is set to **Approved** after creation. <br><br>- **Connect to an Azure resource by resource ID or alias**: Create a private endpoint that is *manually approved* and requires data administrator approval before anyone can use. The endpoint's **Connection status** property is set to **Pending** after creation. <br><br>**Note**: If the endpoint is manually approved, the **DNS** tab is unavailable. |
    | **Subscription** | <*Azure-subscription*> |
    | **Resource type** | **Microsoft.Logic/integrationAccounts** |
    | **Resource** | <*Premium-integration-account*> |
@@ -267,6 +271,52 @@ Before you start, make sure that you have an [Azure virtual network](../../virtu
 
 1. After you confirm that Azure created the private endpoint, check your connectivity and test your setup to make sure that the resources in your virtual network can securely connect to the your integration account through the private endpoint.
 
+### View pending endpoint connections
+
+For a private endpoint that requires approval, follow these steps:
+
+1. In the Azure portal, go to the **Private Link** page.
+
+1. On the left menu, select **Pending connections**.
+
+### Approve a pending private endpoint
+
+For a private endpoint that requires approval, follow these steps:
+
+1. In the Azure portal, go to the **Private Link** page.
+
+1. On the left menu, select **Pending connections**.
+
+1. Select the pending connection. On the toolbar, select **Approve**. Wait for the operation to finish.
+
+   The endpoint's **Connection status** property changes to **Approved**.
+
+<a name="call-integration-account-api"></a>
+
+### Enable Standard logic app calls through private endpoint on Premium integration account
+
+1. Choose one of the following options:
+
+   - To create a Standard logic app that can communicate through the private endpoint on a Premium integration account, see [Create example Standard logic app workflow in single-tenant Azure Logic Apps](../create-single-tenant-workflows-azure-portal.md#create-logic-app-resource).
+
+   - To set up an existing Standard logic app that can communicate through the private endpoint on a Premium integration account, see [Set up virtual network integration](../secure-single-tenant-workflow-virtual-network-private-endpoint.md#set-up-virtual-network-integration).
+
+1. To make calls through the private endpoint, include an **HTTP** action in your Standard logic app workflow where you want to call the integration account.
+
+1. In the Azure portal, go to your Premium integration account. On the integration account menu, under **Settings**, select **Callback URL**, and copy the URL.
+
+1. In your workflow's **HTTP** action, on the **Parameters** tab, in the **URI** property, enter the callback URL using the following format:
+
+   **`https://{domain-name}-{integration-account-ID}.cy.integrationaccounts.microsoftazurelogicapps.net:443/integrationAccounts/{integration-account-ID}?api-version=2015-08-01-preview&sp={sp}&sv={sv}&sig={sig}`**
+
+   The following example shows sample values:
+
+   `https://prod-02-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.cy.integrationaccounts.microsoftazurelogicapps.net:443/integrationAccounts/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX?api-version=2015-08-01-preview&sp={sp}&sv={sv}&sig={sig}`
+
+1. For the **HTTP** action's **Method** property, select **GET**.
+
+1. Finish setting up the **HTTP** action as necessary, and test your workflow.
+
 <a name="link-account"></a>
 
 ## Link to logic app

articles/logic-apps/secure-single-tenant-workflow-virtual-network-private-endpoint.md

@@ -152,6 +152,8 @@ For more information, review the following documentation:
 
    The HTTP action fails, which is by design and expected because the workflow runs in the cloud and can't access your internal service.
 
+<a name="set-up-virtual-network-integration"></a>
+
 ### Set up virtual network integration
 
 1. In the Azure portal, on the logic app resource menu, under **Settings**, select **Networking**.