Design considerations for business units
Published: March 9, 2007
After you have installed Microsoft Dynamics CRM, and before anyone can start using it for their work, one of the first tasks you must do is define the organizational structure. This task involves creating business units, defining security roles, and entering and configuring user accounts. Business units contain security roles to create a two-stage security model that controls the privileges granted to users and the access they have to use those privileges within the business unit they are assigned to and related business units.
The concept of business units can be compared to an organizational chart within a company. However, creating an organizational structure in Microsoft Dynamics CRM is not merely a process of converting an existing organizational chart. This is a design process where the needs of each organization will dictate the structure you should use. This process is complicated by the fact that as soon as they are created business units cannot be renamed or deleted.
On This Page
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 are user owned. These records have a user assigned as an owner. The user is associated with a business unit. If you move a user to a different business unit, all the records owned by that user will 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 who exclusively uses these entities, you should consider creating a business unit to represent members of these groups.
Design factors
There are several factors you must consider when you design your organizational structure:
| • | Size of the organization |
| • | Customer base(s) 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. But the size of the organization usually correlates to a design that requires more business units and deeper levels of hierarchy. Microsoft Dynamics CRM is designed to accommodate 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, there is nothing wrong with keeping your organizational structure simple. You don’t have to create any additional business units if the root business unit is sufficient after considering other factors.
However, always remember that the size of the organization can change. Even when the initial implementation is simple, you should leave yourself with a plan for growth. Microsoft Dynamics CRM MVP John O’Donnell (www.crowecrm.com) 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. This provides easier options for extending the business unit structure to include a parallel business unit or the acquisition of another company in the future.
Customer base
One of the concepts central to Microsoft Dynamics CRM is empowering users to better serve customers. This generally requires enhanced visibility of customer data and collaboration between Microsoft Dynamics CRM users who work with the same customer base. As you design the organizational structure, think about how the customer sees the organization. Unless your organization has a specific restriction, avoid creating barriers that limit a user from seeing data or performing actions that let them best meet customer needs. At the same time, avoid providing access to data the user has no legitimate need to access. Define and apply security roles that prevent users from seeing data or performing actions that are inappropriate for their role.
In larger organizations, there are service groups that need specially defined resources, such as queues, calendars, and equipment. There are sales organizations that target defined geographic regions or specific market segments. Your organizational structure should allow for all users who work with an identified customer base to view data and take any action appropriate to do their work. Although users in larger organizations are generally more specialized, consider how rigidly you control the actions that people can perform. In order to best serve the customer, users may occasionally have to step outside their typical role.
Smaller organizations frequently serve a single customer base. Users in smaller organizations frequently act in a wider range of roles. Therefore, you may not have to create additional business units.
Complexity
The Microsoft Dynamics CRM organizational structure should be kept as simple as possible to allow for easier administration. But that does not mean that it will not become complex. The level of complexity should reflect the security needs of the organization. The goal of your design should be to minimize the effect of the complexity so that you can effectively enforce security and make necessary changes quickly with minimum impact to users.
Be prepared to evaluate your initial plans for organizational structure after data is entered into Microsoft Dynamics CRM. You may be unable to predict all needs or areas of concern. As soon as Microsoft Dynamics CRM goes live and users start using, entering, and accessing data, expect that unanticipated security issues will have to be addressed.
Sensitive information
Customer relationship management (CRM) implementations always have to 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 to know whether a dissatisfied customer currently has a large open sales opportunity. With this information they may decide to prioritize addressing the customers' problem. They may even want to append a note to the opportunity to collaborate with the sales team. But the customer service representative really does not have to see information about quotes that have been sent to the customer.
Your design must make sure that access to sensitive information is only available to users who need it. Fortunately, security roles within business units let you specify the access to each entity. Sensitive information can be stored in separate entities –letting you control access within and between business units through the security roles you assign.
It is critical that potentially sensitive information be identified very early in the planning stages of the implementation. After implementation work has begun, the sudden realization that sensitive information is being exposed can seriously affect the delivery of the implementation.
Summary
When you are faced with designing an organizational structure for your Microsoft Dynamics CRM implementation, you are creating a framework to apply security for the data that will be stored there. You will use security roles within the business units to define privileges and access for users within the business unit.
When you design business units, think about the following considerations:
| • | Size of the organization |
| • | Customer base(s) served by the organization |
| • | Level of complexity in maintaining security |
| • | Sensitivity of information that is stored in Microsoft Dynamics CRM |
Try to avoid making the organizational structure more complex than it has to be. Create business units when it is necessary and recognize that, especially in smaller organizations, it might not be necessary to create a complex hierarchy of business units.
