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 2

In my last post, I talked about what Dynamics CRM 2013 actions are and how I think they're of limited utility in enterprise deployments. I did suggest two scenarios in which I think actions could be useful, and I'm sure other folks may have come up with some ideas of their own. In this post I want to outline some technical considerations to keep in mind when using actions.

 

Security

First and foremost is security. An action executes in the context of the calling user, so the calling user has to have permission to execute each step in an action. Let's say an action creates a custom entity. Any user can call the action's custom message via the CRM organization web service, but if the user is not a member of a security role with create rights for that entity, an error will be returned. On one hand, this is useful because it keeps administrators from having to worry about who can execute actions. On the other hand, this is a limitation when actions are compared to workflows that can run in the security context of the workflow owner.

 

Testability

As those of you who read my series on unit testing custom Dynamics CRM code already know, automated unit testing is a subject near and dear to my heart. Automated unit testing of plug-ins and custom workflow activities is relatively easy. If business logic is moved from those to actions, it becomes much more difficult to test. In fact, I believe the only way to test actions using Visual Studio's unit testing or NUnit would be to export the XAML definition for an action and then set up a test similar to what I suggested for custom workflow activities.

 

Interface/interoperability design

Generally speaking, I avoid designing custom interfaces in which an external system interacts directly with the Dynamics CRM organization web service. I find that using a custom intermediate "proxy" service is usually a better approach for several reasons:

1. A custom proxy service allows for a more loosely coupled solution than when calling the organization web service directly.

2. A custom proxy service can execute complex business logic in the interface layer.

3. A custom proxy service supports a variety of authentication options.

 

Using actions, however, encourages the design of interfaces that rely directly on the organization web service. Also if actions are used for interfaces with external systems, the CRM administrator must consider the impact of potential downtime for editing actions. Like with standard workflows, actions must be deactivated before they can be edited. If custom code attempts to execute a deactivated action, an error message will be returned.

 

Wrapping it up

So, after thinking about how they can be used and technical considerations to keep in mind when using them, my initial feeling that actions aren't a great tool for enterprise Dynamics CRM 2013 implementations stands. Agree/disagree? Please share your thoughts in the comments.

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.