Unlike the last three posts in this series, which followed on from each other and worked towards building and deploying plugins into Microsoft Dataverse, this post will instead cover a few handy things to know when working with plugins. The topics in this post don’t follow on from each other; they are independent actions, which may be useful to know as you get into plugin development. If you’ve not already read the previous three instalments in this series, and want to know

In the last two instalments of ‘Getting Started with Dataverse Plugins’, we ran through installing and configuring the required software, using some of the new commands we’d installed to create the scaffolding (files and folders) for building our plugin and we utilised AI to generate the C# needed for our plugin. We also started using the term ‘assembly’. Today we’ll start to see where terms like ‘assembly’ and ‘step’ tie into our process. We’ll also talk about the ‘pipeline’

In the first instalment of ‘Getting Started with Dataverse Plugins’, we covered the software needed to create, develop and register plugins within Dataverse. In this instalment, we’re going to look at Structuring plugins, Adding in some new terminology (assembly and step), Creating our first plugin, Where AI can help, if you’re not familiar with C#. If you haven’t already read the first part of this series, it’s probably best to start there, just to ensure you have everything

When it comes to Power Apps and Dataverse, JavaScript and PowerFx are great, as are Business Rules, but what about validating the data that users load into Dataverse via methods such as imports? Our JavaScript functions are bypassed, Business Rules only go so far, and Power Automate, while a fantastic tool, only really kicks in once our record is in the database. So, what is our solution to developing slightly more complex data validations and interrogations at the point of c