Workflows are a central part Dynamics CRM. Sales force automation (SFA) requires a sales process with predefined activities to be completed in different stages. Over time capabilities added into the workflow engine, include: expanding the range of use cases to automate data entry tasks, to notify users of important events or to enforce custom business logic.
Workflows are no longer background processes. CRM 2011 introduced Dialogs and the possibility of building “interactive workflows” with a user interface for both presenting output as well as collecting input from the user. The terminology in Dynamics CRM was adjusted slightly in the 2011 release, with the new Process concept is used to cover the two sub-categories of Workflow Processes and Dialog Processes.
CRM 2013 introduces several new features, and moves away from the separation between interactive data entry forms and asynchronous background processes. The core CRM product offers configuration tools to build applications that adapt to the actions of the users in real time and also guides them through the business processes interactively.
Process templates are convenient when you have a number of similar workflow processes and want to define those without duplicating the same logic.
Each workflow process is associated with a single entity.
Workflow processes provide several ways to set conditions and create branching logic to get the results you want
So the concept of a “Process” in Dynamics CRM is now broader that it was previously. The Process Center in CRM 2013, “New” button presents you with a selection of 4 different process categories: Action, Business Process Flow, Dialog, Workflow.
When configuring workflows you have four major areas to consider:
• When to start?
• Should these run as a real-time workflow or a background workflow?
• What actions should these perform?
• Under what conditions should actions be performed?
Background workflows are generally still recommended because this allow the system to apply those workflows when resources on the server are available. This helps to smooth out the server work the server to and to ensure the best performance for everyone using the system.
The drawback is that actions defined by background workflows are not immediate. You can’t predict when those will be applied, and generally it will take a few minutes and in most practical cases that is as good as real time. For most automation of business processes this is fine because people using the system don’t need to be consciously aware that the process is running.
Use real-time workflows when a business process requires someone to immediately see the results of the process or when you need the ability to cancel an operation. For example, you may want to set certain default values for a record the first time it is saved, or you want to make sure that some records are not deleted.
