Microsoft’s Power Platform is usually thought of as a cloud-hosted low-code platform. That’s only partly true, as its process automation tool, Power Automate, also has a desktop component. Bundled with Windows 11, Power Automate for Windows is designed to wrap low-code workflows around your desktop applications, in much the same way as the cloud tooling does for software as a service.
It’s a model often called RPA, or robotic process automation. In the case of Power Automate, the goal is to automate the little tasks that take up so much of our workdays (and in some cases, our personal lives). You could use Power Automate on your desktop or laptop PC to automatically steer documents from emails sent by coworkers into project folders, for example, or to use information from a regularly updated website to plan activities, like keeping track of tide tables when planning a birding trip. Microsoft’s RPA tooling integrates with AI services, allowing you to quickly incorporate text analysis and computer vision in your workflow.
While the Power Automate tooling is useful, there’s a limit to the processes it can automate, especially when it comes to internally developed desktop applications. Unlike web applications, desktop applications are not designed to be remotely controlled. Having desktop apps suddenly steal focus so they can be automated is at best distracting and at worst dangerous. Microsoft has been working on a solution to this, and at Build 2023 the company unveiled a preview of a .NET SDK that adds custom Power Automate actions to your code.
Custom actions work like any other action, appearing as action blocks in the Power Automate for Windows canvas. However, it’s important to note that they’re not for all your users. Rather, they must be uploaded to a Power Platform environment and users must be assigned an appropriate license. That does help manage access, for developers as well as for users, because uploads require Desktop Flow Module Developer roles.
Introducing the Desktop Actions SDK
The Desktop Actions SDK is a .NET library built to .NET Standard 2.0. That should allow it to work with most .NET applications, whether built with .NET Framework or the newer .NET 5.0 and above. The documentation suggests that the minimum version is .NET Framework 4.7.2. You install the Desktop Actions SDK from NuGet, using the .NET CLI or your preferred package management tools, including using the integrated NuGet support in Visual Studio. Along with the SDK you’ll need a copy of Power Automate for Windows, version 2.32 or higher.
Because actions are DLLs that are delivered from your Power Automate tenant, you will need to digitally sign any code you produce and distribute your digital certificate to your users. This does limit your action’s reach to your own users, though you are able to share certificates with partners and suppliers who may have access to your tenant.
Once you have the prerequisites on your development PC, you can start to add Power Automate actions to your existing code, or to new applications that work with existing APIs for line-of-business systems. This last option is an especially interesting one, where you’re using Power Automate to replace aging client/server applications, or even ancient ones written in Visual Basic, that are no longer fit for purpose.
Building custom actions for Power Automate for Windows
Microsoft recommends using Visual Studio to build new custom actions for now. The SDK provides new templates for C# console apps that set up the scaffolding needed to publish an action, with all the necessary references in place, ready for you to start writing code. It’s probably best to start with the Simple Module template, which gives you a sample action you can then customize.
The C# sample is simple. It takes an input string and generates an output string in response, in this case adding a basic “Hello World” to the input. It shows you how to define an action as a public class and how to deliver an error if there’s a failure. You can add defaults to inputs as a test, or as a way of working with null inputs when an action is called. The API used is bare-bones, with just a handful of features.
There are some restrictions on how you name your modules, as there’s a specific format needed for them to be read by the desktop Power Automate tools. This requires the DLL name to either begin with or contain the string Modules. A valid name would by something like Modules.MyAction.dll. Each module needs a unique ID to avoid clashes inside flows.
One important aspect of your actions is making them user friendly. Inputs and outputs need descriptions and friendly names, and the same goes for any necessary parameters. You will need to add these in the module’s resource file, where they’re available to Power Automate, which will then display them to users through its own UI.
You can then set the properties of the module’s attributes. One useful option is the ability to categorize actions, particularly if you’re planning to expose different functionality through different modules. It’s important for modules to be self-describing. With low-code and no-code tools like Power Automate, you have to assume that your users will not be professional developers and will need as much help as you can give them.
Actions can expose conditional functionality. For example, you can create actions that return true or false based on input conditions. This way you can build a flow that checks if a specific record is present before executing other functionality, either through standard or custom actions, providing some element of flow control to your automations. Results are delivered as Booleans, allowing you to use familiar C# constructs.
Building complex actions in Power Automate
More complex actions can use selectors to filter inputs, either using enums or Booleans to choose the inputs to use and the code they call. For example, you can have a module that checks if an IoT device has delivered a specific result based on the user’s choice of inputs. Again, you should give all your selectors descriptions so that your users know how to use the module.
Once you’ve written and signed your code, it’s packaged as a cab file before uploading to the Power Platform. This is a standard Windows package format, so there should be no learning curve and you can use existing tools. Once the package is uploaded, you can manage who has access to your action, as well as editing descriptions. Users will find custom actions in the Power Automate assets library, ready for use in their desktop flows. They can then add them to the Actions pane in their Power Automate for desktop’s canvas.
Bringing Power Automate to the desktop is an effective extension of the platform. RPA tools need interfaces to code, and with custom actions Microsoft is providing the necessary scaffolding for you to build those extensions. However, the simplicity of the SDK means you will have to do the work needed to translate complex APIs into simple flow building blocks. It’s going to be essential to sit down with users and determine what they need before you start building actions.
It’s a good idea to keep your actions simple, as you don’t want to spend developer resources on complex actions that may not be much use. Before you start work, take a close look at the types of actions Microsoft and its partners provide and compare them to the available APIs they wrap. Examining how those actions simplify operations should help you make the right design decisions, and set you on a path to delivering custom actions that combine simplicity and utility.