I finally set up a personal Dynamics CRM 2013 sandbox a couple of weeks ago so I could start trying out some of its new features. Although I had been waiting for most of the Fall to get a look at real-time workflows, I was also intrigued by the new action process. After a few days of experimenting with actions, my early impression is that they're not terribly useful in enterprise Dynamics CRM implementations. In this post, I'll explain what exactly CRM actions are and how I think they might be useful. In my next post, I'll outline some technical considerations to keep in mind when using them.
What is a Dynamics CRM "action"?
According to the documentation included in the Dynamics CRM 2013 SDK:
You can extend the functionality of Microsoft Dynamics CRM by creating custom messages known as "actions." These actions will have associated request/response classes. Presently, actions are available to business applications and extensions through organization web service calls only. Actions are typically used to add new domain specific functionality to the organization web service or to combine multiple organization web service message requests into a single request. For example, in a support call center, you may want to combine the Create, Assign, and Setstate messages into a single new "Escalate" message.
Basically this means that an action is a real-time workflow that you can call via the CRM organization web service (and only via the CRM organization web service). Unlike a custom workflow activity, you cannot trigger an action from directly inside a workflow or a dialog. You can, however, write a custom workflow activity to trigger the action.
Although actions are essentially workflows, they do differ from actual workflows in a few ways. First, actions do support input and output parameters. Second, plug-ins can be registered to fire for actions just like with stock CRM messages. Finally, global actions can be created that don't correspond to any particular entity.
What's the point?
Based on everything I've read about actions, it seems the underlying rationale is to allow non-programmers to extend the core CRM platform using a variation on the workflow designer. Because the custom action messages will only ever be called from external integrations or custom code embedded in CRM, this seems to be of limited utility. That is to say, custom code is required to use an action, so if you're to that point, why not go ahead and put your business logic in code instead of trying to force it to live inside the CRM platform?
Potential applications
As I mentioned at the beginning of this post, I don't think actions will play a major role in enterprise deployments of Dynamics CRM 2013, but I can think of two potential uses for them:
- Organizations that don't have programmers with a deep understanding of CRM functionality but do have knowledgeable super users and business analysts who can create actions for the programmers to simply "consume" in their integrating systems could leverage actions to deploy functionality more quickly. The ability for non-programmers to edit actions also allows for business processes to easily evolve over time.
- An "empty" action could be used to trigger a plug-in in response to a particular custom message.
In my next post, I'll take a look at some technical considerations if you do decide to use actions. In the meantime, what do you think? Have you come up with some good uses for actions? Please let us know in the comments.
A version of this post was originally published on the HP Enterprise Services Application Services blog.