Dataverse Custom API

It’s funny – I have been hearing about Custom API-s for a while now, but, until today, it’s been just “oh, there is something out there I need to try out. But it seems to be a reincarnation of custom actions, so, maybe, I’ll look at it later”.

So, the day has come to look at it. And, at the end of the day, I am neither extremely excited nor disappointed. Except for some edge cases, there seem to be nothing there I could not do with the classic custom actions, and, yet, we got a few extra features to cover those edge cases.

Originally, custom actions (not the newer custom API) were meant to allow non-programmers to build shared processes. In a somewhat stretched way, one could say they were a pre-historic version of Power Automate… although, maybe I’m overstretching too much.

But, then, what actually happened to them is that developers realized at least a couple of other benefits:

• Turned out custom actions were great for calling them from javascript web resources
• There was also that idea of using custom actions to store configuration values (without the need to create configuration tables… sorry, they were called entities back then)

Do you still remember the latter? Quite a few people used to entertain that idea, and, if you do remember it, you’ve probably been around long enough!

But, of course, now that there are Environment Variables, there is Power Automate, classic workflows are, mostly, discouraged… the only real benefit of custom actions seems to be that ability to register a message, to associate a plugin to the message, and to have that message, and a plugin, exposed to other parts of the system.

And that’s exactly where Custom API comes in. Basically, they pick up where custom actions left. In the sense that, since there is no need to use custom actions to expose application configuration properties, and there is no need to use them to define “shared” workflows, the rest might better be done slightly differently. Besides, when doing it differently, a few extra features can be thrown in.

It’s easy to define new Custom API using the maker portal:

Yet there are other ways of doing it, just have a look at the docs if you are curious.

There are a few interesting features there:

1. Plugin type

You can associate a plugin to your custom action. But, unlike with most of the other plugins, that one will in stage 30. Normally, we can register plugins in stage 20 (pre-operation) and 40 (post-operation)

And we don’t even need to use plugin registration tool to register those steps. Well, we still need to use it to register the assembly, but that’s about it.

2. And, yet, we can still register plugins for pre and post operations

For that, we just need to make sure that “Alowed Custom Processing Step Type” is set to something other than “None”.

For example, with the custom API above, I could make use of the usual execution pipeline and register another plugin like this:

My original plugin would run in stage 30.

Another plugin could run in stage 20 (suddenly, “Pre-Operation” starts making even more sense. Since stage 30 would be for “main operation”, and that’s where my original plugin would run.

Then, of course, I could also have another plugin in “post operation” (which is Stage 40). Which is after the “Main operation”.

There is, also, that ability to make the API private, to associate a security role, to make it a function (which would render it useless for Power Automate). But this is where I’d call those scenarios “edge cases”.

The fact that we can have main operation plugin running in stage 30 looks interesting, though, since it all but guarantees that the order of plugins will be as expected (pre-operation plugins will run first, then main operation one will run, then post operation plugins will take over).

Also, it seems we have more options when defining parameter types, and we can tie custom API to entity collections, not just to entities. That might be handy, too.

With that, I guess I’ll just be using Custom API, and not a custom action, the next time I need “custom action” functionality.