Dynamics 365 Process categories
Applies To: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online
Processes enable you to model real-life business processes, for example best practices or standard practices, in Microsoft Dynamics 365. When modeling your business practices, you can choose from four categories of processes:
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 standard Microsoft Dynamics 365 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 of the 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. More information: 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. Because the SDK is developer-focused, we are covering the coding aspect of creating workflow processes.
XAML (Declarative) workflows
You can create XAML workflows for on-premises Microsoft Dynamics 365, 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 365. In addition to creating new workflows, you can also use the Microsoft Visual Studio Workflow Designer to visually modify existing workflows in Microsoft Dynamics 365, and then import the updated workflow into Microsoft Dynamics 365.
Note
You cannot view or update a workflow definition for a workflow that was created or modified outside of Microsoft Dynamics 365. You can only change the state (activate or deactivate) of the workflow, and run it. XAML workflows aren’t supported in Microsoft Dynamics 365 (online).
Differences between workflows and dialogs
The following table provides information about the differences between workflows and dialogs in Microsoft Dynamics 365.
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, entities, and actions for processes. |
Triggers are not supported for dialogs. |
Workflows that are created or updated outside of Microsoft Dynamics 365 by creating or updating the underlying XAML file are supported in Microsoft Dynamics 365 on-premises. For information about these custom XAML workflows, see Custom XAML workflows. |
There is no support for created dialogs outside of Microsoft Dynamics 365 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 365 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 365 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 365 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.
More information: Package and distribute extensions using solutions.
See Also
Automate business processes using Dynamics 365 process
Microsoft Dynamics 365
© 2016 Microsoft. All rights reserved. Copyright