PowerPlatform: beyond the custom code

As far as adding custom code to PowerApps/PowerAutomate goes, I’ve looked at three different options so far:

• Custom Connectors
• Azure Functions
• CDS Custom Actions

 

Those are all valid options, but there are things to consider which go beyond purely technical aspects. For example, even though some Office 365 licenses include Power Apps use rights, those licenses will not allow access to the custom connectors.

So, how do we compare those three options?

It might be worth looking at the following 7 aspects – there is probably more to compare, but that should be a good starting point:

Let’s look at each of those boxes one after another.

1. Data Security

For this one, I mostly wanted to look at it from the perspective of CDS security roles.

When setting up an Azure Function that would be connecting to CDS, we would likley utilize an account (be it a user account or an application account), and that account might be different from the account of the user who is running the Flow/utilizing the PowerApp. Which means there might be quite a few security issues there since those two accounts might have different levels of data access.

CDS Custom Actions, on the other hand, would be utilizing the user account specified in the Flow connection, and that would likely be the user account of the Flow creator. That would be a somewhat more consistent. Moreover, absolutely no effort would be required from the CDS custom action developer to achieve this.

As far as custom connectors go, it seems I don’t have enough experience there to be sure. On the one hand, we can set up authentication for the custom connectors. On the other hand, I am not sure if/how we can reuse those connections from within the custom connector code to open subsequent connections to CDS from code.

As far as data security goes, at least in relation to CSD, it seems CDS Custom Actions would have a bit of an edge.

2. Data Loss Prevention

Azure Functions, unless they are wrapped up into custom connectors, will work over the out of the box HTTP connector.

CDS Custom Actions will work over CDS connector.

From the DLP perspective, there is no way to separate one Azure Function from another or one CDS Custom Action from another.

Custom Connectors, on the other hand, can be added to the DLP individually:

https://docs.microsoft.com/en-us/business-applications-release-notes/october18/microsoft-flow/http-and-custom-connector-support-for-dlp-policies

We can wrap up different API-s into different custom connectors, and, depending on the needs, we can add those connectors to the DLP as required.

From this standpoint, Custom Connectors look better.

3. Code Hosting

Azure Functions are hosted in Azure. That kind of “hosting” is easy to set up, but it’s somewhat limited and is probably not meant to create really complex API-s

CDS Custom Actions are hosted in CDS. Which means you need CDS to start with. Which also means custom actions are tied to the CDS environment. Which allows for the DEV-TEST-UAT-PROD scenario, but, on the other hand, which might not be the best option when you need to host some kind of shared API. Also, just like with the Azure Functions, CDS custom actions are not really meant to serve as advanced API engine.

Custom Connectors are hosted… technically, it’s the API which is hosted. It can be hosted in Azure, or it can be hosted on some other servers. The advantage is that you can go as complex as you want with those API-s, but it’s also a disadvantage since you have to figure out deployment, lifecycle, etc.

The way I see it, there is no clear winner in this category. CDS custom actions work really well when your API is supposed to be tied to a specific CDS environment. Azure Functions work great in the non-CDS scenario where you don’t need complicated code. Yet with the custom connectors you can build something really advanced, but that comes with the additional deployment and configuration complexity.

4. CDS Solution Awareness

What if you wanted to move your custom code from one CDS environment to another? Of course the question itself assumes that such code would be environment-specific somehow. It might be because it is supposed to work with that particular CDS environment, or it might be because if has to mirror the same release process (Dev-Test-Prod).

Azure Functions have no idea of what CDS solutions are, so they are not competing in this category at all.

CDS Custom Actions live in CDS, they can be added to the solutions, so it’s their natural environment.

Custom Connectors can be added to the solutions, though I am wondering what it really means. You can add the connector, but you can’t add the API, so what exactly are you achieving by doing that?

Either way, in terms of CDS solution awareness and in terms of our ability to mimic CDS solution deployment process for custom code, CDS custom actions will definitely be ahead of the other two. They do take this one.

5. CDS Integration

This one is likely going to the CDS Custom Actions, too. Even if only because CDS is right there, in the name.

But, seriously, when it comes to CDS custom actions, we can write plugins and we don’t have to worry about authentication and/or about utilizing web api etc. All those SDK assemblies are there, so we can build code easily.

This is not the same for Azure Functions and Custom Connectors, even though we can always add references to the same SDK assemblies and set up the connections from code. But, then, those connections may have to account for different connection strings depending on whether we are working with Dev/Test/Prod, and how do we do that properly… that’s not a problem for the plugins at all – they just don’t need to worry about it.

6. Licensing

It’s better not to talk about licensing, but it’s also one of those topics which is just unavoidable.

First of all, whether it’s an HTTP connector (for Azure Functions), a Custom Connector, or a CDS connectors, those are all premium connectors. Which means you do need appropriate license to use them in PowerApps/PowerAutomate.

Other than that…

Azure Functions: there are tiers, but, essentially, it’s “pay per use”. Although, there is a caveat. If an Azure Function is not connecting to CDS, then that’s what it is. If it is connecting to CDS, then we also need a license and/or API usage add-on for CDS. Besides, since we will be using an HTTP connector

Custom Connectors: depending on where they are hosted, additional licenses/fees might be involved.

CDS Custom Actions: even if you are using them for something like “regex” validations, each custom action call is still considered a CDS API call, and there are limits on how many calls are allowed per license/add-on.

Is there a winner? I think Custom Connectors offer more flexibility, so will give it to them.

7. Other

Custom Connectors can be shared, and the can also be certified and made available to the users in other tenants. For the Azure Functions, best we can do is share the code. For the CDS Custom Actions, we can package them as solutions and share with other CDS customers.

Logic Apps do not support CDS (Current Environment) connector, so using CDS custom actions from Logic Apps might be more involved than using CDS Custom Actions from Power Automate Flows.

From the usability standpoint, Custom Connectors are, likely, the easiest to consume in the Flows/PowerApps. Azure Functions require json parsing etc. CDS Custom Actions – they seem to be somewhere in between.

Conclusion:

I don’t think there is a clear winner for all situations. I would not even say CDS Custom Actions work best when we are talking about CDS environments. Even more, I am not sure I have not missed something above that would turn everything on its head. But, like I said, this might be a good starting point.

Have fun!