Applications Services Blog
Get the latest thought leadership and information about the role of Applications Services in an increasingly interconnected world at the HP Blog Hub.

Microsoft Dynamics CRM 2013 “actions” - a solution in search of a problem? Part 1

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:

 

1. 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.

2. 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.

 

syndication-footer.png

Comments
JoeNewstrom | ‎01-04-2014 09:12 PM

Hi Lucas,

 

One potential value I can think of is for use by non-developers who are proficient in javascript (but are not capable of creating a custom C# plugin) to maintain separation of concerns while firing business logic through client side scripting.

 

Joe

Lucas | ‎01-06-2014 10:19 PM

Hi Joe,

 

That's a good point that I had not considered. Historically I would have used a workflow in this situation, but, as you pointed out in our discussion on Twitter, actions do allow you to specify input/output parameters, so there definitely could be some value there.

 

Thanks for reading,

Lucas

Darren Lewis | ‎01-26-2014 08:52 PM

Hi,

 

One use case I believe they will fit is in the replacement of "wrapper services" clients so often create.  The Organization Service doesn't fit particularly well into a SOA based architecture with course grained service operations.  Particularly if you want to integrate directly with Biztalk or one of the none MS platform ESBs like SONIC.  This leads to the creation of one or more external WCF services providing service operations over common business processes within the CRM platform.

 

I'm hoping actions will help allieviate the ownership issue for these various services with them now falling more into the realm of the CRM Business and Development Team.

 

Thanks

Lucas | ‎01-30-2014 10:22 PM

Hi Darren,

 

I'd originally thought that actions would be a good fit as "wrapper service" replacements (as I've had to set up more CRM wrapper services than I can count), but I think they're not a big value-add in an enterprise deployment for a few reasons:

  1. You can't grant permissions to execute an action to specific users
  2. You can't set up an action to do anything that the executing user wouldn't be able to do otherwise.
  3. Modifying an action requires taking the action offline for editing and publishing.
  4. Executing actions via the organization web service still requires all the WCF overhead that sometimes makes it difficult for non-.Net clients to use.

That being said, perhaps there could be value in combining custom actions with a service wrapper layer to give the business/functional team more control over interfaces. It's definitely something worth considering.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Microsoft Dynamics CRM solution architect, C# developer, MBA, husband, father, Auburn man. Follow me on Twitter @lucas_is.
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.