Microsoft CRM Organization Structure and Security

Understanding Microsoft CRM security is crucial to setting up your implementation in a manner that will provide your needed functionality. Security in Microsoft CRM is set up under the Business Unit Settings section of the Settings tab in the Web Client. The actual mechanics of setting up security are very straightforward once you understand the concepts. Figure 5.4 shows the options available under the Business Unit Settings area.

Microsoft CRM's security model impacts all areas of Microsoft CRM. For example, the results that a user sees in reports are governed by that user's security settings. By running all operations through a single security model, Microsoft has eliminated the situation whereby users can bypass the security model to gain access to unauthorized data.

The concepts that make up the Microsoft CRM security model are

• Organization

• Business Units

• Teams

• Users

• Privileges

• Access Levels

• Roles

• Queues

• Quotas

When Microsoft CRM is installed, an Organization name must be provided. This becomes the top-level Business Unit to which all other Business Units are directly, or indirectly, linked. It is the only Business Unit that does not have a parent. All other Business Units must have one, and only one, parent. Figure 5.5 illustrates an Organization hierarchy.

Users and Teams

Users are assigned to one and only one Business Unit, but can be assigned multiple roles. Users can be disabled and only active users can log in to the system; users cannot be deleted. Disabling a user enables you to keep track of historical information when a user has left the company. A user can also be disabled temporarily in the case where the user is on vacation and you want to remove her from workflow processes. Keep in mind that simply disabling a user will not release the use of their license. You must go into the Licenses tab of the User record if you want to remove the license and give it to someone else.

Teams are ad hoc groups of users and are created to facilitate information sharing. Figure 5.6 shows a team being setup in Microsoft CRM.

Teams cannot be owners of records (i.e., it is not possible to assign a record to a Team), but records can be shared with Teams. Teams can include users from business units other than the team's business unit. Teams can be used to group those users working together on a large opportunity or to delineate regional sales groups. Keep in mind that teams do not have a relationship to access levels as business units do.

NOTE Teams can be great structures to organize ad hoc groups of users for things such as a large opportunity pursuit team. However, this structure lacks the capability to show each user's role with respect to the opportunity in question. Ideally, Microsoft will add the capability to link users to other records and to specify their relationship to that record. For example, it would be very helpful to be able to link an Account's Sales Representative and Service Representative to the Account record so that other users can see who is playing what role with respect to the Account.

Privileges and Access Levels

Privileges represent a user's ability to do something. For example, creating a Contact or deleting an Account are privileges. The standard Microsoft CRM objects have eight privileges; create, read, write, delete, share, assign, append, and append to. Some objects have nonstandard privileges. For example, the quote, order, and invoice objects have an OverridePriceEngine privilege and the Business Unit object has a ReParent privilege. Some objects do not have certain standard privileges. For example, because Products cannot be assigned or shared, they do not have the assign or share privileges. Table 5.1 later in this chapter defines some of the more common privileges.

Figure 5.7 shows the five Microsoft CRM Access Levels. Access Levels define the scope of where a user can exercise her privileges. For example, you might give a user access to create Contacts only in their Business Unit, or across all Business Units. Microsoft CRM defines five access levels:

• None (None Selected)

• Basic (User)

• Local (Business Unit)

• Deep (Parent: Child Business Units)

• Global (Organization)

A user with no (none) access to a privilege cannot exercise that privilege. For example, if a user has none access to the Read Contact privilege, that user will never see a Contact record: not on a screen, not in a report, nowhere. A user with basic access level for a certain privilege can exercise that privilege only on records specifically assigned to them or specifically shared with them. Keep in mind that the ability to share records is also a privilege, so you can set who can share records and within what access level.

A user with local access for a privilege can exercise that privilege only within the current business unit. So, for example, if a user with local access to view Accounts selects the All Accounts view, she will only be able to see all Accounts in her Business Unit. To see all Accounts in the current Business Unit as well as any child business units, the user needs Deep access for the privilege. Deep simply refers to the current Business Unit and below. Finally, Global access to a privilege gives the user the ability to exercise a privilege on any record in the entire organization.

Business Units

Now that you understand Access Levels, let's return briefly to Business Units. Because Access Levels are built around a hierarchy of Users, Business Units, and the Organization as a whole, this should be considered when determining how to define your Business Units. This is important because the phrase Business Unit might evoke images of large organizational units such as divisions and subsidiaries. In fact, you might want to forget the traditional meaning of the phrase Business Unit entirely and think of Microsoft CRM Business Units as a way to structure your teams from the top level Organization all the way down to the individual sales and support teams. Many CRM systems refer to this as User Groups, and it might help to think of Business Units this way. The key is to remember the User, Local, Deep, and Global Access Levels as you define your organizational hierarchy. Typically, the best way to organize your Business Units is to make the mirror the actual reporting structure of the company.

A very important consideration when structuring Business Units is whether you plan to deploy the Microsoft CRM Sales for Outlook client. By default, the Outlook client will synchronize all records in the user's Business Unit and to which the user has access. This means that if you wanted to have only one Business Unit for simplicity and you set up no record access restrictions, all Outlook client users would be forced to synchronize all records in the database. That could get very ugly as data volumes grow. If the Outlook client is in your future, be sure and review chapter 8, “Microsoft CRM Sales for Outlook,” prior to setting up your Business Units.

The organizational structure of Users and Business Units created in Microsoft CRM can be reorganized by simply changing the parent Business Unit to which a Business Unit reports. By reparenting a Business Unit, you are also moving any Business Units that roll up to it. The only Business Unit you cannot reparent is the top level Business Unit, also known as the Organization name.

You can also delete and disable Business Units. When you delete a Business Unit, you are deleting all its users, customer information, and activities as well as any child Business Units and their users, customer information, and activities. As you'll learn shortly, the records only become marked for deletion and will only be physically deleted from the database if the administrator has enabled Microsoft CRM's deletion service. Regardless of this, when a record is "deleted" through the Microsoft CRM interface it will no longer be visible to the users.

Disabling a Business Unit leaves its structure intact although the Business Unit has temporarily or permanently ceased operation. One area where this can be helpful is if you are planning a merger, acquisition, or reorganization and want to build out the organizational structure before actually exposing it to the users. You could create new Business Units and disable them until they are needed. Keep in mind that when you disable a Business Unit, its users will not be able to log in to Microsoft CRM or access their CRM data.

Roles

Roles are groupings of Privileges along with the Access Levels granted for each privilege. Users are assigned to roles, and the users inherit the privileges and access levels outlined in their assigned roles. Users can be assigned to multiple roles and, when privilege conflicts are encountered, the least restrictive access level will be applied. For example, if a user belongs to one role that allows her to delete Accounts at the Organizational level and one role that only allows her to delete Accounts at the Local level, she will be able to delete Accounts at the Organization level. Figure 5.8 illustrates a custom role with limited privileges.

For the purposes of creating and modifying roles, Microsoft CRM divides record types into the following groups:

• Core Records

• Sales

• Service

• Business Management

Core records are records that a user will work with regardless of the configuration she is using. Sales and Service records pertain to records specific to those areas. Business Management covers setting up users, roles, and so on. When setting the Access Level for each record type, a combination of the privileges shown in Table 5.1 are available:

Table 5.1. Microsoft CRM Privileges

Privilege	Definition
Append	The capability to add other records to the record in question. For example, a Note can be added to a Contact if the user has Append rights on the Contact.
Append To	Append To does the opposite of Append. With Append To, the record in question can be appended to, or attached to, another record. For example, a Note can be attached to a Contact if the user has Append To rights on the Note. You can also think of Append To as Attach.
Assign	The capability to change the owner of a record.
Create	The capability to insert a new record.
Delete	The capability to delete records (see the section titled “Delete Versus Deactivate” later in this chapter).
Enable/Disable	Relevant only to Business Units and Users. This privilege enables the user to turn entire Business Units on and off.
Read	The capability to view and own a record
Reparent	Relevant only to Business Units and Users. This is the act of changing a Business Unit's parent Business Unit. This is, in effect, a reorganization of the organizational structure.
Share	The capability to allow other users to have access to the record.
Write	The capability to update or modify a record (includes the capability to activate and deactivate records).

New roles can be built from scratch or can be copied from an existing role and modified. Microsoft CRM comes with eight standard roles, all of which can be deleted or modified. These roles are listed in Table 5.2.

Table 5.2. Predefined Roles

Role	Description
CEO-Biz Mgr	A user who manages the organization at the corporate business level.
CSR Manager	A user who manages customer service activities at the local or team level.
CSR	A customer service representative at any level.
Marketing Professional	A user engaged in marketing activities at any level.
Sales Manager	A user who manages sales activity at the local or team level.
Sales Rep	A salesperson at any level.
System Admin	A user who manages the organizational setup, business settings, and so on at the business and subbusiness level.
VP of Sales	A user who manages the business at the subbusiness level.

TIP One thing to keep in mind while working with users and roles is that Microsoft CRM enables you to remove all privileges from your own user account. For example, it is entirely possible to login with the administrator role, and then navigate to your user account and remove all roles. The next thing you will see is an error message telling you that you've lost all privileges.

The Microsoft CRM predefined roles have very liberal read access rights. Despite people's initial reactions to this concept, open access to data is really a good thing. When discussing CRM with a company that has never had a true CRM system, one of the common discussions that surfaces early centers around what users should be able to see what information. The concept of CRM is one of information sharing and keeping everyone in the loop, so locking records down naturally makes this information sharing difficult. In fact, in our experience there have been very few cases where there is a justified business need to hide information from users. Some of these are

• When working with a contractor doing telemarketing, it can make sense to limit their access to only the records to which they are placing calls.

• Some Financial Services firms that deal with mergers and acquisitions or initial pubic offerings might have a legal obligation to limit access to certain records.

• Some companies have divisions with very different business lines serving distinct customer segments and information sharing might actually cause confusion or clutter.

Other arguments for open access to data center around the need to let the users of the data keep it clean and updated. One of the biggest issues around CRM data has to do with its cleanliness, accuracy, and integrity. Because CRM data can and should include prospects, customers, vendors, suppliers, and so on the amount of data can grow rapidly. The only way to ensure that the data is up to date and as free as possible from duplicate records is to empower the people using that data daily to keep it clean. Obviously, this cannot be done without the proper access.

Queues

Microsoft CRM uses the concept of Queues with respect to Activities and Service Cases. Queues are simply a place to park Cases or Activities for review by a User or workflow process. Sales Opportunities cannot be assigned to Queues.

Unlike Teams, Queues do not have members and, therefore, cannot share records like Teams can. However, Queues are associated with an owner and an email address and single and bulk emails can be sent from Queues. This can be helpful if you want to send out emails from a generic email alias (for example, [email protected]) instead of a specific user. Figure 5.9 shows a queue designed for sending emails.

In addition to sending email, Queues can also be configured to receive emails. To enable this, the queue must have a specially configured disabled user in Active Directory. The user must be created and then a mailbox must be created for the user before the user is disabled. The user must have one of the 15 extended Active Directory attributes set to CrmEmailEnabled for the Queue to receive email.

Microsoft CRM Email configuration in-depth If you go to the Microsoft CRM tools menu, select “Options” and then go to the Activities tab you will see a setting titled as “Convert incoming email.” This is illustrated in Figure 5.10. The setting has two options: All incoming email (Requires additional configuration on the server) Only email about existing Microsoft CRM records Figure 5.10. Configuring incoming email behavior for the active user. The Microsoft CRM Email connector (an option provided when you install the Microsoft CRM server) installs a service called the Microsoft CRM Exchange Queue service. The role of this service is to monitor incoming email and determine which emails are related to Microsoft CRM. Once the service determines that an email is related to Microsoft CRM, it converts the email into Microsoft CRM as an email activity record. There are two ways that the service will determine that an email should be converted into Microsoft CRM. These are The connector determines that the email originated from Microsoft CRM The recipient's mailbox has been configured to receive all incoming emails into Microsoft CRM regardless of whether they originated from Microsoft CRM In the first case, the Microsoft CRM Exchange Queue service can tell if an email originated from Microsoft CRM if the email has a GUID (globally unique identifier) appended to the email's subject line. By default, Microsoft CRM adds this GUID to emails so that it will be able to associate the email with the object (case, opportunity, etc.) from which it originated. Without the GUID, the Exchange Queue service will not know that the email originated from Microsoft CRM, therefore it will not convert the email into a Microsoft CRM activity. Many users of Microsoft CRM complained that the GUID appended to the subject line of Microsoft CRM emails looked bad and even caused problems with email systems that mistook GUID appended emails as spam. Microsoft responded to these complaints with an update (TK29660) that disables the GUID. This update turns off the GUID which, in turn, means that email activities will not be tracked to their originating crm object. While the update solves the problem of having the GUID appear in the subject line, it also eliminates the tracking functionality that the GUID is intended to provide. If you have applied this update to disable the GUID and later want to turn it back on, you may re-enable the GUID by simply setting the MessageTagBehavior value in the Exchange server's HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSCRM key to “1”. A value of “0” in this key means the GUID is disabled and will not be appended. When the GUID is disabled, no emails will be converted into Microsoft CRM activities unless you have selected the first option in Figure 5.10 (“all incoming email”) for specific users and have done the appropriate server configuration as the option suggests. This additional server configuration involves setting one of the active user's 15 Exchange Custom Attributes to “CRMEmailEnabled” for the users as pictured in Figure 5.11. Having this attribute set tells the Exchange queue service to convert all of the user's incoming email into Microsoft CRM activities regardless of whether the GUID is present or not. Figure 5.11. Setting a custom Exchange attribute tells the Exchange queue service to convert all incoming email into Microsoft CRM activities. To set a user's custom exchange attribute to CRMEmailEnabled, go to the user's properties screen in Active Directory Users and Computers and click the Custom Attributes button on the Exchange Advanced tab. If you do not see the Exchange Advanced tab, go to the Active Directory Users and Computers view menu and select Advanced Features. When all emails are converted into Microsoft CRM email activities, these activities will be attached to CRM records where matching email addresses can be found and resolved. If no matching emails are resolved, the emails will still be converted into activities and the user must then resolve the email addresses and/or link the emails to other CRM objects through the email activity “regarding” field. Converting all emails into Microsoft CRM activities will result in emails that are totally unrelated to CRM being converted into CRM activities. While this will likely not be what you want for regular users, it may be appropriate for queues. Since queues can be associated with exchange email aliases, you might want all email sent to those queues/aliases to be automatically converted into Microsoft CRM activities even when the emails did not originate from Microsoft CRM. A good example of this is the inbound support alias ([email protected]) for companies that support products. Having support emails go directly into a queue will allow your support representatives to retrieve those emails directly from the queue and attach them to Case records. To set up a queue to receive all inbound emails, you must create the user, set one of its Exchange custom attributes to CRMEmailEnabled and then create a queue with that email alias. A detailed set of instructions on how to do this can be found on Microsoft Business Solutions PartnerSource and CustomerSource techknowledge (available to Microsoft CRM partners and customers) in document 30150.

Quotas

The Salespeople with Quotas section enables you to assign quotas to salespeople based on the fiscal periods set under Fiscal Year settings. Figure 5.12 shows the quotas screen for an Organization using a calendar year fiscal period grouped by quarters.

The quota information is used in the standard Microsoft CRM reports.