Workflow processes in Dynamics CRM 2013

Workflows automate business processes without a user interface. People usually use workflow processes to initiate automation that doesn’t require any user interaction.
Though workflows are not new in Dynamics CRM 2013, however Microsoft introduced new feature in Dynamics CRM 2013 that allows users to create real-time/synchronous workflows.
Each workflow process is associated with a single entity. When configuring workflows you have four major areas to consider:

• When to start them?
• Should they run as a real-time workflow or a background workflow?
• What actions should they perform?
• Under what conditions should actions be performed?

1. Where do you customize workflow processes?
You can see the workflows in your organization by viewing the ‘Processes’ node in the ‘Default Solution’ and filtering on processes that have the ‘Category Workflow’.

2. Workflow properties
In the solution explorer, select ‘Processes’ and click ‘New’.
When you create a workflow the ‘Create Process’ dialog requires that you set three properties that all processes have:

– Process name: The name of the workflow process does not need to be unique, but if you expect you will have a lot of workflows, you may want to use a naming convention to clearly differentiate your processes. You may want to apply standard prefixes to the name of the workflow. The prefix may describe the function of the workflow or the department within the company. This will help you group similar items in the list of workflows.
– Category: This property establishes that this is a workflow process.
– Entity: Each workflow process must be set to a single entity. You can’t change the entity after the workflow process is created.
– Run this workflow in the background (recommended): This option appears when you select workflow as the category. This setting determines whether the workflow is a real-time or background workflow. Real-time workflows run immediately (synchronously) and background workflows run asynchronously. The configuration options available depend on your choice for this setting. Background workflows allow for wait conditions that are not available for real-time workflows. As long as you don’t use those wait conditions, at a later time you can convert background workflows to real-time workflows and real-time workflows to background workflows.
You also have the ‘Type’ option to specify whether to build a new workflow from scratch or choose to start from an existing template. When you choose ‘New process from an existing template (select from list)’ you can choose from the available Workflows processes that were previously saved as a process template.
After you create the Workflow or if you edit an existing one, you will have the following additional properties:

– Activate As: You can choose ‘Process template’ to create an advanced starting point for other templates. If you choose this option, after you activate the workflow it will not be applied but instead it will be available to select in the ‘Create Process’ dialog if you select ‘Type: New process from an existing template (select from list)’
Process templates are convenient when you have a number of similar workflow processes and want to define them without duplicating the same logic.
Note: Editing a process template does not change the behaviors of any other workflow processes previously created using it as a template. A new workflow created using a template is a copy of the content in the template.
– Available to Run: This section contain options that describe how the workflow is available to be run.
– Run this Workflow in the background (recommended):This check box reflects the option you selected when you created the workflow. This option is disabled, but you can change it from the ‘Actions’ menu by choosing either ‘Convert to a real-time workflow’ or ‘Convert to a background workflow’.
– As an on-demand process: Choose this option if you want to allow users to run this workflow from the ‘Run Workflow’ command.
– As a child process: Choose this option if you want to allow the workflow to be available to be started from another workflow.
– Scope: For user-owned entities, options are Organization, Parent: Child Business Units, Business Unit, or User. For Organization-owned entities the only option is Organization.
If scope is Organization, then the workflow logic can be applied to any record in the organization. Otherwise, the workflow can only be applied to a subset of records that fall within the scope.
Note: The default scope value is User. Make sure you verify that the scope value is appropriate before you activate the workflow.
– Start When: Use the options in this section to specify when a workflow should start automatically. You can configure a real-time workflow to be run before certain events. This is a very powerful capability because the workflow can stop the action before it occurs.

• Record is created
• Record status changes
• Record is assigned
• Record fields change
• Record is deleted

Note: Keep in mind that the actions and conditions you define for the workflow are not aware of when the workflow is run. For example, if you define a workflow to update the record, this action can’t be performed by a real-time workflow before the record is created. A record that doesn’t exist cannot be updated. Similarly, a background workflow can’t update a record that has been deleted, even though you could define this action for the workflow. If you configure a workflow to perform an action that can’t be performed, it will fail and the entire workflow will fail.
– Execute As: This option is only available if you unselected the ‘Run this workflow in the background (recommended)’ option when you created the workflow or if you later converted a background workflow to be a real-time workflow.

3. Security context of workflow processes
When a background workflow is configured as an on-demand process and is started by a user using the ‘Run Workflow’ command, the actions that the workflow can perform are limited to those the user could perform based on the privileges and access levels defined by the security role(s) set for their user account.
When a background workflow starts based on an event the workflow operates in the context of the person who owns it, usually the person who created the workflow.
For real-time workflows you have the ‘Execute As’ option and you can choose whether the workflow should apply the security context of the owner of the workflow or the user who made changes to the record. If your workflow includes actions which all users would not be able to perform based on security constraints, you should choose to have the workflow run as the owner of the workflow.

4. Activate a workflow
Workflows can only be edited while they are deactivated. Before a workflow can be used manually or be applied due to events it has to be activated. Before a workflow can be activated it must contain at least one step.
A workflow can only be activated or deactivated by the workflow owner or by someone with the ‘Act on Behalf of Another User’ privilege such as the system administrator.  The reason for this is that a malicious user could modify someone’s workflow without them being aware of the change. You can reassign a workflow you own by changing the owner. This field is on the ‘Administration’ tab. If you are not the system administrator and you need to edit a workflow that has to owned by another user, you need them to deactivate it and assign it to you. After you finish editing the workflow, you can to assign it back to them and they will need to activate it.
Real-time workflows require that the user have the ‘Activate Real-time Processes’ privilege. Because real-time workflows have a greater risk of affecting system performance, only people who can evaluate the potential risk should be given this privilege.
Workflows are saved when they are activated, so it is not necessary to save them before activating them.

5. Configure workflow steps
When configuring workflows you have four major areas to consider:

• When to start them?
• Should they run as a real-time workflow or a background workflow?
• What actions should they perform?
• Under what conditions actions should be performed?

 5.1 Workflow stages and steps: When you design workflows you have the option to contain the logic you want to perform in stages and steps.
Stages: Stages make the workflow logic easier to read, and explain the workflow logic. However, stages do not affect the logic or behavior of workflows. If a process has stages, all the steps within the process must be contained with a stage.
Steps: Steps are a unit of business logic within a workflow. Steps can include conditions, actions, other steps, or a combination of these elements.
5.2 Actions that workflow processes can perform: Workflow processes can perform the actions listed in the following table.

Action	Description
Create Record	Creates a new record for an entity you choose and assigns values you choose to attributes.
Update Record	You can update the record that the workflow is running on, any of the records linked to that record in an N:1 relationships, or any records created by earlier steps.
Assign Record	You can assign the record that the workflow is running on, any of the records linked to that record with an N:1 relationship, or any records created by earlier steps.
Send Email	Sends an email. You can choose to create a new email message or use an email template configured for the entity of the record that the workflow is running on or any entities that have an N:1 relationship with the entity, or the entity for any records created by earlier steps.
Start Child Workflow	Starts a workflow process that has been configured as a child workflow.
Change Status	Changes the status of the record that the process is running on, any of the records linked to that record with an N:1 relationship, or any records created by earlier steps.
Stop Workflow	Stops the current workflow. You can set a status of either Succeeded or Cancelled and specify a status message.When real-time workflows are configured for an event, stopping a workflow with a status of cancelled will prevent the event action from completing.
Custom Step	Developers can create custom workflow steps that define actions. There are no custom steps available in Microsoft Dynamics CRM by default.

5.3 Setting record values: When you create a record you can set values for the record. When you update a record you can set, append, increment, decrement, multiply, or clear values.
When you click ‘Set Properties’, a dialog opens showing you the default form for the entity.
At the bottom of the dialog you can see a list of additional fields not present in the form.
For any field, you can set a static value and that will be set by the workflow.
On the right side of the dialog the ‘Form Assistant’ gives you the ability to set or append dynamic values from the context of the current record. This includes values from related records that can be accessed from the N:1 (many-to-one) relationships for the entity.
The options available in the ‘Form Assistant’ depend on the field you have selected in the form. When you set a dynamic value, you will see a yellow placeholder known as a ‘slug’ that shows where the dynamic data will be included. If you want to remove the value, just select the slug and delete it. For text fields, you can use a combination of static and dynamic data.
With dynamic values you don’t know for certain that a field or related entity has the value you want to set. You can actually set a number of fields to try and set the value and sort them in order using the green arrows. If the first field doesn’t have data, the second field will be tried and so on. If none of the fields have data, you can specify a default value to be used.
5.4 Setting conditions for workflow actions: The actions that you will apply often depend on conditions. Workflow processes provide several ways to set conditions and create branching logic to get the results you want. You can check values of the record that the workflow process is running against, any of the records linked to that record with an N:1 relationship, or values within the process itself

Condition Type	Description
Check Condition	A logical “if-<condition> then” statement. You can check values for the record that the workflow is running on, any of the records linked to that record in an N:1 relationships, or any records created by earlier steps. Based on these values you can define additional steps when the condition is true.
Conditional Branch	A logical “else-if-then” statement, the editor uses the text “Otherwise, if <condition> then:” Select a check condition you have previously defined and you can add a conditional branch to define additional steps when the check condition returns false.
Default Action	A logical “else” statement. the editor uses the text “Otherwise:” Select a check condition, conditional branch, wait condition, or parallel wait branch that you have previously defined and you can use a default action to define steps for all cases that do not match the criteria defined in condition or branch elements.
Wait Condition	Enables a background workflow to pause itself until the criteria defined by the condition have been met. The workflow starts again automatically when the criteria in the wait condition have been met. Real-time workflows cannot use wait conditions.
Parallel Wait Branch	Defines an alternative wait condition for a background workflow with a corresponding set of additional steps that are performed only when the initial criterion is met. You can use parallel wait branches to create time limits in your workflow logic. They help prevent the workflow from waiting indefinitely until the criteria defined in a wait condition have been met.
Custom Step	Developers can create custom workflow steps that define conditions. There are no custom steps available in Microsoft Dynamics CRM by default.

5.5 Using real-time workflows: With Microsoft Dynamics CRM 2013 you can configure real-time workflows but you should use them with care. Background workflows are generally recommended because they allow the system to apply them as resources on the server are available. This helps smooth out the work the server has to do and help maintain 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 they will be applied, but generally it will take a few minutes. 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 if you want 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.

6. Converting between real-time and background workflows:
You can change a real-time workflow into a background workflow by choosing ‘Convert to a background workflow’ on the toolbar.
You can change a background workflow into a real-time workflow by choosing ‘Convert to a real-time workflow’ on the toolbar. If the background workflow uses a wait conditions it will become invalid and you won’t be able to activate it until you remove the wait condition.

7. Initiating real-time workflows before or after status changes:
When you configure ‘Options for Automatic Processes’ for real-time workflows, the ‘Start When’ options for the status changes event let you select ‘After’ or ‘Before’ for when status changes. The default option is ‘After’.
When you select ‘Before’ you are saying that you want the logic in the workflow to be applied before data changing the status is saved. This provides you with the ability to check the values before other logic has been applied after the operation and prevent further logic from being performed. For example, you may have additional logic in a plugin or custom workflow action which could initiate actions on another system. By stopping further processing you can avoid cases where external systems are affected. Applying real-time workflows before this event also means that other workflow or plug-in actions in Microsoft Dynamics CRM that may have saved data don’t need to be “rolled back” when the operation is canceled.

8. Using the Stop Workflow action with real-time workflows
When you apply a ‘Stop Workflow’ action in a workflow you have the option to specify a status condition that can be either ‘Succeeded’ or ‘Canceled’. When you set the status to canceled, you prevent the operation. An error message containing the text from the stop action status message will be displayed to the user with the heading ‘Business Process Error’.

Advertisement