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 posts on unit testing 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:
- A custom proxy service allows for a more loosely coupled solution than when calling the organization web service directly.
- A custom proxy service can execute complex business logic in the interface layer.
- 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.
A version of this post was originally published on the HP Enterprise Services Application Services blog.