Edits per feedback

Author: ecfan

articles/connectors/apis-list.md

@@ -137,17 +137,17 @@ To make sure that your workflow runs at your specified start time and doesn't mi
 
 ## Custom connectors and APIs
 
-In Consumption logic apps, you can call APIs that run custom code or aren't available as connectors in the following ways:
+In Consumption logic apps that run in multi-tenant Azure Logic Apps, you can call Swagger-based or SOAP-based APIs that aren't available as connectors or run custom code in the following ways:
 
-* [Create custom API Apps](../logic-apps/logic-apps-create-api-app.md)
-
-* [Create custom connectors](../logic-apps/custom-connector-overview.md) for REST or SOAP-based APIs [up to specific limits](../logic-apps/logic-apps-limits-and-config.md#custom-connector-limits).
+* [About custom connectors for Consumption logic apps](../logic-apps/custom-connector-overview.md#custom-connector-consumption)
 
   Custom connectors make these APIs available to any Consumption logic app in your Azure subscription. To make custom API Apps or connectors public for anyone to use in Azure, you can [submit connectors for Microsoft certification](/connectors/custom-connectors/submit-certification).
 
-In Standard logic apps, you can create natively running custom [built-in connectors](../connectors/built-in.md) that are available to any Standard logic app. For more information, review the following documentation:
+* [Create custom API Apps](../logic-apps/logic-apps-create-api-app.md)
+
+In Standard logic apps, you can create natively running [service provider-based custom built-in connectors](../connectors/built-in.md) that are available to any Standard logic app. For more information, review the following documentation:
 
-* [Custom connectors for Standard logic apps](../logic-apps/custom-connector-overview.md#custom-connector-standard)
+* [About custom built-in connectors for Standard logic apps](../logic-apps/custom-connector-overview.md#custom-connector-standard)
 
 * [Create custom built-in connectors for Standard logic apps](../logic-apps/create-custom-built-in-connector-standard.md)
 

articles/logic-apps/create-custom-built-in-connector-standard.md

@@ -51,7 +51,7 @@ The following outline describes the high-level steps to build the example connec
 
 1. In your project, add the **Microsoft.Azure.Workflows.WebJobs.Extension** NuGet package as a NuGet reference.
 
-1. Provide the operations and operation descriptions for your built-in connector by using the NuGet package to implement methods for the interfaces named [**IServiceOperationsProvider**](custom-connector-overview.md#iserviceoperationsprovider) and [**IServiceOperationsTriggerProvider**](custom-connector-overview.md#iserviceoperationstriggerprovider).
+1. Provide the operations for your built-in connector by using the NuGet package to implement the methods for the interfaces named [**IServiceOperationsProvider**](custom-connector-overview.md#iserviceoperationsprovider) and [**IServiceOperationsTriggerProvider**](custom-connector-overview.md#iserviceoperationstriggerprovider).
 
 1. Register your custom built-in connector with the Azure Functions runtime extension.
 
@@ -65,21 +65,21 @@ The following outline describes the high-level steps to build the example connec
 
 ## Implement the service provider interface
 
-To provide the operations and their descriptions for the sample built-in connector, in the **Microsoft.Azure.Workflows.WebJobs.Extension** NuGet package, implement the methods for the following interfaces. The following diagram shows the interfaces with the method implementations that the Azure Logic Apps designer and runtime expect for a custom built-in connector that has an Azure Functions-based trigger:
+To provide the operations for the sample built-in connector, in the **Microsoft.Azure.Workflows.WebJobs.Extension** NuGet package, implement the methods for the following interfaces. The following diagram shows the interfaces with the method implementations that the Azure Logic Apps designer and runtime expect for a custom built-in connector that has an Azure Functions-based trigger:
 
 ![Conceptual class diagram showing method implementation for sample Cosmos DB custom built-in connector.](./media/create-custom-built-in-connector-standard/service-provider-cosmos-db-example.png)
 
 ### IServiceOperationsProvider
 
-This interface includes the following methods that provide the operation descriptions and operation invocations required from your custom built-in connector. For more information, review [IServiceOperationsProvider](custom-connector-overview.md#iserviceoperationsprovider).
+This interface includes the following methods that provide the operation manifest and performs your service provider's specific tasks or actual business logic in your custom built-in connector. For more information, review [IServiceOperationsProvider](custom-connector-overview.md#iserviceoperationsprovider).
 
 * [**GetService()**](#getservice)
 
   The designer in Azure Logic Apps requires the [**GetService()**](#getservice) method to retrieve the high-level description for your custom service, including the service description, connection input parameters required on the designer, capabilities, brand color, icon URL, and so on.
 
 * [**GetOperations()**](#getoperations)
 
-  The designer in Azure Logic Apps requires the [**GetOperations()**](#getoperations) method to retrieve the operations implemented by your custom service. The operations list is based on Swagger schema. The designer also uses operation descriptions to understand the input parameters for specific operations and generate the outputs as property tokens, based on the schema of the output for an operation.
+  The designer in Azure Logic Apps requires the [**GetOperations()**](#getoperations) method to retrieve the operations implemented by your custom service. The operations list is based on Swagger schema. The designer also uses the operation metadata to understand the input parameters for specific operations and generate the outputs as property tokens, based on the schema of the output for an operation.
 
 * [**GetBindingConnectionInformation()**](#getbindingconnectioninformation)
 
@@ -99,7 +99,7 @@ You can add or expose an [Azure Functions trigger or action](../azure-functions/
 
 * The [**GetFunctionTriggerType()**](#getfunctiontriggertype) method is required to return the string that's the same as the **type** parameter in the Azure Functions trigger binding.
 
-* The [**GetFunctionTriggerDefinition()**](#getfunctiontriggerdefinition) has a default implementation, so you don't need to explicitly implement this method.
+* The [**GetFunctionTriggerDefinition()**](#getfunctiontriggerdefinition) has a default implementation, so you don't need to explicitly implement this method. However, if you want to update the trigger's default behavior, such as provide extra parameters that the designer doesn't expose, you can implement this method and override the default behavior.
 
 ### Methods to implement
 
@@ -170,7 +170,7 @@ public string GetFunctionTriggerType()
 
 #### GetFunctionTriggerDefinition()
 
-This method has a default implementation, so you don't need to explicitly implement this method.
+This method has a default implementation, so you don't need to explicitly implement this method. However, if you want to update the trigger's default behavior, such as provide extra parameters that the designer doesn't expose, you can implement this method and override the default behavior.
 
 <a name="register-connector"></a>
 
@@ -216,7 +216,7 @@ The following sections show how to register your custom built-in connector as an
 
 ### Register the service provider
 
-Now, register the service provider implementation as an Azure Functions extension. This example uses the built-in [Azure Cosmos DB trigger for Azure Functions](../azure-functions/functions-bindings-cosmosdb-v2-trigger.md?tabs=in-process%2Cfunctionsv2&pivots=programming-language-csharp) as a new trigger. This example also registers the new Cosmos DB service provider for an existing list of service providers, which is already part of the Azure Logic Apps extension. For more information, review [Register Azure Functions binding extensions](../azure-functions/functions-bindings-register.md).
+Now, register the service provider implementation as an Azure Functions extension with the Azure Logic Apps engine. This example uses the built-in [Azure Cosmos DB trigger for Azure Functions](../azure-functions/functions-bindings-cosmosdb-v2-trigger.md?tabs=in-process%2Cfunctionsv2&pivots=programming-language-csharp) as a new trigger. This example also registers the new Cosmos DB service provider for an existing list of service providers, which is already part of the Azure Logic Apps extension. For more information, review [Register Azure Functions binding extensions](../azure-functions/functions-bindings-register.md).
 
 ```csharp
 using Microsoft.Azure.Documents;

articles/logic-apps/custom-connector-overview.md

@@ -31,7 +31,7 @@ This article provides an overview about custom connectors for [Consumption logic
 
 ## Consumption logic apps
 
-In [multi-tenant Azure Logic Apps](logic-apps-overview.md), you can create [Swagger-based or SOAP-based custom connectors](/connectors/custom-connectors/) from REST APIs to use in Consumption logic app workflows. The [Connectors documentation](/connectors/connectors) provides more overview information about how to create custom connectors for Consumption logic apps, including complete basic and advanced tutorials. The following list also provides direct links to information about custom connectors for Consumption logic apps:
+In [multi-tenant Azure Logic Apps](logic-apps-overview.md), you can create [custom connectors from Swagger-based or SOAP-based APIs](/connectors/custom-connectors/) up to [specific limits](../logic-apps/logic-apps-limits-and-config.md#custom-connector-limits) for use in Consumption logic app workflows. The [Connectors documentation](/connectors/connectors) provides more overview information about how to create custom connectors for Consumption logic apps, including complete basic and advanced tutorials. The following list also provides direct links to information about custom connectors for Consumption logic apps:
 
   * [Create an Azure Logic Apps connector](/connectors/custom-connectors/create-logic-apps-connector)
   * [Create a custom connector from an OpenAPI definition](/connectors/custom-connectors/define-openapi-definition)
@@ -87,19 +87,19 @@ The following sections provide more information about the interfaces that your c
 
 #### IServiceOperationsProvider
 
-This interface includes the methods that provide the operation descriptions and invocations for your custom built-in connector.
+This interface includes the methods that provide the operations manifest for your custom built-in connector.
 
-* Operation descriptions
+* Operations manifest
 
-  Operation descriptions are metadata about the implemented operations in your custom built-in connector. The Azure Logic Apps designer primarily uses these descriptions to drive the authoring and monitoring experiences for your connector's operations. For example, the designer uses operation descriptions to understand the input parameters required by a specific operation and to facilitate generating the outputs' property tokens, based on the schema for the operation's outputs.
+  The operations manifest includes metadata about the implemented operations in your custom built-in connector. The Azure Logic Apps designer primarily uses this metadata to drive the authoring and monitoring experiences for your connector's operations. For example, the designer uses operation metadata to understand the input parameters required by a specific operation and to facilitate generating the outputs' property tokens, based on the schema for the operation's outputs.
 
   The designer requires and uses the [**GetService()**](#getservice) and [**GetOperations()**](#getoperations) methods to query the operations that your connector provides and shows on the designer surface. The **GetService()** method also specifies the connection's input parameters that are required by the designer.
 
   For more information about these methods and their implementation, review the [Methods to implement](#method-implementation) section later in this article.
 
 * Operation invocations
 
-  Operation invocations are the implementations used during workflow execution by the Azure Logic Apps runtime to call the specified operation in the workflow definition.
+  Operation invocations are the method implementations used during workflow execution by the Azure Logic Apps runtime to call the specified operations in the workflow definition.
 
   * If your trigger is an Azure Functions-based trigger type, the [**GetBindingConnectionInformation()**](#getbindingconnectioninformation) method is used by the runtime in Azure Logic Apps to provide the required connection parameters information to the Azure Functions trigger binding.
 
@@ -113,7 +113,7 @@ Custom built-in trigger capabilities support adding or exposing an [Azure Functi
 
 * The [**GetFunctionTriggerType()**](#getfunctiontriggertype) method is required to return the string that's the same as the **type** parameter in the Azure Functions trigger binding.
 
-* The [**GetFunctionTriggerDefinition()**](#getfunctiontriggerdefinition) has a default implementation, so you don't need to explicitly implement this method.
+* The [**GetFunctionTriggerDefinition()**](#getfunctiontriggerdefinition) has a default implementation, so you don't need to explicitly implement this method. However, if you want to update the trigger's default behavior, such as provide extra parameters that the designer doesn't expose, you can implement this method and override the default behavior.
 
 <a name="method-implementation"></a>
 
@@ -136,7 +136,7 @@ For more information, review [Sample CosmosDbServiceOperationProvider.cs](https:
 
 #### GetOperations()
 
-The designer requires this method to get the operations implemented by your service. The operations list is based on Swagger schema. The designer also uses operation descriptions to understand the input parameters for specific operations and generate the outputs as property tokens, based on the schema of the output for an operation.
+The designer requires this method to get the operations implemented by your service. The operations list is based on Swagger schema. The designer also uses the operation metadata to understand the input parameters for specific operations and generate the outputs as property tokens, based on the schema of the output for an operation.
 
 ```csharp
 public IEnumerable<ServiceOperation> GetOperations(bool expandManifest)
@@ -200,7 +200,7 @@ For more information, review [Sample CosmosDbServiceOperationProvider.cs](https:
 
 #### GetFunctionTriggerDefinition()
 
-This method has a default implementation, so you don't need to explicitly implement this method.
+This method has a default implementation, so you don't need to explicitly implement this method. However, if you want to update the trigger's default behavior, such as provide extra parameters that the designer doesn't expose, you can implement this method and override the default behavior.
 
 ## Next steps