CRM 2013 Workflows What can Workflows do? In CRM 2013, there are four types of Processes that can be created. We are covering Workflows today, but here is a brief explanation of each type. Process category Workflow Dialogs Actions Business Process Flows Description Use workflows to automate business processes behind the scenes. Workflows are typically initiated by system events so the user doesn t need to be aware that they are running, but they can also be configured for people to manually initiate them. Workflows can operate in the background (asynchronously) or in real-time (synchronously). These are referred to separately as background workflows or real-time workflows. Use dialogs to create a user interface that will guide people through a script for customer interaction or a wizard to perform complex actions consistently. Use actions to expand the vocabulary available for developers to express business processes. With core verbs like Create, Update, Delete, and Assign provided by the system, a Action uses those core verbs to create more expressive verbs like Approve, Escalate, Route, or Schedule. If the definition of a business process changes, someone who isn t a developer can edit the Action so the code doesn t need to be changed. Use business process flows to define the steps in which people should enter data to achieve an outcome. Business process flows add a control to the top of a form that show people what data they need to enter to move forward to the next stage and ultimately to completion of a business process. A business process flow can span multiple entities. Since we are dealing with Workflows only, below are the steps a workflow can perform: Stage Step Description Stages make the workflow logic easier to read, and explain the workflow logic. However, stages don t affect the logic or behavior of workflows. If a process has stages, all the steps in the process must be contained with a
stage. Check Condition A logical "if-<condition> then" statement. Conditional Branch Default Action Wait Condition Parallel Wait Branch Create Record Update Record Assign Record Send Email Start Child Workflow Change Status 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 relationship, or any records created by earlier steps. Based on these values you can define additional steps when the condition is true. 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. 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 don t match the criteria defined in condition or branch elements. 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. 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. Creates a new record for an entity and assigns values to attributes. You can update the record that the workflow is running on, any of the records linked to that record in an N:1 relationship, or any records created by earlier steps. 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. 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. Starts a workflow process that has been configured as a child workflow. 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/Stop Dialog Custom Step Stops the current workflow, dialog, or action. You can set a status of either Succeeded or Canceled and specify a status message. Provides extensions to the logical elements available by default in CRM. Steps can include conditions, actions, other steps, or a combination of these elements. Developers can create custom workflow steps. By default, there are no custom steps available in CRM. Creating a New Workflow 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. The options are: Note Record is created Record status changes Record is assigned Record fields change Record is deleted 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. 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. 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.
Example Workflows Set new accounts to be owned by Admin 1. Navigate to Settings Processes. Make a new workflow a. Category is Workflow b. Entity is Account 2. Set the Scope to User 3. Set Start When to Record is Created
4. Then hit Add Step, and select Assign Record 5. Assign the Account to CRM System 6. Hit Activate to turn on the workflow 7. Create a new account and test. Set any account with type of Partner to be owned by Jeff. 1. Start a new workflow as before 2. This time, also select to run As an on-demand process 3. Also select to run automatically when Records Field Change, and select the Relationship Type field 4. Then Add Step, and select Check Condition a. Account, field Relationship Type Eqauls Partner
5. Then click on Select This Row and click Add Step 6. Add an Assign Record step 7. Assign the Account to Jeff 8. Activate the workflow 9. Create or change an account to type Partner and test
Set any contact that has a parent account to inherit the parent account address.
When a new Lead is created, create a follow up task for 3 days later. When a case is closed, create a follow up task based on satisfaction level. More Information http://technet.microsoft.com/en-us/library/dn531067.aspx - Workflow Processes http://technet.microsoft.com/en-us/library/0b47dfd5-76db-464f-90c0- c64a0173dcdd#bkmk_settingconditionsforworkflowactions Setting Workflow Conditions http://technet.microsoft.com/en-us/library/0b47dfd5-76db-464f-90c0- c64a0173dcdd#bkmk_synchronousworkflows using Real-time Workflows http://crmbook.powerobjects.com/system-administration/processes/workflows/