Settings

Design considerations for business units

Published Date : January 1, 2008

After you have installedMicrosoft Dynamics CRM, the next step is creating the organizational structure. This task involves defining business units, security roles, and entering and configuring user accounts. Business units contain security roles to create a two-stage security model that controls the granted user privileges and the access they have to use those privileges in the business unit they are assigned to, and related business units.

The concept of business units can be compared to a company's organizational chart. However, creating an organizational structure in Microsoft Dynamics CRM is not a process of converting an existing organizational chart. This is a design process whereby organizational needs dictate structure. Business units you create cannot be renamed or deleted.

Using business units

When you create an organizational structure, business units let you control access to data in user-owned entities. Most records in Microsoft Dynamics CRM have a user assigned as an owner. The user is associated with a business unit. You will use security roles to define privileges and access for users in the business unit. If you move a user to a different business unit, all the records owned by that user leave the old business unit and enter the new one.

Some entities are business unit–owned. Team, Queue, Calendar, Equipment, Resource, and Resource Group are examples. If there is more than one group in your organization that exclusively uses these entities, consider creating a business unit to represent members of these groups.

Top of page

Design factors

There are several factors to consider when you design your organizational structure:

Size of the organization
Customer bases served by the organization
Level of complexity in maintaining security
Sensitivity of information that is stored in Microsoft Dynamics CRM

Organization size

Size alone isn't a critical consideration. However, the size of the organization usually correlates to a design that requires more business units and deeper levels of hierarchy. Microsoft Dynamics CRM accommodates these complex needs, and if your organization is large you will probably want to use them.

If your organization is small, or the other design factors do not indicate otherwise, keep your organizational structure simple. You don't have to create additional business units if the root business unit is sufficient.

However, always remember that the size of the organization can change. Even when the initial implementation is simple, have a plan for growth.

Tip

Microsoft Dynamics ISV Architect Evangelist John O'Donnell suggests creating a new business unit that is the child of the root business unit. He then uses that second-level business unit as the starting point for his design. You can then extend the business unit structure to include a parallel business unit, or the future acquisition of another company.

Customer base

One of the concepts central to Microsoft Dynamics CRM is empowering people to better serve their customers. This requires enhanced visibility of customer data and collaboration between Microsoft Dynamics CRM users who work with the same customer base. Unless your organization has a specific restriction, avoid creating barriers that limit a user from seeing data or meeting customer needs. At the same time, avoid providing access to data the user has no need to see.

In larger organizations, there are service groups that need specific resources, such as queues, calendars, and equipment. There are sales organizations that target geographic regions or market segments. Your organizational structure should allow users to view data and take actions to do their work. Although users in larger organizations are generally more specialized, consider how you control actions that people can perform. To serve the customer, users may occasionally have to step outside their typical role.

Employees in smaller organizations frequently serve a single customer base and frequently act in a wider range of roles. Therefore, you may not have to create additional business units.

Complexity

Keep the Microsoft Dynamics CRM organizational structure as simple as possible for easier administration. The level of complexity should reflect your organization's security needs. By minimizing the effect of complexity, you can effectively enforce security and make necessary changes with little impact on users.

Be prepared to evaluate your initial organizational structure after data is entered into Microsoft Dynamics CRM. When Microsoft Dynamics CRM goes live and employees start using, entering, and accessing data, unanticipated security issues will have to be addressed.

Sensitive information

Customer relationship management (CRM) implementations balance the need to give users the information that they need against the risk that this information might be misused.

For example, it might be valuable for a customer service representative (CSR) to know whether a dissatisfied customer currently has a large open sales opportunity. The CSR may then better prioritize the customers' problem and perhaps append a note to the opportunity to collaborate with the sales team. That said, the CSR does not have to see customer quotes.

Ensure that access to sensitive information is only available to users who need it. With business-unit security roles you can specify the entity access. Sensitive information can be stored in separate entities – letting you control business-unit access through assigned security roles.

Sensitive information should be identified early in your planning stages. After installation work has begun, exposed information can seriously affect the implementation.