Excerpted from "Working with Microsoft Dynamics CRM 3.0" by Mike Snyder and Jim Steger. Reprinted by permission of Microsoft Press. All rights reserved. For more information, visit
If you've deployed software systems in the past, you already know that you must design your CRM solution to appropriately restrict information based on individual user permissions. Controlling how your users access customer data is a mission-critical component of any business application. Microsoft designed the Microsoft Dynamics CRM 3.0 security model to support the following goals:
- Provide users with only the information they need to perform their jobs; do not show them data unrelated to their positions.
- Simplify security administration by creating security roles that define security privileges, and then assign users to one or more security roles.
- Support team-based and collaborative projects by enabling users to share records as necessary. Microsoft Dynamics CRM provides an extremely granular level of security throughout the application.
By customizing the security settings, you can construct a security and information access solution that will most likely meet the needs of your organization. The process to customize the Microsoft Dynamics CRM 3.0 security settings requires you to configure your organization structure, decide which security roles your system users (employees) will have, and then define the security privileges associated with each security role.
Although you might not expect to, you will find yourself constantly tweaking and revising the security settings as your business evolves. Fortunately, the Microsoft Dynamics CRM security model makes it easy for you to update and change your security settings on the fly.
Mapping Your Microsoft CRM Needs
For the first step in planning security settings for your deployment, we recommend that you create a rough model of your company's current operational structure (by using a tool such as Microsoft Office Visio). For each section of your organization layout, you should identify the approximate number of users and the types of business functions those users perform. You will need this rough organization map to plan how you want to set up and configure security in your Microsoft Dynamics CRM 3.0 deployment.
To put this type of organization mapping into a real-world context, let's consider an example organization. Figure 3-1 shows the business structure for the Microsoft CRM sample company, Adventure Works Cycle.
Each box in the figure represents a business unit in Microsoft CRM, and you can structure parent and child relationships between business units. Business units represent a logical grouping of business activities, and you have great latitude in determining how to create and structure them for your implementation.
One constraint of configuring business units is that you can specify only one parent for each business unit. However, each business unit can have multiple child business units. Also, you must assign every Microsoft Dynamics CRM user to one (and only one) business unit.
For each user in your organization structure, you should try to determine answers for questions such as the following:
- To which areas of Microsoft Dynamics CRM will the users need access (such as Sales, Marketing, and Customer Service)?
- Do users need the ability to create and update records, or will read-only access suffice?
- Will you need to structure project teams or functional groups of users that work together on related records?
- Can you group users together by job function or some other classification (such as finance, operations, and executive managers)?
After you develop a feel for how your organization and users will use Microsoft CRM, you can start to configure the Microsoft Dynamics CRM application to meet those needs.
Read the rest of this excerpt on Microsoft Dynamics 3.0 and download Chapter 3: Managing Security and Information Access
Read other excerpts from our CRM and call center bookshelf
To purchase the book and others in the series, please visit Microsoft Press.
This was first published in August 2006