Similar to Azure DevOps, Logic Apps hosts a marketplace of connectors, triggers and steps. Unfortunately, these are always the "latest" version per Microsoft's whim.

If a breaking change is introduced, the customer must scramble to meet spec or else, have a broken integration. Microsoft does it's best to communicate changes, but the lead time is arbitrary - not every team has the same capacity to absorb changes and some customer may be impacted more often than others.

It would be prudent to follow Azure DevOps lead by introducing a "version selector" on each step. This will grant both the developer and Microsoft flexibility choosing when to adopt or publish new features into Logic Apps.

Currently it is not possible to run a Logic App inside Power Platform environment in the same way as Flow.

As of 9-23-2019 the Power Platform environment provides integration with Microsoft Flow, PowerApps, and Power BI, but not Logic Apps.
It would be nice to be able to add an Azure Logic App to a Power Platform Solution (e.g. a Model Driven App) in a similar way as one could add a Flow. For some projects the Logic Apps per-action billing as opposed to per-flow-run billing (and also, all the features that only exist in Logic Apps) would be really nice to leverage. Even better is if the Azure Logic App, when added from Model Driven App, can support being aware of the Power Platform environment it has been deployed in for Common Data Service. So whenever Common Data Service triggers or actions are used, there would be the ability to automatically scope them to the current environment. A very, very loose comparison would be how Flow currently has a (Current) selector at design time, a feature introduced relatively recently to Flow.

To make this really usable, furthermore, it may be nice for the ability to automatically find and replace any instances of the HTTP Action that calls a Logic App (“child Logic Apps”), with the URL of each Logic App of the imported solution. As a matter of fact, even just in general, when Logic Apps are chained, there is no true way to associate them with each other. The HTTP Action calls a hard-coded URL. There should be ability to select the Logic App specifically, especially if designed in the context of a Model Driven App.

Therefore, we would further suggest that there should also be the concept of a “Logic App Set”. We’ll first describe this, and the use cases of this even without Power Platform integration first, then go into how this could work together with Power Platform. Actions inside a Logic App of a Logic App Set can call another Logic App in that set, through a “Logic App Action Call” (rather than an HTTP Action with the URL hard coded – would be pretty much same thing except the URL will not be asked for, but a Logic App from Azure).

The Logic App Set should furthermore be easily cloned in entirety. The new Logic Apps with HTTP Request Triggers will have different URL’s – however, the “Logic App Action” will automatically know where those manual triggers are and adjust all of the internal Logic Apps Action Calls accordingly.

Applying this philosophy to Power Platform, the Logic App Set and all the Logic Apps that are part of that set will also automatically be aware of the current Common Data Service environment.

Other corollaries of this idea could include the ability to run not just a Flow, but a “Logic App” from the command bar of a Model Driven App in Power Platform, if one or more Logic Apps were included in the solution (managed or unmanaged).

One use case could be where it is desired to utilize billing on a per action basis rather than amount of Flow runs. For example, if it is desired the application, or model driven app / solution (unmanaged and managed alike) should benefit from good Logic App development practices that are optimized for per-action billing. For instance, certain well-architected Logic Apps that use sound practices such as chaining (you sometimes call this “child Logic App” or “child Flow”) and that are easy to maintain, loosely coupled, and properly modularized, tend to use up a lot of Flow runs and could technically cost more, than if it were billed as the equivalent Azure Logic Apps “per action” billing.
Furthermore, many advanced development features could only exist, and may always only exist, exclusively in Azure Logic Apps, not in Microsoft Flow.

In sum, a feature like this would really bring Azure and Power Platform together in a way that could make a lot of interesting ideas and advanced, well-functioning integrations implementations able to work together in tandem seamlessly.

Current workarounds that exist:

Logic Apps does have the ability to export to Power Apps and Flow and then get called as a custom connector from PowerApps and Flow.
One can do this by opening a Logic App and click on the Export button on the top right. Then, once exported to PowerApps and Flow, you would see that Logic App in the list of custom connectors for Flow.

This would be only for Logic Apps that use HTTP request trigger – which is the way PowerApps or Flow will invoke it.

Other workarounds that can currently be done include something like this: in a model driven app, a Flow can be added in which all it does is have an HTTP Action with the HTTP Request Trigger of the Logic App hard-coded into it.

However, this kind of workaround cannot truly accomplish the type of componentized solution development of leveraging Logic Apps natively with Power Platform. The Logic App called in this way still has to manually connect to the Common Data service entity and manually select the specific Power Platform environment, whereas if this feature idea were implemented, these hard-coded details are abstracted away into automatic context-aware modules that can be easily cloned, exported, and imported across different Azure tenants and Power Platform environments.

The ReceiverQualifier and SenderQualifier are optional in some EDI files, but to create a Partner is necessary to select a Qualifier value and there isn't the option to select something similar to "<NotValued>" as in BizTalk. MS has said: "This is already possible today except that the UI doesn’t support it." So we are following this advice but this limits automation possibilities including breaking some we had in place. If you use the “EditAsJson” view you end up with an invalid Agreement in some ways. For instance, Set-AzureRMIntegrationAccountAgreement requires a non-empty HostIdentity.Value and GuestIdentity.Value as does New-AzureRMIntegrationAccountAgreement.
You can use the “EditAsJson” view from the portal and provide empty values and runtime will work."