Custom actions have been around for a while, but, somehow, I have not used them at all on my projects so far. I would always create a plugin or a custom workflow activity instead.. Still, I’ve been watching them for a while:) And what I think is missing is a set of recommendations and/or best practices around actions which would explain when and why we should be using them.
I can hear you saying “of course there are.. have you been in the trenches for the last few years?”
Technically, I probably have been, a little bit:) However, I’d like to explain myself.
What are the primary benefits of the custom actions?
In this 2014 article, PowerObjects are stating that “The most fundamental benefit of custom Actions in CRM is to allow non-programmers to build automated processes; in turn, developers can trigger this Action by using a single command, like “Approve” or “Schedule”, etc. Before custom Actions, this was only possible by making code update a field or save a record that would in turn trigger a workflow.”
In other words, non-developers can define a “workflow” which the developers can, then, trigger through the action. This is interesting and sort of makes sense. However, have you ever looked at all the custom actions included into the default Dynamics 365 solution (actually, it’s not necessarily the “default” solution. It’s what you get when you deploy Field Service, Project Service, etc)? There are lots of the out of the box custom actions, but, if you look at them, you’ll notice something unexpected about them:
NO STEPS HAVE BEEN ADDED. Here is another one:
This seems to be not that unusual at all for the out of the box custom actions.
Why is there a custom action, then, if there are no steps?
The answer comes in the form of the Sdk Message Processing Step:
It’s probably safe to say, then, that Microsoft itself is not considering the ability “of non-programmers to build automated processes” as a primary benefit of using the custom actions.
Then.. why not to use a plugin/workflow instead of a custom action?
The way I see it, there are a few reasons why we may prefer custom actions:
1. They are business logic modules that do not have triggers – we can trigger them when we need to
A workflow will trigger in response to some event. A plugin will run in response to a message. A custom action has to be triggered either as a workflow step or from the web api/plugin using code. This is a somewhat different level of control, although, it’s arguable if it’s that much better than using a workflow/plugin.
2. We can pass input parameters to the actions and retrieve output parameters from the action
This is actually interesting. We can’t pass parameters to / from workflows or plugins. I am not sure why, at some point, the decision was made to introduce custom actions rather than to add this functionality to the workflows, for example. However, as it stands, we can only use custom actions when we actually need to pass parameters to our plugin, for instance. Or when we need to get output parameters from the plugin.
For example, what if we wanted to calculate some sort of total value? We might create a custom action which would calculate that value, and it could simply use input/output parameters to communicate with the calling process – it would not have to update any of the records and/or wait till any of the records are updated.
That said, does it seem like I have arrived at some kind of answer as to when and why we should be using the custom actions? It could be the case if this scenario was clearly described and documented in the SDK manuals/help files. But, as of right now, I still cannot find any indication of how to pass those parameters to/from the custom action in C# code, for example, when I am looking at the SDK files.
Here is what Andrii Butenko, a Dynamics MVP, wrote back in 2013:
This is great, and this allows us to process custom actions parameters in the plugins now; however, I am wondering if that’s even supported? De-facto, that’s how a lot of people have been using the actions now. However, it would be great to see an msdn link where this same process would be described by Microsoft – right now this is all we have on the custom actions:
Then where does it leave us? Custom actions is a feature in Dynamics that is offering some interesting usage scenarios. This feature lacks official documentation for developers, and it also lacks official recommendations on when and how to use it. The community has been trying to figure it out on its own and has offered various scenarios so far, but, if Microsoft could add a bit of packaging to this feature in the form of more detailed documentation and samples, I think this would be very useful.