Processes, Workflows, and Dialogs for Microsoft Dynamics CRM
In Microsoft Dynamics CRM 2011, workflows are now called processes. In addition to this change, there are two categories of processes:
-
Workflows. The automated or asynchronous processes that may require user input to start them. Further, these processes do not require user input to run them to completion. These processes run in the background.
-
Dialogs. The interactive or synchronous processes that require user input to start and run them to completion. When you start the dialog process, a wizard-like interface is presented to you so you can make appropriate selections to run the process.
Processes now support 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.
As a result, you now use the System.Activities namespace instead of System.Workflow.Activities to create custom workflow activities. However, if you want your custom workflow activities to work with earlier versions of Microsoft Dynamics CRM, you should use the System.Workflow.Activities namespace only.
The workflow log stores a result, succeed, failed, or canceled. for each step of a process that is executed. This is the same for both workflows and dialogs.
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. |
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 processes, and do not require user input to run to completion. These processes run in the background. |
Are synchronous processes, and 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 workflow is AsyncOperation. |
The entity that stores information generated by a running dialog is the ProcessSession (dialog session) entity. |
|
Both Windows Workflow Foundation 4 and Windows Workflow Foundation 3.5 custom activities are supported. |
Only Windows Workflow Foundation 4 custom activities are supported. |
|
Triggers are supported for workflows. For a list of supported triggers, see Supported Types, Triggers, and Entities for Processes (Workflows and Dialogs). |
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. For information about these custom XAML workflows, see Custom XAML Workflows for Microsoft Dynamics CRM 2011. |
Dialogs that are created or updated outside of Microsoft Dynamics CRM by creating or updating the underlying XAML file are not supported in Microsoft Dynamics CRM. |
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.
-
It is acceptable to have a delay between when the event occurs and when the workflow rule runs. Unless applied manually, workflow rules run asynchronously and run after the event occurs. If you need synchronous processing, use plug-ins.
-
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.
For more information, 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.
See Also
Microsoft Dynamics CRM 2011
Send comments about this topic to Microsoft.
© 2013 Microsoft Corporation. All rights reserved.
Note