• "Book - Microsoft Dynamics CRM 2011 - Customization & Configuration (MB2-866) - Certification Guide (Capter 3)"
  Published by Neil Benson (PACKT Publishing) on November 2012
  http://packtlib.packtpub.com/library/9781849685801/ch03

The organization structure in Microsoft Dynamics CRM refers to the hierarchy of business units, users, and teams configured within your organization. It is a good idea to plan your organization structure and consider the business units, users, teams, and security roles before creating them. Business units, users, teams, and security roles can all be renamed if required, but using short, descriptive names is preferred so that mergers, acquisitions, divestments, restructuring, or rebranding doesn’t lead to lots of organization structure changes in your CRM system.

Business units

A business unit represents a part of your organization that has security requirements distinct from another part. Business units could correspond to your organization’s divisions or dependents, but the business units configured in Microsoft Dynamics CRM do not necessarily need to match the business units shown in your organization chart. Distinct business unit need to be created in CRM where distinct security requirement exist.

The root business unit

The root business unit is the ultimate parent business unit in the organization structure. It is created by the CRM Server Setup program, when CRM installed with all server roles or by the CRM Deployment Manager, when a new CRM organization is deployed.

The root business unit has the following properties:

• It can be renamed.
• It cannot be disabled or deleted.
• It cannot have a parent business unit.

Managing the business unit

By default you need to have a System Administrator security role to manage business units (users with the CEO-Business Manager security role can also manage business units, but it’s not a good idea to let your CEO do this.)

Users

A user is someone, usually employed by your organization, who needs access to the CRM system

Depending on the number of users in your deployment, user management can be an occasional task for the CRM system administrator or a continuous workload for the CRM system administration team.

There are several reasons why user management is important:

• Maintaining users in the correct business unit and with the correct security roles ensures that they have access only to the privileges and records that they are entitled to according to your security policies.
• Maintaining the access modes and license types for your users and purchasing the appropriate client access licenses ensures that your organization complies with its Microsoft license agreements.
• Maintaining the correct manager for each user ensures that any escalations will work correctly. For example, you might have a workflow rule that notifies a user’s manager when one of the user’s cases or opportunities meets certain criteria.
• Maintaining teams correctly can simplify the task of assigning security roles to specific users and supports the sharing of records between users
• Reports are often based on business units and/or teams. If users are not assigned to the correct business units or teams, management reports will be incorrect.

Teams

Team is an optional feature in Microsoft Dynamics CRM 2011. However, there are a number of scenarios where teams are useful:

• Owning unallocated records: Imagine you have a group of prospect accounts that you don’t want to assign to a user in the sales department yet because it would clutter the user’s views and reports. You can assign those accounts to a team before they are later claimed by a sales person and the account is reassigned to a sales user.
• Sharing records with a group of users: Imagine you frequently share records with the same group of users in different business units. By creating a team and adding those users to it, you can now share records with the team to achieve the same result with few clicks.
• Assigning a security role in one business unit to users in another business unit: Imagine that users in each region can only work with cases in their own region. An upsurge in support cases in region A can be managed by users in region B by assigning some of the users in region B to a team in region A that enables them to work with region A’s cases.

There are some important considerations regarding teams:

• Each team must be assigned to a business unit and an administrator user.
• Users can be a member of any team regardless of the business unit of the team of the user.
• Sharing a record with a team shares it with all the users in the team.