Workflow categories
Applies To: Dynamics CRM 2013
Processes enable you to model real-life business processes, for example best practices or standard practices, in Microsoft Dynamics CRM. There are four categories of processes you can choose from in when modeling your business practices:
Workflow. Use this process to model and automate real world business processes. These processes can be configured to run in the background or in real time and can optionally require user input. Workflow processes can start automatically based on specified conditions or can be started manually by a user.
Action. Use this process to create a new operation that is not available in a stock Microsoft Dynamics CRM installation or to combine multiple disparate operations into a single operation. For example, in the case of a support call center, you could combine create, assign, and setstate operations into a single new “escalate” operation.
Business process flow. Use this process to create a visualization of the business process flow. Users are guided through various stages of the sales or customer service processes. At each stage, you complete specific steps and then move to the next stage. You can customize the process flow by adding or removing steps, changing the order stages, or adding new entities to the process flow.
Dialog. Use this process to create an interactive step-by-step data entry form that requires user input to start and run to completion. When you start the dialog process, a wizard-like interface is presented so you can make appropriate selections or enter data as you progress through each page of the wizard.
The processes capability is implemented using Windows Workflow Foundation. The latest version of Windows Workflow Foundation has improved to facilitate easier creation, running, and maintenance of workflows to implement custom functionalities in your application. For more information, see What's New in Windows Workflow Foundation.
There are three ways to create business processes: interactively through the web application forms and the workflow designer, by writing code that uses workflow related classes, and by importing a pre-made workflow in a solution. Since the SDK is developer focused, we are focusing on the coding aspect of creating workflow processes.
XAML (Declarative) Workflows
You can create XAML workflows for on-premises Microsoft Dynamics CRM, which you visually design and create by using the Microsoft Visual Studio Workflow Designer. This method of creating workflows does not require that you write code. Moreover, you do not have to compile these workflows, and can import the workflow definition (XAML) into Microsoft Dynamics CRM. In addition to creating new workflows, you can also use the Microsoft Visual Studio Workflow Designer to visually modify existing workflows in Microsoft Dynamics CRM, and then import the updated workflow into Microsoft Dynamics CRM.
Note
You cannot view or update a workflow definition for a workflow that was created or modified outside of Microsoft Dynamics CRM. You can only change the state (activate or deactivate) of the workflow, and run it. XAML workflows are not supported in Microsoft Dynamics CRM Online.
Differences between Workflows and Dialogs
The following table provides information about the differences between workflows and dialogs in Microsoft Dynamics CRM.
Workflows |
Dialogs |
|---|---|
Can be either started by a user or can be automated. |
Must be started by a user. |
Are asynchronous or real-time processes, and do not require user input to run to completion. Asynchronous processes run in the background while real-time processes run immediately. |
Are real-time processes that require user input to run to completion. When you run these processes, a wizard-like interface is presented to you so you can make appropriate selections to run the processes. |
The entity that stores the details about a running asynchronous workflow is AsyncOperation while a Process is used for a real-time workflow. |
The entity that stores information generated by a running dialog is the ProcessSession entity. |
Triggers are supported for workflows. For a list of supported triggers, see Supported types, triggers, and entities for processes. |
Triggers are not supported for dialogs. |
Workflows that are created or updated outside of Microsoft Dynamics CRM by creating or updating the underlying XAML file are supported in Microsoft Dynamics CRM on-premises. For information about these custom XAML workflows, see Custom XAML workflows. |
There is no support for created dialogs outside of Microsoft Dynamics CRM by defining XAML. |
When to Use a Workflow Instead of a Plug-in
Most operations that can be accomplished by using workflows can also be accomplished by using plug-ins. However, you should use workflow processes instead of plug-ins when:
Changes in the business logic must be performed by people who are not developers, or the changes should not be dependent on the availability of a developer to do the work. When custom workflow activities are defined as Workflow .NET assemblies, a person who is not a developer can use Microsoft Dynamics CRM to define the conditions when the custom actions are performed and the parameters that will be passed to the assembly.
You need the ability to let users apply your workflow logic manually. With workflow processes, users can trigger the processing of workflow rules by clicking Run Workflow on the form or from a grid.
Use plug-ins when you need the best performance possible from your custom business logic. Plug-ins can start quicker and therefore typically run faster that even a real-time workflow. However, the benefit in performance may be outweighed by the ease of use in creating and maintaining workflows where only a non-developer, for example a business analyst, is required to do the work.
For more information about plug-ins, see Write plug-ins to extend business processes.
Distributing Workflows in Solutions
You can include workflows and custom workflow activities in a solution that is imported into another Microsoft Dynamics CRM deployment. However, if you refer to specific entity instances in a workflow and the workflow is moved into another system, problems will arise because the unique IDs of the entity instances in the workflow will differ from those in the target system. Microsoft Dynamics CRM automatically resolves system user and currency entity records based on the full name property, but it won't automatically resolve records for other entity types.
For more information about solutions, see Package and distribute extensions using solutions.