My colleague Ted Ohlsson had a great 👏 walkthrough of Low Code Plug-Ins (I will refer it as LCP in this post), you may see it here: Getting started with Power FX flow code automated plug-ins. It made me more curious to experiment, and I wanted to share my experience and findings of this new Dataverse feature.
We’ll focus on Automated Plug-Ins in this blog post.
[Note! This blog is written about the public preview version of Low Code Plug-Ins. I will try to update it whenever possible.]
Check out part 2 of this series here: Power Platform – Dataverse Low Code Plug-Ins Part 2: Instant Plug-Ins, the line between Child Flows and Actions…and plugin?
Introduction
We already have set of tools to configure/code processes/rules/data manipulation in Dataverse. Power Automate, Business Rules, JavaScript, Plugins, Classic Workflow, etc. But each of them have their own specific use-case and areas. What makes LCP interesting is that it combines features of other services, while (supposedly) making it easier for non-developers to implement advanced business logic.
My initial thought of LCP was, how is it set up behind the scenes? Does it consume the Web API or IOrganizationService from SDK? Can I see it in Plugin Registration Tool?
In this post, I will partially dig into the core of LCP.
TDLR
- Low Code Plug-Ins makes event registration easy to implement
- LCP is stored as an assembly
- Your LCP is more configurable in Plugin Registration Tool than Dataverse Accelerator App (as for now)
- Can be configured to run asynchronously
- Can be executed as a different user
- Can be configured to trigger on specific fields on update. Today it triggers on all fields.
- Uses Microsoft.Xrm.Sdk
- Goodbye API limits
The Automated Plugin
“Traditionally, plug-ins were created as custom classes compiled into a .NET Framework assembly, which were then uploaded and registered within Dataverse. However, with the introduction of low-code plug-ins, users can create these event handlers with minimal or no coding required, and without the need for manual registration.” Use Dataverse low-code plug-ins (preview).
The fact that the plugin is stored under ‘Plug-in steps’ section in CRM solution, and how Microsoft describes how these event handlers are registered… it should mean that there’s a plugin step within an assembly and that we can access it 🕵️.
For starters, I have no idea which assembly this plugin is registered in. There are tons of managed assemblies from Microsoft. After seeing so many assemblies, my first thought was to enable trace log 👣 to see if it traces anything and it does!
As you perhaps can see in the screenshot, under Plugin column in the trace. It says:
Microsoft.PowerFx.EvaluatorNow, this doesn’t point to the assembly but the step. So the closest thing name to this step is ‘Microsoft.PowerFx.PlexPlugins’. And there we found our plugin, awesome! Microsoft’s description of how easily it is to register plug-in steps is true! 🎉
Before doing all detective work up to this point, I noticed that the ‘Updated’ option under ‘Run this plug-in when the row is’ title, doesn’t include any option to choose which fields the update shall trigger on. And bases on tests, sadly 😔 it triggers on EVERYTHING. That’s a major red flag 🚩 but, luckily this is only in public preview as of writing (2023-11-04).
You may ask yourself, why is this a red flag? Because it will 💯% cause infinite update loop when you configure it to execute as ‘Post-Operation’, if you don’t add some other logic in the expression to avoid it. But generally if you just want to add some default values to a record on create/update, without being dependant on some other post-operation process, Pre-Operation is what you should execute.
For example, let’s say you have a service that generates an email adress after a contact has been created (unrelated to our plugin) then you do not have access to this value in pre-operation stage. More about pre-post operation in another post and which one you should use based on your case! This will be new to non-developers 😁
Back to the detective work, if you open the plug-in step in Plugin Registration Tool you’ll see that the ‘Filtering Attributes’ is set to ‘All Attributes’. This is the cause of triggering on any field update when you update a record and the reason why you get infinite update loop on Post-Operation configuration.
The fact that you can access this configuration, means that you are able to do a lot more fun things than the Dataverse Accelerator App. As you can see, you can configure which attributes to trigger on, the user context, execution order, pipeline stages and execution mode. The option of execution mode gives you the option to execute your plugin asynchronously! Which is equivalent to ‘running workflow in the background’ 🤓:
However, note that it is only possible for Post-Operations.
As previously stated, LCP is public preview. And it is recommend to implement it with caution.
To end this blog post, here’s one of the best part. I asked the question whether the plug-in uses Web API or IOrganizationService. After some extra digging, I found what I wished it to be! IOrganizationService! What does this mean? It means it won’t face the same API limits as Power Automate or any other services that uses Web API.
Exploring LCP has been very interesting and fun 😁, and I will post about it! I am looking forward new things Microsoft has to show on Low Code Plug-Ins.
Happy plugin-ing!
Van Carl Nguyen 
One response to “Power Platform – Dataverse Low Code Plug-Ins Part 1: A hybrid of Power Automate, Classic Workflow and Plug-Ins?”
[…] A continuation of my previous blog post: Power Platform – Dataverse Low Code Plug-Ins Part 1: A hybrid of Power Automate, Classic Workf… […]
LikeLike