Process categories
Processes enable you to model real-life business processes, for example best practices or standard practices, in Dynamics 365 Customer Engagement (on-premises). 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 Dynamics 365 Customer Engagement (on-premises) 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, andsetstateoperations 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.
[IMPORTANT] Dialog is deprecated, and should be replaced by business process flows or canvas apps in Power Apps. More information: Replace dialogs with business process flows or canvas apps.
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 Dynamics 365 Customer Engagement (on-premises), which you visually design and create by using the 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 Dynamics 365 Customer Engagement (on-premises). In addition to creating new workflows, you can also use the Visual Studio Workflow Designer to visually modify existing workflows in Dynamics 365 Customer Engagement (on-premises), and then import the updated workflow into Dynamics 365 Customer Engagement (on-premises).
Note
You cannot view or update a workflow definition for a workflow that was created or modified outside of Dynamics 365 Customer Engagement (on-premises). 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 Dynamics 365 Customer Engagement (on-premises).
| 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 (Workflows and Dialogs). | Triggers are not supported for dialogs. |
| Workflows that are created or updated outside of Dynamics 365 Customer Engagement (on-premises) by creating or updating the underlying XAML file are supported in Dynamics 365 Customer Engagement (on-premises). | There is no support for created dialogs outside of Dynamics 365 Customer Engagement (on-premises) 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 Dynamics 365 Customer Engagement (on-premises) 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 Dynamics 365 Customer Engagement (on-premises) 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. Dynamics 365 Customer Engagement (on-premises) 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 with Dynamics 365 Customer Engagement (on-premises) Solutions.
See also
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for