Overview

Many companies try to adopt and implement standardized business processes to help their operations run more consistently and smoothly. For example, the CEO might say, "All customer service cases must be resolved within 24 hours," or, "We're implementing a new sales process for all deals over $100,000." However, the communication of these business processes often gets delivered to employees in an ad hoc and unregulated manner. A process document might exist on a network file share, but people don't know that it's there. And some employees might rely on word-of-mouth information from co-workers to learn the processes for their jobs. Consequently, standardizing business processes can prove challenging for some companies, particularly larger organizations. So what benefit does workflow offer for these scenarios? Microsoft CRM workflow provides a tool to help you set up and define business process activities (including the proper sequencing) that employees should use when working with Microsoft CRM data.

Important 

Conceptually, you can think of Microsoft CRM workflow as an application or service that runs in the background 24 hours a day, 7 days a week, constantly evaluating your Microsoft CRM data and the multiple workflow rules in your deployment. When the workflow service sees a trigger event, it fires the appropriate workflow rules to run the workflow actions. Typical workflow actions include sending an e-mail message, creating a task, and updating a data field.

We'll cover the following workflow basics in this section:

• Running workflow rules in the user interface

• Types of workflow

• Workflow utilities

• Securing workflow rules

Running Workflow Rules in the User Interface

We'll explain how to create workflow rules shortly, but first we want to show you how workflow rules appear in the Microsoft CRM user interface. Let's assume that you've already created multiple workflow rules for the Opportunity entity. When users look at a view of Opportunity records, they can select one or more records and then click Apply Rule on the More Actions menu, located on the grid toolbar, as shown in Figure 8-1.

Figure 8-1: Accessing workflow rules from the grid toolbar

A dialog box appears, as shown in Figure 8-2.

Figure 8-2: Apply Rule dialog box

As you can see, you choose to apply either a workflow process rule or sales process rule to the records selected in the Opportunity view. After you select the rule that you want to apply and click OK, Microsoft CRM runs that rule for each of the selected records and takes the actions that the rule specifies.

Note 

You can apply sales process rules to Opportunity records only.

We've just described how to apply workflow rules manually by using the user interface. Of course, the real benefit comes from when you set up workflow rules that trigger automatically based on the events that you specify.

Caution 

The Workflow service responsible for executing rules does not respond immediately to new rules. You might experience a slight delay between the time that you apply a rule and the time that the rule is implemented. Depending on the workflow action, you might also have to refresh the record you're viewing to see new or updated values.

Types of Workflow

As you just saw, Microsoft CRM includes two types of workflow rules:

• Workflow process Actions that Microsoft CRM executes based on the trigger events and conditions that you specify

• Sales process Logical phases of a sales process defined by stages and actions within each sales stage

Because sales processes apply only to the Opportunity entity, you'll usually work with workflow process rules. Table 8-1 shows the entities for which you can create workflow process rules, grouped by their functional areas in the software.

Table 8-1: Entities That Support Workflow Process Rules
Open table as spreadsheet

Common	Sales	Marketing	Customer service
Account	Lead	Campaign	Case
Contact	Opportunity	Campaign Activity	Contract
Appointment	Invoice	Campaign Response	Service Activity
E-mail	Order	Marketing List
Fax	Quote
Letter
Phone Call
Task

As you can see, Microsoft CRM does not support workflow rules for organization-owned entities such as Products, Subjects, and Territories.

Important 

You can also create workflow process rules for any custom entity with user-owned records. You specify user ownership (versus organization ownership) at the time that you create a custom entity.

If you need to create many very similar workflow or sales process rules, you can create a workflow template. To create a new workflow rule from a template in Workflow Manager (explained later in this chapter), change the view to Rule Template, and then click Create Rule From Template on the Actions menu. Users can't see or apply workflow templates through the user interface; they're designed to help administrators quickly create new rules and sales processes. This same template technique works for both workflow and sales process rules.

Tip 

You can also create a copy of a workflow or sales process rule by clicking Create Copy on the Actions menu or the Create Copy button on the toolbar.

Workflow Utilities

Microsoft CRM workflow offers several utilities to help you design, manage, and administer workflow rules. The four workflow utilities are:

• Workflow Manager Use this tool to create, modify, delete, activate, and deactivate workflow rules and sales processes.

• Workflow Monitor Use this tool to view and troubleshoot all of the current workflow rules running in your deployment.

• Export Workflow Wizard Use this tool to export one or more workflow or sales process rules so that you can import them into a different Microsoft CRM deployment.

• Import Workflow Wizard Use this tool to import workflow and sales process rules into your current deployment.

All of these utilities offer a simple and clean interface that any power user can quickly learn. You do not need programming skills or complex code to create powerful workflow rules. As we mentioned earlier, you access and run all of these workflow utilities by logging on to the Microsoft CRM Web server (you can use Remote Desktop or Terminal Services). You'll find shortcuts to the workflow utilities by clicking Start, pointing to All Programs, and then clicking Microsoft CRM. We'll discuss the use of each of these utilities in detail in this chapter.

Securing Workflow Rules

Just like the other features in Microsoft CRM, you can set up and configure detailed security settings for your workflow rules. Let's cover securing workflow rules from two different perspectives:

• Creating workflow rules

• Running workflow rules

Creating Workflow Rules

You learned that you create workflow rules by using Workflow Manager on the Microsoft CRM Web server. So before anyone can even launch Workflow Manager, the user must have permission to log on to the server. Most of the time, users with the System Administrator role will be responsible for creating and managing workflow rules. However, this is not a requirement. If you decide to allow other users or managers to create workflow rules, you'll have to give them permission to log on to the Microsoft CRM Web server.

After a user logs on to the server, he or she may launch Workflow Manager. Workflow Manager will run only for users assigned a security role with Create, Read, Write, and Delete privileges for both the Process and Process Instance entities.

Important 

The Microsoft CRM security roles refer to workflow as the Process and Process Instance entities. You can find these entities on the Customization tab when you're editing a security role.

Only the System Administrator and the System Customizer default security roles include the security privileges necessary to launch Workflow Manager, but you can add these privileges to other roles. You can also assign users a security role that includes different access levels for the Process and Process Instance entities; you do not have to assign the Organization-level rights to use workflow.

When a user creates a workflow rule, Microsoft CRM assigns the rule to the same business unit as the owner who created the rule. If someone later updates an existing rule, Microsoft CRM updates the rule owner and the rule's business unit to reflect the last user who modified it.

Important 

The workflow rule's business unit and owner are critically important, because workflow rules run in the security context of the user who created the rule, not the security privileges of the user running the rule. However, if a user manually applies a workflow rule through the user interface, the rule will run under the context of that user's security privileges (not under the security privileges of the rule owner).

If you experience a scenario in which the workflow rule doesn't run correctly when kicked off automatically but it does work correctly when you run it manually, 9 times out of 10 this problem can be fixed by making sure that the workflow rule has the security privileges necessary to execute all of the actions contained in the rule.

Tip 

Because workflow rules can run in the security context of the rule owner, you should not create workflow rules with a Restricted Access Mode user. If a Restricted Access Mode user creates a workflow rule, Microsoft CRM will never execute the rule correctly, because such users by definition cannot modify Microsoft CRM records.

Running Workflow Rules

To manually apply a workflow rule through the user interface, a user must have a security role that includes the Read privilege for the Process entity. By default, all of the security roles in Microsoft CRM include the Organization access level for the Read privilege of the Process and Process Instance entities. Therefore, all of your users can manually run all of the workflow rules. We assume that, sooner or later, you'll want to restrict or hide certain workflow rules so that some of your users cannot run them.

You already learned that each workflow rule includes an owner and a business unit. However, when you're configuring the security roles and access levels for your users in regards to workflow, you need to know that workflow security behaves differently than the regular entities like Account and Contact. Consider the sample business unit hierarchy in Figure 8-3.

Figure 8-3: Sample business unit hierarchy

If you create a workflow rule as the System Administrator, you probably belong to the Root Business Unit, and therefore the workflow rule will belong to the Root Business Unit. Unlike its treatment of the other entities, such as Account and Contact, Microsoft CRM propagates workflow rules down the business unit hierarchy to make the workflow rule available to the child business units. Therefore, this workflow rule would be available to users in all of the child business units (A, B, C, D, and E). So even if a user in Business Unit D only had Business Unit Access Level for the Read privilege of the Process entity, he or she could run a workflow rule created and owned by a user in the Root Business Unit. In regards to the other entities like Accounts or Contacts, a user in Business Unit D would need Organization Access Level to view records owned by someone in the Root Business Unit.

If you logged on as a user from Business Unit B and created a workflow rule, that rule would belong to Business Unit B. If you then modified the default security roles so that users have Business Unit access levels (instead of the default access level of Organization) for the Read privilege of the Process entity, only users who belonged to Business Unit B and Business Unit E could see and apply this rule.

Because users can manually apply workflow rules of any event type (including Create, Assign, and Change Status) if they have security privileges to read the workflow rule, someone might accidentally wreak havoc on your system by manually running a rule that is not designed to be executed manually! To prevent this scenario, you can try using a naming convention with your workflow rules that warns users about potential trouble. For example, you could prefix the rule name with "DO NOT USE -." However, the safest solution for restricting user access is to create workflow rules that belong to a business unit that no users belong to. Then replace Organization-level access with Business Unit—level access for the Process Read privilege for all security roles. By using this technique, you can effectively "hide" complex or sophisticated workflow rules that you don't want users to accidentally apply manually.