Actions are messages that can be defined for an entity. Out-of-the-box CRM provides a set of pre-defined messages for each entity (like create, update, delete and others), but there can be cases when you want a custom action.
For example: approve, reject, delegate or any other action that fits your business needs. Through actions, we can create our own messages for any entity type.
Below are the steps to create a sample action.
Here is an example of creating an action when an account record is delegated.
1. Go to Settings > Processes > Click New
2. A screen similar to the workflows/dialogs screen will be displayed with slightly different options.
Enable Rollback: There may be cases when you have a code which runs out of the scope for CRM and you may not be able to roll back the action. The option of rolling back can be disabled for each action.
Direction: You can set either the Argument as an input or Output Argument to an action, by using direction.
Type: Below are the available types of arguments.
3. Once the Arguments are set, the Steps available to add the logic is similar to the workflows.
When the logic is defined for the action, you just need to activate it. Now this action is available for the developers and they can easily call this action from a custom code whenever it is required.
In addition to the messages for a specific entity, CRM 2013 provides an option to create a Global Action. This can be created by selecting the entity name as None (global), as shown below while creating the action in step 1.
This is useful when you have any common actions that need to be performed for multiple entities or globally across the application
Four Important Concepts Helpful in Understanding Actions in Dynamics CRM
Custom Actions can only be “triggered” by code.
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.
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.
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.