Showing results for 
Search instead for 
Did you mean: 
0 Kudos

New Power platform App type (API App)

We currently have Model driven apps, canvas apps and recently Portal Apps, those are great and have really high potentials. I would suggest creating a fourth type called "API App" without an end user-interface, jsut for developers, where you can easily build the neccasry API collection that is needed to integrate Dynamics with other systems by targeting specfic entities/workflows.. Instead of using the vanilla web api that is provided by Dynamics. A developer can customize her API's here and call them from other systems. Of course, this app needs to handle all the heavy and nasty lifting such as queing api calls from/to Dynamics, monitoring API calls etc. 

Status: New
Power Apps

Hey @OmarZaarour , 


Thank you for the suggestion. There are two platform capabilities that can be leveraged today:


1) Create a custom connector that you can interact with through a Canvas App or a Flow,

2) Create a custom action with a plug-in subscribing to the action. In this case, you can use CDS web API to invoke the action,


Will either of these approaches fulfill your request? If not, what would be the difference?

Advocate I

Thanks so much Mike. I maybe  wasn't clear exactly of my intent. 


One requirement that is asked often it to integrate Dynamics with other systems where the integration can be one way or two ways. 


Take this example, when a case gets created in system X, a record needs to be created in Dynamics and when this record is updated in Dynamics, the record in system X needs to be updated. As simple as this looks, it is really complex ask because if you want things done right, you have to account for crm being offline or the other system being offline or both. This may require a queuing(service bus and azure functions etc) structure in Azure to account for such scenarios.


My app idea is to create these interface points between Dynamics and any other system where this type of App manages all the nasty queuing and retry logic and ensures that the integrations are done right and without writing complex plug-ins that may affect the org performance. 


Now custom connectors require writing an api and hosting it somewhere which again can be a lot of work depending on the complexity of the integration. 


Another use case for such an Api app is to call the Apis from the portal without going through creating complex custom pages and liquid code.


In summary, the integration with Dynamics, in my opinion, can be or should be standarized and my way of thinking about that is through the idea above. I'm pretty sure I'm missing on a lot of details though again 🙂