Yes, it’s really that simple, they are awesome. Why are they awesome? How should you use them? I’ll try to explain a bit about them in here this post.

Brief History

Actions were introduced back in CRM 2013. They were a bit of an odd thing and not a lot of people knew what to do with them. One of the main “issues” with them was the fact that you could only access them via code. You had to either write a bit of C# to create an OrganizationRequest or some JavaScript code to send a SOAP envelope. Also, it wasn’t clear when or why you would use an Action - one could simply create a Plugin or a Workflow that would trigger automatically based on CRM events.

Advancements and Advantages

In the latest update to CRM Online the ability to trigger actions from workflows finally arrived. This means that it is now simple to initiate an Action from a workflow and not be limited by the the need to write code for it. So you’re probably thinking “cool, so now I can trigger Actions easily, but I still don’t need to use one”. It’s true that it’s still possible to create a plugin or a workflow to perform some custom code, but actions have two amazing advantages:

1. They don’t need a “data” trigger. Both plugins and workflows require data to be changed in order for them to work, which can sometimes results in making updates to records just to trigger some custom logic. With an Action you can call it on demand without the need to update data specifically.
2. They are always synchronous yet provide the option to rollback the transaction or not. What this means is that Actions provide the developer with more control over what data should be included in a single database transaction.
3. Global Actions. Build generic code one and apply to all entities with the ability Actions have to not be tied to a specific Entity like Workflows must be. Simple define an Input Parameter of Type EntityReference without specifying the Entity Name and the action can run on any entity in the system.

A great example of item 3 above is the Solution Architecture I created for Notification Queries which are part of my Notification Unleashed solution. A single Action does all of the “hard work” to determine what notification queries apply to a given record. The Action is generic and supports practically any Entity, written in C# code which should perform better than JavaScript, (arguably) easier to unit test and maintain, and runs on the server so potentially reduces quite a bit of overhead if the same type of functionality was built purely with JavaScript.