Actions are a new feature in Microsoft Dynamics CRM 2013. Actions are a type of process that is run by using custom code that uses the Microsoft Dynamics CRM web services. If you are not a developer, or if you haven’t installed some solution that uses actions, you won’t be able to do anything with Actions in Microsoft Dynamics CRM 2013. You cannot call an action from another process except indirectly through a custom workflow activity or plug-in that contains the code to call the action.
However, if you install a solution that uses Actions or if you work with a developer who can write code for one, you will see that Actions is a very powerful feature.
1. Why use actions?
Actions open a range of possibilities for developers and people who compose business logic. Before Actions, the primary way that developers could implement business processes was limited to plug-ins or custom workflows. With these, developers can perform operations composed of verbs like Create, Update, Delete, Assign, and SetStatus. Developers refer to these actions as ”messages”. Each of these messages is based on actions taken on an entity instance. So if the goal of a process is to create a record, then update it, then assign it, there are three separate steps. Each step is defined by the capabilities of the entity – not necessarily your business process.
Actions provide the ability to define a single verb (or message) that matches an operation you need to perform for your business. These new messages are driven by a process or behavior rather than what can be done with an entity. These messages can correspond to verbs like Escalate, Convert, Schedule, Route, or Approve – whatever you need. The addition of these verbs helps provide a richer vocabulary for you to fluently define your business processes. You can apply this richer vocabulary from clients or integrations rather than having to write the action within clients. This also makes it easier because you can manage and log the success or failure of the entire action as a single unit.
2. Configure actions:
You may need to create an action so that a developer will use it in code or you may need to edit an action that was previously defined. Like workflow processes, consider the following:
- What actions should they perform?
- Under what conditions should actions be performed?
Unlike workflow processes, you don’t need to set the following options:
- Start When: Actions start when code calls the message generated for them.
- Scope: Actions always run in the context of the calling user.
- Run in the background: Actions are always real-time workflows.
An action also has something that workflow processes don’t have – input and output arguments.
Create actions: Like workflow processes, actions have the following properties in the Create Process dialog.
– Process Name: This property is used to generate a Unique Name by removing any spaces or special characters from the Process Name.
– Category: This property establishes that this is an action process. You can’t change this after you save the process.
– Entity: With actions processes, you can select an entity to provide context for the workflow just like other types of processes, but you also have the option to choose None (global). Use this if your action doesn’t require the context of a specific entity. You can’t change this after you save the process.
– Type: You can use this property to choose whether to build a new action from scratch or to start from an existing template.
Edit actions: You must deactivate processes before you can edit them. You may edit an action process that was created as part of an unmanaged solution or included in a solution installed in your organization. If the solution is a managed solution, you may not be able to edit it. The solution publisher has the option to edit the managed properties so that the action installed with a managed solution can’t be edited.
When an action is saved a Unique Name is generated based on the Process Name. This unique name has the customization prefix added from the solution publisher. This is the name of the message that a developer will use in their code.
When editing an action you have the following options:
– Process Name: After the process is created and the unique name is generated from the process name, you can edit the process name. You may wish to apply a naming convention to make it easier to locate specific processes.
– Unique Name: When an action is saved, a unique name is generated based on the process name. This unique name has the customization prefix from the solution publisher added. This is the name of the message that a developer will use in their code. Don’t change this unique name if the process has been activated and code is in place expecting to call the action using this name.
– Transaction: Generally, processes that support transactions will “undo” (or rollback) the entire operation if any part of them fails. There are some exceptions to this. Some actions developers might do in code initiated by the action might not support transactions. For example, if the code perform actions in other systems that are beyond the scope of the transaction. Those can’t be rolled back by the action running in Microsoft Dynamics CRM. Some messages in the CRM platform don’t support transactions. But everything you can do just with the user interface of the action will support transactions. All the actions that are part of a real-time workflow are considered in transaction, but with actions you have the option to opt out of this.
You should consult with the developer who will use this message to determine whether it must be in transaction or not. Generally, an action should be in transaction if the actions performed by the business process don’t make sense unless all of them are completed successfully. The classic example is transferring funds between two bank accounts. If you withdraw funds from one account you must deposit them in the other. If either fails, both must fail.
– Activate As: Like all processes, you can activate the process as a template and use it as an advanced starting point for processes that follow a similar pattern.
– Define Process Arguments: In this area, you will specify any data that the action expects to start and what data will be passed out of the action.
When a developer uses a message they may begin with some data that they can pass into the message and use. For example, if you want to create a new case record, you may have the case title value that will be passed in as an argument. This would be an input argument.
When the message is finished the developer may need to pass some data that was changed or generated by the message to another operation in their code. These must be defined as an output argument.
Both input and output arguments must have a name, a type, and some information about whether the argument is always required. You can also provide a description.
The name of the message and the information about all the process arguments represent the “signature” for the message. After an action is activated and it is being used in code, the signature must not change. Changing this signature will cause any code that uses the message to fail. The only exception to this may be changing one of the parameters so that it is not always required.
Changing the order of the arguments by sorting them or moving them up or down doesn’t make a difference because the arguments are identified by name, not by the order. Changing the description will not break code using the message.
Action process argument types: The following table describes the action process argument types.
|Boolean||A true or false value.|
|DateTime||A value that stores date and time information.|
|Decimal||A number value with decimal precision. Used when precision is extremely important.|
|Entity||A CRM record for the specified entity. When you select Entity, the drop-down is enabled and allows you to select the entity type.|
|EntityCollection||A collection of entity records.|
|EntityReference||An object that contains the name, id, and type of an entity record that uniquely identifies it. When you select EntityReference, the drop-down is enabled and allows you to select the entity type.|
|Float||A number value with decimal precision. Used when data comes from a measurement that isn’t absolutely precise.|
|Integer||A whole number.|
|Money||A value that stores data about an amount of money.|
|Picklist||A value that represents an option for an OptionSet attribute.|
|String||A text value.|
Note: EntityCollection argument values can’t be set in the user interface for conditions or actions. These are provided for use by developers in custom code
– Add Stages and Steps: Actions are a type of process very similar to real-time workflows. All the steps that can be used in real-time workflows can be used in actions. For information about the steps that can be used for both real-time workflows and actions
In addition to the steps that can be used for real-time workflows, actions also have the Assign Value step that is similar to the one used to set variables or input arguments in dialogs. In actions, these can be used only to set output arguments. You can use the form assistant to set output arguments to specific values or, more likely, to values from the record that the action is running against, records related to that record with a many-to-one relationships, records created in an earlier step, or values that are part of the process itself.
3. Configurable messages:
Once an action is defined and activated, a developer can use that message like any of the other messages provided by the Microsoft Dynamics CRM platform. However, a significant difference is that now someone who is not a developer can apply changes to what should be done when that message is used. You can configure the action to modify steps as your business processes change. Any custom code that uses that message does not need to be changed as long as the process arguments do not change.
Workflow processes and plugins continue to provide similar capabilities for defining automation. Workflow processes still provide the capability for a non-developer to apply changes. But the difference is in how the business processes are composed and how a developer can write their code. An action is a message that operates on the same level as any of the messages provided by the Microsoft Dynamics CRM Platform. Developers can even create plugins for Actions.
4. Global messages:
Unlike workflow processes or plugins, an action doesn’t have to be associated with a specific entity. You can define ”global” Actions that can be called on their own.
5. Actions limitations:
For Microsoft Dynamics CRM 2013, Actions can be called only from code. You can’t call an action from a workflow or other process. So for now the most common ways to invoke Actions will be:
- From code that executes within a plugin or custom workflow.
- From an integration with another system that uses the Microsoft Dynamics CRM web services.
- From a custom client application that uses the Microsoft Dynamics CRM web services.