Skip to content

Dataverse for Teams and Azure API Management

Dataverse for Teams has given the Power Platform a boost. A stripped down version of Dataverse can now be utilized as the base for solutions with a Microsoft 365 license. If necessary, the environment can be later upgraded to the full version of Dataverse. To top it all off, also Power Virtual Agents are available for the same (free) price.

What has gotten less attention is the possibility to utilize API’s with Azure API Management.

This is interesting because

  • In Power Platform, the use of API’s is a premium feature that requires Power Apps / Flow plan from end users of the solution. If the API’s are available through Azure API Management, this license requirement will disappear (in the Dataverse for Teams environment).
  • An organization can have a significant number of in-house and external services already available through Azure API Management.

This time, let’s take a closer look at the use of API Management in Dataverse for Teams (DV4T). If API Management is a complete stranger to you, you may want to start by reading this introduction to the topic.

Let’s make an example where

  • We add information about a new friend (Power Apps)
  • A row corresponding to a friend is stored in Azure SQL database
  • The storing is done with Logic Apps, which is published using Azure API Management for use in the DV4T environment

So only the API that adds a new friend is called from Power Apps / Flow. The Power Platform developer does not know where and how this information is stored. And he doesn’t need to know.

Let’s get started.

Logic app – Adding a row to the database

We have already created the database (Azure SQL). A simple Logic app is created that adds the name of a friend (FriendName) it gets as a parameter to the MyFriend -table.

How can this Logic App be accessed through API Management?

Azure API Management – Creating a service

We do not yet have an Azure API Management service, so one needs to be set up.

Let’s create a new resource (API Management) using the default settings. Let’s keep the service level developer-oriented by selecting Pricing tier = Developer (no SLA), otherwise this experiment will be unnecessarily expensive.

This takes patience. It can take up to half an hour to create an API Management service.

Adding a new API

Once the service is ready, let’s add the Logic app we created at the beginning as an API to it (APIs -> Add API -> Logic App).

Let’s browse to the right Logic App and we’re almost done!

Too easy.

API permissions

If the API is not intended to be open to everyone, we have to have the option to limit it’s usage. API Management provides a way to do this with subscriptions and related subscription keys.

A subscription grants access to one, several, or all API’s. There are always two keys to match a subscription. You can use the API as long as you have the key for it.

Let’s create a new subscription that allows the use of all API’s.

By default, subscription required checkbox is checked. This can be turned off, but we won’t do so because we want to control who is able to add friends.

The API we created lacks the required parameter (subscription-key) by which the API’s user passes the key in his possession to API Management. Let’s add this parameter from the front-end section of the API design tab.

The API is now ready to be utilized. We can make it easily accessible to Power Platform tools with the Export functionality.

We only need to select the environment to which the API will be exported to.

In practice, the Export function creates a new custom connector from the API to the selected environment.

Using the API in Dataverse For Teams

API’s in API Management work like any custom connector. They can be added as a data source in Power Apps.

The same API looks like this in a standard (not Dataverse for Teams) environment. The diamond icon tells the significant difference. Here, the use of the API requires a Power Apps plan from the end users.

This is how we add a new friend from Power Apps using the API.

The API we added is naturally found among the custom connectors in Flow.

Finally, let’s add a new friend with Flow.

Does it work?

The logic app runs nicely.

And there we go! A new friend has been added.

Separate test and production environments?

What if there are separate test and production environments? How do different environments use different versions of the API’s?

When you use a custom connector in Power Apps and transfer the app from test to production, you also want to transfer the custom connector it uses. Otherwise, your Power Apps will be broken in the production environment after the transfer.

But in this case the custom connector is the same. It calls the same API’s of the same API Management.

To resolve this issue, it is possible to modify the custom connector to use a different address based on a parameter it receives. To achieve this, it is possible to utilize policy templates.

Or you can create a separate parameter (environment) for the API, based on which the call can be routed to the right place in API Management.

Summary

Free use of API Management is a great feature in Dataverse for Teams. But does it make sense to use it to bypass Power Platform licenses?

If your organization doesn’t already use Azure API Management, it doesn’t make sense to set it up just because of Power Platform licenses. This is because there are costs related to Azure API Management as well.

https://azure.microsoft.com/en-us/pricing/details/api-management/ (March 29, 2021)

In addition to the costs, someone also needs to manage it.

But if Azure API Management is already in use, or your organization wants to start using it more extensively to manage API’s, then I think it’s a good option.

API ManagementAzureCustom ConnectorDataverse for TeamsFlowlicensingLogic AppsOffice 365Power Apps

One response to "Dataverse for Teams and Azure API Management"

  1. This is there in the 2022 licensing but it is not present in the 2023 licensing guide from what I can see.

Leave a Reply

Your email address will not be published. Required fields are marked *