If you have ever wondered what concepts are needed to understand Actions in Dynamics CRM, then this your blog! By definition, Dynamics CRM Actions unify and open a broader channel for automation between CRM platform messages and CRM processes like workflow. It allows more streamlined process flow between programmatic logic (code) and point-and-click processes built within CRM. In turn, custom actions can work in concert with plugins, which can be used pre- or post-operation to validate or enhance the custom Action behavior.

Here are some key concepts that we hope will help you understand the benefits and usage of custom Actions in Dynamics CRM.

1. Custom Actions can only be "triggered" by code.

Simple. As of the writing of this blog, you cannot trigger a custom action from another CRM process (workflow or dialog)…only from custom code like a plugin, or Javascript, or via the web services through a custom application.

2. The primary benefit of Actions is to allow point-and-click creation of processes that can be integrated, programmatically, with the CRM execution pipeline.

The most fundamental benefit of custom Actions in CRM is to allow non-programmers to build automated processes; in turn, developers can trigger this Action by using a single command, like "Approve" or "Schedule", etc. Before custom Actions, this was only possible by making code update a field or save a record that would in turn trigger a workflow. With the addition of custom Actions, non-programmers can define custom processes (for example, create Activities when certain criteria is met or send an email when deadlines pass, etc.) and custom code can simply "trigger" the action.

For example, perhaps a portal user (a customer) creates a support request ticket that in turn creates a Case in CRM. The portal code, first, can check to see if the customer that is submitting the support request has any open Opportunities that are "hot". If so, it would call a custom Action (called, say, NotifySalesOfCase) that sends an email to the sales person to notify them that one of their customers submitted a support ticket.

You see, the benefit with this scenario is that the "action" being taken is that an email is sent and the definition of how that email is sent, to whom that email is sent, and the content of that email message can be determined by a non-programmer using point-and-click interface in CRM. In addition, that action can be updated and modified in an on-going basis without the need for programmers to write new code.

3. Actions are Custom Platform Messages.

Perhaps one of the most powerful facts about Actions is that when you create and activate them (again, with CRM point-and-click UI) they act like the standard system messages (Update, Assign, Win, SetState, RetrieveMultiple, etc.) and plugins can run before or after Actions occur. As you can imagine, this allows us to write some custom code to validate that certain conditions apply before the Action occurs or to enhance the details of the Action by running some additional logic after the Action runs.

This approach allows for powerful collaboration between CRM developers and administrators for meeting business need.

4. You can use input and output parameters to send data values into or out of the Action; the parameters can also be used by plugins that are triggered when the Action occurred.

This concept is a great example of how custom Actions unifying logic between custom code and processes defined within CRM. Let's take the example in Item #2 above. If we setup an input parameter for this Action for the "Customer", the code can pass a reference to the Customer into the Action which can use that Account reference within its construct.

To setup a parameter like this, we define a name for the parameter (CaseCustomer), a type (EntityReference), an entity (Account), and whether it is an input or an output parameter.

With this parameter created, the "workflow" section of the Action can utilize the parameter within the workflow construct. For example, below we see that if we are doing a "Check Condition", we can utilize the CaseCustomer parameter in the condition. We could also use property values of that Customer in, say, the values of Activity records.

And, finally, the parameters can be passed into the Action from code, using syntax similar to the following:

CRM Actions are both a custom CRM Platform message and a CRM processes. And with collaboration between CRM developers and administrators, Actions allow a broadened and more streamlined approach to automation across the execution pipeline.

Note for developers: execution of Actions is not available through CRM's oData endpoint; actions CAN be called from Javascript.

For more on Actions or anything else Dynamics CRM related, make sure to stay up to date on our blog. And keep our education department in mind for continued training, webinars and bootcamps. Happy CRM'ing!