8912-En Customization and Configuration Student Manual

COURSE 8912:
CUSTOMIZATION AND CONFIGURATION IN

MICROSOFT DYNAMICS CRM™ 4.0
Microsoft Official Training Materials for Microsoft Dynamics ™

Your use of this content is subject to your current services agreement
December 2007
The information contained in this document represents the current view of Microsoft Corporation on the issues
discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should
not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any
information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED
OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under
copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any
purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights
covering subject matter in this document. Except as expressly provided in any written license agreement from
Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or
other intellectual property.
© 2005 Microsoft Corporation. All rights reserved. Microsoft and Solomon are either trademarks or registered
trademarks of Microsoft Corporation or Dynamics GP Software, Inc. or their affiliates in the United States and/or
other countries. Dynamics GP Software, Inc. is a subsidiary of Microsoft Corporation. The names of actual
companies and products mentioned herein may be the trademarks of their respective owners.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Table of Contents
Introduction to Customization and Configuration in Microsoft

Dynamics CRM 4.0 0-1
E-Learning..........................................................................................................0-1
Instructor-Led Training .......................................................................................0-2
Training Materials ...............................................................................................0-2
Certifications.......................................................................................................0-2
Certification Exam Preparation Guides ..............................................................0-3
Learning Plans ...................................................................................................0-4
Elements of Training Materials for Microsoft Dynamics .....................................0-4
About This Training Material...............................................................................0-6
Student Objectives .............................................................................................0-8
Chapter 1: Creating Your Organizational Structure 1-1
Objectives...........................................................................................................1-1
Introduction.........................................................................................................1-1
Business Units....................................................................................................1-2
Managing Business Units ...................................................................................1-4
Lab 1.1 - Maintaining Business Units .................................................................1-9
Summary ..........................................................................................................1-13
Chapter 2: Configuring Security 2-1
Objectives...........................................................................................................2-1
Introduction.........................................................................................................2-1
Microsoft Dynamics CRM Security Features......................................................2-2
Privileges ............................................................................................................2-4
Access Levels ....................................................................................................2-6
Security Roles ..................................................................................................2-12
Security Roles and Business Units...................................................................2-18
Creating and Copying Security Roles ..............................................................2-22
Demonstration - Creating and Copying Security Roles ....................................2-26
Lab 2.1 - Copying and Creating Roles .............................................................2-29
Planning Considerations when Configuring Security........................................2-34
Summary ..........................................................................................................2-36
Test Your Knowledge .......................................................................................2-37
Quick Interaction: Lessons Learned .................................................................2-40
Solutions...........................................................................................................2-41
Chapter 3: Configuring Users and Teams 3-1
Objectives...........................................................................................................3-1
Introduction.........................................................................................................3-1
User Management Overview ..............................................................................3-2
Adding and Maintaining User Accounts .............................................................3-4
Lab 3.1 - Managing User Accounts ..................................................................3-12
Team Management ..........................................................................................3-18
Lab 3.2 - Managing Teams...............................................................................3-21
Summary ..........................................................................................................3-26
Solutions...........................................................................................................3-30
Microsoft Official Training Materials for Microsoft Dynamics ™ Page i

Customization and Configuration in Microsoft Dynamics™ CRM 4.0
Chapter 4: Configuring Organizational Settings 4-1

Objectives...........................................................................................................4-1
Introduction.........................................................................................................4-1
System Settings .................................................................................................4-2
Auto Numbering ...............................................................................................4-15
Fiscal Year Settings .........................................................................................4-16
Lab 4.1 - Maintaining System Settings .............................................................4-18
Multilingual User Interface ................................................................................4-21
Lab 4.2 - Installing MUI Language Packs.........................................................4-27
Multicurrency ....................................................................................................4-32
Lab 4.3 - Importing Currency Exchange Rates ................................................4-43
Summary ..........................................................................................................4-53
Solutions...........................................................................................................4-57
Chapter 5: Customizing Microsoft Dynamics CRM Overview 5-1
Objectives...........................................................................................................5-1
Introduction.........................................................................................................5-1
Customization Methodology ...............................................................................5-2
Who can Customize Microsoft Dynamics CRM?................................................5-4
Microsoft Dynamics CRM Architecture...............................................................5-6
Types of Customizations ..................................................................................5-11
Upgrading Customizations ...............................................................................5-17
Publishing Customizations ...............................................................................5-18
Reusing Customizations...................................................................................5-19
Lab 5.1 - Importing and Exporting Customizations...........................................5-26
Summary ..........................................................................................................5-30
Solutions...........................................................................................................5-34
Chapter 6: Customizing Forms and Views 6-1
Objectives...........................................................................................................6-1
Introduction.........................................................................................................6-1
Basic UI Customization Capabilities...................................................................6-2
Form Customization Overview ...........................................................................6-3
Form Customization - Editing Tabs ....................................................................6-5
Form Customization - Editing Sections ..............................................................6-6
Form Customization - Editing Fields...................................................................6-9
Preview Your Customizations...........................................................................6-14
Preview Form Customization ...........................................................................6-15
Demonstration - Form Customization...............................................................6-16
Lab 6.1 - Form Customization ..........................................................................6-21
View Customization Overview ..........................................................................6-30
View Customization ..........................................................................................6-34
Demonstration - View Customization ...............................................................6-37
Lab 6.2 - View Customization...........................................................................6-41
Summary ..........................................................................................................6-50
Page ii Microsoft Official Training Materials for Microsoft Dynamics ™

Table of Contents

Solutions...........................................................................................................6-54
Chapter 7: Customizing Entities and Attributes 7-1
Objectives...........................................................................................................7-1
Introduction.........................................................................................................7-1
Customization Concepts ....................................................................................7-2
Customizing Attributes .......................................................................................7-3
Demonstration - Creating a Custom Attribute...................................................7-11
Lab 7.1 - Creating a Custom Attribute ..............................................................7-14
Creating a Custom Entity .................................................................................7-21
Demonstration - Creating a Custom Entity .......................................................7-28
Lab 7.2 - Creating a Custom Entity ..................................................................7-31
Summary ..........................................................................................................7-40
Solutions...........................................................................................................7-44
Chapter 8: Customizing Relationships and Mappings 8-1
Objectives...........................................................................................................8-1
Introduction.........................................................................................................8-1
Supported Entity Relationships ..........................................................................8-2
Unsupported Entity Relationships ......................................................................8-7
1:N Relationship Behavior ..................................................................................8-7
Creating Entity Relationships ...........................................................................8-11
Demonstration - Creating an Entity Relationship..............................................8-16
Lab 8.1 - Create a Manual N:N Relationship....................................................8-19
Lab 8.2 - Create a Native N:N Relationship .....................................................8-31
Entity Mapping..................................................................................................8-42
Demonstration - Entity Mapping .......................................................................8-45
Lab 8.3 - Add a Mapping ..................................................................................8-46
Lab 8.4 - Case Study........................................................................................8-52
Summary ..........................................................................................................8-66
Solutions...........................................................................................................8-71
Chapter 9: Renaming Entities and Translating Customizations 9-1
Objectives...........................................................................................................9-1
Introduction.........................................................................................................9-1
Renaming a Customizable Entity .......................................................................9-2
Lab 9.1 - Renaming a Customizable Entity ........................................................9-6
Translate Customized Labels ...........................................................................9-12
Summary ..........................................................................................................9-14
Solutions...........................................................................................................9-18
Chapter 10: Maintaining Organizations Through Deployment Manager10-1
Objectives.........................................................................................................10-1
Microsoft Official Training Materials for Microsoft Dynamics ™ Page iii

Introduction.......................................................................................................10-1
Creating Multiple Organizations .......................................................................10-2
Lab 10.1 - Maintaining Multiple Organizations ...............................................10-13
Deployment Manager - Deployment Administrators.......................................10-17
Deployment Manager - Organizations............................................................10-18
Deployment Manager - Servers......................................................................10-20
Deployment Manager - License......................................................................10-21
Summary ........................................................................................................10-22
Test Your Knowledge .....................................................................................10-23
Quick Interaction: Lessons Learned ...............................................................10-25
Solutions.........................................................................................................10-26
Chapter 11: Introduction to Advanced Customizations 11-1
Objectives.........................................................................................................11-1
Introduction.......................................................................................................11-2
Introduction to Workflow ...................................................................................11-2
Demonstration - Activity Creation in a Workflow ..............................................11-7
Introduction to Application Event Programming ...............................................11-9
Common Uses for Event Programming..........................................................11-10
Demonstration - Examples of Client-Side Code .............................................11-13
Using Form Events .........................................................................................11-15
Using Field Events .........................................................................................11-16
Demonstration - Referencing Form and Field Values ....................................11-18
Configuring Event Detail Properties ...............................................................11-20
Demonstration - Creating Simple Event Scripts .............................................11-22
Introduction to IFrames ..................................................................................11-25
Demonstration - Add an IFrame .....................................................................11-29
Demonstration - Creating a Dynamic IFrame .................................................11-31
Introduction to URL Addressable Forms ........................................................11-33
Demonstration - URL Addressable Forms......................................................11-35
Introduction to Creating Custom Menus, Navigation Items, and Buttons .......11-36
Demonstration - Integrating Applications .......................................................11-38
Introduction to ISV.Config Integration Points..................................................11-41
Demonstration - ISV.Config structure and custom button ..............................11-43
Introduction to SiteMap ..................................................................................11-48
SiteMap Structure...........................................................................................11-50
Demonstration - Apply Site Map Customizations ...........................................11-53
Introduction to SDK Capabilities.....................................................................11-55
ISV Solutions ..................................................................................................11-57
Summary ........................................................................................................11-58
Test Your Knowledge .....................................................................................11-59
Quick Interaction: Lessons Learned ...............................................................11-61
Solutions.........................................................................................................11-62
Appendix A: Permissions Required for Customization Tasks A-1
Page iv Microsoft Official Training Materials for Microsoft Dynamics ™

Introduction
INTRODUCTION TO CUSTOMIZATION AND

CONFIGURATION IN MICROSOFT DYNAMICS CRM
4.0
Training is a vital component of retaining the value of your Microsoft
Dynamics™ investment. Quality training from industry experts helps keep you
updated on your solution and develops skills to maximize the value of your
solution. Whether choosing E-Learning, instructor-led training, or self-paced
study using training materials, there is a type of training that meets your needs.
Additionally, validate your training and demonstrate your expertise with one of
many certifications for Microsoft Dynamics. Choose the training or certification
type that best enables you to stay ahead of the competition.
E-Learning
Online training for Microsoft Dynamics products helps you increase your
productivity without spending time away from your home or office. E-Learning
allows you to learn at your own pace through flexible access to training, therefore
proving beneficial for those lacking the time or budget to travel. E-Learning are
online training courses designed to cover detailed concepts on specific product
areas and allow you to:
• Gain in-depth technical and business application training through
daily on-demand training.
• Learn at your own pace - lessons can be stopped and restarted,
skipped or repeated.
• Save time and increase your productivity.
• Receive product knowledge comparable to instructor-led training
without the need for travel or time away from the office.
• Gain beneficial training when preparing for Microsoft Dynamics
certification exams.
• Find tips and tricks to show you how to increase productivity and
save time.
• Learn about the changes in features and functionality of a new
Microsoft Dynamics product version.
• Evaluate a new Microsoft Dynamics module or product.
Microsoft Official Training Materials for Microsoft Dynamics ™ 0-1

Instructor-Led Training
With instructor-led training, you can gain a solid foundation or refresh your
knowledge in Microsoft Dynamics products and processes while learning from
an expert in an interactive environment. With courses on a variety of topics, you
can:
• Follow demonstrations and attend presentations.
• Receive hands-on product experience.
• Participate in classroom activities and discussions with other
attendees.
• Gain beneficial training when preparing for Microsoft Dynamics
certification exams.
Training Materials
Training materials can be ordered for the purpose of self-paced study. These
materials are comparable to courseware used with instructor-led training, and
enable you to:
• Learn at your own pace, in your own time.
• Refer to an abundance of tips, tricks, and insights.
• Learn using a self-study format when preparing for Microsoft
Dynamics certification exams.
For selected training materials there are training material – local functionality
available which cover country specific features in the product. The training
material – local functionality add on to existing training materials and are
designed to teach local functionality within a given country. Please notice that
training material – local functionality are used only in conjunction with the
training material, not as stand-alone training materials
Certifications
Certifications help identify and distinguish an individual’s technical skill set
using a Microsoft Dynamics or related business product. Certifications for
Microsoft Dynamics are widely recognized by industry employers and provide an
objective validation of an individual’s knowledge. Organizations that employ
certified individuals benefit from a complete approach to learning – certified
individuals have higher skills retention and increased productivity. Organizations
can streamline their employee recruitment process and lower their external
support costs plus downtime by maintaining technically skilled employees by
requiring Microsoft Certified Business Management Solutions Specialist and
Professional certifications.
0-2 Microsoft Official Training Materials for Microsoft Dynamics ™

Introduction
Microsoft Certified Business Management Solutions

Specialist
The achievement of this certification demonstrates an individual’s proficiency in
one module of a Microsoft Dynamics or related business product. Microsoft
Certified Business Management Solutions Specialists must pass a single
certification exam for a Microsoft Dynamics or related business product to earn
the title.
Microsoft Certified Business Management Solutions

Professional
The Microsoft Certified Business Management Solutions Professional is a
premier certification where an individual has completed a pre-determined set of
required and elective certification exams. These include certification exams for
Microsoft Dynamics and related business products, as well as certification exams
for other Microsoft technologies such as SQL Server. The pre-determined set of
required and elective exams for this certification are focused on one of three
specific knowledge areas – Applications, Developer, or Installation and
Configuration – for one Microsoft Dynamics product. This certification
demonstrates an individual’s broad and deep knowledge of a Microsoft
Dynamics product — more knowledge than what is needed to achieve a
Microsoft Certified Business Management Solutions Specialist title.
Certification Exam Preparation Guides

To help prepare for a certification exam, Microsoft highly recommends the use of
the certification exam preparation guides available for each exam. Certification
exam preparation guides contain valuable information about a specific exam,
including:
• The target audience

• Skills being measured
• Time expected to take each portion of the exam
• Pass rates and requirements
• Question types and topics
• Preparation tools, such as:
– recommended training
– supplemental learning resources
– additional recommended skills

Certification Exam Preparation Guides help you determine which learning

options are appropriate to best prepare you for a certification exam. Microsoft
does not expect or intend one course or type of training to be the sole preparation
method for passing a certification exam. A combination of hands-on experience
using the product and training are recommended certification exam preparation.
Certification exam preparation guides are available through PartnerSource and
CustomerSource.
Learning Plans
Learning Plans can help you plan the best learning strategy for you and your
organization. Learning plans illustrate module specific learning tracks that can
be easily targeted towards specific roles. Learning plans also provide a learning
track towards obtaining certifications. Learning plans can be found on both
PartnerSource and CustomerSource,
NOTE: For more information on E-Learning, instructor-led training, training materials

and certifications for Microsoft Dynamics log in to PartnerSource or CustomerSource
and visit Training & Certification.
Elements of Training Materials for Microsoft Dynamics

Training Materials for Microsoft Dynamics products contain a number of
sections or elements. Each chapter includes the following elements:
Objectives
Each chapter begins with a statement of the learning objectives for that chapter.
Learning objectives are important because they inform you about what needs to
be done to successfully complete the chapter.
Introduction
An introduction sets the stage for the learning to take place and prepares you with
key statements of the chapter.
Topics
Chapters are split up into topic areas, usually according to the learning objectives
for the chapter. This is especially beneficial in large chapters so that the
knowledge and skills to be learned are split up into more manageable units.
Test your Knowledge

The Test your knowledge section consists of review questions for each chapter or
topic and is designed to help reinforce learning concepts. Questions can be short
answer, true and false, multiple-choice, fill-in-the-blank or any other type.
Answers to questions are also provided.

Introduction
Conclusion
The conclusion wraps up the chapter by highlighting the important parts of the
chapter as well as providing a transition to the next chapter. The conclusion also
offers an opportunity to refresh earlier learning.
Labs
Labs test your skills with the learning concepts presented and learned during a
topic or chapter. Labs begin with a scenario paragraph which describes the
business problem to be solved, and also sets the stage for the exercise. Solutions
to the labs are also provided. Labs may be offered at different levels to
accommodate the variety of skills and expertise of each student.
Challenge Yourself!
Challenge Yourself! labs are the most challenging. These exercises are designed
for the experienced student who requires little instruction to complete the
required task. This level of exercise states the business problem to be solved and
describes the tasks the learner needs to complete.
Need a Little Help?
These exercises are designed to challenge students while providing some
assistance. These exercises do not provide step-by-step instructions; however,
they provide the user with helpful hints and more information to complete the
lab.
We suggest you try the “Challenge Yourself!” labs first, and if you need help
completing the task, look to the information in the “Need a Little Help?” labs. If
additional assistance is required, refer to the “Step by Step” lab solutions located
in an Appendix.
Quick Interaction: Lessons Learned

At the end of each chapter within the Training Material for Microsoft Dynamics,
you will find a Quick Interaction: Lessons Learned page. This interaction is
designed to provide you with a moment to reflect on the material you have
learned. By outlining three key points from the chapter, you are maximizing
knowledge retention, and providing yourself with an excellent resource for
reviewing key points after class.

About This Training Material

This section provides you with a brief description of:
• The training material
• Audience
• Suggested prerequisites
• Training material objectives
• Student materials
• Related certification exams
Description
This three-day instructor-led course provides students with the tools to configure
and customize Microsoft Dynamics CRM 4.0. Configuration topics include
setting up business management functions such as:
• Business units
• Users
• Teams
• Security privileges and roles
• System Settings
• Multilingual User Interface Language Packs
• Currency Exchange Rates
• Multiple Organizations
The course also focuses on using the Microsoft Dynamics CRM 4.0
Customization tools to customize the following system components:
• Forms
• Views
• Entities
• Attributes
• Relationships
• Entity Mappings
The following customization topics are outside the scope of this course, but are
introduced here to provide students with insight into potential advanced
customization features:
• Application Event Programming
• Client Extensions
• Workflow
• SiteMap

Introduction
• URL Addressable Forms

• IFrames
• SDK
Audience
This course is intended for Microsoft Dynamics CRM Implementation
Consultants and System Administrators and Customizers who will configure the
application’s organizational settings and customize the application using its built-
in customization tools. The course is not intended for developers who customize
the application using Web development, JavaScript (JScript), DHTML, and the
Microsoft Dynamics CRM SDK.
At Training Material Completion

The course completion objectives are:
• Configure a company’s organizational structure within Microsoft
Dynamics CRM
• Add user accounts
• Create and maintain security roles
• Create teams of users
• Create and configure multiple organizations within one
implementation
• Configure system settings, currency exchange rates, and multilingual
user interface language packs
• Import and export customizations
• Customize forms and views
• Customize database entities and attributes
• Customize entity relationships and mappings
• Identify areas where advanced customization functionality can be
implemented
Prerequisites
Participants in this course must have a working knowledge of how to use
Microsoft Dynamics CRM 4.0. It is recommended, but not required, that students
have completed Microsoft Dynamics CRM 4.0 Applications training. Because
this course focuses on customizing database entities, attributes, relationships, and
mappings, it is recommended that students have a basic understanding of
Microsoft SQL Server and relational database functionality.
Student Materials
The student kit includes a comprehensive workbook and other necessary
materials for this class.

Student Objectives
What do you hope to learn by participating in this course?
List three main objectives below.
1.
2.
3.

Chapter 1: Creating Your Organizational Structure
CHAPTER 1: CREATING YOUR ORGANIZATIONAL

STRUCTURE
Objectives
The objectives are:
• Identify why an organizational hierarchy is defined in Microsoft

Dynamics™ CRM
• Identify the differences between the root business unit and all other
business units
• Identify the guidelines that control maintenance of business units
• Create and maintain business units in Microsoft Dynamics CRM
Introduction
After you have installed Microsoft Dynamics CRM and before anyone can start
using it for his or her work, one of your first tasks is to define the organizational
structure. This task involves creating business units, defining security roles, and
creating and configuring user accounts and teams.
This training examines how to set up your organizational structure by

maintaining business units within an organization. Microsoft Dynamics CRM
provides the flexibility needed so that a business of any size can create a
deployment model that closely mirrors its actual organizational structure.

Business Units
Business units form the foundation upon which the rest of the organizational
structure is built. When planning a Microsoft Dynamics CRM deployment, start
with a current organization chart if one exists; otherwise, consider creating one
before defining your organizational structure.
While an organization chart provides a good starting point, the actual process of
defining an organization in Microsoft Dynamics CRM entails a larger design
process where the needs of each organization dictate the structure you must use.
Within this structure, business units provide the framework upon which you
configure the following components of a Microsoft Dynamics CRM deployment:
• User management
• Security
• Reporting
When defining your organizational structure in Microsoft Dynamics CRM, you

will create the top organization and underlying business units first, followed by
the functional regions, branches, departments, and other sectors that divide the
company into its existing operating units.
Root Business Unit

The root business unit is the top-level node of the Microsoft Dynamics CRM
organizational hierarchy. This may be the corporation or holding company of all
business units in the organization. The root business unit has the following
characteristics:
• There is only one root business unit in Microsoft Dynamics CRM.

• The root business unit is automatically created by the Microsoft
Dynamics CRM Server Setup program.
• Because it is the top-most business unit in any organizational
hierarchy, the root business unit cannot be assigned a parent business
unit.

• The name of the root business unit cannot be changed.

• The root business unit cannot be deleted or disabled.
FIGURE 1.1 ROOT BUSINESS UNIT
All other Business Units

A business unit is any part of an organization under the root business unit.
Business units may represent subsidiaries, divisions, or departments. Business
units (other than the root business unit) have the following characteristics:
• All business units must be parented by either the root business unit
or another business unit.
• The name of a business unit cannot be changed.
• A business unit cannot be deleted.
• A business unit can be disabled.
FIGURE 1.2 BUSINESS UNIT MAINTENANCE RESTRICTIONS

Caution - Creating Business Units

When you create a business unit in Microsoft Dynamics CRM, type the name of
the business unit exactly as you want it to appear throughout the application. You
cannot change the name of a business unit, delete a business unit, or correct a
misspelled name after you save the record. If you accidentally create a misnamed
business unit, your options include the following:
• Accept the misspelled name in your organizational structure

• Disable the business unit
BEST PRACTICE: When creating the organization hierarchy, it is important

that naming conventions, future reorganizations, and any changes that may
occur are considered. This can prevent incorrect, misspelled, or erroneous
business units from cluttering the application.
Managing Business Units

Implementers need to consider the following best practices when planning and
maintaining their organizational hierarchies:
• Follow an implementation methodology when you plan and

configure your application. This controls the definition of an
organizational hierarchy that includes business units, users, teams,
and security roles.
• Review the Microsoft Dynamics CRM Implementation Guide, which
includes guidelines to assist with your planning efforts.
– These guidelines are designed to help analyze your
organizational hierarchy relative to corresponding Microsoft
Dynamics CRM functionality.
– With regard to business units, the Business Hierarchical form
displays each enabled business unit and any business units that
report to it.
• Use an existing organization chart when defining your business units

in Microsoft Dynamics CRM. It is strongly recommended that you
create one if it does not exist; this will help prevent incorrect,
misspelled, or erroneous business units from cluttering the
application.

• Consider naming conventions, future reorganizations, and any other

organizational changes that may occur when defining your
organization structure Microsoft Dynamics CRM.
– The Implementation Guide provides a sample Organization
Hierarchy form that you can use in your planning.
– Double-check the name and spelling of each business unit before
saving the record. Business unit names cannot be modified, nor
can records be deleted once the record is saved.
Guidelines for Maintaining Business Units

Microsoft Dynamics CRM imposes the following guidelines on the maintenance
of business units:
• The Parent Business Unit field is required for any business units you
create. The Root Business Unit is always displayed as the default
Parent Business Unit and remains as such unless you select a
different business unit.
• A business unit can be disabled if it permanently or temporarily
ceases operation. This leaves its organizational structure in the
Microsoft Dynamics CRM database for historical purposes.
• Users assigned to a disabled business unit cannot access Microsoft
Dynamics CRM.
• A business unit can be created and intentionally disabled if
reorganization is planned for the future. This allows the business unit
to be enabled when the reorganization occurs.
• An organization can be reorganized by simply changing a business
unit's Parent business unit.
• All child business units move with the Parent business unit when the
Parent business unit is changed.
WARNING: Double-check spelling and naming of the business unit before

saving the record. After the record is saved, the business unit's name cannot be
modified nor can the record be deleted. If this occurs, you must accept the error
in your organizational hierarchy, or disable the business unit and create a new
one with the correct name.

Creating a Business Unit

Perform the following steps to add a business unit:
1. From the Navigation Pane, click Settings, click Administration,

then click Business Units.
2. On the Actions toolbar, click New.
3. In the Business Unit form, enter the information that you want for
the new business unit.
a. On the General tab, enter a Name for the new business unit.
Microsoft Dynamics CRM fills the Parent Business field with
the name of the root business unit. Click the Lookup button to
change the value in the Parent Business field if a new business
unit has a different parent.
b. Enter any of the remaining fields on the General tab required by
your organization.
c. On the Addresses tab, you can enter information for the business
unit's Bill To Address and Ship To Address.
4. Click Save. After saving the record, you can click the record types
under Organization to see a list of related records, and to change the
settings for selected records.
5. Click Save and Close.
Maintaining a Business Unit

Perform the following steps to change settings on an existing business unit:

2. Open the business unit record that you want to change.
3. Change the settings for an existing business unit:
a. The Information window displays by default for the business
unit. Select the General or Addresses tab and enter or change
any necessary values. Note that you cannot delete or rename a
business unit.
b. Under the Organization pane on the left hand side of the
window, select a record type to see the list of related records, and
to change the settings for selected records (for example, users,
teams, and facilities/equipment).
c. Use the buttons on the Actions toolbar to add new records,
enable or disable a listed record, and make other changes.
4. Click Save or Save and Close.

Reorganizing Business Units

Reorganizing a business unit is a matter of changing a business unit's parent. This
changes the reporting relationship for the business unit and all users in that
business unit, in addition to all its child business units.
• When a business unit is reassigned to a new parent, all its child

business units move with it by default.
• Any clean-up required following reorganization (for example,
cleaning up duplications) must be performed manually either before
or after the move.
Perform the following steps to change the parent business unit.

2. Select the business unit with settings that you want to change.
3. On the Actions toolbar, click More Actions and then select Change
Parent Business.
4. In the Change Parent Business dialog box, in the New parent
business field, search for and select the new parent business unit.
5. In the Change Parent Business dialog box, click OK.
You can also open a specific business unit record to change its parent. However,
you cannot change the parent business unit directly on the Business Unit form
because the Parent Business unit field is read-only. To change the parent
business unit, you must click the Actions menu and select the Change Parent
Business option.
Disabling/Enabling Business Units

Disabling a business unit has serious repercussions, especially to the users
assigned to the disabled business unit.
• Disabling a business unit disables not only that particular business

unit, but also every child business unit below it. The users assigned
to these business units will be unable to log on to Microsoft
Dynamics CRM.
• Disabling a business unit does not unassign the user licenses
associated with each user in the business unit, nor does it disable any
one of the users.
• Users cannot be assigned to a disabled business unit.
• Child business units cannot be assigned to a disabled business unit.

WARNING: Although users assigned to a disabled business unit cannot access

Microsoft Dynamics CRM, no data associated with the business unit is deleted
or lost. If a disabled business unit is enabled, each enabled user assigned to
that business unit can again access the application.
Similarly, enabling a disabled business unit also affects the users assigned to the
business unit.
• All enabled users assigned to a business unit that is enabled can

access Microsoft Dynamics CRM.
• Any disabled user, which is an unlicensed user in Microsoft
Dynamics CRM, is not enabled when his or her business unit is
enabled.
• If a user is disabled when the business unit was disabled, the user
must be enabled before he or she can access Microsoft Dynamics
CRM after the business unit is enabled.
Perform the following steps to enable or disable a business unit:

2. Select the business units that you want to activate or deactivate.
3. On the More Actions menu click either Enable or Disable to change
the status of the business unit.
4. In the confirmation message, click OK.
You can also open a specific business unit record to enable or disable it. To
enable or disable a specific business unit record, click the Actions menu and
select the Enable or Disable option. If the business unit is enabled, the Actions
menu only includes the Disable option; conversely, the Actions menu only
includes the Enable option if the business unit is disabled.

Lab 1.1 - Maintaining Business Units

This lab requires you to create, maintain, and reorganize business units within an
existing organizational structure. As you perform the instructions, use the
information in the Scenario and Goal Description to complete the lab.
Scenario
You are a Microsoft Dynamics CRM implementation consultant. Your customer,

Adventure Works Cycle, has recently upgraded their Microsoft Dynamics CRM
3.0 installation to Microsoft Dynamics CRM 4.0.
During the needs analysis meeting, you reviewed and analyzed the company's
organizational chart with Adventure Works’ management team. This discussion
revealed that Adventure Works’ existing organizational structure, which was
defined in the prior release of Microsoft Dynamics CRM, had not taken into
account the company's planned growth.
FIGURE 1.3 ADVENTURE WORKS CYCLE ORGANIZATION CHART

Goal Description
Adventure Works has decided to make the following changes to their Microsoft
Dynamics CRM organizational hierarchy to better reflect their revised corporate
structure:
• Two new business units must be added under the Customer Support
business unit: Premier Support and Support Services.
• Because of the separation between the Service and Customer Care
divisions, communication and coordination regarding support issues,
service plans, and escalated cases has been less than satisfactory.
Therefore, the Service division will now report to the Customer Care
division.
• During the implementation of Microsoft Dynamics CRM 3.0, the
National Accounts division of Channel Sales & Marketing was
created. However, following a subsequent management
reorganization, it was later decided that the company's national
accounts were better served by the National Channel Marketing
business unit; therefore, the National Accounts business unit was
never implemented.
During the implementation planning for Microsoft Dynamics CRM,

Adventure Works’ management team asked you to disable the
National Accounts business unit so that it no longer appears in the
organizational hierarchy.
Log on to Microsoft Dynamics CRM as the CRM Administrator (crmadmin) in

order to make the requested changes.
Challenge Yourself
Perform the following steps to complete this lab:
1. Create new Premier Support and Support Services business units

under the Customer Support business unit.
2. Reorganize the Service business unit so that it now reports to the
Customer Care business unit instead of the Adventure Works Cycle
root business unit.
3. Disable the National Accounts business unit.

Need a Little Help?

Step 1: Create New Business Units
1. On the Business Units view, add a new business unit.

2. Enter Premier Support as the business unit name and select Customer
Support as the parent business unit. Repeat this step for the Support
Services business unit.
Step 2: Reorganize a Business Unit
1. Open the Service business unit.

2. Select Change Parent Business from the Actions menu.
3. Change the Parent Business to Customer Care.
4. Verify the change in the Business Units view.
Step 3: Disable a Business Unit
1. Open the National Accounts business unit.

2. Select Disable from the More Actions menu.
3. Verify the business unit was disabled by viewing the Inactive
Business Units.
Step by Step
Step 1: Create New Business Units

2. Click New on the Actions toolbar.
3. Enter Premier Support as the name and select Customer Support
as the parent business unit.
4. Click Save and New.
5. Repeat this step for the Support Services business unit. When
complete, click Save and Close.
NOTE: Be careful when entering the business unit names and verify the
spelling and name before saving the record. Business units cannot be deleted
from Microsoft Dynamics CRM once they have been created; they can only be
disabled.

Step 2: Reorganize a Business Unit
1. On the Business Units view, double-click the Service business unit

to open it.
2. In the Service Business Unit form, click on the Actions menu and
select Change Parent Business.
3. In the Change Parent Business dialog box, click on the lookup icon
to change the Parent Business.
4. Select the Customer Care business unit and click OK.
5. Click OK to confirm your choice in the Change Parent Business
dialog box.
6. Verify the change on the Service Business Unit form. Click Save
and Close.
Step 3: Disable a Business Unit
1. On the Business Units view, click the National Accounts business

unit.
2. Click More Actions on the Action toolbar, and then click Disable.
Click OK to confirm your choice.
3. Verify that the business unit was disabled. Change the view to
display Inactive Business Units. The National Account business
unit will appear in the list of inactive business units.

Summary
This section described several of the Microsoft Dynamics CRM components that
the administrator needs to configure after installing the application and before
allowing users access. Configuring the application must begin with defining the
organizational structure. Within an organizational hierarchy in Microsoft
Dynamics CRM, business units form the foundation upon which the remainder to
the application is built.
Security roles and users are later defined at the business unit level. By assigning
users to business units, you define the patterns of who has access to which kinds
of data and determine who has access to records. When you evaluate your
business unit structure, remember that business units can be nested to form parent
and child relationships, where child business units cannot access data in the
parent business unit.

Test Your Knowledge

1. What are the three core components of business units?
2. During the installation process, what does the Microsoft CRM Server Setup
program do related to business units?
3. What are three restrictions when you manage Business Units?
4. True or False. When a Parent Business Unit is moved, no child business units
are moved.
( ) True
( ) False

5. True or False. When a Business Unit is disabled, users assigned to that

business unit are able to access their Microsoft CRM data, but are not able to
update it.
( ) True
( ) False
6. Which of the following are true statements regarding Business Unit

maintenance? (Select all that apply.)
( ) Disabling a business unit removes it from the organizational structure.
( ) Users assigned to a disabled business unit cannot access Microsoft
Dynamics CRM.
( ) Deleting a business unit leaves its assigned users in the database, but they
are prohibited from accessing Microsoft Dynamics CRM.
( ) An organization can be reorganized by changing a business unit's Parent
business unit.
7. What are some of the characteristics that apply to the root business unit?


Take a moment and write down three key points you have learned from this
chapter:
1.
2.
3.

Solutions
Test Your Knowledge
1. What are the three core components of business units?
MODEL ANSWER - – User management (for example users, managers, and
teams) – Security (for example data access) – Reporting
2. During the installation process, what does the Microsoft CRM Server Setup
program do related to business units?
MODEL ANSWER - The Microsoft CRM Server Setup program creates the
root business unit in Microsoft CRM. The name of the root business unit is
the organizational unit name which the install user enters during the Server
Setup program.
3. What are three restrictions when you manage Business Units?
MODEL ANSWER - Any of the following are correct: – The name of a
business unit cannot be changed. – A business unit cannot be deleted. – A
business unit can be disabled. – A parent business unit must be assigned to
all business units (other than the root business unit).
4. True or False. When a Parent Business Unit is moved, no child business units
are moved.
( ) True
(•) False
5. True or False. When a Business Unit is disabled, users assigned to that

business unit are able to access their Microsoft CRM data, but are not able to
update it.
( ) True
(•) False

6. Which of the following are true statements regarding Business Unit

maintenance? (Select all that apply.)
( ) Disabling a business unit removes it from the organizational structure.
(√) Users assigned to a disabled business unit cannot access Microsoft
Dynamics CRM.
( ) Deleting a business unit leaves its assigned users in the database, but they
are prohibited from accessing Microsoft Dynamics CRM.
(√) An organization can be reorganized by changing a business unit's Parent
business unit.
7. What are some of the characteristics that apply to the root business unit?
MODEL ANSWER - The root business unit has the following
characteristics: - There is only one root business unit in Microsoft Dynamics
CRM. - The root business unit is automatically created by the Microsoft
Dynamics CRM Server Setup program. - Because it is the top-most business
unit in any organizational hierarchy, the root business unit cannot be
assigned a parent business unit. - The name of the root business unit cannot
be changed. - The root business unit cannot be deleted or disabled.

Chapter 2: Configuring Security
CHAPTER 2: CONFIGURING SECURITY

Objectives
The objectives are:
• Identify how privileges, access levels, and security roles are used by
Microsoft Dynamics CRM to ensure data integrity and privacy
• Distinguish between entity-based privileges and task-based
privileges
• Differentiate between the five types of access levels used within the
security roles
• Identify how Microsoft Dynamics CRM uses security roles
• Identify the advantages of using the default Microsoft Dynamics
CRM security roles
• Identify the properties of the system's two default administrative
roles
• Define the relationship between roles and business units
• Create new security roles
• Create new security roles by copying privileges and access levels
from existing security roles
• Identify best practices to follow when configuring security roles
Introduction
Microsoft Dynamics CRM provides a security model that helps protect
unauthorized access to data, supports efficient data access and collaboration, and
supports recommended security best practices. This section reviews the
Microsoft Dynamics CRM security model, the components that make up the
model, and how to manage them. This includes:
• Security privileges and access levels. These are the components

that control what actions a user can perform on each entity and the
records the user can perform those actions upon.
• Security roles. A security role contains the combination of
privileges and access levels for a specific job function.

Microsoft Dynamics CRM Security Features

The goals of the Microsoft Dynamics CRM security model include the following:
• Providing users with access to the appropriate levels of information

required to do their jobs.
• Categorizing types of users in order to define security roles that fit
their job requirements and restrict user access based on those roles.
• Supporting data sharing so that users can be granted access to
records they do not own for a specified collaborative task.
Microsoft Dynamics CRM accomplishes these goals through a role-based

security model. Each user must be assigned one or more security roles in order to
access the system. Users receive their permissions based on the roles they are
assigned.
FIGURE 2.1 FUNCTION OF ROLES
Role-based Permissions
Within each role, security permissions are defined at the following levels:
• Entity and Record level. Every security role includes the complete
list of actions that can be performed on each entity.
– Entities include Leads, Opportunities, Contacts, Accounts,
Cases, and so on.
– Typical actions that can be performed on each of these entities
include Read, Create, Write, Delete, Share, and so on.

The administrator can define an access level for every entity/action

combination in a security role. The access level indicates which records
the user can perform that action upon for that entity.
• Task level. Each role also includes yes/no access levels for certain
user and administrative tasks. Tasks include Print, Merge, Go
Offline, and so on. The access level indicates whether the user can
perform that task.
Although default security roles are automatically created by the Microsoft

Dynamics CRM Server Setup program to make implementations easier, quicker,
and less costly, custom roles can also be created to satisfy unique security
requirements.
Security Configuration Options

Microsoft Dynamics CRM implementers and administrators must clearly
understand the use of security roles in their Microsoft Dynamics CRM
implementations. Two options are available when configuring system security:
• Microsoft Dynamics CRM can be quickly deployed by assigning

each user one or more of the default roles that map to their job
functions.
• For some businesses, the security permissions included in the default
roles do not provide the preferred security level; in these cases, the
default roles serve as a template to create customized roles.
This training examines the security permissions built into each role and reviews
the steps involved in creating new roles and customizing existing roles to fit your
business requirements.
The security permissions defined within each security role consists of the
following two components:
• Privileges. Privileges define what actions a user can perform on each

entity in Microsoft Dynamics CRM. Privileges are pre-defined in
Microsoft Dynamics CRM and cannot be changed. A few examples
of privileges include:
– Create
– Read
– Write
– Delete

• Access Levels. Access levels indicate which records associated with

each entity the user can perform actions upon. Although default
access levels are assigned to each privilege, the access level can be
changed.
FIGURE 2.2 ACCESS LEVEL, PRIVILEGE, AND ROLE RELATIONSHIP
Data access is controlled by assigning a specific access level to each privilege

within a security role. This gives a user assigned the System Administrator role
control over every record and action a user can perform upon them.
EXAMPLE: If a role allows the user to delete accounts, the access level
associated with the Account Delete privilege indicates which accounts the user
can delete.
Privileges
Privileges are the basic security unit in Microsoft Dynamics CRM, defining what
actions a user can perform on each entity in the system. When thinking of
privileges, think actions each user can perform on an account, contact, lead, and
so on.
EXAMPLE: Considering your organization's business model, are sales

representatives allowed to create an invoice, view customer service cases,
update product information, and delete accounts?
Privileges are the foundation of each underlying security check. Privileges are
associated with three types of objects in Microsoft Dynamics CRM security
roles.
• User-owned entities. Most privileges map to user-owned entities,

such as deleting Accounts, reading Contacts, assigning Service
Cases, and so on.
• Organization-owned entities. Organization-owned entities include
entities such as User, Business Unit, Team, Role, and so on.
• Global tasks. These privileges are more administrative or task-based
and do not map to a specific entity. These include privileges such as
Print, Export to Excel, and Assign Roles.

The net result is that administrators are provided with precise control over every
action each user can perform in the system.
A section of the default Sales Manager role is displayed in the figure Privileges
within a role. Privileges such as Create, Read, Write, and Delete are displayed
along the top of the tab, and the entities to which each privilege is associated are
displayed in the left column (Account and Contact). The icon under each
privilege/entity combination refers to the access level associated with that
privilege and entity.
FIGURE 2.3 PRIVILEGES WITHIN A ROLE
Common Privileges for each Entity

The primary security privileges available for most user-owned entities are
described in the following chart:
FIGURE 2.4 COMMON SECURITY PRIVILEGES

Task-Based Privileges
The Business Management tab in each security role includes several task-based
privileges that are not related to a specific entity.
• Some of these privileges are administrative tasks, such as Assign

Role, and Go Mobile.
• Others are user-oriented tasks that can be applied to any entity, such
as Export to Excel and Print.
NOTE: The majority of task-based privileges are located at the bottom of the
Business Management tab. This tab is displayed in the figure “Task-based
privileges in the default Sales Manager role.”
FIGURE 2.5 TASK-BASED PRIVILEGES IN DEFAULT SALES MANAGER

ROLE
Access Levels
Privileges indicate what actions a user can perform on each entity, whereas
access levels define which records for that entity the user can perform those
actions upon. Access levels are based on a combination of:
• User ownership
• The business unit to which the user belongs

For user-owned entities Microsoft Dynamics CRM supports five access levels for
each privilege. These are presented in the figure titled Access Levels.
FIGURE 2.6 ACCESS LEVELS
For privileges associated with organization-owned entities and global tasks, there
are only two access levels available: Organization and None. These basically
equate to Yes or No options, respectively, for these privileges.
For the five access levels associated with user-owned entities, each access level
includes records made available by all access levels below the level granted to
the user by the privilege. For example, if you have Parent:Child Business Unit
Read access for Accounts, by default you implicitly have Business Unit and User
Read access for Accounts as well. This relationship is displayed in the figure
titled Hierarchical Access Levels.
FIGURE 2.7 HIERARCHICAL ACCESS LEVELS

Access Level - None

The None access level restricts the user from performing an action on any
records within that entity - even on records owned by the user. A privilege is not
assigned to a security role if the access level is set to None. Conversely, a
privilege is assigned to a role when the access level is changed from None to
another value.
EXAMPLE: Gail Erickson is the Sales Manager for Adventure Works’ Western
Region. Adventure Works has decided that there are some privileges the Sales
Manager must be restricted from performing, such as creating, writing, and
deleting Views. To guarantee this, the System Administrator creates a copy of
the default Sales Manager role and assigns the None access level to the Create,
Write, and Delete privilege for the Views entity. Gail is assigned this new,
customized role instead of the default Sales Manager role.
FIGURE 2.8 NONE ACCESS LEVEL

Access Level - User

Of all the remaining access levels that provide some degree of access, User
access is the most restrictive. If your role provides User access for a specific
entity and privilege, you can only perform that action on the following records
for that particular entity:
• Records you own

• Records owned by someone else but have been shared with you
• Records shared with a Team in which you are a member
EXAMPLE: In Adventure Works Cycle, Douglas Hite is a Customer Service

Representative in the Customer Support business unit. Douglas has “User
Account Create” and “User Account Write” access. The User level access for
these two privileges enables Douglas to create new Accounts and edit (change)
any records that are assigned to him, shared with him by other users, or shared
with any team in which he is a member.
FIGURE 2.9 USER ACCESS LEVEL

Access Level - Business Unit

Business Unit access is the next step up from User level access. Business Unit
access for a specific entity and privilege provides the following privileges:
• User access rights

• Access to records owned by or shared with other users assigned to
the same business unit as you
EXAMPLE: Stefan DelMarco is the Customer Support Manager at Adventure

Works Cycle. He manages the Customer Service representatives and is required
to assign and review all accounts and cases assigned to these representatives.
Assigning him “Business Unit Case Create” access enables him to create cases
for any customer assigned to the Customer Support business unit. Similarly, if
Stefan has “Business Unit Account Delete” access, he can delete any Account
record that is owned by him or any user who is assigned to the Customer
Support Business Unit.
FIGURE 2.10 BUSINESS UNIT ACCESS LEVEL

Access Level - Parent:Child Business Unit

Parent:Child Business Unit access is the next step up from Business Unit access.
Parent:Child Business Unit access for a specific entity and privilege provides the
following privileges:
• User and Business Unit access rights

• Access to records owned by users and shared with users who are
assigned to any business unit subordinate to your business unit,
regardless of how deep in the organizational structure the user's
business unit appears.
EXAMPLE: Mary Baker is the VP of Sales and Marketing for Adventure Works
Cycle. She manages all the Sales and Marketing representatives for the Field
Sales and Marketing Divisions. By assigning Mary “Parent:Child Opportunity
Read” access, she can view all opportunities that are owned by any user who is
assigned to the Sales & Marketing business unit or any one of its child business
units. Because the Adventure Works Cycle, Customer Care, Customer Support,
and OEM Support business units are not subordinate to Mary's business unit,
she cannot view opportunities owned by users assigned to those business units.
FIGURE 2.11 PARENT:CHILD BUSINESS UNIT ACCESS LEVEL

Access Level - Organization

Organization access is the least restrictive of all access rights. Organization
access for a specific entity and privilege allows you to perform that action on
records owned by any user within the entire organization, regardless of the
business unit to which the owner belongs. There are no access restrictions with
Organization access.
EXAMPLE: David Lawrence is the System Administrator for Adventure Works

Cycle. He requires the ability to reassign ownership of any record in the system,
regardless of the business unit to which the owner of the record belongs.
Because his System Administrator role gives him Organization Lead Assign
access, David can reassign any lead that is entered in the system, regardless of
who owns the record.
FIGURE 2.12 ORGANIZATION ACCESS LEVEL
Security Roles
A security role is the combination of privileges and access levels for a specific
job function. Although you can create custom roles for individual users,
Microsoft Dynamics CRM's focus from an implementation standpoint is on
security roles at the job function level. This enables a specific role to be assigned
to one or more users, each of whom performs the same job function.

Default Security Roles

When Microsoft Dynamics CRM is installed, the Server Setup program
automatically creates a series of 13 default security roles in the root business unit.
These roles correspond directly with the typical job functions performed within
most Sales and Service organizations. For each default role:
• Access levels for Read privileges assigned to user-owned entities are

usually more liberal (Organization and Parent:Child)
• Access levels for update privileges assigned to user-owned entities
are strategically limited to the operational requirements of each role
There are several advantages to using the default security roles:
• User accounts can be quickly activated, while providing a secure,

360-degree view of customers.
• Each user can be assigned default roles based on job functions to
reduce system startup time.
• Following deployment, each user's specific requirements relative to
those provided by their default role(s) can be analyzed and adjusted.
When adjustments need to be made, default roles can act as
templates when custom roles are created. An organization can copy
an existing role as a new role and then change the necessary access
levels in the new role to meet their business requirements.
The following default security roles are created by the Microsoft Dynamics CRM
Server Setup program:
• Administrative roles
– CEO-Business Manager
– System Administrator
– System Customizer
• Customer Service roles

– CSR Manager
– Customer Service Representative
– Schedule Manager
– Scheduler
• Sales and Marketing roles

– Vice President of Sales
– Sales Manager
– Salesperson
– Vice President of Marketing
– Marketing Manager
– Marketing Professional

Default Security Roles - Workgroup Edition

There is no difference in the default roles automatically installed by the
Microsoft Dynamics CRM Server Setup program for the Enterprise, Professional,
and Workgroup Editions. However, there may be a difference in how the roles
are implemented by small businesses running the Workgroup Edition.
In these organizations individual users generally perform multiple roles that are
typically split among multiple workers in mid- to large-sized organizations. This
means the small business administrator may have to assign multiple roles to each
user, because the default roles are associated with job titles that may not exist in
the small business.
Consider the following issues when planning security roles in deployments

involving the Microsoft Dynamics CRM Workgroup Edition:
• The small business administrator may extend more privileges to each

user than desired if multiple roles are assigned to a user to satisfy the
user's security needs.
• Alternatively, custom roles may be created to assign the exact
combination of privileges required by small businesses.
Business Units and Roles

Each security role that you create must be assigned to a specific business unit.
The relationship between roles and business units includes the following
characteristics:
• Each role must be assigned to a specific business unit.

• The security roles created for a business unit are automatically
inherited by each of its “child” business units when each child
business unit is created.
• Multiple business units may each contain a role that has the same
name, but the access levels for each privilege and entity may differ.
WARNING: This is generally not considered a best practice. It is better to have

roles with different names if the access levels are different. This prevents any
confusion between roles.

Users and Roles

When a Microsoft Dynamics CRM user account is created, it must be assigned at
least one security role in order for the user to access the application. The
relationship between roles and users includes the following characteristics:
• A user can only be assigned roles that belong to the same business
unit to which the user is assigned.
• If a user is reassigned to a new business unit, the user's security
role(s) is removed. The user must then be assigned a new role(s)
from the list of roles that belong to the same business unit to which
the user has been moved.
• When a role is assigned to a user, the user has access to all the
privileges specified in that role as dictated by its access levels.
• A user can be assigned more than one role.
EXAMPLE: Adventure Works Cycle has ten sales representatives in their

organization, four of whom maintain customer service information for the
corporate accounts. The System Administrator assigns the default Salesperson
role to each representative. This gives each representative the ability to view
both Sales and Customer Service information about each account; however, it
does not allow them to add or maintain customer service cases or other service-
related information. Because four of the representatives need this update
capability, the System Administrator also assigns them the Customer Service
Representative role. Therefore, six of the representatives have just the
Salesperson role, and four representatives have both the Salesperson and
Customer Service Representative roles.
• If a user is assigned multiple roles, the user's privileges are the union
of access rights assigned to all those roles.
• If a user is assigned more than one role and the access level for a
specific entity and privilege conflict between the roles, the access
level granted to the user is the least restrictive for that entity and
privilege.

EXAMPLE: Adventure Works assigned Mary Baker both the Sales Manager
and Marketing Professional roles. The Sales Manager role has Business Unit
Account Delete access, and the Marketing Professional role has User Account
Delete access.
This means Mary has Business Unit Account Delete access, because this access
level is less restrictive than User Account Delete.
FIGURE 2.13 SECURITY ROLE CHARACTERISTICS
System Administrator Role

The System Administrator role is unlike any other default role because it
provides administrative control over security and maintenance to the entire
application. A unique set of restrictions is placed on this role that is not included
with any other default role. These include the following:
• The default System Administrator role cannot be deleted or

modified.
• The last user account assigned the System Administrator role cannot
be disabled.

Any attempt to perform one of these actions causes an error. If your organization
requires modification to the privileges defined in the System Administrator role,
copy the role as a new role and modify the security rights in the new role.
FIGURE 2.14 SYSTEM ADMINISTRATOR ROLE RESTRICTIONS
To ensure the default System Administrator role is assigned during the

installation of Microsoft Dynamics CRM Server 4.0 or during an upgrade from a
prior release, the following procedures have been implemented within the setup
and upgrade processes:
• When running the Microsoft Dynamics CRM Server Setup program

in a new deployment, the System Administrator role is automatically
assigned to the user who runs the Setup program.
• If the System Administrator role exists during an upgrade but is not
assigned to a user account in the prior Microsoft Dynamics CRM
implementation, the upgrade program automatically assigns it to the
user running the upgrade.
System Customizer Role

Microsoft Dynamics CRM 3.0 includes a System Customizer role designed for
users who customize forms, views, and mappings through the System
Customization tool. The following characteristics define this role:
• The System Customizer role enables non-system administrators to

customize forms, views, and mappings.
• The System Customizer role has almost all the privileges of the
System Administrator role, with the following exceptions:
– The System Customizer does not have Organization Read level
access to all records.
– There are some customization tasks that only a System
Administrator can perform. An example of this is importing
customizations, because it involves areas where security
information might be exposed in the exported XML.

See the Appendix topic, "Permissions Required for Customization Tasks", for
more details on the permissions required to customize Microsoft Dynamics
CRM.
Security Roles and Business Units

Roles may be modified or removed as required to fit the needs of the
organization. Assigning roles to business units enables each role to be
customized to fit each business unit's security model.
When you create a new business unit within the organization, all of the security
roles assigned to its parent business unit are automatically copied to the new
business unit. This includes the default roles and any custom roles that were
manually created at the parent business unit.
NOTE: As you create each new business unit, the roles are copied from the new
business unit's parent. The parent is the root when creating business units one
level down from the root. If the business unit created is more than one level
down from the root, the roles are copied from its parent and not from the root.
Creating Custom Security Roles

Each security role you create must be assigned to a business unit. This lets you
create custom security roles that apply to one business unit and not another.
IMPORTANT: When you create a security role for a business unit, the system
automatically creates the same role at all the child business units subordinate
to that business unit, regardless of how deep in the organizational structure it
has to go.

This concept may be easier to visualize by looking at an organization chart and

walking through an example. This exercise uses the Adventure Works Cycle
organization chart displayed in the following figure. Specifically, focus on the
structure of the Channel Marketing business unit, which has two levels of child
business units.
FIGURE 2.15 ADVENTURE WORKS CYCLE ORGANIZATION CHART
In this example, assume you create a custom role titled Marketing Representative
and assign it to the Channel Marketing business unit. What occurs when you save
the role?
• The system automatically creates an identical copy of the Marketing

Representative role at all the Marketing business units’ child
business units.
• As illustrated in the figure titled Adding a Role to a Parent Business
Unit, Microsoft Dynamics CRM adds the Marketing Representative
role to the National Marketing, Retail Marketing, Bicycle Parts
Marketing, and Bicycle Marketing business units.

For a custom role that you want assigned to all business units, create it at the root
business unit. Because all other business units are subordinate to the root, the
system automatically creates the role at all business units in the organizational
structure.
FIGURE 2.16 ADDING A ROLE TO A PARENT BUSINESS UNIT
Inherited Security Roles

When a user creates a custom role at a business unit, Microsoft Dynamics CRM
automatically copies the custom role to each of the business unit's child business
units. The new roles created at the child business units are referred to as
“inherited roles” because they inherit the security rights of the custom role
created at the parent business unit.
EXAMPLE: In the figure titled, Adding a Role to a Parent Business Unit, the
Marketing Representative roles in the National Marketing, Retail Marketing,
Bicycle Parts Marketing, and Bicycle Marketing business units are “inherited
roles,” because they were automatically created from a similar role at the
Marketing business unit.
The following rules control how inherited roles can be maintained in Microsoft
Dynamics CRM:
• Inherited roles cannot be modified or deleted.

• To change an inherited role, you must modify the parent role from
which the inherited role originated. The system then applies the same
changes to all inherited roles associated with the parent role.

• To delete an inherited role, you must delete the parent role from
which the inherited role originated. All inherited roles associated
with the parent role are automatically deleted.
Microsoft Dynamics CRM requires that all maintenance to security roles is

performed at the parent role level. Parent role changes and deletions are
automatically propagated down the hierarchy and applied to the inherited role at
each child business unit. This ensures that all parent and inherited roles remain in
sync.
FIGURE 2.17 INHERITED ROLES
Security Impact when Reassigning Users

Security roles are similar to user accounts in that each must be assigned to a
specific business unit. However, because security roles in different business units
can have the same name but possess different privileges, what happens to a user's
security roles when the user is reassigned from one business unit to another?
• When a user is reassigned to a new business unit, no security roles

are assigned to the user's account in the new business unit.
• Microsoft Dynamics CRM cannot assume the privileges in the same
role(s) at the new business unit will match those from the security
role(s) at the old business unit.
• New roles must be manually assigned to the user at his or her new
business unit.

EXAMPLE: Mary Baker is reassigned from Adventure Works’ Central Region

business unit to the Retail Marketing business unit. At the Central Region, Mary
was assigned the Marketing Professional role. Although a similarly named role
exists in Retail Marketing, Microsoft Dynamics CRM does not automatically
assign Mary a security role when she is reassigned to the Retail Marketing
business unit. The System Administrator must review Mary's requirements for
this role in comparison to her current access rights when she attended the
Central Region business unit.
Creating and Copying Security Roles

Three options are available if the default roles or custom roles do not meet your
organization's security requirements for a given job function.
• Modify an existing role. This is not recommended if it is a default

role.
• Create a new custom role. When you create a new role, you must
select the business unit to which the role will be assigned when you
enter role information in the New Role form.
• Copy an existing role as a new role. You cannot copy a role from
one business unit to another; the new role you create is assigned to
the same business unit as the role that is copied.
BEST PRACTICE: If the default roles do not fit your organization's security
needs, copy the role with the closest resemblance to your requirements over as
a new role, modify the new role as required, and leave the default role
unchanged. This permits the default security roles to act as templates and
ensures a consistent set of security privileges across all business units.
Create a New Role by Copying an Existing Role

Perform the following steps to copy an existing role as a new role:
1. From the Navigation Pane, click Settings, click Administration, and

then click Security Roles.
2. Select the security role you want to copy.
3. On the Actions toolbar, click More Actions, and then click Copy
Role.
4. In the Copy Role dialog box, type the name of the new role in the
New Role Name field. You can enter only alphanumeric characters;
no symbols are allowed.
5. If you want to change the privileges for the new security role, select
the Open a new security role when copying is complete check box.
6. Click OK.

NOTE: If you select the Open a new security role when copying is complete
check box, the system creates the new role from the existing role and then opens
the new role so that it can be edited. After you make your required edits to the
new role, click Save, or Save and Close.
Create a New Role

Perform the following steps to create a new role:

3. On the Details tab, type the name of the new role.
4. The business unit field is automatically populated with the business
unit selected on the Security role page.
5. Edit the necessary access levels associated with the entities and tasks
in each tab. Click each access level radio button to change the
privilege depth. Every time that you click, the symbol cycles through
the applicable symbols for that record and access level. Depending
on the record and access level, you can advance one or more levels.
For example, for Account, Contact, or Lead, you can set User,
Business Unit, Parent:Child Business Unit, or Organization levels.
However, for Relationship Role, you can only set it at the
Organization level.
6. Click Save, or Save and Close.
Using Shortcuts to Quickly Create a New Role

You do not have to click through the access levels for each of the several
hundred privileges when you create a new role. When creating a new role, all the
access levels are set to None by default. To speed up the process of assigning
access levels, you can either:
• Click the column (privilege) header

• Click the row (entity) header
In either case, Microsoft Dynamics CRM automatically pre-fills appropriate

access level combinations for that privilege or entity. Various combinations of
access levels are displayed as you continue to click the same header. This allows
you to quickly set all the access levels for a specific privilege or entity at the
same time.
NOTE: Access level combinations are displayed starting with the most
restrictive through the least restrictive combinations.

After finding a set of access level combinations that are generally acceptable to
your organization, you can change any individual exceptions to meet your
requirements. This process is faster than clicking through the combinations of
access levels for each privilege and entity.
Using the Privilege Shortcut
The figure titled Using the Privilege Shortcut displays a sequence of screens to
create a new role using the privilege shortcut. This example selects a specific
privilege and cycles through the various combinations of access levels for that
privilege and each entity in that tab.
As shown in the first step in the graphic, all access levels are set to None when
the role is created. However, by clicking the Create column heading, the second
screen displays a combination of access levels for this privilege and each entity
in this tab.
By continuing to click the Create column heading, the combinations of access

levels change from the most restrictive (User access) to the least restrictive
(Organization access).
FIGURE 2.18 USING THE PRIVILEGE SHORTCUT
Using the Entity Shortcut
Alternatively, you can let the system automatically pre-fill the access levels for a
specific entity. Clicking the entity displays a set of default access levels for each
privilege on that tab. A different set of access levels appears each time you click
the privilege. The system displays combinations of the most restrictive access
levels through the least restrictive.

In the figure titled Using the Entity Shortcut, the first screen displays a new role
where access levels are set to None when the role is created. By clicking the List
entity in the second screen, note the change to the access levels for each privilege
on the tab. If you continue to click the List entity, the combinations of access
levels change from the most restrictive (User access) to the least restrictive
(Organization access).
FIGURE 2.19 USING THE ENTITY SHORTCUT
NOTE: Some of the privileges have dependencies with other privileges. For a
list of all security dependencies, see the Security System section of the
Implementation Guide.

Demonstration - Creating and Copying Security Roles

This instructor demonstration illustrates how to create a new security role and
update its permission settings using the shortcut methods described earlier in this
training. This demonstration also displays how to copy a security role, and it
examines the affect on security roles when a new business unit is created. Steps
are provided so you can follow along with the instructor.
Scenario
As an aid to managing security, Microsoft Dynamics CRM provides default

security roles. A security role is represented by a position title, such as Sales
Manager or Customer Service Representative. Assigned to each role are
privileges typically required by people serving in that position.
Besides default roles, you can also create custom security roles for your
organization. You can create a new role or copy an existing default or custom
role. When you create a new role, you must assign it to a specific business unit.
All child business units of the business unit in which you create the new security
role are assigned the new security role. As new roles are propagated down the
organizational hierarchy, so too are changes and deletions made to security roles.
Create a New Role

This exercise demonstrates the tasks to perform when creating a new role and
setting up a few of the privileges and entities for the role. You will create a new
role called Program Manager in Adventure Work's Channel Marketing business
unit.
1. From the Navigation pane, click Settings, click Administration,

3. In the role form, on the Details tab, type Program Manager in the
Role Name field.
4. Click the lookup button for the Business Unit field. In the list of
business units, select Channel Marketing.
5. Using the Privilege shortcut. Define a set of access levels using the
Privileges shortcut. In the Core Records tab, click the Read
privilege. Note the change to the access levels for each entity. This
sets almost every access level to User access. Click the Read
heading again and the User access levels are changed to Business
Unit access.
6. Individual access level changes. Change individual access levels
that are exceptions to this Business Unit access level. Click the
access levels for the Read privilege and the Account, Contact,
Lead, and Opportunity entities and change them to Organization.
Hint: Clicking each access level two more times changes it to
Organization.

7. Using the Entity shortcut. Click the Sales tab, and then click the
Quote entity until all privileges are set to Organization.
8. Click on the Competitor entity. Notice how all the access levels
change from None to Organization with one click. If you click on
the Competitor entity again, it cycles back to None. This is an
example of an entity that has limited access levels for each privilege.
9. Save the changes by clicking Save and Close.
Copy a Role
Even when using the privilege and entity shortcuts, creating a role can be a
lengthy process. There is another approach to creating a new role. This includes:
1) copy an existing role over as a new role; and then 2) change the access levels
in the new role that differ from the existing role.
1. To copy a role, first change the Security Roles view to display the
roles in the business unit associated with the role you are copying.
This is also the business unit to which the new role will be assigned.
Click National Channel Marketing from the Business Unit drop-
down list.
Because National Channel Marketing is a child business unit of

Channel Marketing, notice how the Program Manager role created in
the prior exercise for the Channel Marketing business unit has also
been automatically created at this child business unit.
2. Select the role to be copied; in this case, select the Marketing

Manager role.
3. On the Actions toolbar, click More Actions, and then click Copy
Role.
4. In the Copy Security Role dialog box, type Product Group
Manager in the New Role Name field.
5. To change privileges for the new security role, select the Open a
new security role when copying is complete check box. Click OK.
6. Click the Core Records tab.
7. Product Group Managers want the ability to delete any one of the
core records, regardless of the owner. They also want the ability to
assign any Account or Contact record in the organization.
a. The quickest way to change the Delete privilege for all core
entities is to click the Delete privilege column heading once
(using the Privilege shortcut). Continue to click the Delete
heading until it cycles through the different combinations and all
entities (except Saved View) are set to Organization.
b. Next, click the individual access levels for the Assign Account
privilege and set it to Organization. Repeat for the Assign
Contact privilege.

Create a New Business Unit and Verify the Roles

The prior exercise demonstrated how the Program Manager role created for the
Channel Marketing business unit was automatically copied down to the National
Channel Marketing business unit, which is a child of the Channel Marketing
business unit.
This exercise verifies that all the roles of a parent business unit - which include
both default roles and the two custom roles that were just created - are copied
down to child business units whenever a new child business unit is created.
1. From the Navigation pane, click Settings, click Administration,

2. On the Actions bar, click New.
3. In the business unit form, type OEM Marketing in the Name field.
4. In the Business Unit lookup field, select National Channel
Marketing.
6. Click Administration in the Settings pane.
7. Click Security Roles.
8. In the View drop-down list, select OEM Marketing.
9. The Program Manager and Product Group Manager roles appear
in the list with the other default roles copied down from the National
Channel Marketing parent business unit.
Open these two roles and verify the settings made earlier.

Lab 2.1 - Copying and Creating Roles

In this lab you must copy and create security roles in Microsoft Dynamics CRM.
Use the information in the Scenario and Goal Description to complete the lab
requirements.
Scenario
Adventure Works Cycle is implementing Microsoft Dynamics CRM. As their

implementation consultant, you will configure the system to meet their specific
business requirements. During the needs analysis, the organizational chart was
reviewed and analyzed, and the appropriate business units have been created in
Microsoft CRM. The next task is to make sure that all users have the appropriate
permissions to access and update the data.
During the needs analysis, it is discovered that Gail Erickson requires different
permissions than what the Sales Manager role provides. Because the
recommended best practice is to refrain from modifying the default roles, it is
decided that you will copy the Marketing Professional role in the Adventure
Works Cycle business unit as a new Marketing Representative role and then
customize the new role to meet Gail's requirements.
It is also discovered that Roger Van Houten can provide better support for OEM
customers if a unique OEM Support role is created in the Customer Support
business unit and tailored to meet the needs of this market.
Goal Description
To meet these requirements, you have been asked by the Project Team to create
the two new roles. To do this, you will:
• Create one role by copying an existing role as a new role and then
modifying the attributes of the new role
• Create a new role that is not based on an existing role
Copy the Marketing Professional role as a new role
Copy the Marketing Professional role in the Adventure Works Cycle business
unit as a new Marketing Representative role. In the Marketing Representative
role, modify the following access levels:
• Change the Write and Sharing privileges from Business Unit access
to User access for the Quote entity.
• In the Marketing tab, change all of the privileges for the Marketing
List and Campaign entities to Organization access. Use the entity
shortcut method to expedite this change.

Create a new OEM Support role
Add a new role titled OEM Support to the Customer Support business unit.
Assign the access levels and privileges to this role that are defined in the chart
(for the purposes of this exercise, ignore the tabs and the entities not included in
this chart).
FIGURE 2.20 ACCESS LEVELS FOR THE OEM SUPPORT ROLE
Challenge Yourself
1. Log on to the Microsoft CRM Server as the CRM Administrator

account.
2. Create the Marketing Representative role in the Adventure Works
Cycle business unit with the privileges defined in the Goal
Description.
3. Assign the Marketing Representative role to Gail Erickson's user
account. Remove all other roles from Gail's account.
4. Create a new OEM Support role in the Customer Support business
unit and assign the access levels as defined in the figure titled Access
Levels for the OEM Support Role in the Goal Description. Use the
shortcut methods to expedite the data entry process.
5. Assign the OEM Support role to Roger Van Houten.

Need a Little Help?

Step 1 - Copy the Marketing Professional role

account.
2. Navigate to Security Roles.
3. Select Adventure Works Cycle from the Business Unit drop-down
list if necessary.
4. Copy the existing Marketing Professional role as a new Marketing
Representative role and update the privileges per the instructions in
the Goal Description.
5. Assign the Marketing Professional role to Gail Erickson's user
account. Remove any other roles assigned to her.
Step 2 - Create a new role
1. Create a new role titled OEM Support in the Customer Support

business unit.
2. Assign to this role the access levels defined in the figure titled
Access Levels for the OEM Support Role displayed in the Goal
Description.
a. For the privileges and entities listed in the Core Records tab, use
the Privilege Shortcut method to quickly assign each
combination of access levels for each privilege, and make any
necessary changes to these default settings on an exception basis.
b. For the Service tab, use the Entity shortcut method to quickly
assign the majority of access levels for each entity, and make any
changes on an exception basis.
3. Assign this role to Roger Van Houten.
Step by Step
Step 1 - Copy the Marketing Professional role

account.
3. Select Adventure Works Cycle from the Business Unit drop-down
list if it was not used for the return screen.
4. Select the Marketing Professional role.

5. Click More Actions on the Action toolbar. Click Copy Role.

6. In the Copy Security Role dialog box, type Marketing
Representative in the New Role Name field. Click the Open new
security role when copying is complete check box if it is not
selected. Click OK.
7. When the Marketing Representative role is opened, change the
access levels as follows:
a. Click the Sales tab.
b. Change the Write and Sharing privileges to User access for the
Quote entity.
c. In the Marketing tab, change all of the privileges for the
Marketing List and Campaign entities to Organization access.
Use the entity shortcut method to expedite this change.
8. When complete, click Save and Close.

9. Click Administration under the Settings pane.
10. Click Users.
11. Click Gail Erickson's user account to open it.
12. Click the Roles side tab.
13. Click Manage Roles on the Action toolbar.
14. Select the Marketing Representative role and click OK.
15. Remove any other roles assigned to Gail.
Step 2 - Create a new role
1. On the Navigation Pane, click Administration, and then click

Security Roles.
2. On the Security Roles page, click New on the Action toolbar.
3. Enter OEM Support as the name of the role and select Customer
Support as the business unit.
4. Assign to this role the access levels defined in the figure titled
Access Levels for the OEM Support Role in the Goal Description.
a. For the Core Records tab, use the Privilege shortcut. Click on
each privilege until the majority of entities for that privilege have
the privilege defined in Goal Description table. Where
exceptions occur, click on each individual privilege/entity and
set the access level to the appropriate value.
b. For the Service tab, use the Entity shortcut. Click on Case
until all access levels match the majority of access levels in the
Goal Description table. Where exceptions occur, click on each
individual privilege and set the access level to the appropriate
value. Repeat for the Contract entity.

6. Click Administration under the Settings pane.

7. Click Users.
8. Double-click on Roger Van Houten to open his user account.
9. Click the Roles side tab.
11. Select the OEM Support role and click OK.

Planning Considerations when Configuring Security

There are several best practices to consider when planning and configuring your
organization's Microsoft Dynamics CRM security model. These include:
• Company culture is important. Company culture dictates the types

of positions that exist within an organization, and even how many
organizations (business units) are defined. Culture also dictates the
level of control that you want over authorizing access to data and job
function privileges. Perform the following tasks when planning your
organizational model:
– Review the current Sales and Service processes within the
company
– Determine the pain points with the current system or process.
• Understand existing job functions. By having a better

understanding of the responsibilities each person has within the
company, you can clearly define what data is accessed and to which
roles he or she must be assigned. Also, people who perform the same
job function can have a standard role and privileges. This results in:
– Easier deployment of the application
– Standardized training for the users by job function
– Standard business processes
– Increased support for the deployed solution among the user base
• Compare standard security roles with existing job functions. One

or more roles can be established for each job function. Map the
default roles within Microsoft Dynamics CRM to the organization's
Microsoft Dynamics CRM job functions. Any job function that
cannot be mapped must be documented, and a new role must be
created to reflect the new requirements. Both the default role and the
custom role can be assigned to users to provide the required security
privileges.
Questions to ask during the planning process include the following:

– Does an existing role in the system provide sufficient privileges
for the user's job functions?
– Does it provide too many privileges based on the user's job
functions?
– Are there unique job functions that require creating or modifying
an existing role?
• Review security dependencies. During the analysis of the job

functions and associated roles, careful attention must be paid to
security dependencies of privileges. Dependencies exist for various
reasons.

EXAMPLE: User A must perform an action that is dependent on User B

completing all the required fields in a record. If User B does not have access to
that record or cannot perform an action such as “update” against the record,
User A will not be able to complete the action.
• Create and/or modify custom security roles. During the

implementation phase of the project, job functions that have not been
mapped to a default role need to have new roles created for them.
Analyze your security needs and, just as importantly, document
them.
As soon as you create custom security roles, the roles will be

automatically copied down to each child business unit. The following
best practices must be observed during this process:
– Determine whether the role's access levels at the parent business

unit apply to the child business units.
– If the access levels are different, it may be fitting for you to
create a different custom role at the child business unit level if
the changes are significant enough.
– Remember, changing an access level for a role at a parent
business unit automatically applies the change to the same role at
all child business units.
• Test new or modified roles extensively to make sure that new

roles reflect the security features that you want. The correct
method of testing is to test not just what you expect to occur, but
what should not occur. If you assign someone Business Unit Lead
Read access, test to make sure that they can access leads owned by
other users within their business unit. Additionally, your tests must
ensure that users cannot access leads owned by users assigned to
different business units.
• Security can affect some development tools such as Workflow
processes and customization tools. For each role, review privileges
and access levels associated with each entity. Also review the major
business processes, customization capabilities and
read/write/create/sharing functionality.
• By default, all security roles give users ‘Delete’ permissions for
their own records. This must be given careful consideration. If it is
determined that users will not be able to delete records (but
‘deactivate’ unwanted records) then custom roles must be created
with the Delete privilege set to ‘None’.
• Security roles can be exported. As a best practice, create custom
roles in a test environment first. Once they have been approved,
export the role(s) from the test environment and import the role(s)
into the production environment.

Summary
This section reviewed the following core concepts that are part of Microsoft
Dynamics CRM security:
• Privileges
• Access levels
• Security roles
This section also examined the procedures required to create new roles and to
create new roles by copying and modifying existing roles. Lastly, it discussed the
characteristics associated with maintaining access levels for roles that have been
inherited from parent business units.

Test Your Knowledge

1. What is the primary purpose of the default security roles?
2. How are privileges granted to users in the Microsoft Dynamics CRM

system?
3. If Joe has User Delete access for Leads, then what Leads can Joe delete?

4. Mary is assigned two security roles. One provides User Account Delete
access, and the second provides Parent:Child Business Units Account Delete
access. What access right will Mary have to delete accounts?
5. If a user is assigned multiple Roles, the Privileges are the union of all the
privileges assigned to all the user's Roles.
( ) True
( ) False
6. List several of the key features of the Microsoft Dynamics CRM security
model.

7. What is the most basic security unit that is used as the core of
security checks?
8. When a custom role is created at a business unit and automatically copied to

each of its child business units, the new roles created at the child business
units are referred to as ______________ roles.
9. Which of the following are valid rules relating the maintenance of inherited
roles? (Select all that apply.)
( ) Inherited roles cannot be modified or deleted.
( ) In order to change an inherited role, you must modify the parent role from
which the inherited role originated.
( ) If you add a role and a role with the same name exists at the parent
business unit, the role that you create inherits all of the privileges
associated with the same role
( ) All of the above.
10. When you create a new role by copying an existing role, you can copy any
security role from any business unit in your Microsoft Dynamics CRM
deployment.
( ) True
( ) False


chapter:
1.
2.
3.

Solutions
Test Your Knowledge
1. What is the primary purpose of the default security roles?
MODEL ANSWER - Default security roles allow Microsoft Dynamics CRM
to be quickly deployed by assigning each user one or more default roles that
map to their job functions.
2. How are privileges granted to users in the Microsoft Dynamics CRM

system?
MODEL ANSWER - Privileges are granted through roles.
3. If Joe has User Delete access for Leads, then what Leads can Joe delete?
MODEL ANSWER - Joe can delete: - leads that he owns - leads owned by
someone else that have been shared with him - and leads shared with teams
in which Joe is a member
4. Mary is assigned two security roles. One provides User Account Delete
access, and the second provides Parent:Child Business Units Account Delete
access. What access right will Mary have to delete accounts?
MODEL ANSWER - Mary would have Parent:Child Account Delete
privileges. This is the least restrictive of the two conflicting Account Delete
access levels provided by her security roles.
5. If a user is assigned multiple Roles, the Privileges are the union of all the
privileges assigned to all the user's Roles.
( ) True
(•) False

6. List several of the key features of the Microsoft Dynamics CRM security
model.
MODEL ANSWER - The following are just a few of the key features: –
Preventing users from accessing entities that have not been shared with them.
– Allowing shared access to entities among multiple users and teams. –
Defining roles and restricting access based on those roles.
7. What is the most basic security unit that is used as the core of
security checks?
MODEL ANSWER - Privileges are the most basic security unit in Microsoft
Dynamics CRM, defining what actions a user can perform on each entity in
the system.
8. When a custom role is created at a business unit and automatically copied to

each of its child business units, the new roles created at the child business
units are referred to as ______________ roles.
MODEL ANSWER - inherited
9. Which of the following are valid rules relating the maintenance of inherited
roles? (Select all that apply.)
(√) Inherited roles cannot be modified or deleted.
(√) In order to change an inherited role, you must modify the parent role
from which the inherited role originated.
( ) If you add a role and a role with the same name exists at the parent
business unit, the role that you create inherits all of the privileges
associated with the same role
10. When you create a new role by copying an existing role, you can copy any
security role from any business unit in your Microsoft Dynamics CRM
deployment.
( ) True
(•) False

Chapter 3: Configuring Users and Teams
CHAPTER 3: CONFIGURING USERS AND TEAMS

Objectives
The objectives are:
• Review the characteristics of Microsoft Dynamics CRM's user

management structure
• Create and maintain user accounts in Microsoft Dynamics CRM
• Identify the differences between adding a single user and adding
multiple users at one time
• Identify the characteristics associated with each user licensing option
• Create and maintain teams of users in Microsoft Dynamics CRM
Introduction
At this point in your implementation plan, Microsoft Dynamics CRM is installed
and your organizational hierarchy and security roles defined. The next step in
configuring your organization is defining the users who access Microsoft
Dynamics CRM and the teams that share Microsoft Dynamics CRM data.
Defining user accounts starts during the implementation planning process. As

you plan your Microsoft Dynamics CRM implementation, think about how the
people who work for the company are organized. This involves not only
identifying who reports to whom, but also includes informal relationships that
support data sharing.
How a user accesses data is determined by a combination of the following:
• A license. Each user license must be unique, and every user who
logs on to Microsoft Dynamics CRM needs a license.
• A security role. Security roles are predefined groups of common
privileges based on the types of tasks users perform.
• A business unit. Every user belongs to a unit of the top-level
organization.
• One or more teams. Teams are groups of users who share and
collaborate on business records across business units.
• E-mail configuration. Identifies how the user's incoming and
outgoing e-mail is managed.

User Management Overview

Microsoft Dynamics CRM offers features for managing users that are flexible,
yet secure, and that simplify the maintenance process. However, depending on
the size of your organization, and considering the amount of turnover, internal
transfers, and promotions that occur, managing users can be a daily task.
Depending on the size and preference of the organization, managing users might
be the responsibility of a system administrator at the corporate level, or a system
customizer or manager at the location or department level.
Any member of your organization that uses Microsoft Dynamics CRM must be
assigned an Active Directory user account and a Microsoft Dynamics CRM user
account. Each Microsoft Dynamics CRM user account includes a user profile.
The information on the user profile can be maintained as follows:
• When you create user records, add information in the user profile
that is essential to the organization; for example, full name, job title,
home address, e-mail address, and phone number.
• After users have been added to the system, they can manage non-
essential personal information themselves.
NOTE: The information entered in user profiles is available for all Microsoft
Dynamics CRM users to see. To preserve the integrity of the user data, security
privileges need to be based on the individual's role in the organization and the
type of work he or she needs to do. For instance, a system administrator will
create teams and make organization changes, and a line supervisor or manager
redefines only the employee roles within his or her teams.
There are several reasons to establish a well thought-out user management

system. These include the following:
• Maintaining users in the correct business unit affects the

Microsoft Dynamics CRM security model. Because security
permissions are based in part on the user’s position in the
organization hierarchy, it is important that users are assigned to the
appropriate business unit.
• Maintaining a manager on each user account supports Workflow

functionality. Workflow rules can automatically notify a user's
manager when specific conditions occur.
• Maintaining users on teams supports the sharing of information

across teams. A user can share a specific record he or she owns
(such as an order, invoice, quote, and so on) with other individual
users and with other users that belong to a team.

Depending on how you are using Microsoft Dynamics CRM, you may also want
to explore additional ways to organize users. These groupings do not have any
impact on controlling data access.
• Sales territories. Territories are used to manage accounts and sales

and for organizing data in sales reports.
• Resource groups. Groups of two or more resources (users, facilities,
or equipment) that can be scheduled interchangeably. These can be
users that perform a service, or the equipment or facilities that are
required for a service.
• Queues. Queues are holding containers for work items. There are
queues that contain cases and activities in the Workplace, and queues
of articles in the knowledge base. Queues are used for grouping
cases and activities so that anyone in the queue can work on the case
or complete the activity.
NOTE: Using sales territories, resource groups, and queues to organize users
is not covered in this training. Non-administrative personnel typically use these
methods to organize users; therefore, these methods are covered in the
Microsoft Dynamics CRM Applications training offering.
Active Directory Integration

Microsoft Dynamics CRM uses Active Directory for user authentication. When a
Microsoft Dynamics CRM user logs into the network, the user's network login
credentials are authenticated in Active Directory. This eliminates any
requirement to log on again to use Microsoft Dynamics CRM.
The user's Active Directory domain logon name is stored with the user's
Microsoft Dynamics CRM user account. This supports authentication when the
user accesses the application. This concept is referred to as the principle of single
sign-on.
Microsoft Dynamics CRM User Licenses

A significant change in Microsoft Dynamics CRM is in the area of user licensing.
Each user can be assigned one of three types of user licenses:
• Full. A user assigned this license type has full access to any part of
Microsoft Dynamics CRM that he or she has the security roles and
privileges to access. This is the license type assigned to typical CRM
users that require both read and update capabilities.

• Administrative. A user assigned this license type has no access to

the Sales, Marketing, and Service areas, but he or she does have
access to the Settings area. This license does not consume either a
Full or Read-only license. It is available free of charge. Assigning a
user this license type allows your organization to create a backup
user account for a member of the IT department for administering
and customizing Microsoft Dynamics CRM without consuming a
Full license or Read-only license.
• Read Only. A user assigned this license type has Read-only access
to the Sales, Marketing, and Service areas that he or she has the
privileges to access. This license type consumes one of the available
Read-only user licenses. If a user with a Read-only license is
assigned a security role that provides any form of update capability,
the Read-only license overrides the security role privileges. In this
case, no update capabilities are allowed.
Customers can purchase two types of user licenses: Full and Read-only. Separate
license counts are maintained for each license type. For example, an organization
may purchase 100 Full licenses and 25 Read-only licenses.
Adding and Maintaining User Accounts

Microsoft Dynamics CRM provides the following user maintenance
functionality:
• Create and maintain user accounts

• Assign security roles to users
• Enable and disable users
• Assign users to business units
• Identify managers for users
• Assign users to appropriate teams
As soon as users are added to Microsoft Dynamics CRM, they can maintain their
own user account's non-essential information if their assigned security role
provides them with this update capability. However, the default non-management
roles do not allow User update as a default feature.
NOTE: Once users are added in Microsoft Dynamics CRM they cannot be
deleted, but they can be disabled.

Creating New User Accounts

Any users that you want to add into Microsoft Dynamics CRM must already be
defined in Active Directory. To add one or more new users into Microsoft
Dynamics CRM, navigate to the Users area, select the New option, and then
indicate if you want to add a single user or multiple users.
FIGURE 3.1 ADD NEW USER OPTIONS
Perform the following steps to add a new user account:
1. In the Navigation Pane, click Settings, click Administration, and

then click Users.
3. Click either User or Multiple Users.
• User. This is the same manner in which you add any other
record into the system. In this case, the New User form opens
and you enter all of the user profile information.
• Multiple Users. If you select this option, the system starts the
Add Users wizard, which asks you to select the users that you
want to add into Microsoft Dynamics CRM from the Active
Directory domain. Each selected user must share same CRM
business unit, security role(s), e-mail invitation option (for CRM
Live deployments), and licensing option (for on-premise and
partner-hosted deployments), all of which are requested by the
wizard.
These are the only common attributes that can be assigned to a

group of user accounts that are created at the same time. All
other user information must be added to each individual user
account once the users have been created by the wizard.

Adding a Single User

When adding a single user, enter the following information in the New User
form:
General tab - Enter primary user profile information and observe any noted
restrictions or requirements as needed. Key fields include:
• Domain Logon Name. Enter the Microsoft Dynamics CRM domain

name and log on name for the user. The name must match the logon
name in Active Directory. Microsoft Dynamics CRM uses this logon
name to authenticate the user against Active Directory (for example:
ADVWORKS\gail). When you Tab off this field, the First and Last
names for this user will be retrieved from his or her Active Directory
user account and displayed in their respective fields.
• Business Unit. Click the Lookup button to search for and select the
business unit to which the user is assigned. By default, Microsoft
Dynamics CRM pre-fills this field with the root business unit.
• E-mail access type - incoming and E-mail access type - outgoing.
Select how e-mail will be accessed for incoming and outgoing mail.
– None. E-mail will not be sent or received.
– Forward Mailbox. E-mail will not be forwarded from another e-
mail address (this option is only available for incoming).
– Microsoft Dynamics CRM for Outlook. E-mail is sent and
received with Microsoft Dynamics CRM for Microsoft Office
Outlook.
– E-mail Router. E-mail is sent and received with the Microsoft
Dynamics CRM E-mail Router.
• Access Mode. Select one of the Client Access License types. Refer
to the earlier lesson in this training titled Microsoft Dynamics CRM
User Licenses for complete information on the available license
types.
Click Save to save this record and leave it open to continue working in this
account. After you save the user record, you can edit the users’ teams, security
roles, work hours, services, and system jobs. Because every user must have at
least one security role in order to access the system, you must perform the
following steps to add one or more roles to the user account:
1. Click the Roles tab to add a security role to the user account.
2. Click Manage Roles on the Action bar.
3. When the Manage User Roles window opens, select the
appropriate role(s) for the user. Click OK.
4. Click the Save, or Save and Close to save the user record.

Adding Multiple Users

When you select the Multiple Users option, the Add Users wizard starts. The
wizard begins by prompting you to select the business unit and security role(s)
that will be assigned to each user. The remaining information that is requested by
the wizard depends on your Microsoft Dynamics CRM deployment.
• For Microsoft Dynamics CRM Live customers, you must select the
users and the appropriate E-mail Invitation option.
• For Microsoft Dynamics CRM on-premise and partner-hosted
customers, you must select the licensing option, the Active Directory
domain, and the users.
The Add Users wizard is an effective tool during the initial implementation
process. The wizard has the following characteristics:
• It is a bulk-import tool that is used strictly for creating new user

accounts in Microsoft Dynamics CRM.
• It cannot be used to maintain existing account information; account
maintenance must be performed within the Microsoft Dynamics
CRM application.
Obviously, not every user in an organization will have the same role, business
unit, and so on; in fact, job functions alone will predicate the assignment of
different security roles even in smaller companies with just one office. This has
the following affect on how you use the wizard:
• You must run multiple iterations of the Add Users wizard to enter all
the users into Microsoft Dynamics CRM.
• Each run is for a different group of users, where each group shares
the same business unit, security role(s), licensing option, and Active
Directory domain.
The following information applies to each field requested by the wizard:
• Business Unit. Select the business unit to which the new users
belong. This option is only presented if more than one business unit
exists. If only one exists, you will not receive this option because the
wizard will assign the business unit to the new user accounts.
• Security Roles. Select one or more security roles for the new users.
The roles that are displayed are the ones assigned to the selected
business unit.
• E-mail Invitations. For Microsoft Dynamics CRM Live customers,
you can select whether invitations will be sent to the e-mail address
of each new user. The E-mail invitations instruct new users how to
access Microsoft Dynamics CRM Live. If this option is selected, an
invitation is automatically sent after each new user is created.

• Licensing. For on-premise and partner-hosted customers, you can

select which license you want for the new users. The options include
Full, Read-only, and Administrator.
• Domains and Groups. For on-premise and partner-hosted
customers, the list of available users you can select from belongs to
the domains and groups that you select here.
– If you do not select a specific Active Directory Organizational
Unit (OU) on this window, Microsoft Dynamics CRM queries all
of the OUs for users to display.
– If an organization stores all of their Active Directory user
accounts in one OU, or if they store all of their CRM users in
one OU, then the organization can point to that specific OU in
the wizard. By doing so, the wizard does not have to query all
the OU’s in order to retrieve the user accounts to display.
• Users. From the list of available users, select the users you want to
add to the system.
Enabling and Disabling User Accounts

Microsoft Dynamics CRM automates the process of assigning user licenses to its
user accounts that have a Full license type.
• When a Microsoft Dynamics CRM user account with a Full license

type is created and Full user licenses are available, the status of the
user account is set to Enabled and the user is automatically assigned
a Full license.
• When a user account is created and there are no Full licenses
available, the status of the user account is set to Disabled and no
license is assigned to the account. A disabled user cannot access
Microsoft Dynamics CRM.
• When a disabled user is enabled, a user license is automatically
assigned to the account if one is available.
• When an enabled user is disabled, the user license is automatically
unassigned from the account and the user can no longer access
You can enable or disable a user account while maintaining User data. User
records are typically disabled to temporarily control user access. You can disable
a user record, but you cannot delete it.

Perform the following steps to enable or disable a Microsoft Dynamics CRM

user account:

then click Users.
2. To Activate a user record:
a. In the View list, select Disabled Users.
b. In the list of users, select the user records that you want to
activate.
c. On the More Actions menu, click Enable to activate the
selected user records.

4. To Deactivate a user record:
a. In the list of users, select the user records that you want to
deactivate.
b. On the More Actions menu, click Disable to deactivate the
selected user records.
c. In the confirmation message, click OK.
Assigning a Manager to a User Account

A manager is a Microsoft Dynamics CRM user with one or more direct reports.
You are not required to enter a manager for each Microsoft Dynamics CRM user
account. However, this information can play an integral role in reporting,
workflow, and other functionality.
EXAMPLE: Adventure Works has a standing policy that if a support call is not
resolved within two hours, the Customer Service Representative's manager is
notified that no action has been taken on the request. Adventure Works
implemented this rule by creating a workflow rule that monitors support cases
and notifies the CSR's manager when this condition occurs. They have also
created similar workflow rules that notify sales rep managers when timely
follow-ups do not occur for new leads and opportunities.
Changing the manager's name on a user profile disassociates the relationship with
the current manager and creates an association with the new manager. If your
company experiences reorganization and direct reporting relationships change,
you can make multiple hierarchical changes at the same time by selecting several
users on the Users list view and performing a single Change Manager action.

The following rules control whether a Microsoft Dynamics CRM user can be
assigned as a manager to another user's account:
• The manager must belong to either the user's business unit or to one
of the business units that parent the user's business unit.
• The manager cannot be assigned to a business unit that is a child of
the user's business unit.
• The manager cannot be assigned to a business unit that is not in the
direct chain above the user's business unit.
EXAMPLE: Following Adventure Works recent reorganization, Douglas Hite

is scheduled to be assigned a new manager. Douglas works for the Central
Region office. In this case, Douglas’ manager can belong to the Central Region
or to any of the business units directly above it. This direct chain of business
units to which Douglas’ manager can belong is displayed in the figure titled
“Managerial Business Unit Hierarchy.” Douglas’ manager cannot belong to
any of the other business units because they are not in the direct line of parent
business units above Central Region.
FIGURE 3.2 MANAGERIAL BUSINESS UNIT HIERARCHY

You can assign or change a manager for one or more user accounts at the same
time. The process is almost identical to enabling and disabling one or more user
accounts that was covered earlier.

then click Users.
2. In the list of users, select the user records that you want to change.
3. On the More Actions menu, click Change Manager.
4. In the Change Manager dialog box, click the Lookup icon to view
the list of user accounts.
5. Click the user who will be the new manager for this selected group
of users. Click OK.
6. In the Change Manager dialog box, click OK.

Lab 3.1 - Managing User Accounts

This lab requires you to add and maintain Microsoft Dynamics CRM user
accounts. Use the information in the Scenario and Goal Description to complete
the lab.
Scenario
Adventure Works Cycle is implementing Microsoft Dynamics CRM. The project

team has decided to implement a phased roll-out of Microsoft Dynamics CRM.
Besides the original users who were added to Microsoft Dynamics CRM during
the setup process, the first phase of the roll-out distributes the system to six
additional users for a short pilot project.
The goals of the pilot project are to determine the types of customization options
the business requires and gain internal support before the final roll-out. This user
group is expected to provide feedback on the system and help in training during
the final rollout. As their system administrator, you have been asked to add the
six new users into the application.
Goal Description
Now that you have configured Adventure Works’ business units and security
roles, your next task is to configure the user accounts of the six pilot project team
members. Add users with both the single user method and the multiple user
method. Your goal during the pilot project is to become familiar with the process
required by each method. Therefore, when Microsoft Dynamics CRM goes live
across the organization, you will be able to add the users in the most efficient
manner possible.
The following members of the pilot project team must be entered into Microsoft
Dynamics CRM:
FIGURE 3.3 PILOT PROJECT USERS

Each user can be found in the ADVWORKS domain, and each must be assigned
a Full license in Microsoft Dynamics CRM.
NOTE: For training purposes, each of these user accounts has already been
added into Active Directory in your VPC image. In this lab you will add the
accounts into Microsoft Dynamics CRM. The password assigned to each
account in Active Directory is Pa$$w0rd.
IMPORTANT: The default security policy for Domain Controllers only allows
users who are members of the Domain Admins group to log on to the server. In
this training environment, the Microsoft Dynamics CRM Server is also the
domain controller. This means that by default each sample data user will have
to be a domain administrator to log on and perform the labs in this training. To
avoid making each user a domain administrator in your training environment,
this security policy has been adjusted so that any user can log into the domain
controller.
THIS IS NOT A STANDARD SECURITY BEST PRACTICE. This non-
standard security policy is only implemented in your training environment
because of the requirements of the Virtual PC image.
After reviewing the chart provided by the management team, you decide to group
the six pilot project users together by business units and job roles. Two sets of
users have similar job responsibilities and business units. Toby and Cynthia are
both Customer Service Representatives in the Customer Support division, and
Megan and Gabriele are Salespersons in the Channel Field Sales office.
After careful consideration, you decide to enter Toby, Cynthia, Megan and
Gabriele using the Multiple Users option. Randy and Mark will be added
individually.
Make sure you are logged in as the CRM Administrator user account.
Challenge Yourself
Using the information provided in the Goal Description, add the six pilot project
users into Microsoft Dynamics CRM:
1. Create user accounts for Toby, Cynthia, Megan, and Gabriele using
the Add Users wizard.
2. Create user accounts for Mark and Randy. Assign each his
appropriate security role.

3. Test your work by logging in as one of these users to make sure that
he or she can access to Microsoft Dynamics CRM.
4. After you have added the users into Microsoft Dynamics CRM, you
are approached by Adventure Works’ management and instructed to
perform the following tasks:
a. Assign Mark Harrington as Toby and Cynthia's manager.
b. Disable Gabriele's user account. It was just learned that Gabriele
will be transferring to a new role within the company and will no
longer participate in the pilot project.
You have been asked to temporarily disable his user account

until the pilot project is complete and the application is rolled out
to the entire organization.
To verify that he can no longer access Microsoft Dynamics

CRM, log on as Gabriele and try to access Microsoft Dynamics
CRM.
Need a Little Help?

1. Cynthia Randall and Toby Nixon belong to the same business unit
and have the same role. They can be added in one pass through the
Add Users wizard. Megan Sherman and Gabriele Cannata belong to
the same business unit and have the same role. They can be added
together by making a second pass through the wizard.
a. When adding new users, select the Multiple Users option.
b. In your first pass through the Add Users wizard, select the
Customer Support business unit and the Customer Service
Representative security role.
c. From the Users folder of the ADVWORKS domain, select
Cynthia Randall and Toby Nixon from the User list.
2. Repeat the process for Gabriele and Megan. Select the correct
business unit and role for these users.
3. Test one of the new Microsoft CRM user accounts. Log off the
system and log back in as Toby Nixon. As soon as you have verified
that you can log on as Toby and access Microsoft CRM, log back
off, and then log back in as the CRM Administrator.
4. Create Microsoft CRM user accounts for Mark Harrington and
Randy Reeves. Add each of these through the single User option.
a. After entering the data for each user, select the Save option so
that the account is saved and still remains open.
b. Select the Roles option and assign the appropriate security role.

5. On the Users view, select Toby and Cynthia's user accounts, click
More Actions, and select the Change Manager option. Assign Mark
Harrington as their manager.
6. It was just learned that Gabriele will be transferring to a new role
within the company and will no longer participate in the pilot
project. You have been asked to temporarily disable his user account
until the pilot project is complete and the application is rolled out to
the entire organization.
a. Select Gabriele's user account on the Users view, click More
Actions, and select the Disable option.
b. To verify that he can no longer access Microsoft Dynamics
CRM, log on as Gabriele and try to access the application.
Step by Step
Step 1 - Add Multiple Users at one time
As you can see from the table in the Goal Description, both Cynthia Randall and
Toby Nixon belong to the Customer Support business unit, and both will be
assigned the Customer Service Representative role. They can be added at one
time in the Add Users wizard. However, because Megan Sherman and Gabriele
Cannata belong to a different business unit and have a different role, you have to
make a second pass through the Add Users wizard in order to create their user
accounts.

then click Users.
3. Click Multiple Users. This starts the Add Users wizard.
4. On the Select Business Unit page, select Customer Support. Click
Next.
5. On the Select Security Roles page, select the roles that will be
assigned to the users that you will be adding together. For Cynthia
and Toby, click the Customer Service Representative role. Click
Next.
6. On the Select License Type page, select Full. Click Next.
7. On the Select Domains and Groups page, select the “Select users
from the following domain or group” option. Expand the
ADVWORKS domain. Select Microsoft CRM. Click Next.
8. On the Select Users page, click the Look Up icon to select the Active
Directory user accounts for Cynthia and Toby. Click OK to close
the Look Up Records dialog box. Click Next.
9. Click Create New Users.
10. Click Add More Users.
11. Repeat this process for Megan and Gabriele, although this time
select the Channel Field Sales business unit and the Salesperson
role.

12. Test one of the new user accounts by logging off the system and
logging back in as Toby Nixon and starting Microsoft CRM. To log
in, enter:
- username = toby
- password = Pa$$w0rd
13. As soon as you have verified that you can access Microsoft CRM as
Toby, log off the system and then log back in as the CRM
Administrator.
Step 2 - Add Individual Users into Microsoft CRM
You must now create Microsoft CRM user accounts for Mark Harrington and
Randy Reeves. You will add these through the single User option, and you will
assign each user account its appropriate security role.
1. On the Users view, click New.

2. Click User. This opens the New User form.
3. On the General tab, enter Mark Harrington's information from the
table.
a. Enter ADVWORKS\mark as the Domain Logon Name.
b. Tab into the First Name field. Mark's first and last name are
automatically filled in from his Active Directory user account.
c. In the Business Unit field, click the lookup icon, and select
Customer Support from the Look Up Record window. Click
OK.
4. Click Save (not Save and Close; if you accidentally clicked Save and
Close, then open Mark's user account). This keeps Mark's user
account open.
5. After clicking the Save icon, the Details list becomes enabled on the
side tab.
6. Click Roles.
8. On the Manage User Roles window, select CSR Manager and click
OK.
9. Click the Save and New icon to save Mark's user account and open a
new User Form for the next user.
10. Repeat the process for Randy.
11. Since Randy is the last user account, click Save and Close instead of
Save and New when you have finished entering Randy's security
role.

Step 3 - Assigning a Manager
Now that you have created a user account for Mark Harrington, assign him as the
manager on Toby and Cynthia's user account.
1. In the list of Users, click on Cynthia's record, then hold down the
CTRL key and click on Toby's record. This selects just these two
user accounts.
2. Click More Actions on the Action toolbar, then click Change
Manager.
3. In the Change Manager dialog box, click the Lookup icon to view
the list of user accounts.
4. Click Mark Harrington, then click OK.
5. In the Change Manager dialog box, click OK to confirm the change.
Step 4 - Disable a User Account
After you have added the users into Microsoft CRM, you are approached by
Adventure Works’ management and instructed to disable Gabriele Cannata's user
account. It was just learned that Gabriele will be transferring to a new role within
the company and will no longer participate in the pilot project. You have been
asked to temporarily disable his user account until the pilot project is complete
and the application is rolled out to the entire organization.
1. In the list of Users, click on Gabriele's record.

2. Click More Actions, then click Disable to deactivate his record.
3. In the Confirmation dialog box, click OK to confirm the
deactivation.
4. To verify that Gabriele can no longer access Microsoft CRM, log off
as the CRM Administrator, log back in as Gabriele, and try to access
Microsoft CRM. To log in, enter:
- username = gabriele
- password = Pa$$w0rd
5. As soon as you have verified that you cannot access Microsoft CRM
as Gabriele, log off and then log back in as the CRM Administrator.

Team Management
A team is a group of users who share and collaborate on work projects. Teams
are typically created by a system administrator or by a user with the appropriate
team management permissions. The use of teams in Microsoft Dynamics CRM is
optional; there is no requirement that an organization must create teams.
However, the advantage of using teams is that information can be shared more
quickly with a group of users instead of individually sharing the information with
each member of the group.
The primary purpose for creating teams is to facilitate sharing of information

among its members. If you are continually sharing certain records with same
group of users, create a team of users so that you can share future records with
the team as opposed to each individual user.
EXAMPLE: Fabrikam, Inc. has been invited to bid for a new piece of work.
Fabrikam's CEO said that he wants “the best people” on this project. That
means drawing together experts from all across the company—probably from
different business units. Because Fabrikam's existing structure does not make
all information available to this “all star” group of people, the System
Administrator has created a team made up of these users. Using a team makes it
easy to share all project-related information among the team members.
Creating Teams
The following guidelines control how teams are managed:
• Each team must be associated with one business unit.

• Even though a team is associated with a particular business unit, its
members can include users who are assigned to any business unit
within the same organization.
• Users can be associated with more than one team.
• Users can be added to and removed from teams.
• Teams cannot own records, although records can be shared with
teams.
• Sharing a record with a team implicitly shares the record with each
member of the team.
• Teams cannot be deleted.

• You can disable a team by removing all the members from the team.
• To enable a disabled team, just add new members to it.
FIGURE 3.4 TEAMS
Perform the following steps to create a new team:

then click Teams.
3. On the General tab, enter information or observe any noted
restrictions or requirements as needed:
• Team Name. Type a unique name that describes the team's
purpose, business focus, location, or other meaningful
characteristic.
• Business Unit. Click the Lookup button to search for and select
a business unit. By default, Microsoft Dynamics CRM selects
the root business unit, the top-level business unit based on the
organization name entered during the installation.
4. Click Save or Save and Close.
NOTE: If you click the Save button instead of Save and Close, the Members
tab appears. This enables you to add users to the team.
Adding Users to Teams

Users can be added to a team in either of two ways:
• At the time you create the team record, you can select each of the
users that will be members of the team.
• When you are adding or updating an individual user account in

Microsoft Dynamics CRM, you can select each of the teams in
which that user is a member.

The following procedures outline the steps required to complete each of these
methods.
Adding Users to a Team
This procedure is a continuation of the prior procedure where you created a team.
After you saved the team record (which enabled the Members tab), proceed with
the following steps to add users to the team:
1. Click the Members tab. This form provides the ability to add
multiple users to the team at one time.
2. From the Team Member form, click the Add Members button on
the Action bar to add users to the team.
3. In the Lookup Records form, select all users from the Available
Records list who will be a part of the team. Move them to the
Selected Records list by clicking the right arrow button.
4. Click OK. The selected members appear in the Members list for the
team.
Adding Teams to a User Account
In the prior procedure, you opened a team record and then added users to the
team. Another approach to creating teams is from the perspective of a single user
account. In this case, you must open a user record and then add teams to the user
account.

then click Users.
2. Double-click on the user record you want to assign to one or
more teams. This opens the user account record.
3. Click the Teams tab and select the Join Teams button on the
Action bar.
4. From the Available Records list, select the teams to which the user
will be assigned. Move them to the Selected Records list. Click the
OK button to close the Lookup window.
5. The teams to which the user has been assigned now appear in the
Team form. Click the Save or Save and Close button to save the
changes to the user account.

Lab 3.2 - Managing Teams

This lab requires you to create teams in Microsoft Dynamics CRM, assign
members to those teams, and share records with those teams. Use the information
in the Scenario and Goal Description to complete this lab.
Scenario
Adventure Works Cycle is implementing Microsoft Dynamics CRM. As their

implementation consultant, you are charged with configuring the system to meet
the company's needs. The project team decided to go with a phased roll-out of
Microsoft Dynamics CRM 3.0. The first phase of the roll-out distributes the
system to six users for a short pilot project.
The goals of the project are to determine the types of customization options the
business requires and gain internal support before the final roll-out. This user
group is expected to provide feedback on the system and assist in training during
the final rollout.
Goal Description
Adventure Works Cycle promotes team selling and team customer support. Two
management team members, Stefan Del Marco and Patricia San Juan, have
approached you and asked that you set up the following teams to support the pilot
project:
FIGURE 3.5 TEAMS AND TEAM MEMBERS
In order to test the data sharing functionality, create a new account for the
Custom Bicycle Store. Use the following information for the new account:
• Custom Bicycle Store

• 2354 Walnut Ave
• Mansfield, Texas 76063
• (817) 555-1212
• Annual Revenue = $590,000
• 12 Employees

Challenge Yourself
1. Log in as the CRM Administrator and follow the instructions in the

Goal Description to create the requested teams and assign the
respective team members to each team.
2. Randy Reeves later approaches you and asks that you add him to the
Field Sales Representatives team.
3. Create the new account defined in the Goal Description.
4. To test the ability of a team member to view a shared record, modify
a team member's security role so that without the record being
shared, the user will not be able to view the record. You will perform
this test using Patricia San Juan. Patricia's Marketing Manager role
provides Organization Read and Business Unit Delete access for
Accounts. Change this role's Account Read and Account Delete
access to User. Log on as Patricia and view the Active Accounts.
Patricia should not be able to see the account that you just created
because of the change that you made to her security role. Log back
on as the CRM administrator.
5. Share the account that you previously created with the Fields Sales
Representatives team and assign them Read, Write, and Append
privileges.
6. Log on as Patricia San Juan and test the sharing privileges. See if
Patricia can now view the new account that was shared with her
team. Then select the account and attempt to delete it. What happens
and why?
Need a Little Help?

1. Log on as the CRM Administrator and launch Microsoft Dynamics

CRM from the web browser.
2. Create each of the teams that appear in the chart in the Goal
Description and assign the respective team members to each team.
a. After creating each team, Save the record to keep it open.
b. Select the Members side tab to add the appropriate users to the
team.
3. Randy Reeves later asks you to assign him to the Field Sales
Representatives team. Open Randy's user account, select the Teams
side tab, and assign Randy to this team.
4. Create the new account defined in the Goal Description.

5. To test the ability of a team member to view a shared record, modify

a team member's security role so that without the record being
shared, the user will not be able to view the record. You will perform
this test using Patricia San Juan. Patricia's Marketing Manager role
provides Organization Read access for Accounts.
a. Open the Marketing Manager role and change its Account Read
access to User.
b. Log on as Patricia. Navigate to Sales, and then Accounts.
Change the view to Active Accounts. Because of the change that
you made to her security role, Patricia should not be able to see
the account that you just created.
c. Log back on as the CRM administrator.
6. Select the account from the Active Accounts view. On the More
Actions menu, select Sharing.
7. Share the account with the Fields Sales Representatives team and
assign the team Read, Write, and Append privileges.
8. Log off as the CRM Administrator and log on as Patricia San Juan in
order to test the sharing privileges. See if Patricia can view the new
account. Then attempt to delete the account. What happened when
you tried to delete the account, and why?
Step by Step
Step 1 - Creating Teams and Assigning Team Members
1. Log into the computer as the CRM Administrator and launch

then click Teams.
4. In the Team form, enter OEM Support Representatives as the
Team Name.
5. In the Business Unit field, choose the lookup icon to view the list of
business units. Click OEM Support, then click OK.
6. Click Save (this leaves the team record open and enables the side tab
options).
7. Click the Members side tab.
8. Click Add Members on the Actions toolbar.
9. In the Look Up Records dialog box, click the lookup icon to view the
list of available users.
10. Select Roger Van Houten and click the >> arrow to move Roger to
the Selected Records pane. Repeat for Stefan Del Marco. Click OK.
12. Repeat these steps to create the two remaining teams identified in the
Goal Description. When you are finished with the last team, click
Save and Close.

Step 2 - Add a user to a team
Randy Reeves later approaches you and asks that you add him to the Field Sales
Representatives team.

then click Users.
2. Double-click on Randy Reeves’ user account to open it.
3. Click the Teams side tab.
4. Click Join Teams.
5. In the Look up records dialog box, click the lookup icon to view the
list of available teams. Select the Field Sales Representatives team
and click the >> arrow to move it to the Selected Records pane.
Click OK.
Step 3 - Create A New Account
In order to test the data sharing functionality, you decide to create a new account
for the Custom Bicycle Store, using the information provided in the Goal
Description.
1. In order to create a new account, click Sales in the navigation pane,

then Accounts.
2. Click New, then add the information for the Custom Bicycle Store
that appears in the Goal Description. Save and Close the record.
Step 4 - Test Access Prior to Sharing
To test the ability of a team member to view a shared record, modify a team
member's security role so that without the record being shared, the user will not
be able to view the record. You will perform this test using Patricia San Juan.
Patricia's Marketing Manager role currently provides Organization Read and
Business Unit Delete access for Accounts.

click Security Roles, and then double-click the Marketing
Manager role to open it.
2. On the Core Records tab, change the Account Read and Account
Delete access to User.
3. Save and Close the record.
4. Log off the system as the CRM Administrator and log in as Patricia
San Juan (username = patricia, password = Pa$$w0rd). Open

5. From the Navigation Pane, click Sales, and then click Accounts.
Change the view to Active Accounts. Because of the change that
you made to her security role, Patricia should not be able to see the
account that you just created.
6. Log off the system and log back on as the CRM administrator.
Step 5 - Share the Account with a Team
1. Navigate back to Sales, and then Accounts. Select the new account
that you just created. Click More Actions, and then click Sharing.
2. In the Sharing dialog box, click the Add User / Team option from
the Common Tasks pane.
3. In the Look Up Records dialog box, click the drop down arrow on
the Look For field and click Team. Click the lookup icon to view the
list of available teams.
4. Select the Field Sales Representatives team and click the >> arrow
to move it to the Selected Records pane. Click OK.
5. Select the Read, Write, and Append privileges only. Click OK.
Step 6 - Test Access After Sharing
1. In order to test the sharing privileges, log off the system as the CRM
Administrator and log on as Patricia San Juan (username = patricia,
password = Pa$$w0rd). Open Microsoft Dynamics CRM.
2. Click Sales, and then click Accounts.
3. Change the view to Active Accounts and verify that you can see
Custom Bicycle Store.
4. Select the Custom Bicycle Store record, then click on Delete icon
on the Action toolbar.
5. Click the Delete button to confirm the account deletion. Then click
OK to confirm the permanent deletion of the account.
What happened when you tried to delete the account, and why?

Summary
This section reviewed the procedures necessary to configure Microsoft Dynamics
CRM users and teams. It also covered the following best practices when planning
and maintaining your personnel structure:
• All users must be added to Active Directory before they can be

added to Microsoft Dynamics CRM.
• During the original implementation phase, selecting the Multiple
Users option when adding new users initiates the Add Users wizard.
This wizard is designed for the initial bulk load of users; it cannot
perform maintenance on existing Microsoft Dynamics CRM user
accounts.
• When adding one user at a time, the value entered in the user's
Domain Logon Name must be the same logon name assigned to the
user in the Active Directory. Microsoft Dynamics CRM uses the
logon name to authenticate each new user against Active Directory.
• Teams are groups of users who share and collaborate on accounts
and work projects. The advantage of using teams is that information
can be shared more quickly with a group of users instead of
individually sharing the information with each member of the group.

Test Your Knowledge

1. What are the two methods that create users in Microsoft Dynamics CRM?
2. What are the three steps to properly add a user into Microsoft Dynamics
CRM?
3. True or False. Users can be deleted in Microsoft Dynamics CRM.

( ) True
( ) False
4. Name two reasons for creating Teams in Microsoft Dynamics CRM.

5. What are the three types of user licenses that can be assigned to a user
account? (Select all that apply.)
( ) Administrative
( ) Privileged
( ) Read-only
( ) Full
6. True or False. Teams can be reassigned to different business units.

( ) True
( ) False
7. Which of the following statements is true regarding the assignment of a

manager to a user's account?
( ) The manager must belong to either the user's business unit or to one of the
business units that parent the user's business unit.
( ) The manager cannot be assigned to a business unit that is a child of the
user's business unit.
( ) The manager cannot be assigned to a business unit that is not in the direct
chain above the user's business unit.


chapter:
1.
2.
3.

Solutions
Test Your Knowledge
1. What are the two methods that create users in Microsoft Dynamics CRM?
MODEL ANSWER - Users can be added individually or in groups. When
adding multiple users at one time, the selected users must share the same
business unit, security role(s), and license type.
2. What are the three steps to properly add a user into Microsoft Dynamics
CRM?
MODEL ANSWER - – Add the user to Active Directory. – Add a new user
account in Microsoft Dynamics CRM. – Assign one or more security roles to
the user.
3. True or False. Users can be deleted in Microsoft Dynamics CRM.

( ) True
(•) False
4. Name two reasons for creating Teams in Microsoft Dynamics CRM.
MODEL ANSWER - – Information can be shared more quickly with a group
of users instead of sharing the information with each member of the group –
Selected views can be restricted to the members of a team.
5. What are the three types of user licenses that can be assigned to a user
account? (Select all that apply.)
(√) Administrative
( ) Privileged
(√) Read-only
(√) Full
6. True or False. Teams can be reassigned to different business units.

( ) True
(•) False

7. Which of the following statements is true regarding the assignment of a

manager to a user's account?
( ) The manager must belong to either the user's business unit or to one of the
business units that parent the user's business unit.
( ) The manager cannot be assigned to a business unit that is a child of the
user's business unit.
( ) The manager cannot be assigned to a business unit that is not in the direct
chain above the user's business unit.
(•) All of the above.
Lab 3.2 - Managing Teams

What happened when you tried to delete the account, and why?
MODEL ANSWER - You received an error message because the Delete
privilege was not shared with the team for this account, and Patricia’s role
only provided User Account Delete access. If Patricia’s role allowed her to
delete this account (for example, if she had Organization Account Delete),
then that privilege would have overridden the fact that her team could not
delete the account.


Chapter 4: Configuring Organizational Settings
CHAPTER 4: CONFIGURING ORGANIZATIONAL

SETTINGS
Objectives
The objectives are:
• Configure several “one-time” only organization settings that control

various system-wide functionalities
• Identify the impact of each System Setting on end-user functionality
• Identify the impact of the Auto Numbering settings on end-user
functionality
• Identify the impact of the Fiscal Year Settings on Sales Quota
reporting
• Identify how Multilingual User Interface packs let users personalize
their UI experience by displaying Microsoft Dynamics CRM in the
language of their choice
• Examine how multicurrency enables monetary transactions and
attributes to be defined in multiple currencies
Introduction
This section examines a variety of configuration settings that enable each
organization to tailor Microsoft Dynamics CRM to satisfy its business
requirements. These settings control the appearance and functionality of the
application; they are defined at the organization level and apply to all business
units in a given implementation.
These options include the following configuration parameters:
• System Settings. These options are typically one-time only settings

configured during system start-up. Normally, you will not need to re-
visit them unless you find that your organization is best served by
changing a specific option.
• Auto-Numbering. Newly created records are assigned a record ID
based on entity type. These options determine the numbering
schemes used to create the record IDs.
• Fiscal Year Settings. These calendar settings define the fiscal
periods used for sales quota management reporting.

• Multilingual User Interface. Microsoft Dynamics CRM allows

users to view the User Interface and Online Help of Microsoft
Dynamics CRM in different languages within the same installation.
This configuration control defines the languages required by the
users in your organization.
• Multicurrency. Microsoft Dynamics CRM supports a true
multicurrency model where an organization can enter any financial
transaction in multiple currencies. This configuration control defines
the currencies used by your organization, along with their
corresponding exchange rates.
System Settings
System Settings allow you to modify organizational parameters that control a
variety of system-wide functionalities. You can access these settings by clicking
Settings, then Administration, then System Settings. This lesson examines each
of the tabs in this window and the options associated with each.
FIGURE 4.1 ORGANIZATION SETTINGS

General Tab
The General tab contains a variety of system-level settings.
FIGURE 4.2 GENERAL TAB OF THE SYSTEM SETTINGS
Full-Name Format
The Name Format option configures how the full names of contacts and users are
displayed. Changing the Name Format after users have already been added does
not change the way those names are displayed. A change to the Name Format
only changes new entries.
Currency Precision
This parameter controls the number of decimals that appears with any currency
amount. The options are zero (0) through four (4).
Share entities with original owner
This option indicates whether objects that are assigned to a new owner will
remain shared with the original owner. This is a Yes/No option.
Blocked file extensions
Microsoft Dynamics CRM allows you to attach files to various objects. This
setting allows an organization to identify the file types that users will be
restricted from attaching to objects. This field is prefilled with a number of
default file extensions that are typically not recommended as best practices.
However, each organization is free to add or remove file extensions from this list.
Use a semi-colon to separate each new file extension that you add.

Currency display option
This option allows an organization to indicate whether currency amounts will be

displayed with the currency symbol or the currency code. For example, if
Adventure Works Cycles’ currency is United States dollars (which has a
currency symbol of $ and a currency code of USD), and if an order is for one
hundred dollars, then selecting the currency symbol for this option displays the
order amount as $100.00, whereas, selecting the currency code displays the
amount as 100.00 USD.
Formats Tab
The Formats tab allows organizations to identify how the following
measurements are displayed throughout the application:
• Numbers
• Currency
• Time
• Long and Short dates
FIGURE 4.3 FORMATS TAB
From the Current Formats list, you can define the formats that your organization
wants to use for these measurements in either of two ways:
• Select pre-defined formats for a given language and region. If

you select this option, then you must use all of the default formats
that are defined for the language and region that you select from the
drop-down list.

• Customize your own formats. If you click the Customize button,

you can select a custom format for each measurement.
FIGURE 4.4 CUSTOMIZE REGIONAL FORMATTING OPTIONS
E-mail Tab
The E-mail tab allows you to indicate whether outgoing e-mails are tracked as
Microsoft Dynamics CRM e-mails by means of a tracking token, and if so, the
format of the tracking token for your organization. The tab also includes
additional e-mail options that define e-mail form options and file size limits for
attachments.
FIGURE 4.5 E-MAIL TAB
Configure e-mail correlation
This section includes two options. The first option indicates whether a tracking
token must be assigned to each outgoing Microsoft Dynamics CRM e-mail
message.

A tracking token is an alphanumeric string generated by Microsoft Dynamics

CRM. It is appended to the subject immediately following the original subject
line of the outbound e-mail. There is only one space separating the Tracking
Token from the original subject.
NOTE: It is not possible to configure the tracking token to appear in any other
location within the e-mail message (for example, hidden away in the message
header). The system components that reference the tracking token are designed
to locate it at the end of the subject line.
The tracking token is used in the following manner:
• The tracking token is a unique identifier that tracks and matches e-

mail activities with e-mail messages.
• When Microsoft Dynamics CRM generates an outgoing e-mail
activity, it can optionally attach a tracking token to the subject line of
the outgoing e-mail message.
• An incoming e-mail response to the Microsoft Dynamics CRM
system is correlated to the originating activity.
– Microsoft Dynamics CRM considers an e-mail response to be a
solicited, or subscribed e-mail when a valid tracking token is
present in the subject line of the incoming message.
– An unsubscribed e-mail is a message incoming to the Microsoft
Dynamics CRM system that does not have a tracking token or
cannot be correlated with an originating activity.
For example, if an organization has a customer that also has

Microsoft Dynamics CRM installed, the organization might
receive an e-mail message from the customer that has the
customer's tracking token assigned to it. However, because the
customer's tracking token is not valid in the organization's
system (for among other reasons, it has a different prefix), the
token cannot be correlated with an originating activity in the
organization.
• The Microsoft Dynamics CRM E-mail Router checks each message

for this token to determine whether the e-mail is a reply to a
Microsoft Dynamics CRM e-mail or an unsubscribe message.
Tracking tokens can be turned on or off and configured to be unique for a

specific Microsoft Dynamics CRM deployment. This means that a company with
multiple Microsoft Dynamics CRM organizations can configure tracking tokens
that are unique to each organization.

Each tracking token consists of several parameters. If you select the option to use
a tracking token, then you can customize the tracking token by configuring the
following tracking token parameters:
• Prefix. The prefix is a 20-character field at the start of the tracking

token. The default value is “CRM:”.
IMPORTANT: Because your organization may deal with other accounts or

contacts that also have Microsoft Dynamics CRM installed, consider changing
the prefix to a different value as a best practice. A common approach is to
change the value to something that reflects your organization's name.
• Deployment base tracking ID. If you have multiple Microsoft

Dynamics CRM deployments, then a unique base tracking ID should
be assigned for each deployment. This allows you to link e-mails to
each specific deployment.
• Number of digits for users. This field identifies the digits in the
number of system users. You can select between one and ten digits.
• Number of Digits for incremental counter. The incremental
counter is an automatically generated tracking number. This field
controls the number of digits to use for this number, which can be
from one to nine.
Set tracking options for e-mails between CRM users
This option controls whether e-mail activity records are created for incoming and
outgoing e-mail between two Microsoft Dynamics CRM users.
• If you select this option, then an outgoing e-mail activity record is

created to reflect the message that is sent, and an incoming e-mail
activity record is created to reflect the message that is received.
• If you do not select this option, an incoming e-mail activity record is
not created for the message that is received; however, an outgoing e-
mail activity record is created for the message that is sent.
The following three conditions must be satisfied in order to create an e-mail

activity record for an incoming message:
• The “Use tracking token” option is selected.

• The message is a CRM e-mail.
• The “Set tracking options for e-mails between CRM users” option is
selected.

Set E-mail form options
These E-mail form options control the format of the e-mail form that is presented
to the user, and whether outgoing e-mails are restricted to CRM users.
• User secure frames to restrict e-mail message content. This option

controls whether some HTML constructs are blocked in the e-mail
form.
• Allows messages with unresolved e-mail recipients to be sent.
Resolved e-mail recipients are CRM users. If this option is set to
Yes, then messages will still be sent if a user entered in the To, BCC,
or CC fields is not a CRM user. If this option is set to No, then all e-
mail addresses entered on the e-mail must be for a CRM user in
order for the message to be sent.
Set file size limit for attachments
This option allows you to define a maximum file size (in kilobytes) for files that
are attached to outgoing CRM e-mails. The default file size is 5,120 KB.
Marketing Tab
The Marketing tab includes settings that control how e-mail messages are
processed for several automated marketing features.
FIGURE 4.6 MARKETING TAB
Enable Direct E-mail through Mail Merge in Campaigns
By default, Microsoft Dynamics CRM does not allow users to send e-mail
messages as campaign activities using the mail merge feature from within
Campaigns. Setting this option to Yes allows you to override this default setting
and enable users to send e-mail messages using mail merge from Campaigns.

Creating Campaign Responses Automatically from Incoming E-mail Messages
This option is only available if e-mail tracking is enabled on the E-mail tab. This
Yes/No option controls whether an e-mail response is automatically created and
sent whenever an e-mail is received relating to a marketing campaign.
The system determines if an incoming e-mail is related to a marketing campaign

by checking the subject line of the message. If the subject line of the e-mail that
your users have sent from Microsoft Dynamics CRM includes a campaign code,
and if the e-mail address for the incoming e-mail matches an e-mail address for a
customer record, Microsoft Dynamics CRM can automatically create a campaign
response based on the incoming e-mail message.
Setting the Auto-Unsubscribe Options
The following options are only available if e-mail tracking is enabled on the E-
mail tab. Some customers may want to unsubscribe from e-mail marketing
communications your organization sends them. You can configure several
options specifically related to the unsubscribe feature.
• Set “Do Not Send Marketing Material” option when unsubscribe

e-mail is received. When you enable your customers to unsubscribe,
Microsoft Dynamics CRM inserts a link into each outgoing e-mail
message. When the customer clicks the link, the e-mail application
opens a new message with the unsubscribe information in the subject
line.
Next, when the customer sends the e-mail message and Microsoft
Dynamics CRM receives it and determines from the information in
its subject line that it is an unsubscribed e-mail response, the system
checks this “Do Not Send Marketing Material” option to
determine how to respond.
– If you set this option to Yes, the “Send Marketing Materials”
flag on the account, contact, or lead record is set to “No”. This
prevents the person from receiving any future marketing
communications from your organization.
– If you set this option to No, the “Send Marketing Materials” flag
on the account, contact or lead record is not set to “No”. This
allows your organization to send future marketing
communications to this person.

• Send acknowledgement to customers when they unsubscribe.

This option is only enabled if you set the prior “Do Not Send
Marketing Material” option to Yes. In this case, marketing material
is not sent to the customer; however, you may still want to send him
or her an e-mail acknowledging your receipt of the message. This
option controls whether an acknowledgement will be sent.
– If you set this option to No, then no acknowledgement is sent to
the person who sent the unsubscribed e-mail.
– If you set this option to Yes, an acknowledgement e-mail is
automatically sent to the person who sent the unsubscribed e-
mail. In addition, you can optionally select the e-mail template to
use for the acknowledgment e-mail message. The template can
be selected from the drop-down field that appears following this
option.
Customization Tab
The Customization tab controls the naming convention assigned to each custom
entity and attribute that an implementer creates.
FIGURE 4.7 CUSTOMIZATION TAB
Schema name prefix for custom entities and attributes
This option identifies the prefix appended to the names of custom entities and
attributes. The default value is “new_”.

BEST PRACTICE: As a best practice, partners creating customizations should

consider using a prefix that reflects their company name. Therefore, if an
organization has contracted with multiple partners to create customizations, the
customizations from each partner will not conflict with one another for a given
customer.
Custom Menus and Toolbars
By updating the ISV.Config, implementers can create custom buttons and toolbar
(menu) items. This option allows you to identify which types of Microsoft
Dynamics CRM clients upon which the custom buttons and toolbar items will be
displayed. This field must be left blank if you have not customized the
ISV.Config; otherwise, you must select any combination of the following client
types:
• Outlook Laptop client

• Outlook Workstation client
• Web client
Application Mode
This option determines whether Microsoft Dynamics CRM will be loaded in a

browser window that does not display address, tool and menu bars. Setting this
option to “On” results in the following:
• The user is presented with less options and Microsoft Dynamics

CRM, not Internet Explorer, becomes the focus of the user's
experience.
• Each time the user logs in, Microsoft Dynamics CRM prompts the
user if he or she wants to close the Internet Explorer page and open a
second page.
If this option is changed, you must close the browser and re-open it in order to
view Microsoft Dynamics CRM in the new mode.

Outlook Tab
The Outlook tab includes settings that control how e-mail messages are
processed for Microsoft Dynamics CRM for Microsoft Office Outlook.
FIGURE 4.8 OUTLOOK TAB
Set e-mail promotion options
When you work in Microsoft Dynamics CRM for Outlook, you can use all the
familiar Outlook buttons and toolbars together with the Microsoft Dynamics
CRM toolbar and menu to manage e-mail messages and most other activities. At
any time, you can track an Outlook e-mail message in Microsoft Dynamics
CRM. This is also referred to as promoting an e-mail message. The Personal
Options settings let each user identify which messages he or she wants to track in
Microsoft Dynamics CRM. The tracking options include:
• All e-mail messages

• E-mail messages in response to a CRM e-mail
• E-mail messages from CRM leads, contacts, and accounts
A message can be promoted automatically when it meets the requirement of the

Personal Options setting. A message can also be promoted manually by the user.
Promoted messages still appear in Outlook mail folders, but they are marked with
a Tracked in CRM icon and a copy of the message is saved as an e-mail activity
in Microsoft Dynamics CRM. For any e-mail where the user is a recipient,
sender, or owner, Microsoft Dynamics CRM first checks the user's security
privileges before promoting the message. The user must have Read privilege for
Activities, and if the Personal Options is set to promote e-mail messages for
CRM leads, contacts, and accounts, the user must also have Read privileges for
the lead, contact, or account, respectively; otherwise, the e-mail is not promoted.

Consider the following scenario:
1. Pernille is viewing her Outlook inbox and notices that an icon

changed for one of the e-mails. The item was “auto-tagged” by a
Microsoft Dynamics CRM process running in the background of her
Microsoft Dynamics CRM for Outlook.
2. Pernille clicks on the item and notices the “View in Microsoft
Dynamics CRM” button appears. This indicates that a link exists for
the item in Microsoft Dynamics CRM. The link is in the form of an
e-mail activity record, which exists in Microsoft Dynamics CRM for
that message.
3. Pernille clicks the “View in Microsoft Dynamics CRM” button and
launches the web form for this e-mail activity.
The options in this section of the Outlook tab define when and how often
incoming e-mail is promoted and tracked in Microsoft Dynamics CRM.
• Perform checks as new e-mail is received. This option controls

whether incoming e-mail is automatically checked as it is received. If
this option is set to Yes, each received e-mail is checked whether it
satisfies the user's e-mail tracking setting in his or her Personal
Options. Any message that meets this criteria is promoted to a CRM
e-mail activity.
• Promote incoming e-mail every __ minutes. Instead of checking
each e-mail as it is received, e-mail messages can be checked at
regular intervals. This is referred to as the standard polling interval.
At each interval, the user's Outlook inbox is checked for messages
that satisfy the user's e-mail tracking setting in his or her Personal
Options. Any message that meets this criteria is promoted to a CRM
e-mail activity. The default value for this setting is ten minutes. The
minimum value for this setting is one (1); the maximum value is
9999.
• Send pending CRM e-mail every __ minutes. The default value for
this setting is ten minutes.
NOTE: With the polling interval feature, a user may reply to an incoming e-
mail before the polling interval is reached and before it is recognized or
promoted as a Microsoft Dynamics CRM e-mail. In this case, the e-mail is
treated like a regular non-Microsoft Dynamics CRM e-mail. The user can
manually promote the e-mail, but it does not happen automatically.

Schedule Synchronization options
This section of the Outlook tab includes the following parameters that control
data synchronization:
• Users can schedule synchronization. This option controls whether

or not scheduled synchronizations will be available for all Microsoft
Dynamics CRM for Outlook users. Scheduling automatic
synchronizations enables companies to reduce user concern about
not having up-to-date Microsoft Dynamics CRM data in their
working Outlook folders.
• Minimum Time between synchronizations. If the option to
schedule synchronizations is turned on, you can specify the
minimum time interval between synchronization runs. This helps
ensure the user sees the most up-to-date Microsoft Dynamics CRM
data in their Outlook folders. Note: Each synchronization process
runs in the background; it does not interrupt the user from interacting
with Outlook.
Updating local data in the background
This section of the Outlook tab includes the following options that control
background synchronization of local data:
• Users can schedule background local data synchronization. You

can select whether synchronization of background local data will be
available for all Microsoft Dynamics CRM for Outlook users.
• Minimum Time between background local data
synchronizations. If background synchronization of local data is
turned on, you can specify the minimum time interval between
synchronization runs.
Set Schedule for Address Book Synchronization
This section of the Outlook tab includes the following options that control
background synchronization of the address book:
• Users can schedule background address book synchronization.

You can select whether background synchronization of the address
book will be available for all Microsoft Dynamics CRM for Outlook
users.
• Minimum Time between address book synchronizations. If
background synchronization of the address book is turned on, you
can specify the minimum time interval between synchronization
runs.

Reporting Tab
The Reporting tab controls the sequence in which report categories appear in
Microsoft Dynamics CRM. You can arrange existing categories in an order that
meets your organization's requirements. You can also remove existing categories
and add new ones.
FIGURE 4.9 REPORTING TAB
Auto Numbering
Auto Numbering allows you to configure the way records for certain objects are
numbered. Each number has a prefix and a number. Regardless of the Auto
Numbering format used, all sequential numbers begin with 1001.
Two different types of auto numbering formats can be configured within the
system:
• Prefix + Number Format

• Prefix + Number + Suffix format
The following document types allow auto numbering:
• Contracts
• Cases
• Articles
• Quotes
• Orders

• Invoices
• Campaigns
FIGURE 4.10 AUTO NUMBERING SETTINGS
Prefix + Number Format
Knowledge Base (KB) Articles use the Prefix + Number format. This format
configures the first segment of the numbering sequence using a three character
value. The numeric values are consecutive beginning with the value of 1001.
NOTE: The numeric value cannot be changed or reset.
Prefix + Number + Suffix Format
All the remaining entities (Contracts, Cases, Quotes, Orders, Invoices and
Campaigns) use a Prefix + Number + Suffix format. The Prefix can be three
alpha characters. The length of the suffix can be a range from four to six
randomly generated alphanumeric characters. The number values are consecutive
beginning with 1001.
NOTE: If you change the suffix length for a specific entity, the new suffix length
is also applied to the other entities that include a suffix. For example, if you
change the suffix length to 5 under the Contracts tab, then the suffix displays as
5 for Cases, Quotes, Orders, Invoices, and Campaigns.
Fiscal Year Settings

Fiscal year settings must be defined in Microsoft Dynamics CRM to enable Sales
Quota functionality. Sales Quotas provide productivity information for the sales
force. Use this information when measuring the progress of the sales force
against the quotas that have been set for them, their managers, and the territories
in which they are divided.

WARNING: Fiscal year settings affect the way in which your organization's
data is stored in the Microsoft Dynamics CRM database. Therefore, you can
set the fiscal year options only once. Because you cannot change these settings
after you have set them, ensure the fiscal period parameters are correct before
clicking OK to save the screen.
FIGURE 4.11 FISCAL YEAR SETTINGS
The following fiscal year settings are required:
• Start Date. Select the date you want the fiscal year to start.
• Template. Select the template that describes how your fiscal year is
divided.
• Fiscal Year. Select how you want to display the fiscal year.
• Named Based On. Select whether the fiscal year name is displayed
based on when the fiscal year starts or ends.
• Fiscal Period. Select the abbreviation you want to display to
represent the fiscal period.
• Display As. Select the format for displaying how the fiscal year and
fiscal period will be displayed together.
The only optional setting on this screen is the parameter to base the monthly
period name on the name of each month. This option is only applicable if your
organization's fiscal periods match the calendar months.

Lab 4.1 - Maintaining System Settings

In this lab you will update a number of the system settings in Microsoft
Dynamics CRM. Use the information in the Scenario and Goal Description to
complete the lab.
Scenario
Adventure Works Cycle is implementing the Enterprise Edition of Microsoft

Dynamics CRM. As their implementation consultant, you are helping the
company configure the system to meet their specific needs. You have completed
installation of the Microsoft Dynamics CRM Server and configured your
organization and business units. It is now time to configure the organizational
settings.
During the needs analysis planning sessions, the planning team reviewed each of
the system settings and decided which values best fit Adventure Work's
requirements. It is your job as implementation consultant to implement these
changes.
Goal Description
The project planning team has reviewed the System Settings and has decided to
accept all of the default values, except for the settings displayed in the table
below. You have been asked by the project planning team to update these
exceptions.
FIGURE 4.12 SYSTEM SETTINGS

You have also been asked to update the Auto Numbering options displayed in the
table.
FIGURE 4.13 AUTO NUMBERING SETTINGS
Verify that you are logged on as the CRM Administrator.
IMPORTANT: When the Adventure Works sample data was loaded into the
VPC image used for these training purposes, the fiscal year parameters had to
be set in the Fiscal Year Settings. Because Fiscal Year Settings can only be
updated once, the settings are now read-only. You cannot update the Fiscal
Year Settings in this lab; however, if you are interested, you can view the
settings by navigating to Settings, then Business Management, then Fiscal Year
Settings.
Challenge Yourself
Based on the information in the tables displayed in the Goal Description,
configure the organization settings for Adventure Works Cycle by modifying the
following:
• System Settings
• Auto Numbering
Test each configuration once you have applied the changes. Verify the changes to
the Report Headings. Create a Contract record and verify the contract number
assigned to it.
Need a Little Help?

Based on the information in the tables displayed in the Goal Description,
configure the System Settings and Auto Numbering settings for Adventure
Works Cycle.
1. Open Microsoft Dynamics CRM by double-clicking the shortcut on

your desktop.
2. To open the System Settings, click Settings, click Administration,
and then click System Settings.

3. In System Settings, you will accept all of the default values except
for the options displayed in the System Settings table in the Goal
Description. Update these exceptions in their corresponding tabs.
4. In the Administration menu, click Auto Numbering.
5. In Auto Numbering, update each option as it appears in the Auto
Numbering table in the Goal Description.
6. Test the new configurations.
a. Navigate to the Reports section. Verify that the report headings
appear in the correct order.
b. Navigate to the Contracts area, create a new contract and confirm
that the contract number assigned to it has the correct number of
digits requested.
Step by Step
1. To open the System Settings, click Settings, click Administration,
and then click System Settings.
2. In the General tab, update each field with the corresponding value
from the System Settings table in the Goal Description. Repeat this
for each tab identified in the table.
3. Click OK when you have updated all tabs.
4. On the Administration menu, click Auto-Numbering.
5. In the Contracts tab, update the prefix with the value from the table.
Repeat this for each prefix in each tab.
6. Click the Contracts tab again. Select the value in the Suffix length
field that matches the value in the table. Confirm the change. Click
the Cases, Quotes, Orders, and Invoices tab to verify they have the
same suffix length. Click OK.
7. Test the new configurations. From the Navigation Pane, click
Service, then click Contracts. Click New to create a new contract.
8. In the Template Explorer, select a Contract template option. Click
OK.
9. In the Header section of the Contract form, enter Test Contract as
the Contract Name. Select a customer, the contract start date and
contract end date. Select a Bill to Customer in the Billing
Information section, and a currency in the Pricing section. These are
all the business required fields.
10. Click Save. The Contract ID should display the system assigned
contract number. Confirm that the contract number assigned to it has
correct the number of characters requested.

Multilingual User Interface

In today's global economy, organizations have diverse work forces that have
varied language requirements. Organizations need software solutions which can
cater to multiple language user interfaces and corresponding online Help in a
single installation.
Microsoft Dynamics CRM addresses this need by offering a Multilingual User

Interface (MUI) capability that:
• Allows users to view the User Interface and Online Help of

Microsoft Dynamics CRM in different languages within the same
installation.
• Defines, stores, and views all Microsoft Dynamics CRM metadata in
multiple languages. In a MUI deployment, users can define their own
regional formats for date, time, currency, and numbers.
The language edition of Microsoft Dynamics CRM Server that is installed by the
organization is considered its base language. The organization can then install
MUI language packs for additional languages if they are requested by any of the
users. When one or more MUI language packs have been installed, each user can
select which language he or she wishes to use when accessing the application and
online Help files. This enables each user to personalize his or her Microsoft
Dynamics CRM experience.
MUI Language Packs

The language specific code and online Help for each MUI language is packaged
together in an MUI language pack. Each available language has its own MUI
pack that is installed as a separate stock keeping unit (SKU). Installation of an
MUI language pack in Microsoft Dynamics CRM is a two-step process:
1. For each language required by an organization, its corresponding

MUI language pack must be installed on the Microsoft CRM Servers
that service the organization.
2. The organization must enable each installed MUI language so that
the language is available for the users to select.
For each language, there are separate MUI packs for both the Microsoft CRM
Server and Microsoft Dynamics CRM for Microsoft Office Outlook. For on-
premise deployments, the system administrator can download the MUI language
packs that the organization needs from the Microsoft Downloads site. Each MUI
language pack will be a separate download that the System Administrator can
install on the Microsoft CRM server and online Help server. Similarly, Microsoft
Dynamics CRM for Outlook users can download the MUI language pack they
need from Microsoft Downloads and install the pack on their client computers.

EXAMPLE: Nancy and Inez are Contoso employees who want to see the
Microsoft Dynamics CRM User Interface (UI) in the language of their choice.
Nancy works in the Sales Department out of San Antonio, Texas, whereas Inez
works out of the Customer Service Center in Mexico City. Inez wants to access
Microsoft Dynamics CRM using a Spanish UI, whereas Nancy prefers the
English UI. Simon, the system implementer for Contoso, installs the Spanish
MUI pack so that the users who want to use the Spanish UI can do so.
An MUI language pack can be installed over any base language. For example,
you can have a German edition of Microsoft Dynamics CRM and then install a
French MUI pack within it. Or, you can have a French CRM base edition and
install a German MUI pack.
Installation of an MUI language pack has no effect on system functionality. In

the previous example, the user receives the same Microsoft Dynamics CRM
functionality if the French MUI pack is installed over a German CRM base
edition, or if using the German base edition.
When you upgrade from Microsoft Dynamics CRM 3.0 to 4.0, the language
edition of each version has to be the same. This will also be the base language of
the organization for the 4.0 installation. For example, if an organization is
upgrading their German version of Microsoft Dynamics CRM 3.0, the language
edition of Microsoft Dynamics CRM that they are installing must also be
German. German will also be identified as the implementation's base language.
Additional MUI language packs can then be installed following the upgrade.
Installing the MUI Language Packs

In Microsoft Dynamics CRM, organizations can install MUI language packs for
free. They can also install and enable as many MUI language packs that are
required to meet the needs of their users.
MUI language packs must be installed on all Microsoft CRM Servers and all
Online Help Servers in a Microsoft Dynamics CRM on-premise or partner-hosted
deployment. For each server on which the MUI installation process is performed,
the MUI Setup program performs the following checks to determine which server
roles are installed on the server (Note: Server roles are a new feature in Microsoft
Dynamics CRM. Because server roles are assigned during the Microsoft
Dynamics CRM Server Setup process, they are examined in the Installation
training):
• Microsoft CRM Servers have the AppServer role installed. On

these servers, the MUI Setup program installs the MUI binary files
for the selected language.

• Online Help Servers have the HelpServer role installed. On these

servers, the MUI Setup program installs the Help files for the
selected language.
• Servers that act as both the Microsoft CRM Server and the
Online Help Server contain both roles. On these servers, the MUI
Setup program installs both the MUI binary files and the Help files
for the selected language.
In on-premise and partner-hosted deployments, the system administrator must

install all the MUI language packs required by the organizations’ users. For each
MUI pack, the administrator has to download and install it on all servers that
have AppServer roles and HelpServer roles installed. If the administrator does
not install the same MUI packs on all servers that have AppServer roles and
HelpServer roles installed, users will experience a mixed language User Interface
and Online Help.
Currently, only French and English language packs are available for Microsoft
CRM Live deployments. No separate download or installation of MUI language
packs is necessary for users accessing Microsoft Dynamics CRM Live through
the web browser. However, Microsoft Dynamics CRM for Outlook users that
require either the French or English MUI language pack in a CRM Live
deployment must download and install the required client language pack.
Enabling the MUI Language Packs

Once each MUI language pack is installed in an on-premise or partner-hosted
deployment, the system administrator must enable the MUI pack for the
organization before its language becomes available for users to select. The
number of languages that can be enabled is restricted to the MUI language packs
installed on that local Microsoft CRM server.
The MUI language packs selected by the administrator are enabled for the whole
organization, which means:
• All MUI data for the selected languages are added for the
organization.
• The languages are available for users to select.
Enabling MUI language packs is a single transaction. If the transaction fails for
any reason, the entire transaction rolls back. This gives the Administrator an
opportunity to re-enable the packs at a later time. If a rollback occurs, all
database updates that occurred as a result of the transaction are rolled back.
However, the rollback process does not delete any reports or templates that were
added as part of the transaction.

The System Administrator must follow these steps to enable the MUI language
packs required by the organization:
1. Click Settings, click Administration, and then click Languages.

The Language Settings page is displayed. This lists the languages
that have been installed on that local application server and includes
the languages that have already been enabled for the organization, in
addition to the languages that have not yet been enabled.
• The MUI language packs that have been installed and have not
been enabled will appear with their respective check boxes
blank.
• The MUI language packs that have already been enabled will
appear with their respective check box checked.
2. Select the languages that you want to enable for the organization and
click Apply. All newly selected languages are enabled, all selected
language metadata are available for the organization, and the users
can select one of the enabled languages as their preferred language.
3. To deactivate a language, just clear the language's check box and
then click Apply.
Security Settings to Enable Languages

The ability to enable MUI languages is controlled by a new entity that was added
to the security roles. This entity is called Language Settings, and it appears under
the Business Management tab for each role. The permissions associated with
Language Settings are Organization or None (in other words, Yes or No).
FIGURE 4.14 SECURITY ROLE SETTING TO ENABLE LANGUAGES
Users can enable, de-activate, and re-enable a language if their security role has
Organization permission for this Language Settings entity. By default, only the
System Administrator and System Customizer roles have this permission set.

MUI and Microsoft Dynamics CRM for Outlook

Both the Microsoft Dynamics CRM Server and Microsoft Dynamics CRM for
Outlook have a base language. The base language of each is determined by the
language editions purchased by the organization. Because the Microsoft
Dynamics CRM Server and Microsoft Dynamics CRM for Outlook are separate
products, they can have different base languages within the same deployment. An
organization can purchase the German edition of the Microsoft Dynamics CRM
Server and the Spanish edition of Microsoft Dynamics CRM for Outlook.
And just as MUI language packs can be installed on the server, so too can
language packs be installed on Microsoft Dynamics CRM for Outlook. A
Microsoft Dynamics CRM for Outlook MUI language pack must be installed in
order to display the Microsoft Dynamics CRM UI in a language other than the
client's base language. If a Microsoft Dynamics CRM for Outlook MUI pack is
not installed, the Microsoft Dynamics CRM UI is displayed in the base language
of Microsoft Dynamics CRM for Outlook.
The language of the Microsoft Dynamics CRM for Outlook UI will be persisted
when the user goes offline. If the user changes the language and the regional
options in the Web client while Microsoft Dynamics CRM for Outlook is offline,
Microsoft Dynamics CRM for Outlook will not reflect the change until the user
goes back online.
Both Web browser users and Microsoft Dynamics CRM for Outlook users must
select the language of the user interface and Help files from the Web client's
Personal Options. Microsoft Dynamics CRM for Outlook users will then view
their Microsoft Dynamics CRM for Outlook user interface (UI) in their selected
language.
The following rules control which parts of the Microsoft Dynamics CRM for
Outlook UI are controlled by the MUI language selection:
• The standard Microsoft Office UI components (such as menus,

forms, and Outlook folders) that are not Microsoft Dynamics CRM-
related are displayed in the language selected in the Microsoft Office
Language Settings.
• All sections of the Microsoft Dynamics CRM for Outlook that are
related to Microsoft Dynamics CRM are displayed in the MUI
language the user selects in the Web client's Personal Options. This
includes:
– The Microsoft Dynamics CRM for Outlook ribbon
– Microsoft Dynamics CRM forms and error messages
– Outlook folders specific to Microsoft Dynamics CRM
– Microsoft Dynamics CRM Address Book Provider
– Offline Synchronization user interface

Selecting the MUI Language

Users who want to modify the language of the Microsoft Dynamics CRM user
interface for either the Web client or Microsoft Dynamics CRM for Outlook must
follow these steps to select the language of their choice:
1. Either click the Personalize Workplace link from the Microsoft

CRM Home Page, or locate Personal Options by clicking Tools,
and then clicking Options.
2. Select the Languages tab.
3. Select the language to be used when displaying the Microsoft
Dynamics CRM user interface and online Help files. The languages
are stored as a part of the User Settings table.
4. Click OK.
FIGURE 4.15 PERSONAL MUI LANGUAGE OPTIONS

Lab 4.2 - Installing MUI Language Packs

In this lab you will install several MUI language packs, enable the installed
packs, and then select a language for the CRM Administrator. You will verify the
language on the Web browser. You will then install the same MUI language pack
on the Microsoft Dynamics CRM for Office Outlook. Use the information in the
Goal Description to complete the lab.
Scenario
You are the Microsoft Dynamics CRM implementation consultant for Adventure
Works Cycle. Adventure Works recently opened Sales offices in Toronto and
Mexico City. The French Canadian sales representatives in the Toronto office
have asked to implement the French version of the Microsoft Dynamics CRM
user interface. Conversely, the sales representatives in the Mexico City office
have requested implementation of the Spanish version of the CRM UI.
Goal Description
As the implementation consultant, you have been asked to install and enable the
French and Spanish MUI language packs. The language packs have been
downloaded to the following locations on both the Microsoft Dynamics CRM
Server and the Microsoft Dynamics CRM for Microsoft Office Outlook:
• French = C:\Course
Materials\Customization\Ch.4\MUISetup_1036.msi
• Spanish = C:\Course
Materials\Customization\Ch.4\MUISetup_3082.msi
As part of your testing program, you will implement the French version for your
Web client and the Spanish version for your Microsoft Dynamics CRM for
Microsoft Office Outlook.
Note: Once you change the language of the Web client to French, change the
language back to English to complete the remainder of this training.
Challenge Yourself
1. Install the French and Spanish MUI language packs on the Microsoft
Dynamics CRM Server.
2. Enable the Languages Requested by the Users.
3. Select French as the New Language for Your Microsoft Dynamics
CRM Web browser. Test the Web client to verify that Microsoft
Dynamics CRM appears in French. Change the language back to
English.

4. Using the Ready Client VPC image, install the Spanish MUI
language pack on the Microsoft Dynamics CRM for Microsoft
Office Outlook.
5. Using the Ready Server VPC image, select Spanish as the new
language for your Microsoft Dynamics CRM for Microsoft Office
Outlook.
6. Using the Ready Client VPC image, test to verify that the Microsoft
Dynamics CRM for Office Outlook appears in Spanish.
Need a Little Help?

Step 1 - Install the French and Spanish MUI language packs on the Microsoft
Dynamics CRM Server
The MUI language packs have been downloaded to the file location specified in
1. Using Windows Explorer, navigate to the folder specified in the Goal

Description.
2. To install the French language pack, double-click the
MUISetup_1036.msi file.
3. When finished, repeat these steps for the Spanish language pack,
MUISetup_3082.msi.
Step 2 - Enable the Languages Requested by the Users
Installed MUI language packs must be enabled before they can be selected by
end-users.
1. Navigate to Settings, Administration, and then Languages.

2. Enable for French and Spanish languages.
Step 3 - Select French as the New Language for Your Microsoft Dynamics
CRM Web browser
Once the MUI languages have been enabled, you can select the language for your
Microsoft Dynamics CRM Web browser user interface.
1. Navigate to the Personal Options in the Tools menus.

2. In the Languages tab, select French for both the User Interface and
online Help.
3. Close the application and re-open it to verify that it appears in
French.
4. Repeat the steps above and select English as the language for both
the User Interface and online Help.

Step 4 - Install the Spanish MUI language pack on the Microsoft Dynamics
CRM for Microsoft Office Outlook
The Spanish MUI language pack has been downloaded to the file location
specified in the Goal Description.
1. Start the VPC image of the Microsoft Dynamics CRM Ready Client.
2. Log on as the crmadmin; password = Pa$$w0rd.
3. Using Windows Explorer, navigate to the folder specified in the Goal
Description.
4. Install the Spanish language pack.
Step 5 - Select Spanish as the New Language for Your Microsoft Dynamics
Microsoft Dynamics CRM for Office Outlook.
1. On the Ready Client image, open Microsoft Office Outlook.

2. Start Microsoft Dynamics CRM and note that the UI is the base
language of English.
3. In the Ready Server image, change the language in the Personal
Options to Spanish.
4. On the Ready Client VPC image, close Microsoft Office Outlook
and then re-open it. Microsoft Dynamics CRM should appear in
Spanish.
5. Close the Ready Client image.
Step by Step
Step 1 - Install the French and Spanish MUI language packs on the Microsoft
Dynamics CRM Server
The MUI language packs have been downloaded to the file location specified in
1. Right click on the Start menu button and click Explore to open
Windows Explorer. Navigate to the folder specified in the Goal
Description.
2. To install the French language pack, double-click the

3. Select the I accept the terms in the License Agreement option and
click Install.
4. Click Finish when complete.
5. Repeat these steps for the Spanish language pack,
MUISetup_3082.msi.
Step 2 - Enable the Languages Requested by the Users
Installed MUI language packs must be enabled before they can be selected by
end-users.

then click Languages.
2. Select the French and Spanish check boxes.
3. Click Apply.
Step 3 - Select French as the New Language for Your Microsoft Dynamics
CRM Web browser
Microsoft Dynamics CRM Web browser user interface.
1. Click Tools on the Microsoft Dynamics CRM menu.

2. Click Options.
4. Select French for both the User Interface and online Help.
5. Click OK.
6. Close to application and then re-open it. The application should
appear in French.
7. Repeat the steps above and select English as the language for both
the User Interface and online Help.
8. Close the application and then re-open it. The application should
appear in English.
Step 4 - Install the Spanish MUI language pack on the Microsoft Dynamics
The Spanish MUI language pack has been downloaded to the file location
1. Start the VPC image of the Microsoft Dynamics CRM Ready Client.
2. Log on as the crmadmin; password = Pa$$w0rd.
3. Right click on the Start menu button and click Explore to open
Windows Explorer. Navigate to the folder specified in the Goal
Description.

4. To install the Spanish language pack, double-click the

5. Select the I accept the terms in the License Agreement option and
click Install.
6. Click Finish when complete.
Step 5 - Select Spanish as the New Language for Your Microsoft Dynamics
Microsoft Dynamics CRM for Office Outlook.
1. On the Ready Client image, open Microsoft Office Outlook.

2. Start Microsoft Dynamics CRM and note that the UI is the base
language of English.
3. In the Ready Server image, click Tools on the Microsoft Dynamics
CRM menu.
4. Click Options.
6. Select Spanish for both the User Interface and online Help.
7. Click OK.
8. On the Ready Client VPC image, close Microsoft Office Outlook
and then re-open it. Microsoft Dynamics CRM should appear in
Spanish.
9. Close the Ready Client image.

Multicurrency
Today more and more businesses are performing financial transactions across
borders and in multiple currencies. The figure titled Currency Examples displays
just a portion of the total currencies used throughout the world. In this
environment, organizations typically transact in multiple currencies but book all
financial transactions in a single base currency - a currency in which the
organization reports its balance sheet, profit, and loss statement, and other
financial reports.
FIGURE 4.16 CURRENCY EXAMPLES
Microsoft Dynamics CRM addresses this global financial requirement by

supporting a true multicurrency model where an organization can enter any
Microsoft Dynamics CRM financial transaction in multiple currencies. This
means financial transactions such as opportunities, quotes, orders and invoices,
as well as attributes such as Product Price Lists can be transacted in multiple
currencies.
Using the multicurrency model in Microsoft Dynamics CRM starts with:
• Defining a base currency for the organization

• Defining transaction currencies and their corresponding exchange
rates that associate the transaction currencies with the base currency
• Providing a currency choice to the user whenever a financial
transaction occurs
In Microsoft Dynamics CRM, these features are expanded into the following
design goals, enabling:
• Users to select the currency in which they want to define and transact
an Opportunity, Quote, Order, and Invoice.
• All financial transactions to capture the value of the transaction in
both the base currency and transaction currency.
• System administrators to define transaction currencies and define an
exchange rate to associate the base currency with the transaction
currency.

• All currency exchange rates to be defined in relation to the base

currency.
• Product price lists to be defined for a currency.
Defining Currencies for an Organization

Every organization must define its base currency, regardless of whether the
organization uses a single currency or multiple currencies. Organizations define
their base currency during the Microsoft Dynamics CRM Server Setup process
when the installation wizard prompts the administrator for the base currency
value.
The base currency is one in which the organization reports its financial
statements. For organizations utilizing multiple currencies, the base currency is
also the currency in which all other currencies are quoted.
IMPORTANT: The base currency cannot be changed once it is defined during

the Server Setup process.
Apart from defining the base currency, the transaction currencies are defined as
part of the System Settings. Each transaction currency has the following
properties:
• Transaction currencies are related to the base currency with the

definition of a currency exchange rate.
• As soon as the base currency and the transaction currencies are
defined, the users can carry financial transactions in both the base
currency and transaction currencies.
The exchange rate for a currency is always defined as the value of the transaction
currency for a given base currency. The figure titled Transaction Currency List
displays several currency exchange rates when the base currency is Unites States
dollars (USD).
FIGURE 4.17 TRANSACTION CURRENCY LIST

NOTE: This is a sample currency table and has no relevance to the actual
exchange rates in which these currencies are traded for each U.S. dollar.
This view displays the currency code, currency name, currency symbol, and
exchange rate for each transaction currency. You can create a new transaction
currency by clicking the New link. You must enter the following information
when creating a new currency:
• Currency code. Select the currency code from the list of ISO
approved currencies.
• Currency symbol. As soon as you select the currency code, the
system automatically populates the currency symbol and currency
name for the selected code. However, you do have the option of
changing the symbol and currency name if it is necessary
• Exchange rate. Enter the exchange rate per the base currency
Defining Exchange Rates

In addition to manually adding currencies and exchange rates, you can also
import currency exchange rates from a delimited Comma Separated Values
(CSV) file. An example of an exchange rate file in csv format is displayed in the
figure titled Sample Exchange Rate File.
FIGURE 4.18 SAMPLE EXCHANGE RATE FILE
When a transaction currency is created, it can later be deactivated. A deactivated

currency remains in the system for historical purposes; however, it cannot be
assigned to any new records that are created (such as an order or invoice) because
the deactivated currency no longer appears in the currency lookup when the user
selects a currency for the record.

Any existing record that has been previously assigned a currency before it was
deactivated can still use the currency after it is deactivated. For example, a quote
that was created with a currency which was subsequently deactivated can still be
converted into an order, and the order can still be processed using the deactivated
currency.
A transaction currency can also be deleted if it has not been linked to any other
record in the system. The base currency defined for an organization can neither
be deactivated nor deleted.
Updating Records with the Latest Exchange Rate

Once a transaction currency is created, it can then be assigned as the currency on
records related to quotes, orders, invoices, and prices lists. When this occurs, the
system converts the value of each money field on the record to the base currency
using the exchange rate assigned to the transaction currency.
Because exchange rates change frequently, Microsoft Dynamics CRM uses the
following criteria to determine when to apply the latest exchange rate to the
money fields on a record:
• When the record is created

• When any money field on the entity is updated
• When the state of the record changes
NOTE: A change to a quantity on a record does not force a recalculation of its

money fields based on the latest exchange rate.
When the exchange rate is updated for a transaction currency, the existing
records assigned that currency are not updated. However, if a money field on one
of these records is later updated or the state of the record changes, then the
system retrieves the latest exchange rate for the currency and recalculates the
record's money fields based on the latest rate.
When you view a record, the monetary values displayed are based on the
exchange rate that was last assigned to the record. This rate may or may not
reflect the latest exchange rate.
EXAMPLE: At the time an order is created, the value of its money fields are
calculated based on the assigned currency's exchange rate that is in effect at
that time. If the order is viewed ten days later, the value of the money fields still
reflects the exchange rate that was applied when the order was created, even
though the exchange rate assigned to the currency may have been updated
several times between when the order was created and when it was viewed.

Security Settings for Maintaining Currencies

There is an explicit currency permission that must be attached to a security role
in order to define the transaction currencies and their corresponding exchange
rates. The figure titled Security Role Privileges for Currency Management
displays the separate line item for Currency as a part of the Business
Management tab.
FIGURE 4.19 SECURITY ROLE PRIVILEGES FOR CURRENCY

MANAGEMENT
The privileges available in security roles for the Currency entity include the
following:
• Create. Ability to create transaction currency and exchange rate in

relation to the base currency.
• Read. Ability to read the transaction currency record.
• Write. Ability to modify exchange rates associated with transaction
currencies.
• Delete. Ability to delete a transaction currency record.
• Append. Ability to append a currency to another entity (for example,
assigning a default currency to an account).
• Append To. Ability to append other entities to a currency.
By default, the System Administrator, Sales Manager, and the Vice President of
Sales roles have these permissions set for currency management. Users who are
assigned these roles will be able to define transaction currencies and their
associated exchange rates in relation to the base currency.
Defining Currency-Based Price Lists

As soon as the transaction currencies have been defined, price lists can be
defined for a currency. An organization can have multiple price lists that are also
typically defined for a target geographical market in the local currency.

EXAMPLE: Fabrikam does business in the United States and Mexico and has
two retail price lists, one for the United States in U.S. dollars (USD) and the
other for Mexico in Mexican peso (MXN). Kevin, the Sales Manager who
manages the price lists for Fabrikam, creates two retail price lists and
associates the corresponding currency to each list.
Associating a Currency with Accounts

Users can define a default currency for each account. An account's currency is
assigned as the currency for any opportunity, quote, order, or invoice that is
created for the account. However, the user can override this by assigning a
different currency to the opportunity, quote, order, or invoice.
EXAMPLE: Fabrikam has dealings with Northwind Traders, a Tokyo-based

company. Fabrikam identifies Japanese yen as the base currency for Northwind
Traders’ Microsoft CRM account and it uses Japanese yen when it creates
opportunities for Northwind's Tokyo-based office. However, Fabrikam must
override Northwind Traders’ base currency when it creates opportunities for
Northwind's U.S.-based offices. In these instances, Fabrikam creates the
opportunities in U.S. dollars (USD) instead of Japanese yen.
There is one caveat related to using default account currencies. An account's

default currency will only be assigned to an opportunity, quote, order, or invoice
if the record is created from within the Account entity page. In other words, you
must open the specific account, select the desired financial entity - either an
opportunity, quote, order, or invoice - and then create a new record for that
financial entity. When the entity's form is opened, the account's default currency
is prefilled in the currency field on the form.
Alternatively, if you create a financial entity directly from the entity form, the
account's default currency will not be prefilled on the form. For example, if you
navigate directly to Orders, create a new order, and select an account for the
order, the account's default currency will not be prefilled on the order. Instead,
the organization's base currency will be displayed on the Order form.
Creating Quotes in Multiple Currencies

An organization can create quotes for its customers who operate in different
currencies. Every quote must be assigned a currency. By doing this, all products
(existing or write-in) entered on the quote will have their prices defined in the
quote level currency.

In Microsoft Dynamics CRM, an organization can create new quotes or convert

opportunities to quotes. In each case, the currency in which the quote is defined
must be specified. This can occur in either of two ways:
• Any quote created from an opportunity inherits the opportunity

transaction currency and the user cannot modify the currency.
• If a user creates a new quote for an account, the default currency on
the account is assigned to the quote. However, the user can change it
to any transaction currency for that particular quote.
When associating a price list to a quote, the user can only associate a price list
whose currency matches the currency defined for the quote. Any write-in
products entered on the quote are priced in the currency of the quote.
Creating Orders and Invoices in Multiple Currencies

The same logic that applies to quotes and currencies also applies to sales orders,
including:
• Every sales order must be assigned a currency.

• When a quote is converted to an order, the order inherits the currency
defined on the quote and the user cannot modify this currency.
• Only those price lists whose currency matches the order's currency
can be associated with the order.
• The price of write-in products is in the currency of the order.
Similar logic also applies to invoices, including:
• Every invoice must be assigned a currency.

• When an order is converted to an invoice, the invoice inherits the
currency defined on the order and the user cannot modify this
currency.
• Only those price lists whose currency matches the invoice's currency
can be associated with the invoice.
• The price of write-in products is in the currency of the invoice.
Displaying Currencies
When you are displaying a currency in the system, Microsoft Dynamics CRM
lets you display the currency using either its currency symbol or code. This
option is set in the System Settings area, which can be accessed by clicking
Settings, then Administration, and then System Settings. The system
administrator can indicate if the organization wants to display the currency
symbol or the International Organization for Standardization (ISO) currency code
as part of any currency value.

EXAMPLE: If the currency is euro, you can display the currency symbol € or
the ISO currency code EUR. If the currency is United States dollars, the
currency symbol is $ and the ISO currency code is USD.
FIGURE 4.20 CURRENCY OPTION IN SYSTEM SETTINGS
Importing Currency Exchange Rates

Transaction currencies and their exchange rates can be either manually entered or
imported into the system. Because currency exchange rates frequently change,
importing enables organizations to update rates much more quickly than through
manual data entry.
The following rules control how transaction currencies are processed when
importing a CSV delimited exchange rate file into Microsoft Dynamics CRM:
• Exchange rates are updated based on the ISO currency code.

• If a record in the CSV file is for a transaction currency that is not
defined in Microsoft Dynamics CRM, the import process adds the
currency to the organization's list of available currencies, and then
assigns it the imported exchange rate.
• If the currency code exists in Microsoft Dynamics CRM, the import
process updates only the exchange rate.
• The import file must be eight bit Unicode Transformation Format
(UTF-8) encoded.

Perform the following steps to import a file of currency exchange rates:
1. On the Microsoft Dynamics CRM menu bar, click Tools. In the drop
down list, click Import Data.
2. On the Select the File to Import page, click Browse to select the file
to import.
3. Navigate to the file location specified in the Goal Description. Select
the file and click Open. The location of the file should be displayed
in the Data file field. Click Next.
4. On the Select the Record Type and Map page, click the drop down
arrow for the Record Type field and select Currency from the list of
record types. The Data map field is prefilled with Automatic. Click
Next.
5. On the Select Options page, select the option to Import duplicate
records. Because exchange rate files are typically imported on a
daily basis, this option allows you to update the rates for existing
currencies each time you import. Click Next.
6. On the Confirm Import Details page, verify that the file name is
correct. You do not need e-mail notification when the import is
complete, so leave this option unchecked. Click Import.
7. From the Navigation Pane, click Settings, and then click System
Jobs.
8. To quickly access the latest jobs that were processed, click on the
Started On column heading to sort the jobs in descending date and
time sequence.
9. The Import process generates several system jobs (Import File Parse,
Transform Parse Data, and Import). For a successful import, each of
these jobs must have a “Succeeded” Status Reason.
10. Verify that the currencies were created in the system. From the
Navigation Pane, click Settings, click Business Management, and
then click Currencies.
User-Defined Default Currency

Although an organization defines it base currency, each user can define his or her
default currency that overrides the base currency. When a new Opportunity,
Quote, Order, or Invoice is created from within an Account entity, the application
uses the following rules to determine the currency to display in the entity form:
1. The account's default currency is displayed if one has been defined.

2. If a default currency is not defined for the account, the user's default
currency is displayed if one has been defined.
3. If a default currency is not defined for the user, the base currency is
displayed.
Letting each user define his or her default currency eliminates the need for the
user to repeatedly enter a currency other than the base currency.

EXAMPLE: Fabrikam's base currency is U.S. dollars. However, Fabrikam's

Canadian sales rep, Mary, creates transactions in Canadian dollars for most
her customers. In order to simplify the data entry when she creates financial
transactions, Mary has updated her personal settings by defining Canadian
dollars as her default user currency. When Mary creates an Opportunity,
Quote, Order, or Invoice from an account, the system defaults the currency to
Canadian dollars if the account does not have a currency defined. Although
Mary is free to change the currency at will, in most of her cases she operates in
Canadian dollars. Having the currency default to Mary's user currency reduces
the need for additional data entry.
Perform the following steps to update the user's currency:
1. In Microsoft Dynamics CRM, click Tools, and then click Options.

2. In the General tab, select the value for the User's Default Currency.
Defining Currencies for Products, Price Lists, and

Discount Lists
Prices in Microsoft Dynamics CRM can be defined at the following two levels:
• At the product level, where the user can define the list price, standard
cost, and the current cost.
• At the price list item level, where the user can have different prices
for the products in the price list.
Both the price at the product level and the price list level are associated with a
currency. The option that you choose for the Pricing Method on the Price List
Item controls the currency you can use.
• If you choose a Pricing method of “Currency Amount”, you can

select a price list with any currency, regardless of the default
currency defined on the product.
• If you choose a Pricing method other than “Currency Amount”, you
can only select a price list whose currency matches the default
currency defined on the product. This is controlled by the price list
lookup field because it only displays price lists whose currency
matches the product's currency.
IMPORTANT: When you create a new product, the product currency is an

optional field. However, defining the product currency is mandatory if the list
price, standard cost, and current cost are defined for the product.

For price lists, the currency is defined at the header level. This indicates that all
products and price list items associated with the price list will have their prices
defined in one single currency. The following rules control how currencies are
used at the price list header level:
• The currency cannot be modified once the price list is defined.

• All prices of products associated with a price list are defined in the
price list currency.
• If the pricing method is Currency Amount, it is assumed to be in the
price list currency.
Discount lists can also be defined in multiple currencies. However, this only
applies to discount lists where the type is “Amount.” The currency option is
disabled for discount lists where the type is “Percentage.” For discount lists, the
currency is defined at the discount list header level. In turn, any discount line
item associated with the discount list is defined in the currency from the header
level.

Lab 4.3 - Importing Currency Exchange Rates

In this lab you import a currency exchange rate file, verify the exchange rates
were imported successfully, and then manually add an additional currency. You
will create sales orders in three ways - you will first create the order from within
an account, and then from outside an account. You will then create a second
order outside an account to verify the user's default currency. Creating these sales
orders allows you to verify what happens with the currency in each situation. Use
the information in the Goal Description to complete the lab.
Scenario
You are the Microsoft Dynamics CRM implementation consultant for Adventure
Works Cycle. Because they have recently opened sales offices in several
countries, it is essential that Adventure Works implement the multi-currency
capabilities in Microsoft Dynamics CRM.
Adventure Works’ project planning team has agreed to perform a pilot project
involving the application's multi-currency capabilities. They have asked you to
import a small exchange rate table and test the default currency functionality.
Goal Description
The currency exchange rate file that you will import is stored in the following
location:
C:\Class Materials\Customization\Ch.4\CurrenciesToImport.csv
Once you have imported the exchange rate file, you note that it did not include
the Polish Zloty. Because of Adventure Works’ expansion into Europe, you
decide to add this currency (Poland Zloty) into the system with an exchange rate
of 5.6452.
Your next goal is to test the application's currency functionality by performing

the following tasks:
• Set the default currency for the Basic Bike Company to the Euro.
• From within the Basic Bike Company, create a new sales order with
a Name = test default account currency. Note how the currency
defaults to the account's currency. When assigning a price list, note
that no price lists exist based on the Euro. Add a new price list with
the name = Retail-Euro, and set the currency = Euro. Update the
Write-in Product line item with the following information:
– Product Description = seat
– Price per unit = 50.00
– Quantity = 10

• Create a sales order from the Order entity with a name = test base
currency. Note how the currency defaults to the base currency. Save
the order, and then add a write-in product to the order. Select the
Retail price list, which is defined in the base currency of US Dollars.
Update the Write-in Product line item with the following
information:
– Price per unit = 50
– Quantity = 10
• Navigate to the Basic Bike Company account and display the orders
for the account. Note the difference between the two orders.
• Change the user's default currency to the Mexican Peso.
• From within the Basic Bike Company, create a new sales order with
a Name = test user currency. Note how the currency defaults to the
user's currency and not the account's currency. Save the order, and
then add a write-in product to the order. When assigning a price list,
note that no price lists exist based on the Mexican Peso. Add a new
price list with the name = Retail-Mexican Peso, and set the currency
= Mexican Peso. Update the Write-in Product line item with the
following information:
– Price per unit = 50.00
– Quantity = 10
• Navigate to the Basic Bike Company account and display the orders
for the account. Note the difference between the three orders.
Challenge Yourself
Using the information defined in the Goal Description, perform the following
steps to complete this lab:
1. Import the currency exchange rate file specified in the Goal

Description.
2. Create an Currency record for the Poland Zloty.
3. Test the default Account currency logic by changing the default
currency for the Basic Bike Company to euro and creating an order
within the Basic Bike Company account.
4. Test the base currency by creating an order for the Basic Bike
Company, but not from within the account.
5. Change the user's default currency to Mexican Peso.
6. Test default user's currency by creating an order for the Basic Bike
Company, but not from within the account.
7. From within the Basic Bike Company account, view all orders to
compare the currency differences between the three orders.

Need a Little Help?

Step 1 - Import the Currency Exchange Rate File
1. Select Import Data from the Tools menu.

2. Select the file at the location specified in the Goal Description.
3. The record type you are importing is Currency.
4. Because exchange rate files are typically imported on a daily basis,
allow duplicate records to be imported.
5. Verify the import was successful by examining the System Jobs.
6. Verify that the currencies were created in the system by navigating to
Currencies within the Settings >> Business Management menu. The
exchange rate file that you imported had 13 currency records. The
Active Currencies view should display these 13 currencies and their
corresponding exchange rates.
Step 2 - Add an Additional Currency and Exchange Rate
You decide to add the Poland Zloty to the list of transaction currencies. The latest
exchange rate for the Zloty is 5.6452.
1. Navigate to Currencies and add a new transaction currency with a

corresponding exchange rate.
2. In the Currency Code field on the Currency form, select the Poland
Zloty.
3. Set the Zloty's exchange rate to 5.6452.
Step 3 - Test Default Account Currency
1. Navigate to Accounts and open the Basic Bike Company account.

2. The Currency field currently displays US Dollar, which is Adventure
Works’ base currency. However, for this account you decide to
change the base currency to the Euro. Select Euro as the value of the
Currency field.
3. Save the account, which enables the Details pane. Select Orders and
add a new order for this account. Because the order is being created
from within the account, note how Basic Bike Company is prefilled
in the Customer field and that its default currency of Euro is prefilled
in the order's Currency field.
4. Enter test default account currency in the Name field.
5. Because no price list exists for the Euro, create a new Euro price list
and assign it to the order. On the Order form, click Save (not Save
and Close).

6. Add a Write-In Product with the following information:

a. Product Description = seat
b. Price per unit = 50.00
c. Quantity = 10
7. Save the order.

8. This displays the list of Orders for this account. NOTE: If the Total
Amount and Total Amount (Base) are zero for the order you created,
click the Refresh icon (on the right side of the column heading row)
to refresh the view and display the actual order amounts.
Step 4 - Test Base Currency
The prior step created an order from within an account. This displayed how the
account's currency defaulted to the order's currency. However, when an order is
created on its own and not from within an account, the order's currency defaults
first to the user's default currency, and then to the organization's base currency.
At this point, you have not assigned a base currency to your user account, so the
order's currency must default to the base currency.
1. Navigate to Sales and select Orders.

2. Add a new order with a name = test base currency. Note how the
currency defaults to the base currency of US Dollar.
3. Select Basic Bike Company as the customer. Note how the
Currency field does not change to Euro, which is the currency
defined for the Basic Bike Company. Because you are not creating
the order from within the account, the order's currency does not
default to the account's currency.
4. Select Retail as the price list. This is one of two existing price lists
with a currency set to US Dollars.
5. Save the Order.
6. Add a write in product with the following information:
c. Quantity = 10
7. Save and close the order.

8. Navigate to the account and view all orders for the account. This
displays the prior order based on the account's default currency, and
this order that displays the organization's base currency.

Step 5 - Change the User's Default Currency
You now want to test how the currency defaults on an order when the user
assigns a default currency on his or her Personal Options. Perform the following
steps to change the user's default currency to Mexican Peso.
1. On the Tools menu, select Options.

2. Set your default user currency code to Mexican Peso.
Step 6 - Test Default User Currency
Repeat the same steps that you performed in Step 4 when you added an order
from outside the account.
1. Create a new order with a name = test user currency. Note how the
currency defaults to the Mexican Peso currency from your personal
settings.
2. Select Basic Bike Company as the customer. Note how the
Currency field does not change to Euro, which is the currency
defined for the Basic Bike Company. Because you are not creating
the order from within the account, the order's currency does not
default to the account's currency.
3. Because no price list exists for the Mexican Peso, create a new
Mexican Peso price list and assign it to the order.
4. Add a Write-In Product with the following information:
• Product Description = seat
• Price per unit = 50.00
• Quantity = 10
5. Save the order.

6. Open the Basic Bike Company account and view its orders. The
three orders that you created for the account are displayed. Note the
difference between the orders.
Step by Step
Step 1 - Import the Currency Exchange Rate File
1. On the Microsoft Dynamics CRM menu bar, click Tools. In the drop
down list, click Import Data.
2. On the Select the File to Import page, click Browse to select the file
to import.
3. Navigate to the file location specified in the Goal Description. Select
the file and click Open. The location of the file should be displayed
in the Data file field. Click Next.

4. On the Select the Record Type and Map page, click the drop down
arrow for the Record Type field and select Currency from the list of
record types. The Data map field is prefilled with Automatic. Click
Next.
5. On the Select Options page, select the option to Import duplicate
records. Because exchange rate files are typically imported on a
daily basis, this option allows you to update the rates for existing
currencies each time you import. Click Next.
6. On the Confirm Import Details page, verify that the file name is
correct. You do not need e-mail notification when the import is
complete, so leave this option unchecked. Click Import.
7. From the Navigation Pane, click Settings, and then click System
Jobs.
8. Click on the Started On column heading to sort the jobs in
descending date and time sequence.
9. The Import process generates several system jobs (Import File Parse,
Transform Parse Data, and Import), each of which has a System Job
Name of “CurrenciesToImport.csv(Currency)”. For a successful
import, each of these jobs must have a “Succeeded” Status Reason.
10. Verify that the currencies were created in the system. From the
Navigation Pane, click Settings, click Business Management, and
then click Currencies. The exchange rate file that you imported had
13 currency records. The Active Currencies view should display
these 13 currencies and their corresponding exchange rates.
Step 2 - Add an Additional Currency and Exchange Rate
You decide to add the Poland Zloty to the list of transaction currencies. The latest
exchange rate for the Zloty is 5.6452.
1. If you closed the Currencies window at the end of the prior step, then
click Settings, click Business Management, and then click
Currencies.
2. Click New on the Action toolbar.
3. On the Currency form, click the lookup icon for the Currency Code
field. From the list of ISO Currency Codes, select the Poland Zloty.
Click OK.
4. In the Currency Conversion field, enter an exchange rate of 5.6452.

Step 3 - Test Default Account Currency
2. Double-click on the Basic Bike Company to open the account
record.
3. The Currency field currently displays US Dollar, which is Adventure
Works’ base currency. However, for this account you decide to
change the base currency to the Euro. Click on the lookup icon for
the Currency field, and in the list of currencies, select Euro and click
OK.
4. Click Save (not Save and Close).
5. On the Details pane, click Orders.
6. On the Orders view, click New Order on the Action toolbar. This
opens the Order form. Because the order is being created from within
the account, note how Basic Bike Company is prefilled in the
Customer field and that its default currency of Euro is prefilled in the
order's Currency field.
7. Enter test default account currency in the Name field.
8. Click on the lookup icon for the Price List field. Because the order's
Currency is set to Euro, the system searches for price lists with a
Currency of Euro. Since no Euro price lists exist, the search returns
no records.
9. For this test, we will create a Euro price list. Click New on the Look
Up Records dialog box.
10. In the Price List form, enter Retail - Euro as the Name, and click the
lookup icon for the Currency field. Select Euro in the Look Up
Records dialog box and click OK. Euro is now displayed as the Price
List Currency.
12. The Retail - Euro price list that you just created is now selected in
the Look Up Records window for the order's price list. Click OK.
13. On the Order form, click Save (not Save and Close).
14. Click Write-In Products in the Details pane.
15. Click New Order Product. On the New Order Product form, enter
the following information:
c. Quantity = 10
16. Click Save and Close on the New Order Product form.
17. Click Save and Close on the Write-In Products page.
18. This displays the list of Orders for this account. NOTE: If the Total
Amount and Total Amount (Base) are zero for the order you created,
click the Refresh icon (on the right side of the column heading row)
to refresh the view and display the actual order amounts.

Step 4 - Test Base Currency
The prior step created an order from within an account. This displayed how the
account's currency defaulted to the order's currency. However, when an order is
created on its own and not from within an account, the order's currency defaults
first to the user's default currency, and then to the organization's base currency.
At this point, you have not assigned a base currency to your user account, so the
order's currency must default to the base currency.
1. From the Navigation Pane, click Sales, and then click Orders.
3. Create a sales order with a name = test base currency. Note how the
currency defaults to the base currency of US Dollar.
4. Click on the lookup icon for the Customer field. Select Basic Bike
Company and click OK. Note how the Currency field does not
change to Euro, which is the currency defined for the Basic Bike
Company. Because you are not creating the order from within the
account, the order's currency does not default to the account's
currency.
5. Click on the lookup icon for the Price List field. Because the order's
Currency is set to US Dollars, the system displays the two existing
price lists with a currency of US Dollar. Select Retail and click OK.
c. Quantity = 10

12. Double-click on the Basic Bike Company account to open it.
13. Click on Orders in the Details pane. Both orders that you created for
the account are displayed. Note the difference between the two
orders.

Step 5 - Change the User's Default Currency
You now want to test how the currency defaults on an order when the user
assigns a default currency on his or her Personal Options. Perform the following
steps to change the user's default currency to Mexican Peso.
1. Click Tools on the Microsoft Dynamics CRM menu bar.

2. Click Options.
3. On the General tab, click the lookup icon for the Currency field.
Select Mexican Peso from the currency list and click OK.
4. Click OK on the Set Personal Options page.
Step 6 - Test Default User Currency
Repeat the same steps that you performed in Step 4 when you added an order
from outside the account.
1. From the Navigation Pane, click Sales, and then click Orders.
3. Create a sales order with a name = test user currency. Note how the
currency defaults to the Mexican Peso currency from your personal
settings.
4. Click on the lookup icon for the Customer field. Select Basic Bike
Company and click OK. Note how the Currency field does not
change to Euro, which is the currency defined for the Basic Bike
Company. Because you are not creating the order from within the
account, the order's currency does not default to the account's
currency.
5. Because the order's Currency is set to Mexican Peso, the system
searches for price lists with a Currency of Mexican Peso. Since no
such price lists exist, the search returns no records.
6. For this test, we will create a Mexican Peso price list. Click New on
the Look Up Records dialog box.
7. In the Price List form, enter Retail - Mexican Peso in the Name.
Note how the currency on the price list defaults to your personal
currency of Mexican Peso.
9. The Retail - Mexican Peso price list that you just created is now
selected in the Look Up Records window for the order's price list.
Click OK.

c. Quantity = 10
16. Double-click on the Basic Bike Company account to open it.
17. Click on Orders in the Details pane. The three orders that you
created for the account are displayed. Note the difference between
the orders.

Summary
This training examined the organization settings that control various system-wide
functionalities. These settings were divided into three functional areas:
• System Settings
• Auto Numbering
• Fiscal Year Settings
In addition, you reviewed how an organization can install and deploy

Multilingual User Interface (MUI) language packs for their users. This allows
users to view the Microsoft Dynamics CRM User Interface and Online Help in
different languages within the same installation.
Finally, this training examined how Microsoft Dynamics CRM supports a true
multicurrency model where an organization can enter financial transactions in
multiple currencies.

Test Your Knowledge

Test your knowledge with the following questions:
1. System Settings are personal settings that are configurable on a per-user

basis.
( ) True
( ) False
2. What is the stipulation that accompanies a change to the Name Format

option?
3. What is the purpose for creating Fiscal Year Settings?
4. The suffix field in the Auto-Numbering settings applies to Contracts, Cases,

Quotes, Orders, Invoices, and Campaigns. Each of these objects can have its
own custom suffix length.
( ) True
( ) False

5. For a given user, any e-mails where that user is a recipient, sender, or owner
on an e-mail that has been _____________ into Microsoft Dynamics CRM
will be tagged.
6. In the Customizations tab under System Settings, what is the purpose of the
schema prefix parameter?


chapter:
1.
2.
3.

Solutions
Test Your Knowledge
1. System Settings are personal settings that are configurable on a per-user
basis.
( ) True
(•) False
2. What is the stipulation that accompanies a change to the Name Format

option?
MODEL ANSWER - Changing the Name Format after users have already
been added does not change the way any existing names are displayed. A
change to the Name Format only changes the way in which full names are
displayed for new entries that are created from that point forward.
3. What is the purpose for creating Fiscal Year Settings?
MODEL ANSWER - Fiscal year settings must be defined in Microsoft
Dynamics CRM to enable Sales Quota maintenance and reporting.
4. The suffix field in the Auto-Numbering settings applies to Contracts, Cases,

Quotes, Orders, Invoices, and Campaigns. Each of these objects can have its
own custom suffix length.
( ) True
(•) False
5. For a given user, any e-mails where that user is a recipient, sender, or owner
on an e-mail that has been _____________ into Microsoft Dynamics CRM
will be tagged.
MODEL ANSWER - promoted
6. In the Customizations tab under System Settings, what is the purpose of the
schema prefix parameter?
MODEL ANSWER - The prefix is appended to the names of custom entities
and attributes which the customer creates in Microsoft Dynamics CRM.


Chapter 5: Customizing Microsoft Dynamics CRM Overview
CHAPTER 5: CUSTOMIZING MICROSOFT

DYNAMICS CRM OVERVIEW
Objectives
The objectives are:
• Recognize the importance of defining and using an effective

implementation methodology as you develop customizations
• Recognize the types of customizations that can be made based on the
default Microsoft Dynamics CRM security roles
• Identify how the Microsoft Dynamics CRM architecture influences
how and where you customize Microsoft Dynamics CRM
• Recognize some of the ways that Microsoft Dynamics CRM can be
customized
• Identify how Microsoft Dynamics CRM's architecture enables
organizations to safely upgrade their customizations
• Identify which customizations require publishing and the various
ways to publish your customizations
• Discover how you can re-use customizations by exporting
customizations made in one deployment and importing them into
another
Introduction
The Microsoft Dynamics CRM application design recognizes that businesses
must respond to constant change. When changes occur within an organization or
its business processes, this design allows the organization to adapt these changes
much more easily and affordably within the application.
Microsoft Dynamics CRM is designed to be customized to adapt to the model of

the business instead of forcing the business to adapt to a process built into the
application. This adaptive process enables Microsoft Dynamics CRM to integrate
into existing infrastructure and build upon Microsoft investments. The adaptable
design of Microsoft Dynamics CRM enables organizations to build and develop
new processes within the application. Additionally, the system:
• Can be customized to adapt to the model of the business instead of

forcing the business to adapt to a process built into the application.
• Work the way users work.
• Work the way the organization's IT staff expects it to work.

This training introduces you to all of the application features that can be
customized in Microsoft Dynamics CRM and the different ways in which
customizations can be applied. This is an introductory section that lays the
foundation for the hands-on training that follows.
Customization Methodology
Depending on the role you play in the implementation, the value you provide for
organizations implementing Microsoft Dynamics CRM requires far more than
just a familiarity with the customization features. Experienced, successful CRM
implementers may tell you that the key to successful CRM implementations
comes from:
• Understanding the application architecture and the types of

supported customizations
• Understanding the organization's needs and expectations
• Having a strong implementation methodology and using it
• Maintaining a perspective on the long term success of the
implementation
Customer Relationship Management is a business strategy supported by software.

To successfully implement the software you must understand the organization's
CRM strategy. If an organization does not have a clear CRM strategy, you may
have to help them define it.
A strong Implementation Methodology helps create a plan that:
• Sets the organization's expectations.

• Discovers opportunities to implement solutions
• Keeps efforts synchronized for delivery
• Verifies that important elements are not overlooked
The adoption of a CRM strategy and the implementation of the software to

support it frequently represents a strong commitment to a fundamental change in
the ways an organization does business. But this change does not stop at the end
of the initial implementation. The capability of the CRM implementation to
continue to respond to change is affected by decisions and processes you make
during the initial implementation.

Customization Tactics
An effective implementation methodology must consider each of the ways in
which an organization can implement customizations. These can include:
• Deployment customizations. You can use the customization tools

within Microsoft Dynamics CRM to directly make customizations
for the implementation, which is the primary focus of this training.
• Re-Using Customizations. After you have created a set of
customizations for Microsoft Dynamics CRM, you can export those
customizations and reuse them with another organization. If you
develop a set of customizations that target a specific vertical market,
you can use those customizations again.
Re-using customizations can help speed the implementation of

Microsoft Dynamics CRM or serve as an advanced starting point for
more specific customizations.
• ISV Products. It is important for implementers to stay up-to-date
with the various add-on products available for Microsoft Dynamics
CRM. Independent software vendors (ISVs) have created many
solutions that target the needs of organizations in specific vertical
markets.
Make sure that you look for ISV solutions that have been certified.
Microsoft has a certification program through an external testing
company that verifies the ISV solution uses supported methods.
• Microsoft Dynamics CRM SDK. If you find that a requirement
cannot be met using the customization tools and there is no ISV
product available that fits the need, you can have a developer create a
custom solution for the organization.
Customizations in a Multiple Organization Environment

For organizations that have installed the Enterprise Edition of Microsoft
Dynamics CRM and have multiple organizations installed, customizations made
for one organization are not automatically applied to all of the organizations.
Each organization is a unique implementation; therefore, customizations are
implemented on a per-organization basis.
However, just as the same accounts, contacts, leads, users, and so on can be
created in multiple organizations, so too can the same customizations be applied
to multiple organizations. If you want the customizations created for one
organization implemented across other organizations, you must export the
customizations from the source organization and then import and publish them in
each additional organization. Details on how to perform the exporting, importing,
and publishing processes are covered later in this training.

Who can Customize Microsoft Dynamics CRM?

Based on the default Microsoft Dynamics CRM security roles, the following
users can take advantage of the customization tools provided in the application to
customize its appearance and behavior.
• Company Managers. CEO-Business Managers, Sales and

Marketing Managers, and Customer Service Managers can
customize views, user permissions, business unit settings, and
workflow processes.
• System Customizers. System customizers can customize the
Microsoft Dynamics CRM schema, including adding, modifying,
renaming, and deleting entities and fields. System customizers can
also modify the user interface by changing form and view content
and defaults, adding and modifying reports, and changing default
report filters.
In some organizations, the System Customizer role is assigned to a

“power” user that has normal user roles. For example, because the
sales manager is highly technical, his organization assigns him the
System Customizer role so that he can perform basic form and view
customizations.
• System Administrators. System administrators can perform the
same tasks as system customizers. Administrators can also modify
any record in the application, and there are some entities that can
only be imported and exported by a System Administrator for
security reasons.
The default Microsoft Dynamics CRM security roles for end-users do not
provide the ability to customize the application. However, users such as
salespeople and customer service representatives can use the built-in
configuration tools to configure their personal options and the way they view
information.
The Role of Developers

Developers can customize and extend Microsoft Dynamics CRM functionality
by:
• Using the product's built-in customization tools

• Programming client-side events in the Microsoft Dynamics CRM
forms
• Creating customized .NET solutions supported by Microsoft
Dynamics CRM Software Development Kit (SDK)

This training focuses on using Microsoft Dynamics CRM's customization tools,

although it does provide a high-level introduction to client-side events and
integrating Microsoft Dynamics CRM to other applications. However, since
these are advanced methods of customization designed solely for developers,
detailed coverage of these topics including hands-on programming labs are
outside the scope of this training. The purpose of these introductions is to expose
non-developers to the myriad of enhancements that can be made by developers
using advanced customization methods.
Permissions Needed for Customizing

By default, only the System Administrator and System Customizer roles have the
privileges to import and export configurations and customizations, including
changes to entities, security role definitions, workflows, and templates.
Both of these roles also have the privileges necessary to perform the basic
application and platform customizations provided in the application's
customization tools. In order to perform these basic customizations, a user needs
to be assigned a security role that includes all the privileges found in the role's
Customization tab.
FIGURE 5.1 CUSTOMIZATION TAB IN THE SYSTEM ADMINSTRATOR

SECURITY ROLE
The Customization tab includes permissions that allow or prohibit the user from
customizing the following areas for each entity:
• Attribute
• Relationship
• Form
• View
• Process

Each of these areas can be assigned one of two possible access levels (these are
basically Yes/No permissions to customize each area):
• Organization. This access level allows the user to customize this

area for an entity.
• None Selected. This access level prohibits the user from customizing
this area for an entity.
See the Appendix topic, Permissions Required for Customization Tasks, for a
complete reference to the privileges required to perform customization tasks.
Microsoft Dynamics CRM Architecture

In order to effectively customize Microsoft Dynamics CRM, you must first have
good understanding of the application's architecture. The system's architecture
influences how and where you can customize the system components.
The key to understanding the Microsoft Dynamics CRM architecture as it relates

to customization is the Microsoft Dynamics CRM platform. One way to
understand the value of the Microsoft Dynamics CRM platform is to contrast it
with the client/server (two tier) architecture that has been around for more than
two decades.
Client/Server Architecture
In client/server architecture, most of the application logic is found in the client.

The client processes the information and the server is typically just the database
that processes transactions and stores the data. The services that the database
provides may be unappreciated now that uses have become accustomed to them.
However, consider the difficulty that developers may face if they had to devise
their own methods to store, retrieve, and manage data without the database.
The database simplifies much of the complexity that a developer has to deal with
and provides him or her with the means to interact with the database through
available APIs using languages such as Transact-SQL. But the client/server
architecture has many shortcomings and there is only so much that a database
designed for general use can provide.

Microsoft Dynamics CRM's Multi-Tier Architecture
Microsoft Dynamics CRM is a web-based application that uses a multi-tier

architecture. This structure provides many benefits that support scalability,
flexibility, and extensibility that cannot be matched using client/server
architecture.
FIGURE 5.2 MICROSOFT DYNAMICS CRM CUSTOMIZATION

ARCHITECTURE
In this multi-tier design, the Microsoft Dynamics CRM platform serves as an

intermediary between the software developer and the database. Just as the
database provides important services in the client/server architecture, the
Microsoft Dynamics CRM platform provides a set of CRM specific APIs that not
only handles interaction with the database, but also provides all the building
blocks for the Microsoft Dynamics CRM application.
The Microsoft Dynamics CRM platform removes all the complexity that
developers may otherwise deal with and provides a rich environment for
customizing the application. Because it is designed specifically for use as a CRM
application, it can provide more specific features that programmers can use when
they build applications that use it.
Microsoft Dynamics CRM Platform

The Microsoft Dynamics CRM platform is responsible for creating domain-
specific objects. Examples of domain-specific objects in Microsoft Dynamics
CRM include Contact, Lead, Opportunity, Account, and Business Unit.
NOTE: A record is an instance of an entity. When you create a new Account

record in Microsoft Dynamics CRM, you create an instance of the Account
entity. Users generally refer to this as a “record” and developers generally use
the term “object.” These terms are used somewhat interchangeably in this
training.

The goal of the Microsoft Dynamics CRM platform is to implement the service-
specific rules by manipulating and combining the underlying domain-specific
objects. The platform accomplishes this by:
• Controlling access to objects through security

• Controlling access to the database
• Raising events for workflow processes and custom business logic
implementations
• Providing for both incoming and outgoing e-mail processing through
the Microsoft Dynamics CRM E-mail Router
Except for reports, every application that interacts with Microsoft Dynamics
CRM does so through Web services in the Microsoft Dynamics CRM platform.
This includes the Workflow tools and solutions created by ISVs. In summary,
think of the platform layer as providing the entire infrastructure that is required to
implement a complete Microsoft Dynamics CRM application.
Domain and Business Logic

The platform by itself does not impose business-specific logic. This layer
imposes only generic domain constraints. It contains the components for an
application, but by itself is nothing more than a collection of related objects.
However, the interaction between these domain specific objects implements more
extensible business logic for the organization. You can apply business logic at
the platform through workflow processes and plug-ins.
• Microsoft Dynamics CRM Workflow enables you to create

automated business processes at the platform layer. Workflow
processes perform actions based on rules set up by the business.
Workflow processes are triggered by events within Microsoft

Dynamics CRM when specific actions are performed and specified
conditions are met.
• Plug-ins refer to the ability to create business logic extensions using
pre- and post-plug-ins available in the platform. Plug-ins are
extension points made available by the Microsoft Dynamics CRM
platform.
There are a published set of events that a solution can subscribe to.
As part of the subscription, a developer must specify an event
handler, which is a segment of customized code that runs in response
the system event.
NOTE: Creating plug-ins requires a .NET developer and is beyond the scope of
this training. Refer to the Microsoft Dynamics CRM SDK for more information,
as well as the Extending Microsoft Dynamics CRM with .NET training offering.

There are certain parts of the Microsoft Dynamics CRM application that include
business logic that is not found in the platform and cannot be customized.
An example of this is the logic that converts a Lead into a Contact, Account, and
Opportunity. This behavior occurs because the application interacts with the
platform to create these new objects based on programmatic information stored
in the Lead object. The platform creates the Lead, but the built-in business logic
performed by the application converts the Lead to a Contact, Account, and
Opportunity.
Database Access
The Microsoft Dynamics CRM platform handles all interactions between the
application and Microsoft SQL Server, which contains the Microsoft Dynamics
CRM database.
IMPORTANT: With only one exception, direct interaction with the Microsoft
Dynamics CRM database is not supported.
Developers must not directly access or update the CRM database for the
following reasons:
• It introduces the opportunity for invalid or corrupt data to be added

to the database, which in turn can cause the Microsoft Dynamics
CRM platform to break.
• The Microsoft Dynamics CRM database structure might change
without notice in a future release.
NOTE: Because all data transactions go through the CRM platform, the
structure of Microsoft Dynamics CRM's actual SQL Server database is
technically irrelevant to even the deepest level customizations.
Filtered Views - the exception to the rule
The one exception to the platform controlling all access to the database is a set of
filtered SQL Server views used to retrieve data for Microsoft Dynamics CRM
reports. Filtered views provide the following features:
• Any ODBC compliant application can report against the data stored
in Microsoft Dynamics CRM; this includes Microsoft SQL
Reporting Services and Microsoft Office applications such as Excel,
Word, and Access.
• Ad-hoc analysis is simplified.
• Third-party reporting tools can be integrated into the Microsoft
Dynamics CRM system.

• A filtered view for a custom entity is created automatically during

the creation of the entity.
• New attributes added to an entity are also added to the filtered views.
FIGURE 5.3 FILTERED VIEWS
Filtered Views and Database Security Checking
The platform layer constructs filtered SQL views at runtime. When the platform
constructs a filtered view it builds row based security checking directly into the
query statement. This means the returned dataset only includes the records to
which the user has access.
Microsoft SQL Reporting Services and other ODBC compliant applications use
filtered views to access data directly from the Microsoft Dynamics CRM
database. By using filtered views:
• These applications can access Microsoft Dynamics CRM data

through an ODBC connection.
• The returned data set bypasses the Microsoft Dynamics CRM
platform because the data has already been filtered based on the
user's security privileges.
• Returned records are only those to which the user has access.
• Limited numbers of records are returned from large databases.
In Microsoft Dynamics CRM reports, the security check is built directly into the
filtered SQL views. So instead of returning all possible records to the platform so
that it can filter out the records that the user is not allowed to access, SQL Server
performs both the filter and aggregate, and only those records to which the user
has access are returned.
Microsoft Dynamics CRM Clients

Because it is built on .NET technologies, Microsoft Dynamics CRM can be
accessed by users in either of two ways:
• Through a web application that is running in Microsoft Internet

Explorer
• Through Microsoft Dynamics CRM for Microsoft Office Outlook

Web Browser Client
The Microsoft Dynamics CRM Web application is a client for the Microsoft
Dynamics CRM platform. The Web Browser client provides a web-based user
experience running in Internet Explorer.
Microsoft Dynamics CRM for Outlook
Microsoft Dynamics CRM for Outlook is integrated into Microsoft Outlook and
is a client for the Microsoft Dynamics CRM platform while online. When offline,
the client interacts with a version of the Microsoft Dynamics CRM platform
installed on the user's computer. Customizations to the Microsoft Dynamics
CRM platform are automatically transferred to Microsoft Dynamics CRM for
Outlook when data is synchronized.
Types of Customizations
Customizations to Microsoft Dynamics CRM can be classified into one of the
following groups:
• Customizing the application's forms and views

• Customizing the Microsoft Dynamics CRM schema
• Extending the application using application event programming
• Extending the application using .NET
• Using client extensions to link the Microsoft Dynamics CRM portal
in other applications
• Automating business processes through Microsoft Dynamics CRM
Workflow
• Customizing reports
This training examines in detail the first two types of customizations; that is,
customizing the forms and views and customizing the schema. In both cases, the
customizations take advantage of the application's built-in customization tools.
Whether you make minor changes to increase your users’ efficiency or major
changes to match your business needs, Microsoft Dynamics CRM can be
customized right from the Web-based user interface using the application's built-
in customization tools.
The remaining customization types are outside the scope of this training. These
tasks are typically performed by target audiences that are different from the
implementer/customizer that configures and customizes the application and
platform. For example, customizing reports and creating workflow rules are
covered in the Microsoft Dynamics CRM Application training offering.

It is important to understand the differences between customizing the Microsoft

Dynamics CRM User Interface and the Microsoft Dynamics CRM schema.
These differences, which are identified in the earlier diagram titled Microsoft
Dynamics CRM Customization Architecture, will affect the scope of the
customizations that your organization makes to Microsoft Dynamics CRM.
For example, you might modify an application event that performs specific data
validation important to your business processes. If you then build or purchase a
solution that directly interacts with the Microsoft Dynamics CRM platform, the
data validation logic you added to the Microsoft Dynamics CRM application may
not necessarily be applied. However, if you include the data validation logic in a
Workflow rule within the Microsoft Dynamics CRM platform, that logic is
enforced regardless of which client is used.
Customizing the Application - Forms

Customizing the application's user interface includes both form and view
customizations. Forms are used in Microsoft Dynamics CRM for entering data
for a given entity. Form customizations typically involve the following tasks:
• Modifying an existing form to add new tabs, sections, and fields.

• Re-arranging each of these items to simplify the way users view and
enter data.
• Removing any of these items.
• Modifying field properties such as labels and layout options.
FIGURE 5.4 MICROSOFT DYNAMICS CRM FORM LAYOUT

Customizing the Application - Views

Views are a type of saved query; they return lists of records for a given entity that
meet a certain criteria. Views typically display only a subset of data related to
each record. The views for a given entity can also display fields from related
entities. For example, each account record in an Account view can display fields
from its related Contact record.
Providing a variety of views gives users more choices in how they locate the
records they are looking for. Views can also represent a small type of report, and
the data displayed in a view can be extracted to a Microsoft Excel spreadsheet.
Each view includes the following elements:
• Filter criteria. Filters are rules or conditions that allow users to

request a subset of the objects associated with the view.
• Columns. The columns in a view display fields pertaining to each
record, and they enable users to change the order in which the
displayed records are sorted.
FIGURE 5.5 ACTIVE ACCOUNTS VIEW DISPLAYING THE PREVEW FOR A

RECORD
Within a given view, users can select the preview option on a record to display
more (although not all) information associated with the record without actually
opening the record. Alternatively, users can open a record by clicking a line in
the view. The fields displayed in both a view and a preview can be customized.
You can create views for the entire organization to use, or you can create and
save your own personal views using the Advanced Find functionality.
Customizing the Microsoft Dynamics CRM Schema

System customizers can customize the Microsoft Dynamics CRM Schema by
adding, modifying, renaming, and deleting entities and attributes. An entity is a
definition for the type of record used to store information in Microsoft Dynamics
CRM. Microsoft Dynamics CRM includes a standard set of system entities such
as Account, Contact, Opportunity and Case.

NOTE: Implementers and System Customizers that interact with end-users and
other non-customizer audiences must note that the term “record type” is
interchangeable with the term “entity.” Record type is also the term typically
exposed to a non-customizer audience.
Customizing the Microsoft Dynamics CRM schema using the application's built-
in customization tools can entail any one of the following tasks:
• Adding completely new custom entities to Microsoft Dynamics

CRM to meet the requirements of the organization
• Adding or removing attributes from existing entities
• Creating relationships between entities
• Creating mappings between entities
These modifications can be made without the need for programming skills
because the system customizer modifies the schema and not the Microsoft
Dynamics CRM database directly. In turn, the platform handles all the
interactions between Microsoft Dynamics CRM and Microsoft SQL Server,
which contains the Microsoft Dynamics CRM database. And as is the case when
customizing the application's user interface, customizations to the schema are
accomplished through the application's built-in customization tools that are
accessed from the Web-based user interface.
Application Event Programming

Microsoft Dynamics CRM includes application events that developers can
program to trigger different actions within the application. This is another form
of schema customization; however, customizing application events requires a
good understanding of the use of JScript and the Document Object Model
(DOM).
NOTE: Detailed discussion of application event programming is outside the

scope of this training, since it is targeted to developers. However, because the
Microsoft Dynamics CRM customization tool provides the ability to program
application events, the training offering titled “Introduction to Advanced
Customizations” introduces the topic to ensure that you are aware of this
advanced customization functionality.
Client Extensions
To make linking applications easier, Microsoft Dynamics CRM lets you add new
buttons and menu items to both the Web application and Microsoft Dynamics
CRM for Outlook.

To link the Microsoft Dynamics CRM Portal with other applications, you can:
• Create buttons and menu items, configure them to point to a URL of

another application, and pass parameters to the application about a
Microsoft Dynamics CRM entity. This enables the other application
to perform a lookup to find an associated record.
• Use URL addressable forms to display Microsoft Dynamics CRM
forms from within other applications.
• Use URL addressable forms to let users create a new Microsoft
Dynamics CRM record from within another application.
NOTE: Detailed discussion of using client extensions to link the Microsoft

Dynamics CRM portal in other applications is outside the scope of this training,
since it is targeted to developers. However, the training offering titled
“Introduction to Advanced Customizations” introduces the basic concepts of
this topic so that you are aware of this advanced customization capability.
Workflow Customization
Workflow is a powerful type of platform customization in Microsoft Dynamics
CRM. It allows organizations to define, automate, and enforce specific rules,
policies, and procedures. Workflow streamlines and simplifies current business
processes by automating tasks. Task automation through workflow allows an
organization to:
• Specify actions to take when specified conditions are met.

• Automate tasks to achieve consistency and efficiency.
FIGURE 5.6 WORKFLOW FLOWCHART

Microsoft Dynamics CRM uses Microsoft Windows Workflow Foundation to

create workflow rules. Both end-users and developers can use this tool to create
workflow rules that automate business processes.
• End-users can design simple workflow rules that apply basic

condition/action constructs. Workflow training for end-users is
available in the Microsoft Dynamics CRM Application training
offering.
• Developers can further enrich workflow rules by calling web
services and .NET assemblies. Advanced workflow training for
developers is available in the Extending Microsoft Dynamics CRM
with .NET training offering.
NOTE: Detailed discussion of workflow in Microsoft Dynamics CRM is outside

the scope of this training, since it is targeted to developers. However, the
training offering titled “Introduction to Advanced Customizations” introduces
the basic concepts of this topic so that you are aware of this advanced
customization capability.
Reporting
The reporting solution included with Microsoft Dynamics CRM is SQL Server
2005 Reporting Services (Microsoft Dynamics CRM does not support SQL
Server 2000 or SQL Server 2000 Reporting Services). A group of standard
Microsoft Dynamics CRM reports created using Reporting Services is included
with the application. In addition, the Reporting Services Report Designer tool can
be used to modify existing reports or create new Reporting Services reports.
NOTE: Using Microsoft SQL Server Reporting Services to create and

customize reports is beyond the scope of this training. Refer to the Microsoft
Official Curriculum course “Creating Reporting Solutions using Microsoft SQL
Server 2005 Reporting Services” for more information.
Microsoft Dynamics CRM also lets you export data from the different views
available throughout the application, including the Advanced Find view. This
data can be exported into “live” Microsoft Excel worksheets and pivot tables that
can be automatically refreshed when they are opened. You can quickly create
reports in a format that is familiar to many users.
Microsoft Dynamics CRM also provides a Report Wizard that allows users to
create SQL Server 2005 Reporting Services reports directly from within the
CRM application.

Creating reports by exporting data into Microsoft Excel and through the Report
Wizard is covered in the Microsoft Dynamics CRM Applications training
offering.
FIGURE 5.7 REPORTS
Extending the Application Using .NET

The Microsoft Dynamics CRM SDK documents how developers can use
Microsoft Dynamics CRM platform Web service APIs to create applications that
interact with the Microsoft Dynamics CRM platform. The Microsoft Dynamics
CRM SDK simplifies Microsoft Dynamics CRM development by providing a
strongly typed system. For developers familiar with .NET, this makes it much
easier to create solutions that interact with Microsoft Dynamics CRM.
NOTE: Using the Microsoft Dynamics CRM SDK to extend the functionality of
Microsoft Dynamics CRM is beyond the scope of this training. For more
information, refer to the “Microsoft Dynamics CRM SDK” and to the
“Extending Microsoft Dynamics CRM with .NET” training offerings.
Upgrading Customizations
Microsoft Dynamics CRM was designed to address a common problem faced by
organizations that purchase third-party business application software - after the
applications were customized to fit each organization's business requirements, the
cost to maintain the code-based customizations made it difficult to upgrade to
newer versions of the software. Without the ability to easily upgrade,
organizations cannot take advantage of new features added in later versions.
Microsoft Dynamics CRM addresses this problem by managing the application's

metadata, which is the data that defines an organization's customizations. The
Microsoft Dynamics CRM customization features use XML definitions that
describe how the application is customized. Because these definitions follow a
known schema, Microsoft Dynamics CRM can safely manage your
customizations when you are ready to upgrade to a next version of the
application.

Although the core customization tools that are built within Microsoft Dynamics
CRM allow you to define the most common types of customizations, there are
frequently some business requirements that necessitate integration with other
systems or the development of some highly specific process that is unique to
your business. Developers can extend the capabilities of a Microsoft Dynamics
CRM deployment while maintaining the ability to upgrade later.
Developers do not change Microsoft Dynamics CRM code; instead, they use
Web services and XML configurations to integrate their custom extensions with
Microsoft Dynamics CRM. Because the Web services and XML configurations
provide a consistent interface in each new version of Microsoft Dynamics CRM,
customized extensions using supported methods can be safely upgraded.
Publishing Customizations
Publishing makes customizations visible to users, although not all customizations
must be published. Publishing customizations allows you to complete a number
of inter-related customizations and makes them available to users at the same
time.
The following rules control which types of customizations require publishing,

and which do not:
• You must publish changes to user interface elements such as forms

and views.
• You must publish changes to form scripts for an entity.
• You do not have to publish changes to the Microsoft Dynamics CRM
schema. Changes to entities, relationships, and attributes are applied
immediately and do not require publishing.
You can publish customizations for a specific entity, for a group of entities, or all
customizations.
• To publish customizations for one entity, click the Actions menu on

the entity form, then click Publish.
• To publish customizations for a group of entities (or for one entity),
select the entities that you want to publish in the Customize Entities
list, and then click Publish on the Actions toolbar.
• To publish all customizations, click More Actions on the Actions
toolbar of the Customize Entities list, and then click Publish All
Customizations.

Reusing Customizations
Many implementations begin by first importing a base set of customizations
before manually applying unique customizations. Implementing customizations
created in a different deployment requires exporting the customizations from the
source system to an .xml file, and then importing the .xml file into the target
deployment.
For example, an organization may purchase a vertical solution from a vendor. In

this case, the vendor exports the customizations from its system into an .xml file,
which it then supplies to any organization that purchases its solution. When an
organization purchases this solution, it receives the file from the vendor and
imports the customizations into its own system.
In other cases, an organization may have installed a separate development system

for creating their own internal customizations. Once the customizations are
completed, they are exported from the development system and imported into the
production system.
The goal of the export/import process is to allow organizations to transport whole

solutions from one implementation to another. To complete the whole solution
experience, the following items are included in the import/export process:
• Custom and Customizable Entities and Entity Metadata.

Includes UI elements such as forms and views. Entity metadata items
include:
– attributes
– attribute default values
– relationship mappings
– Multilingual User Interface (MUI) labels
– multicurrency attributes
– relationship types
• Security Roles. Roles that are imported from one Microsoft

Dynamics CRM implementation into another are attached to the root
business unit. If a matching role exists in the target system, the two
roles are merged.
All standard, or non-custom entity privileges are replaced with the

new privileges from the imported role. Custom entity privileges are
replaced and/or added. The System Administrator role is not
imported.

• System Settings. In addition to the standard system settings, two of

the settings that were previously updated in the web.config file have
been moved to the Systems Settings area of Microsoft Dynamics
CRM and are now included in the Import/Export file. These include
the “Launch in Application Mode” and “Set ISV integration”
settings.
• Workflow. Workflows are imported in an unpublished/inactive state
to prevent accidental changes to transactional data.
• Templates. These include e-mail, mail merge, article, and contract
templates.
• Client Extensions. These include customizations made to the
SiteMap and ISV.config.
Security Requirements
Each security role includes the following privileges to manage access to the
Importing and Exporting Customization user interface:
• Import Customizations
• Export Customizations
• Publish Customizations
By default, each of these Boolean privileges is turned on in the System

Administrator and System Customizer roles. No other security roles have these
privileges enabled by default.
The Export Customization privilege works in conjunction with the Read privilege
in order to export each respective item:
• Entities. Read privileges for all the following objects:

– Entity
– Attribute
– View
– Relationship
• Templates. Read privileges for all the following objects:

– E-mail Templates
– Mail Merge Templates
– Article Templates
– Contract Templates
• Client Extensions (SiteMap and ISV.Config). ISV Integration

• Workflow. Read Workflow
• Security Roles. Global Read privilege for Security Roles
• Relationship Roles. Global Read privilege for Relationship Roles

The Import Customization privileges must work together with the following
privileges in order to import each respective item:
• Entities. Global Create, Read, and Update privileges for all the
following objects:
– Entity
– Attribute
– Relationship
– Form
– View
• Templates. Global Create, Read, and Update privileges for any one
of the following objects:
– E-Mail Templates
– Mail Merge Templates
– Article Templates
– Contract Templates
• Client Extensions (SiteMap and ISV.Config). ISV Extensions

• Workflow. User Create, Read, and Update privileges for Workflow
• Security Roles. The user performing the import must be assigned the
System Administrator role
• Import Relationship Roles. Global Create, Read, and Update
privileges for Relationship Roles
• Settings. The user performing the import must either be assigned the
System Administrator role, or the user's assigned role(s) must
contain Organization Read and Update privileges for System
Settings.
The import customization process will fail if the Import file contains items which
the user does not have access to.
Exporting Customizations
Microsoft Dynamics CRM enables administrators and customizers to export
customizations using one of the following methods:
• Export all customizations

• Export the customizations displayed on a Customization View
• Select customizations to be exported from a list of customization
types

The list of customizations that you can select to export is displayed on a

Customization View. The customizations are sorted by customization type to
facilitate selection of specific changes. A drop-down list of view options controls
which customizations are displayed in the view. These options include:
• All customizations
• Custom and Customizable Entities
• Custom Entities
• Customizable Entities
• Settings
• Workflows
• Security Roles
• Client Extensions (SiteMap and ISV.config)
• Templates
Only published customizations are exported by the system. In addition, the

export process does not include non-modifiable attributes in entities,
relationships, attributes, and templates.
NOTE: If you select an individual entity for Import/Export, any dependent child
objects must be included in the Import/Export operation to preserve the
relationship.
Exported customizations are saved in an .xml file which can be used as a backup,
or to import to another Microsoft Dynamics CRM implementation. The default
file name is customizations.xml, and the export process creates a zipped version
of this file that you can save on your system.
Perform the following steps to export customizations:
1. On the Navigation Pane, click Settings, click Customization, and

then click Export Customizations.
2. To export all customizations, including changes to the templates, Site
Map, and the ISV configuration file, click More Actions, and then
click Export All Customizations
-OR-
To only export customizations to selected items, select the items,
then on the Actions toolbar click Export Selected Customizations.

Importing Customizations
When importing customizations from an .xml file, you can import:
• All the customizations included in the file, or

• Any specified entity or set of entities included in the file
Importing is additive for custom entities and attributes. If an import file contains
objects that do not exist on the target system, the objects are added to the target
system. Import is a summation of the import file and the target system. If an
object exists on the target system but does not exist in the import file, the objects
remain on the target system. Existing objects not included in the import file are
not affected by the import process.
Because import is additive and a summation, when you import entirely new
entities, there will be nothing on the system that can be overwritten. But if you
are importing customizations to customizable system entities or custom entities
that already exist on the system, those entities will be configured exactly like the
system from which the customizations were exported.
This means that if the current system customizations are not identical to those on
the system that the customizations were exported from, the current system
customizations that are different will be overwritten.
Finally, once the import process is complete, you must publish your
customizations before they will appear in the application. When publishing
customizations, you can select the entities you wish to publish, or you can
publish all customizations.
As a best practice, you should publish all customizations if the imported

customizations involve multiple entities. In this example, if you only publish the
customizations for selected entities and you forget to select one of the affected
entities, then the customizations that are published will be incomplete because
they will not include the missed entity.
For organizations that have installed the Enterprise Edition of Microsoft

Dynamics CRM and have multiple organizations installed, importing
customizations does not automatically import the customizations to all of the
organizations. Just like the publishing process that was examined earlier, the
import process functions on a per-organization basis only. If you want the
customizations implemented at more than one organization, you must import and
publish the customizations in each selected organization.
When importing customizations to a production system that has already been

customized, use the following procedure to preserve existing customizations:
1. Export the current customizations from the production system.

2. Import and publish the customizations to a development system. This
makes the development and production systems identical.

3. Develop and test customizations on the development system.

4. Export customizations from the development system.
5. Import customizations to the production system.
6. Publish customizations on the production system.
WARNING: When deciding which customizations to export, consider how the

exported customization file will be used. When you import customizations for an
entity, prior customizations to that entity are overwritten, including any
customized relationships between that entity and other entities.
To avoid overwriting existing customizations, either:
• Import all customizations from the target Microsoft Dynamics CRM

system prior to performing additional customizations, so that when
you export customizations, all existing customizations will be
included as well as new ones.
• Only export entities that have not been customized in the target
system.
Perform the following steps to import customizations:

then click Import Customizations.
2. In the Import File box, either type the path and file name of an .xml
or .zip file that contains exported customizations, or click Browse
and navigate to the file that you want to import. Click Upload. The
list of customized entities from the file is displayed.
3. To import all customizations, on the Actions toolbar click More
Actions, and then click Import All Customizations.
- OR -
To import selected customizations, select the customizations you
want to import, and then on the Actions toolbar click Import
Selected Customizations.
4. Publish the imported customizations. To publish all customizations,
click Customization, then click Customize Entities. On the Actions
toolbar, click More Actions, and then click Publish All
Customizations.
Importing from a Different Base Language

Organizations that install Microsoft Dynamics CRM purchase the language
edition they want to deploy (for example, the Spanish edition). This installed
language edition is known as the base language. In addition to the base language,
Microsoft Dynamics CRM supports a Multilingual User Interface (MUI) that
allows additional MUI language packs to be installed (for example, Russian,
Italian, and German).

Each user can select the language of his or her choice from either the base
language or any of the downloaded MUI language packs. The user's Microsoft
Dynamics CRM user interface is then displayed in the selected language. In an
MUI environment, the label for each system component is displayed in the
language selected by the user.
So how does the MUI environment in Microsoft Dynamics CRM affect

customizations? In many organizations, customizations made in one deployment
are frequently imported into another. This may involve importing customizations
from a test environment into a production environment, or from a partner
organization into a customer's deployment.
In Microsoft Dynamics CRM, customizations exported from one installation do

not have to be in the same language used by the target installation in which they
are imported. The Import Customization feature enables customizations made in
one base language to be imported into a deployment running a different base
language.
The following example explains how the Import process works in a multilingual
environment:
1. Pierre has created a set of customizations in System A. It has a base

language of French, together with Russian and English MUI
language packs.
2. Pierre wants to load the customizations from System A to System B.
3. System B has a base language of Spanish and a German MUI
language pack.
4. Pierre selects the customizations to be exported from System A and
then exports the selected customizations.
5. Because System A's base language is French, the export process
stores the selected customizations in the export file in French. The
export process ignores System A's Russian and English MUI
language packs.
6. Pierre imports the file into the Microsoft Dynamics CRM
deployment on System B.
7. System B has a base language of Spanish. Because no labels for
Spanish are contained within the file, the import process replaces
each French label with a Spanish label.
8. The German MUI language pack installed on System B does not
affect the import process. Instead, the German labels are processed
as usual for all system components (both out-of-the-box components
plus all imported customizations) when they are displayed in the user
interface for users who selected German as their language of choice.

Lab 5.1 - Importing and Exporting Customizations

This lab illustrates how customizations are imported and applied to a Microsoft
Dynamics CRM deployment. Once the import is complete, you are asked to
perform the export process by exporting the customizations for backup purposes.
Scenario

Adventure Works Cycle, has recently had Microsoft Dynamics CRM installed,
but it is not yet customized to meet their business requirements.
During Adventure Works’ CRM Implementation Needs Analysis meeting, Mary

Sandidge said they want a more formal way of tracking a company’s relationship
with Adventure Works. In their old system, users were able to type random
information into a text field. Mary said that if users are able to select which type
of relationship the contact has with the company from a list of options, more
meaningful information will be captured in the system.
You mention that the Contact entity already includes a Relationship Type picklist
field that may be exactly what she needs. Because the field is not implemented
on the Contact form, you indicate that you will:
• Update the picklist values per Mary's requirements

• Expose the field on the Contact form
• Display it on the Active Contacts view
• Display it on the Contact Preview form
Mary also requested that you add a Yes/No field to the Contact entity that
indicates if the contact is a VIP. This field will be used later when Adventure
Works implements its Event registration system. You agree to add this field to
the Contact entity, Contact form, and Contact Preview form.
Goal Description
As Adventure Works’ implementation consultant, you created the customizations
on their test installation. You have tested the changes and verified they are
functioning properly. The Adventure Works QA team has also tested the changes
and approved them.
You are ready to implement the changes in Adventure Works’ production

environment. To do so, you have exported the customizations from the test
system. You are now ready to import the changes to the production system. Once
the customizations are installed, you plan to export all customizations on the
production system for backup purposes.

Use the following information when importing and exporting the customizations:
• Import. The customizations made in the test system were exported

to the following zipped file: c:\Class
Materials\Customization\Ch.5\ Contact customizations.zip.
Import this file into Adventure Works’ production system.
• Export. Once the import is complete the customizations have been
validated, back up all of Adventure Works customizations to the
following zipped file: c:\Class
Materials\Customization\Ch.5\AWC config bkup.zip.
Challenge Yourself
1. In order to appreciate the new application changes, first review the

default appearance of the Contact form. Once the customizations are
imported, the new Relationship Type picklist field will appear on the
General tab to the right of the Currency field. The Relationship Type
field will also appear on the Active Contacts view and the Contact
Preview pane. The new VIP code will appear on the Details tab of
the Contact form, and on the Contact Preview pane.
2. Import the customizations located in the zipped file displayed in the
Goal Description. Publish the customizations once the import is
complete.
3. Verify that the changes were imported successfully.
a. Add a new Contact record and set its Relationship Type field to
one of the picklist values. Set the VIP contact code to Yes.
b. Locate the record in the Active Contacts view and verify that the
Relationship Type value is displayed.
c. Open the Preview pane and verify that the Relationship Type
and VIP code are displayed there as well.
4. For backup purposes, export Adventure Works’ existing

configuration after applying the customizations. Export the
configuration for all entities to the zipped file defined in the Goal
Description.
Need a Little Help?

1. In order to verify Adventure Work's requested application changes,

you should first review the default appearance of the Contact form.
a. Navigate to the Sales menu, select the Contacts entity and
request a new Contact form.

b. Once the customizations are imported, the new Relationship

Type picklist field will appear on the General tab to the right of
the Currency field, and the VIP code will appear on the Details
tab. Note the current appearance of the form prior to the
customizations.
2. The customizations requested by Adventure Works have already

been created and exported from the test system. The location of the
file is displayed in the Goal Description. Import all customizations
from the zipped file into Adventure Works’ organization.
3. Verify that the changes were imported successfully.
a. Add a new Contact record and set its new Relationship Type
field to one of the picklist values. Set the VIP contact code
to Yes.
b. Navigate to the All Contacts view. Locate the contact that you
just added and verify that the Relationship Type value is
displayed.
c. Verify that the Relationship Type and VIP code appear on the
Preview pane.
4. For backup purposes, export Adventure Works’ existing

configuration after applying the customizations.
a. Navigate to the Customization area, select Customize Entities,
and then Export Customizations.
b. Export the configuration for all entities to the zipped file defined
in the Goal Description.
Step by Step
Step 1 - View Contact form before customizations
In order to appreciate the new application changes, first review the default
appearance of the Contact form.
1. On the Navigation Pane, click Sales, then click Contacts.

2. Click New on the Actions toolbar to request a new Contact form.
3. Once the customizations are imported, the new Relationship Type
picklist field will appear on the General tab to the right of the
Currency field, and the VIP code will appear on the Details tab. Note
the current appearance of the form.
4. Cancel the form.

Step 2 - Import and Publish Customizations
The customizations requested by Adventure Works have already been created

and exported from the test system. The location of the file is displayed in the
Goal Description. Import all customizations from the zipped file into Adventure
Works’ organization.

2. To select the import file, click the Browse button next to the Import
File box and navigate to the folder specified in the Goal Description.
Select the zipped customization file that is identified in the Goal
Description and click Open.
3. On the Import Customizations page, click Upload. The list of
customizations from the file is displayed in the Import Customization
view.
4. To import all customizations, on the Actions toolbar, click More
Actions, then click Import All Customizations. A dialog box
appears, noting that it can take several minutes to import all the
customizations. Click OK to close the dialog box.
5. Click Customization in the Settings area to navigate back the
Customization area.
6. Click Customize Entities.
7. On the Actions toolbar of the Customize Entities list, click More
Actions, and then click Publish All Customizations.
Step 3 - View Contact form after changes
Verify that the changes were imported successfully. Add a new Contact record
and set its new Relationship field to one of the picklist values and set the VIP
contact code to Yes. Locate the record in the All Contacts view and verify that
the Relationship Type value is displayed. Verify the Relationship Type and VIP
code are displayed in the Preview pane.
1. On the Navigation Pane, click Sales, then click Contacts.

2. Click New on the Actions toolbar to request a new Contact form.
3. Add a new Contact record for
a. Name = Kim Akers
b. Relationship Type = Reseller
c. VIP contact = Yes
d. Click Save and Close.
4. On the View Menu, click the drop-down button to list the available
views. Select the Active Contacts view.

5. Locate Kim Akers‘ Contact record. Verify that the Relationship

Type column displays the correct value.
6. Click on the Preview icon on Kim’s record. Verify that the
Relationship Type and VIP code display in the Preview pane.
Step 4 - Export existing configuration as a backup
For backup purposes, export Adventure Works’ existing configuration from its
production system after applying the customizations. Export the configuration for
all entities to the zipped file defined in the Goal Description.

2. To export all customizations, click More Actions, then click Export
All Customizations.
3. In the File Download dialog box, click Save.
4. In the Save As dialog box, save the customizations to the location
5. The Download complete dialog box appears. Click Close.
Summary
The purpose of this training is to provide a foundation for understanding how
Microsoft Dynamics CRM processes customizations. Subsequent training
examines in detail how to customize the application's user interface and platform
using its built-in customization tools.
This training began by examining the product's multi-tier architecture. This

structure provides many benefits that support scalability, flexibility, and
extensibility. The key component of the architecture is the platform layer, which
controls access to objects through security and controls access to the database.
This training then introduced all the application features that can be customized
in Microsoft Dynamics CRM and the different ways in which customizations can
be applied using the product's built-in customization tools.

Test Your Knowledge

Test your knowledge with the following questions.
1. What are some of the ways in which an organization can implement

customizations.
2. Which of the following represents the main types of Microsoft Dynamics

CRM Customizations? (Select all that apply.)
( ) Customization of the Microsoft Dynamics CRM Platform
( ) Customization of the Microsoft Dynamics CRM Application
( ) Customization of the Microsoft Dynamics CRM Web Services
( ) Customization of the Microsoft Dynamics CRM Database
3. Is direct interaction with the Microsoft Dynamics CRM SQL database

supported?
( ) Yes, to change the database tables
( ) Yes, to retrieve data from tables
( ) Yes, to retrieve data from Filtered Views
( ) No, direct interaction is not supported
4. What is the primary benefit of using only supported methods of

customization?
( ) Easier to upgrade
( ) Technical Support will help you
( ) Investment preservation
( ) Opportunity to learn new technologies

5. Is it possible to create custom entities like "Project" with Microsoft

Dynamics CRM?
( ) Yes, it is possible by developing an external .NET assembly.
( ) Yes, it is possible with external tools.
( ) Yes, it is possible with Microsoft Dynamics CRM customization tools
( ) No
6. Is it possible to re-use customizations for other deployments?

( ) Yes, it is possible to export and import customizations with Microsoft
Dynamics CRM tools.
( ) Yes, it is possible to export and import customizations with SQL Server
tools.
( ) Yes, it is possible to export and import customizations with file tools.
( ) No, it is not possible
7. Three of the most important factors in the success of a CRM implementation

include:
( ) A deep understanding of every Customization feature
( ) Understanding the organization's needs and expectations
( ) Having a strong implementation method and using it
( ) Maintaining a perspective on the long term success of the implementation


chapter:
1.
2.
3.

Solutions
Test Your Knowledge
1. What are some of the ways in which an organization can implement
customizations.
MODEL ANSWER - - Deployment Considerations - Re-using
Customizations - ISV Products - Microsoft Dynamics CRM SDK
2. Which of the following represents the main types of Microsoft Dynamics

CRM Customizations? (Select all that apply.)
(√) Customization of the Microsoft Dynamics CRM Platform
(√) Customization of the Microsoft Dynamics CRM Application
( ) Customization of the Microsoft Dynamics CRM Web Services
( ) Customization of the Microsoft Dynamics CRM Database
3. Is direct interaction with the Microsoft Dynamics CRM SQL database

supported?
( ) Yes, to change the database tables
( ) Yes, to retrieve data from tables
(•) Yes, to retrieve data from Filtered Views
( ) No, direct interaction is not supported
4. What is the primary benefit of using only supported methods of

customization?
( ) Easier to upgrade
( ) Technical Support will help you
(•) Investment preservation
( ) Opportunity to learn new technologies
5. Is it possible to create custom entities like "Project" with Microsoft

Dynamics CRM?
( ) Yes, it is possible by developing an external .NET assembly.
( ) Yes, it is possible with external tools.
(•) Yes, it is possible with Microsoft Dynamics CRM customization tools
( ) No

6. Is it possible to re-use customizations for other deployments?

(•) Yes, it is possible to export and import customizations with Microsoft
Dynamics CRM tools.
( ) Yes, it is possible to export and import customizations with SQL Server
tools.
( ) Yes, it is possible to export and import customizations with file tools.
( ) No, it is not possible
7. Three of the most important factors in the success of a CRM implementation

include:
( ) A deep understanding of every Customization feature
(√) Understanding the organization's needs and expectations
(√) Having a strong implementation method and using it
(√) Maintaining a perspective on the long term success of the implementation


Chapter 6: Customizing Forms and Views
CHAPTER 6: CUSTOMIZING FORMS AND VIEWS

Objectives
The objectives are:
• Introduce the basic user interface components that can be customized

to meet your organization's business requirements
• Identify the features of the form customization tool
• Examine how to organize data on a form by organizing the data in
tabs
• Examine how to organize data within tabs by using sections
• Identify how to add and maintain fields on a form
• Examine how to test the appearance and behavior of a customized
form prior to saving the customizations
• Examine how to customize an entity's Preview form
• Identify the types of views that can be customized
• Identify the different ways in which a view can be customized
• Examine what properties can be customized on a view, and how to
perform the customizations
Introduction
This training examines how to customize the Microsoft Dynamics CRM user
interface using the application's customization tools. This includes
customizations to the forms used to enter and update data and the views that
display lists of records.
As a system customizer, your organization will invariably ask you to modify

some of the forms and views that are used by your Sales and/or Service teams.
For example, in a sales organization, the Credit Manager may ask you to create a
new view that displays all Accounts that are on credit hold.
To successfully modify the user interface to implement these requests, it is

important that you have a thorough understanding of the Microsoft Dynamics
CRM customization tools. They are a set of metadata driven tools that provide
powerful ways for you to change Microsoft Dynamics CRM so that it fits your
business without the need for a developer to write any code. The customization
tools can be accessed directly from the Web-based user interface. This puts the
power to customize Microsoft Dynamics CRM into the hands of those who know
the business best - you, your business consultant, and/or your IT staff.

Basic UI Customization Capabilities

The majority of the basic customization tools can be found in the Settings >
Customization area of the Navigation pane. Most of the customizations described
in this section are included in the Customize Entities group.
FIGURE 6.1 CUSTOMIZATION AREA WITH CUSTOMIZE ENTITIES
To customize the application, or more specifically, the application's user

interface, you must begin by selecting the entity that you want to customize.
Other than navigation pane customizations, all user interface customizations
using the customization tools are performed at the entity level.
lYou can customize the following user interface components for an entity to meet
your organization's business requirements:
• Forms. A form is used for entering data in the application for a

given entity. Each entity has one form. You can modify how a form
is organized, and you can choose which of the entity's attributes to
display as fields in the form, as well as how those fields are
displayed.
When you add a new entity, the system creates its corresponding
form for you. However, you can customize the form to only include
the attributes your organization plans to maintain.
• Views. A View is a type of saved query that is used to locate records.
The results of each view query are presented to the user in a grid.
Users can select different views to see the data presented with
different columns and filtering controls.
When you add a new entity, the system creates several default views
for you. However, you can customize those views, as well as add
additional custom views.
• Previews. Each record that is displayed in a view includes a preview
arrow. When a user clicks the preview arrow for a given record,
some of the available fields are displayed for that record without
actually opening the record. You can customize which fields are
displayed in the preview form.

Renaming Customizable Entities

Forms, views, and previews are the user-facing structures used by Microsoft
Dynamics CRM to update and display information for each customizable entity.
In addition to being able to modify a customizable entity's forms and views, you
can also modify the name of customizable entities themselves to match the
terminology used by the organization.
For example, Microsoft Dynamics CRM uses the term “Account” to describe a
customer that is a business. If your organization is a wholesale distributor that
refers to its customers as Resellers, you can change the name of the entity from
“Account” to “Reseller.”
NOTE: Renaming an entity requires a number of manual steps to ensure that

all references to the entity are consistent. For example, when you rename an
entity, the system messages and standard error messages need to be changed so
they are consistent with the new entity name. These steps are examined in the
training offering titled “Renaming Entities and Translating Customizations.”
Form Customization Overview

Form customization allows you to modify the appearance and behavior of the
forms that capture and display data in Microsoft Dynamics CRM. The figure
displays the user interface to customize the Account form. A representation of
the form is presented on the left, and a set of common tasks that are used to
customize the form are listed on the right.
FIGURE 6.2 ACCOUNT FORM CUSTOMIZATION

NOTE: The default security role setting for Record Customization is set to
grant Read Access at the Organization level. This cannot be changed. This does
not mean that all users have the ability to view the Entity Customization area. If
you want to allow selected users to preview customizations before publishing,
they need to be assigned a role that has Organization level Create and Read
rights for the Entity Customization privilege.
Perform the following steps to access the form customization tool for a given
entity:

then click Customize Entities.
2. Open the entity containing the form that you want to customize, and
then click Forms and Views.
3. Select Form, and then on the More Actions menu, click Edit
-OR-
Double-click the Form item.
Form Properties
The Form Properties window contains the following tabs:
• Display. The options on this tab control the use of the Form
assistant.
• Events. The form has events that can activate client-side scripts. The
training offering titled Introduction to Advanced Customizations
introduces the use of client-side scripting.
• Non-Event Dependencies. The fields in the form can be referenced
in scripts for custom buttons and menu items configured in the
isv.config.
If these fields are referenced in scripts and then later removed, an

error will occur. To prevent this, the Non-Event Dependencies tab
provides a place to document these dependencies. This prevents the
fields from being removed accidentally.
Refer to the training offering titled Introduction to Advanced

Customizations for more information about creating custom buttons
and menus that use scripts.
Forms are composed of tabs, sections, and fields. In the prior figure displaying
the Account form, the tabs include General, Details, Administration, and Notes.
These four tabs are common to most entity forms. The sections in the General tab
for the Account form include Account Information and Address. Note how the
Account Information section name is not displayed. The fields are located within
each section. The following lessons examine how to customize each of these
form features.

Saving Your Form Customizations

You can save your form customizations without publishing the changes. After
saving your changes:
• You can continue to customize the form.

• You can return at another time and continue to make additional
customizations.
• Other users with the ability to customize forms can view and modify
the customizations you made.
However, once you have completed the form customizations, you must publish
the changes so they become visible to the users.
Form Customization - Editing Tabs

Tabs provide a way to organize the data that is updated and displayed on a form.
Most forms have the following default tabs:
• General
• Details
• Administration
• Notes
When modifying a form, you can add, move, and remove tabs on a form. If you
add too many sections or fields to a tab, the user must scroll down to view or edit
them. Rather than include a large number of sections and fields within a single
tab, just add more tabs.
NOTE: The Microsoft Dynamics CRM customization tool allows you to define
up to eight tabs to a form.
Adding and Editing Tabs

Perform the following steps to add a new tab or to edit an existing tab. The tab
name is the only property that is maintained when adding and editing tabs.
1. To add a new tab, in the Common Tasks area, click Add a Tab.
- OR -
Select the tab you want to edit, then in the Common Tasks area, click
Change Properties.
2. To change the name of an existing tab, enter a unique name in the

Name field for the tab.
3. Click OK.

Moving Tabs
You can change the location of tabs on the form by using the green arrows in the
Common Tasks area. To move a tab:
1. Click the tab you want to move. Note how the tab is highlighted to
indicate that it has been selected.
2. In the Common Tasks area, click either the left or right arrow to
move the selected tab to the desired location.
Removing Tabs
Removing a tab also removes any sections or fields that are included on the tab.
If you plan to remove a tab that contains fields that are assigned a Business
Required constraint, you must first move these business required fields to other
tabs. Perform the following steps to remove a tab:
1. Select the tab you want to remove by clicking on the tab.
2. In the Common Tasks area, click Remove.
Form Customization - Editing Sections

Sections provide a way to organize the fields that appear on a tab. Sections have
a label and a divider line which you can choose to display. This lesson examines
how to add, move, and remove sections, as well as how to customize the layout
of a section.
The earlier figure that displayed the Account form displays a tab that includes
two sections: one in which the label and divider line are displayed, and one that
hides the label and divider line.
Adding and Editing Sections

To add a section, click the Add Section option in the Common Tasks area. To
edit a section, select the section and click Change Properties. Both adding and
editing a section involves customizing the section's Name, Label, and Location
properties.
WARNING: A section's layout properties can only be entered when adding a

section; once a section is created and the form is saved, the layout properties
cannot be changed.

Perform the following steps to add a new section to a tab, or to edit the properties
for an existing section.
1. Select the tab that contains the section you want to edit, or where you
want to add a new section.
2. To add a section, click the Add a Section option in the Common
Tasks area.
- OR -
To edit a section, select a tab and the section in the tab you want to
edit, and then click Change Properties in the Common Tasks area.
On the Add a Section or Section Properties dialog box, add or change the
following section properties on the Display tab:
• Name. Enter a unique name for the section.

• Label. If you want the section name displayed on the form, select the
Show the name of this section on the form check box.
– If you select this option, then the Show divider line below the
section name option is enabled.
– Select this check box if you want to display the divider line.
• Field Label Width. You can specify the width of the field label area
in pixels.
• Location. In the Tab drop-down list, select the tab you want the
section to appear in. When adding a section, this will be prefilled
with the tab that you previously selected. When editing a section, this
will be prefilled with the tab in which the section currently appears.
When adding a section, select the Formatting tab to customize the section layout.
The section layout information cannot be changed when editing the properties of
an existing section.

When you add a section, you can select the type of layout to apply from two
mutually exclusive options: Variable Field Width and Fixed Field Width. Your
selection determines the column layout options that are available on the
Formatting tab for each field in the section.
FIGURE 6.3 SECTION FORMATTING
Variable Field Width
This is the default option. Fields are set up in two columns. The reason this
section layout option is referred to as “variable” is that for IFrame and ntext
fields, an option exists on the field properties that allows you to set the width to
be one or two columns. This field property is enabled if the IFrame or ntext field
appears within a Variable Field Width section; however, this field property is
disabled if the field is within a Fixed Field Width section. Because the field
property determines whether the field is displayed in one or two columns, the
Column Format options for the section is disabled.
Fixed Field Width
With this formatting option, fields can be set up in two, three, or four columns as
seen in the figure. Each field can only be as wide as the column in which it is
displayed. In addition, a Fixed Field Width section does not allow the
administrator to set IFrame and ntext field properties to automatically expand to
fill available space.

Moving Sections
You have two options when moving a section:
• Move a section to a different location in its existing tab by using the

arrows in the Common Tasks area.
• Move a section to another tab by specifying the new tab in the
Location property field.
In both cases, all of the fields within the section are moved along with it. Perform
the following steps to move a section:
1. Click the section you want to move.

2. To move a section to another location within its existing tab, click
the appropriate arrow in the Common Tasks area to move the section
to its new location.
3. To move a section to another tab:
a. Click Change Properties
b. In the Display tab of the Section Properties dialog box, click on
the Location drop down arrow and select the tab you want the
section to appear under.
c. Click OK.
Removing Sections
A section can be removed as long as it does not contain fields with dependencies.
Removing the section removes all fields in the section from the form.
1. Select the section you want to remove.

Form Customization - Editing Fields

For each field displayed on a form, you can edit the properties, the position, and
the behavior of the field as it relates to the form. Changing the form properties
for a field is not related to changing the database properties for an attribute on the
entity. Modifying entity attributes is covered in the training offering titled
Customizing Entities and Attributes.
The field properties discussed in this lesson refer to how the field is presented
and behaves on the entity form. When changing a field's properties for a form,
the properties have been grouped into the following four tabs:
• Display
• Formatting

• Schema
• Events
Design Considerations
When adding a field to a form, the tab that you want to add the field into must
contain a section. You can add one or more fields into a given tab and section at
the same time. This is done by selecting the attribute(s) that you want included
on the form from the list of available attributes for the entity. Once you expose an
attribute on a form, the attribute no longer appears in the list of available
attributes.
There are a number of attributes for each entity that are not displayed on the
default forms. If you do not find an existing attribute that fits your need you can
create a new attribute (this is covered in the training offering titled Customizing
Entities and Attributes). Before creating a new attribute to store data for an
entity, it is recommended that you first review the existing attributes to determine
if one exists that might satisfy your business requirement.
The location of a field within a section can have an impact on how well the form
is received by the end-users. When designing the appearance of a form, it is
important to remember that some users prefer to use the mouse to point and click
their way from field to field, while other users prefer to tab from one field to the
next.
Therefore, the location of a business required, business recommended, or

otherwise popular field can have an impact on users that prefer to tab through the
fields. This is especially true if the user has to tab through too many fields to get
to the desired field. When end-users enter data on a form, the default tab order is
from top to bottom in each column, starting with the left-most column and
moving to the right.
Adding a Field to a Form

Once you have opened the form that you want to customize, perform the
following steps to add a field on to the form:
1. In the Common Tasks area, click Add Fields.

2. On the Add Fields dialog box, select the fields you want to add to the
form.
3. If you had previously selected a section on a tab prior to clicking
Add Fields, that tab and section will be displayed in the Location in
the Add Fields dialog box.
You can accept these defaults, or you can select a new tab and/or
section from their respective drop-down lists. Note: Tabs that do not
contain a section will not appear in the tab list.
4. Click OK.

Editing Field Properties

Each field displayed on a form is assigned specific properties that affect how the
field is displayed, formatted, and behaves. You can customize these properties to
meet your business requirements.
Customizing field properties is initiated by opening the form, selecting the field,
and then clicking Change Properties in the Common Tasks area. This opens the
Field Properties dialog box.
FIGURE 6.4 FIELD PROPERTIES
The Field Properties dialog box groups the properties into the following four
tabs:
• Display
• Formatting
• Schema
• Events

Display Tab
The properties on this tab affect how the field is displayed and maintained on the
form. These include:
• Label. The label defaults to the Display Name assigned to the

attribute in the database schema. You can change this label if you
want to display a different field name.
• Display label on the form. If this option is not checked, the field
will still display on the form, but the label will not be displayed next
to it (although the display name will still be displayed within the
field in a transparent or watermark manner).
• Field Behavior. You can select whether or not to make the field
read-only. For example, you may choose to make the field read-only
if it uses calculated information based on information stored in other
fields.
• Location. You can change the tab and section in which a field
appears by selecting the appropriate values from the drop-down lists.
Formatting Tab
The formatting options displayed on this tab depend on the formatting options
assigned to the section in which the field appears.
• If the section formatting is defined as Variable Field Width, you

can choose a layout of one or two columns.
• If the section formatting is defined as Fixed Field Width, you do not
have the option of modifying the number of columns. However, for
ntext fields, you can define the number of rows for the field.
The properties that can be maintained on the Formatting tab are dependent on the
field type. These include:
• All fields. If the section the field is located in is set to Variable Field
Width, you can set the layout to one or two columns.
• Bit fields. For bit fields, you can specify if the field is displayed as a:
– Radio button
– Check box
– Picklist
• ntext fields. For ntext fields, you can specify the height of the field
in rows. If the section the field is located in is Variable Field Width
you can also set an option on the field properties that displays the
field in one or two columns.

Schema Tab
The Schema tab displays read-only attribute information for the field. This is an
informational-only tab that cannot be updated. The information displayed in this
tab is taken from the field's attribute record in the entity schema. You cannot
change the values here, although the display name can be modified on the form.
To change some visible features of a field, like the options available in a picklist,
you need to edit the attribute in the entity schema. Modifying attribute properties
is covered in the next training offering titled Customizing Entities and Attributes.
Events Tab
Each field on a form has a corresponding OnChange event which can be used to
trigger client-side code when a user changes the value of the field. The Events
tab is where developers attach client-side scripts to the OnChange event for a
field. Event programming is introduced in a later training offering titled
Introduction to Advanced Customizations.
Moving a Field on a Form

When designing the appearance of a form, it is important to group related fields
together for a logical presentation of information. Sometimes you may find that
you have to move fields from one location to another to adjust the presentation,
or to control the tab order within a form.
There are two ways to move a field on a form.
1. Moving a field to another location in the same tab. In this case,

select the field you want to move, and then click the appropriate
arrow(s) in the Common Tasks area to move the selected item left,
right, up, or down on the form.
2. Moving a field to another tab. The arrows in the Common Tasks
area can only be used when moving fields within a given tab; they
cannot move fields from one tab to another. In this case, you must
select the field, and then select Change Properties in the Common
Tasks area.
a. On the Field Properties form, the Display tab includes Tab and
Section drop-down fields.
b. From these drop-down lists, select the Tab and Section to which
the field will be moved.

Removing a Field from a Form

You can remove a field from a form, unless the field has a constraint or
dependency assigned to it.
• Constraint. Each attribute includes a Requirement Level property

that indicates if it is a business required field, a business
recommended field, or has no such constraints. Fields that are
identified as business required or business recommended cannot be
removed from a form.
When you customize a form, the Form customization tool provides

the following indicators to assist you in identifying which fields have
assigned constraints:
– Business required field. A red asterisk is displayed following
the field name on the form.
– Business recommended field. A blue plus sign is displayed
following the field name on the form.
• Dependency. The training offering titled Introduction to Advanced

Customizations addresses how developers can program form and
field events so that when specific events occur, the business logic
programmed into the event is performed.
If the code that a developer adds to an event references a field in the

form, removal of the field from the form will cause the code to
break. Therefore, developers can add these fields to a list of
dependent fields to prohibit system customizers from removing the
field from the form.
Perform the following steps to remove a field from a form:
1. Select the field you want to remove.

Preview Your Customizations

A final step before saving customizations is to test the appearance and behavior
of the form. An option to view your customized changes is available from the
Preview menu. The figure titled Form Preview Types describes the three types of
forms that you can test.
FIGURE 6.5 FORM PREVIEW TYPES

The Form Preview also allows you to test any application scripting that has been
added for form and field events. Previewing event scripts is covered in the
training offering titled Introduction to Advanced Customizations.
BEST PRACTICE: Any change to an entity's form should be validated using

the Preview option prior to publishing the customization.
Preview Form Customization

Every public view displays a triangle shaped icon on the far left side of each
record displayed in the view. Clicking on this icon opens the Preview form for
the entity. The Preview form displays additional information about the record
without actually opening the record.
Although the Preview form displays additional fields for a record, it is considered
by the application to be a form and not a view. When the filter is changed on the
Forms and Views page to display All Forms, the entity's Form and Preview form
are displayed.
FIGURE 6.6 INVOICE PREVIEW FORM
A Preview form is customized just like an entity form, although fewer

customization options are available. You can add, remove and re-position fields
within the Preview form. Perform the following steps to access an entity's
Preview form:
1. Click Settings, click Customization, click Customize Entities, click

the entity, then double-click Forms and Views.
2. Click Customize Entities.
3. From the displayed list, double-click the entity that you want to
customize.
4. Select Forms and Views, and double-click Preview.
Use the same procedures to customize Preview forms as you did to edit fields on
a form. Once you have completed customizing the Preview form, save the
changes and publish them.

Demonstration - Form Customization

This instructor demonstration illustrates how form customizations can be applied
to a deployment. Steps are provided so you can follow along with the instructor.
Scenario
Adventure Works Cycle wants to reorganize their Account form to better fit their
business processes. They have also requested a change to the Account's Preview
form to display the account's Business Type code.
Goal Description
The goals for this demonstration include:
• Create an Address tab between the Details and Administration tab

• Display Primary and Secondary addresses in the Address tab
• Display Business and Company Information on the General tab
• Remove the Details tab and the Description field
• Reformat the fields in the Contact Methods section of the
Administration tab to require less vertical space on the form (refer
to the two figures for a “before” and “after” reference)
• Add Business Type code to the Account's Preview form
FIGURE 6.7 CONTACT METHODS SECTION BEFORE APPLYING CHANGES
FIGURE 6.8 CONTACT METHODS SECTION AFTER APPLYING CHANGES

Step by Step
To complete this demonstration, you first must open the Account form. Click
Settings, click Customization, click Customize Entities, double-click Account,
click Forms and Views, and then double-click Form.
Step 1: Add a Tab
1. On the Account Form, click Add a Tab from the Common Tasks
area.
2. Enter “Addresses” as the name of the tab.
3. Click OK.
Step 2: Move a Tab
1. Select the Addresses Tab.

2. Click the green left arrow until the Addresses Tab is between the
Details and Administration Tab.
Step 3: Move Sections
1. Click the General Tab. Select the Address section by clicking on the
Address section label.
2. Click Change Properties.
3. Change the Location Property to the “Addresses” tab.
4. Click OK.
5. On the Details Tab, use the same method to move the Business
Information and Company Information sections to the General tab.
Step 4: Add a Section
1. Click the Addresses Tab.

2. Click Add a Section.
3. Enter the following properties in the Add a Section dialog box and
then click OK.
FIGURE 6.9 SECONDARY ADDRESS SECTION PROPERTIES

Step 5: Edit an Existing Section
1. On the Addresses tab, select the Address section and click Change
Properties.
2. Change the Name to “Primary Address.”
3. Click OK.
Step 6: Remove Tab, Section and Field
1. Select the Details Tab.

2. Click Remove and OK. Note: The Description Section and Field are
removed with the Details tab.
1. On the Addresses tab, select the Secondary Address section.
2. Click Add Fields.
3. On the Add Fields dialog box, select the following fields:
• Address 2: City
• Address 2: State/Province
• Address 2: Street 1
• Address 2: ZIP/Postal Code
4. Click OK.
Step 8: Move the Fields in the Section
Use the green arrows to position the fields in the following order:
FIGURE 6.10 SEQUENCE OF FIELDS
Step 9: Change the Labels of the Fields
For each of the fields in the Secondary Address section:
1. Click the field to select it, then click Change Properties (double-
clicking on the field does the same thing).
2. Remove the text “Address 2: “ from the Label.
3. Click OK.

Step 10: Adjust Field Layout Properties
For each of the five Contact Methods listed in the Administration Tab, you want
to adjust its format from two columns to one. Since the format for the section is
locked once the section has been added, you must first remove the section, and
then add it back with a different formatting property.
1. Select the Contact Method section. Click Change Properties.

2. Click the Formatting tab. Note the Section Layout is set to Variable
Field Width. Click Cancel.
3. Click Remove to remove the tab. Click OK to confirm.
4. Click Add a Section.
5. Enter the following properties on the Add a Section dialog box, then
click OK. Click the green Up arrow to move the Contact Method
section below the Billing Information section.
FIGURE 6.11 SECTION FORMATTING PROPERTIES
6. Click Add Fields. Select the following fields and click OK.
a. Do not allow Bulk E-mails
b. Do not allow Bulk Mails
c. Do not allow E-mails
d. Do not allow Faxes
e. Do not allow Mails
f. Do not allow Phone Calls
g. Preferred Method of Contact
7. For each of the “Do not allow” fields, select the field and click
Change Properties.
8. On the Display tab, change the label to “No <Label>.” Example:
“Do not allow Bulk E-Mails” becomes “No Bulk E-mails.”
9. On the Formatting tab, set Control Formatting to “Checkbox.”

Step 11: Verify Your Changes Using the Form Preview
To see how the changes you made to the Account form will look once you
publish them, use the Preview option on the menu bar.
1. On the menu bar, click Preview, then click Create Form to preview
customizations.
2. Verify the changes you made, then close the Create Form.
3. On the Forms and Views page, click Save and Close.
Step 12 - Update the Preview form
1. On the Forms and Views page, double-click Preview.

2. On the Preview form, click Add Fields.
3. On the Add Fields dialog box, select the Business Type field. Click
OK.
Step 13 - Save, Publish and Verify Customizations
1. On the Forms and Views page, click Actions on the menu bar, then
click Publish.
2. Navigate to Workplace and create an Account record to confirm your
changes to the Account form.
3. View the Active Accounts. Open the Preview form for a record and
verify that the Business Type field is displayed..

Lab 6.1 - Form Customization

The objectives of this lab include:
• Explaining to a customer what form elements can be changed as part

of the Microsoft Dynamics CRM customization tool.
• Modifying various User Interface elements on a form to meet a
customer's specific business requirements including tabs, sections,
attributes, labels and formatting.
• Knowing the Microsoft Dynamics CRM User Interface design
constraints and being able to explain these to a customer who may
request unsupported customizations.
Scenario

Adventure Works Cycle, has recently had Microsoft Dynamics CRM installed
but it is not yet customized to meet their business requirements. You are in a
CRM design review meeting with the customer team members who are
responsible for customer tracking but who have no exposure to Microsoft
Dynamics CRM form customization or potential user interface changes.
However, the customer does have a legacy customer tracking system as their
point of reference.
Adventure Works’ goals for this project include:
• Understanding the extent to which Microsoft Dynamics CRM forms

can be customized
• Customizing their customer screens to make them efficient and
productive for their users
• Allowing you to make changes while they witness how simple the
application is to customize.
You decide to start with the Contact form and explain to the customer the focus
of this exercise is on basic form customization and changes to the user interface.
Later, you will be making changes to the database and fields (called attributes)
and creating new fields to be added to forms.
Goal Description
Since the customer has not yet seen the extent to which Microsoft Dynamics
CRM forms can be customized, you start the exercise with an explanation and
then demonstrate the customization capabilities.

What basic form changes do you decide to show the customer?
Based on your demonstration, the customer asks you to make the following
changes to the Contact form while they observe the customization process:
• Create a new tab named “Personal” between the Details and

Administration tabs.
• Move the Personal Information section to the new Personal tab.
• Add the following fields to the Personal Information section:
Children's Names, Number of Children, and Nickname.
• Remove the following fields from the Personal Information section:
Marital Status and Anniversary.
• Add a section on the Personal tab named “Home Address” beneath
the Personal Information section. Ensure that the section name and
divider line is displayed for this section.
Add the following “Address 2:” fields to this section: Street 1, Street
2, City, State/Province, and Zip/Postal Code. Rearrange these fields
into a logical order. Change each of the field labels to eliminate the
“Address 2:” designation.
• Remove the following fields from the Address section on the
General tab: Address Type, Shipping Method, and Freight Terms.
Rearrange the remaining Address section fields in a logical order so
they take less space on the form. Change the label of the Phone field
to “Main Phone”.
• Move the Home Phone field from the General tab to the new Home
Address section.

• Create a new section at the bottom of the Administration tab named

“Tracking”. Ensure that the section name and divider line are
displayed.
Select Fixed Field Width as the Section Layout. Select Two Columns
(1:1) as the Column Format. Add to this section the following fields:
Created By, Created On, Modified By, and Modified On.
• Rearrange the fields in the Marketing Information section of the
Administration tab so they take up less space on the form.
• Remove the Billing Information section on the Administration tab.
Upon further review of the Administration tab, Adventure Works is concerned

that it is overloaded with fields and will require the user to scroll down too far to
enter data. They have asked you to rearrange the Contact Methods section so that
the fields are in two columns instead of one. By having two fields per line, the
length of the tab can be reduced by three lines.
What is your response to Adventure Works, and how can you accommodate their
request?
Adventure Works has also requested the following changes to the Contact's
Preview form:
• Remove the Fax number and add the following fields: Nickname,
Job Title, Manager, and Manager Phone fields.
• Arrange the fields so they appear in the following order:
– left column, top to bottom: Street 1, Street2, City,
State/Province, and ZIP/Postal Code, Relationship type.
– right column, top to bottom: Nickname, Job Title, Mobile
Phone, Home Phone, E-mail, Manager, and Manager Phone.
After these customer changes are implemented on the Contact entity, you should
publish the changes and test the functionality by creating a new Contact record,
adding some data, and viewing the Contact's Preview form.

Adventure Works previously developed their own sales force automation system.
Because of their experience in developing this legacy system, they have asked for
the following user interface customizations to the Contact form:
• Placing all fields on the Account form on one tab

• Adding fields on this form from other entities
• Displaying the same field multiple times on different tabs on the
Contact form
• Changing field colors and fonts
• Adding their company logo to the form
After studying their request, you realize the requested changes are not part of the
standard customization toolkit and are both unsupported and not recommended.
How do you explain the advantages and constraints of the Microsoft Dynamics
CRM user interface design to the customer?
Challenge Yourself
Based on the instructions in the Goal Description, perform the following steps to
complete this lab:
1. Create a Personal tab on the Contact form based on the design

specifications in the Goal Description.
2. Update the General tab.
3. Update the Administration tab.
4. Update the Contact's Preview form.
5. Publish the changes to the Contact entity.
6. Test the functionality by creating a new Contact record and adding
some data. Then view all active contacts and test the Preview form
changes on one of the records.

Need a Little Help?

Step 1 - Create a Personal tab
1. Navigate to the Customize Entities menu and select the Contact

entity.
2. Open Forms and Views, and then open the Contact Form.
3. Create a new tab named “Personal” between the Details and
Administration tabs.
4. Move the Personal Information section from the Details tab to the
new Personal tab.
5. Add the following fields to the Personal Information section:
Children's Names, No. of Children, and Nickname.
6. Remove the following fields from the Personal Information section:
Marital Status and Anniversary.
7. Add a section on the Personal tab named “Home Address” beneath
the Personal Information section. Be sure the section name and
divider line are displayed for this section. The section layout must be
Variable Field Width.
8. Add the following “Address 2” fields to the Home Address section:
Address 2: Street 1, Address 2: Street 2, Address 2: City, Address 2:
State/Province, and Address 2: Zip/Postal Code.
9. Rearrange these fields into a logical order. The Street 1 and Street 2
fields must appear on the first line (left to right) of the section, the
City and State/Province must appear on the second line, and the
ZIP/Postal Code on the third line.
10. Change each of the field labels to eliminate the “Address 2:”
designation.
Step 2 - Update the General tab
1. Remove the following fields in the Address section: Address Type,

Shipping Method, and Freight Terms.
2. Rearrange the remaining Address section fields in a logical order so
they take less space on the form: line one (left to right) - Address
Name and Street 1, line two - Street 2 and Street 3, line three - City
and State/Province, line four - ZIP/Postal Code and Country/Region,
and line five - Phone.
3. Change the label of the Phone field to “Main Phone”.
4. Move the Home Phone field from the top section of the General tab
to the new Home Address section.

Step 3 - Update the Administration tab
1. Create a new section at the bottom of the tab named “Tracking”.

Ensure that the section name and divider line are displayed. Select
Fixed Field Width as the Section Layout. Select Two Columns (1:1)
as the Column Format.
2. Add to this section the fields: Created By, Created On, Modified By,
and Modified On.
3. Rearrange the fields in the Marketing Information section so they
take up less space on the form.
4. Remove the Billing Information section.
5. Save the Contact form.
Step 4 - Modify the Contact's Preview form
1. On the Contact's Forms and Views page, open the Preview form.
2. Apply the following changes to the Contact's Preview form:
a. Remove the Fax field.
b. Select the Add Fields option and select the following fields:
Nickname, Job Title, Manager, and Manager Phone fields.
c. Arrange the fields so they appear in the following order:
• left column, top to bottom: Street 1, Street2, City,
State/Province, ZIP/Postal Code, Relationship type.
• right column, top to bottom: Nickname, Job Title, Mobile
Phone, Home Phone, E-mail, Manager, Manager Phone.
d. Save and Close the Preview form.

e. Publish all the changes to the Contact entity and test the new
form and preview functionality.
Step by Step
Step 1 - Create a Personal tab
1. On the Navigation Pane, click Settings, click Customization, click

Customize Entities, double-click Contact, click Forms and Views,
and then double-click Form.
2. To create a new tab, click Add a Tab in the Common Tasks area.
3. In the Add a Tab dialog box, enter Personal in the Name field. Click
OK.
4. The new Personal tab is displayed. Click the left green arrow twice
to move the tab between the Details and Administration tabs.
5. Click the Details tab.

6. Click the Personal Information section. A green box will appear

around the section. Click Change Properties in the Common Tasks
area.
7. In the Section Properties dialog box, click the drop-down arrow on
the Tab field. Select Personal. Click OK.
8. The Personal tab is displayed, and it should now include the Personal
Information section, which is selected by default (the green box
outlines the section).
9. To add new fields to the section, click Add Field in the Common
Tasks area.
10. In the Add Fields dialog box, select the following fields: Children's
Names, Nickname, and No. of Children. Because the Personal
Information section of the Personal tab was selected when you
clicked Add Fields, this section and tab will be pre-filled in the
Location fields. If this tab and section are not displayed, select them
from the drop-down lists. Click OK.
11. To remove the Marital Status field, click on the field to select it.
The field will be outlined in a green box. Click Remove in the
Common Tasks area. Click OK on the confirmation dialog box.
Repeat this step for the Anniversary field.
12. To add a new section on the Personal tab named “Home Address”,
click Add a Section in the Common Tasks area.
13. In the Add a Section dialog box, enter Home Address in the Name
field. Select the Label option to Show the name of this section on
the form. Select the second Label option to Show divider line
below the section name.
Verify the Tab field is prefilled with Personal; if not, select Personal
from the Tab drop-down list. In the Formatting tab, the section
layout must be Variable Field Width. Click OK.
14. Select the Home Address section on the tab. To add the Address 2
fields to this section, click Add Fields in the Common Tasks area.
15. In the Add Fields dialog box, select the following fields: Address 2:
Street 1, Address 2: Street 2, Address 2: City, Address 2:
State/Province, and Address 2: Zip/Postal Code. Because the
Home Address section of the Personal tab was selected when you
16. Rearrange these fields into a logical order. The Street 1, Street 2, and
City fields must appear on the left-hand column (top to bottom), and
the State/Province and ZIP/Postal Code must appear top to bottom
on the right-hand column.
17. Click on the Address 2: Street 1 field. To change the address field
label to eliminate the “Address 2:” designation, click Change
Properties. In the Label field, remove the “Address2:” portion of the
label. Click OK. Repeat for the other address fields.

Step 2 - Update the General tab
1. Click the General tab.

2. In the Address section, click on the Address Type field to select it.
Click Remove. Click OK to confirm. Repeat these steps for the
Shipping Method and Freight Terms fields.
3. Rearrange the remaining Address section fields in a logical order so
they take less space on the form. Using the green arrows in the
Common Tasks area, move the fields so they appear in the following
sequence (top to bottom, left-hand column): Address Name, Street 1,
Street 2, and Street 3; (top to bottom, right-hand column), City,
State/Province, ZIP/Postal Code, Country/Region, and Phone.
4. Click the Phone field. Click Change Properties.
5. In the Field Properties dialog box, change the label to Main Phone.
Click OK.
6. Click the Home Phone field. Click Change Properties.
7. In the Field Properties dialog box, click the drop-down arrow for the
Tab location. Select Personal. Click the drop-down arrow for the
Section. Select Home Address. Click OK.
Step 3 - Update the Administration tab
1. Click the Administration tab.

2. To add a new section on the Administration tab named “Tracking”,
click Add a Section in the Common Tasks area.
3. In the Add a Section dialog box, enter Tracking in the Name field.
Select the Label option to Show the name of this section on the
form. Select the second Label option to Show divider line below
the section name. Verify the Tab field is prefilled with
Administration; if not, select Administration from the Tab drop-
down list.
4. Click the Formatting tab.
5. Select Fixed Field Width as the Section Layout. Select Two
Columns (1:1) as the Column Format. Click OK.
6. The Tracking section will be displayed on the tab. Select the section,
then click Add Fields in the Common Tasks area to add fields to the
section.
7. In the Add Fields dialog box, select the following fields: Created
By, Created On, Modified By, and Modified On. Since the
Tracking section of the Administration tab was selected when you

8. In the Marketing Information section, rearrange the fields so they

take up less space on the form. Click on the Last Date Included in
Campaign field, and then click the green Right arrow.
9. To remove the Billing Information section, click on the section to
select it. Click Remove, and then click OK to confirm.
10. Click Save on the Contact form's menu bar.
the changes you just made.
12. Close the Create Form.
13. If the changes are correct, click Save and Close on the Contact
form's menu bar.
14. Click Save on the Entity: Contact window.
Step 4: Update the Preview form
1. On the Contact's Forms and Views list, double-click the Preview

form.
2. Select the Fax field.
3. In the Common Tasks area, click Remove. Click OK to confirm the
deletion.
4. In the Common Tasks area, click Add Fields.
5. In the Add Fields dialog box, select the following fields: Job Title,
Manager, Manager Phone, and Nickname. Click OK.
6. Using the green arrow buttons, arrange the fields so they appear in
the following order:
• left column, top to bottom: Street 1, Street2, City,
State/Province, ZIP/Postal Code, Relationship type.
• right column, top to bottom: Nickname, Job Title, Mobile
Phone, Home Phone, E-mail, Manager, Manager Phone.
7. Save and Close the Preview form.

8. Save and Close the Contact's Forms and Views.
9. Publish the Contact customizations.
Step 5: Test the New Functionality
1. To test the functionality, create a new Contact record. From the

Navigation Pane, click Sales, click Contacts, and then click New.
2. Enter data for a new contact (use your name and address
information). Enter data in the Personal tab. Click on the
Administration tab. Note how the fields in the Tracking tab are read-
only because they are system maintained fields. Click Save and
Close.
3. On the Contacts page, click the View drop-down and click on the
Active Contacts view. Select any record, and then click on the
Preview form icon. Confirm the new fields are visible and in the
correct order.

View Customization Overview

Views are a type of saved query where the results are presented to the user in a
grid. Each view is based on filter criteria which return the subset of records that
satisfy the filter rules. The following are examples of views for the Account
entity:
• Accounts with no campaign activities in the last three months

• Accounts with no orders in the last six months
• Active Accounts
• Inactive Accounts
• My Accounts
Types of Views
There are three primary types of views: public, system, and personal. Only the
public and system views can be customized using the Microsoft Dynamics CRM
customization tools.
• Public views. These are the views that are provided with the
application, as well as custom views an organization creates. For
each entity, you can define one of its public views as the default
view for that entity. The default view is displayed when a user
selects that entity in the navigation bar of the application.
• System views. There are four additional system-defined views for
each entity. These system views are used in unique situations within
the application:
– Associated view
– Advanced Find view
– Lookup view
– Quick Find view

• Personal views. Each user can create his or her own queries using
the Advanced Find tool. These can be “one-time” queries that the
user does not save, or they can be saved as one of the user's personal
views. Saving an Advanced Find query as a personal view allows the
user to access the view at any time in the future.
Users can also share their personal views with other users. Using the
Advanced Find tool to create personal views is covered in the
Applications in Microsoft Dynamics CRM training offering.
FIGURE 6.12 ACCOUNT VIEWS
System Views
The four system views described earlier are unique to each entity. These views
are provided as part of the application, and each is designed for use in a specific
situation. Because these are not public views, they are not displayed in an entity's
View menu. Each of the four system views is discussed below.
Associated View
An entity's associated view can be seen when you observe related entities. In
other words, this is the view of an entity that is displayed from within another
entity.
For example, if you open an Opportunity record, the application allows you to
view the Associated views for Activities, Quotes, Orders, and Invoices that are
associated with that Opportunity record. If you select Activities, the system
displays the Activity associated view. This displays all Activities associated with
that Opportunity. If you select Invoices, the system displays the Invoice
associated view. This displays all Invoices related to that Opportunity.

There is only one associated view for each entity. In the previous example, the
Invoice associated view that is displayed for a given Opportunity is the same
Invoice associated view displayed for a given Order or a given Quote. The figure
shows the Invoice's Associated view.
FIGURE 6.13 INVOICE ASSOCIATED VIEW
Advanced Find View
The Advanced Find view represents the information displayed by default for an
entity when a user creates an Advanced Find query. Although an end-user can
customize the view used during the Advanced Find operation, the default view
used as the starting point for the advanced find is the Advanced Find view
discussed here.
The user interface for customizing the Advanced Find view is similar to the user
interface for modifying any other view, with one exception. For custom public
views that you create, you must define the filter criteria associated with the view
that makes it unique (for example, all Western Region Accounts). However,
because the filter criteria for Advanced Find queries is defined by end-users at
the time they perform the search, the Advanced Find view does not include pre-
defined filter criteria like public views.
FIGURE 6.14 INVOICE ADVANCED FIND VIEW
Lookup View
A Lookup view is displayed after you click a lookup button to search for all
records for a given entity. You can add additional columns to the lookup view to
quickly find data that can differentiate similar records. For example, when
creating a new Opportunity record, you can click a lookup button to select the
Currency associated with that particular opportunity. This opens a Look Up
Records dialog box that displays the Currency Lookup view.

The figure shows the Account lookup view. When customizing the Lookup view
for an entity, you can define the columns to be returned, the sorting criteria, and
the Find Columns. Find Columns assist users in locating the records using the
search criteria window. This topic is covered later in this lesson during the Find
Columns discussion.
FIGURE 6.15 INVOICE LOOKUP VIEW
Quick Find View
When using the quick find feature for an entity, the results are displayed in the
entity's Quick Find view. In the View menu, this is referred to as “Search
Results.” When customizing this view, you can define the columns to be
returned, the sorting criteria, and the Find Columns.
FIGURE 6.16 INVOICE QUICK FIND VIEW
Views have the following attributes that can be customized:
• View Properties. Each view for an entity must have a unique name.
You can also include a description for the view.
• Filter Criteria. Each View has filter criteria defined. This filter
definition uses the same user interface as the Advanced Find tool.
The entity attributes used in the filter criteria do not need to be
included in the results of the view. For example, if you have a view
called “Inactive Accounts” there is no need to include the Status
attribute in the view because by definition the state attribute value
must always be “inactive.”
• Columns. You can define which columns are displayed in the view.
This is typically the most common customization made to existing
views. You can also define the column position and width.

• Find Columns. For Quick Find and Lookup views, you can specify
which columns in the view must be used when searching the records
to be displayed. This is a valuable feature that can easily be
overlooked because there is no visual cue for the user to let him or
her know which fields are searchable. For example, when searching
for accounts users can employ the following default searchable
fields: Account Name, Account Number, and Email. But if users also
want to apply the Account telephone number or city name, those
fields can be added as Find Columns in the Account Quick Find
view. Note: The Find Columns do not need to be attribute columns
that are included in the view.
• Sorting. Any column in a view can be set with a default sort criteria.
Users, in turn, can re-sort the data by clicking on the heading of any
column.
View Customization
This lesson examines the procedures involved in adding a new view and
customizing an existing view, including the system-defined views discussed
earlier.
To add a new view or customize an existing view, you must first navigate to the
Forms and Views page for the entity being customized. You can then request a
new view, or open an existing view.
1. In the Navigation Pane, click Settings, click Customization, and

2. Open the entity for which you want to either create a new view or
edit an existing view.
3. Under the Details pane, click Forms and Views. If Forms and
Views does not appear, you cannot add or edit views for the entity
you selected. The Forms and Views window displays all existing
views for the entity, along with the entity's form.
4. If you want to customize an existing view, double-click on the view.
5. If you want to add a new view, click New on the Actions menu.
a. In the Provide Information for This View dialog box, enter a
unique name for this view. You can optionally enter a more
detailed description of the view.
b. Click OK.

Common Tasks when Customizing Views

Whether you are adding a new view or customizing an existing view, the
application opens the customization form for the view you are processing. All of
the tasks you can perform to customize the new or existing view are included in
the Common Tasks area. These tasks include:
• View Properties. Use this task to change the name or description of

the view.
• Edit Filter Criteria. You can only change the filter criteria on
public views. This task does not appear in the Common Tasks area
when you open a system view. Customizing the filter criteria uses
the same user interface as the Advanced Find query.
• Configure Sorting. From the Column drop-down list, select the
column you want to sort on, and then select if the records need to be
sorted in ascending or descending order.
• Add Columns. In the Add Columns dialog box, select the attributes
that you want to include in the view. In addition to displaying the
entity's attributes, you can also display the attributes of related
primary entities.
If the entity to which the view pertains is the related entity in a 1-to-
Many relationship, then you can also select the primary entity in that
relationship from the Record Type drop-down list in the Add
Columns dialog box. All of the attributes for that primary entity will
be displayed for you to select as well. For example, an Opportunity
view can be modified to display the telephone number of the
associated customer account.
• Change Properties. This option allows you to change the width of a
column. Click on the heading of the column that you want to
customize. This selects the column and displays a green box around
the column. In the Change Column Properties dialog box, select the
width of the column in pixels from the options provided.
• Remove. This option allows you to remove a column from the view.
Click on the column heading to select the column, then click
Remove.
• Move a Column. Click on a column to select it, then click the green
right or left arrow to move the column to a different location.
Setting the Default View for an Entity

One other task is available when customizing views; however, this task is not
included in the Common Tasks area of the customization form. For each entity,
you can select which public view will be the default view displayed for that
entity when a user selects the entity on the navigation pane.

Only the public views are eligible to be set as the default view. On the Forms and
Views list for an entity, the Type column identifies the type of each view. The
existing default view is assigned the type “Default Public View”. The four
system views (Associated, Advanced Find, Lookup, and Quick Find) cannot be
set as the default view for the entity.
If an entity has a “My <entity name>” view (such as My Accounts), then this
view is typically set as the application's default view for that entity. However, by
performing the following steps, you can change an entity's default view:
1. In the Forms and Views list for an entity, select the Public view you
want to set as the default.
2. On the Actions toolbar, click More Actions, and then click Set
Default.
3. Click Save or Save and Close on the Entity form.

Demonstration - View Customization

This instructor demonstration illustrates how to create and edit views. Steps are
provided so you can follow along with the instructor.
Scenario
Adventure Works Cycle has requested a number of Account view customizations

that will make their users more efficient.
• Open Service Cases. The Customer Service team has requested a

new view of Accounts with open Service cases. The view must be
called “Open Service Cases”.
• Account Number. Adventure Works uses the Account Number field
extensively in their interactions with customers where they want the
ability to:
– See the Account number displayed by default in the Account's
Associated View and Advanced Find View.
– Enter an account number as a search criteria when doing a
lookup to associate Account records and when doing a quick find
of Accounts.
• City and Phone Number. When looking up accounts, users want to

enter the city or telephone number in the “Look for:” search to
quickly locate records using either of those criteria.
Goal Description
Adventure Works has requested that you make the following view
customizations for the Account entity:
• Create a new Public View. Create a new Account view called

“Active Service Cases.” The default sorting criteria must be
ascending Account Name sequence. The filter criteria must include
all Accounts with associated Cases that have a status of Open. The
view must display the following columns:
– Account Number
– Account Name
– Primary Contact
– Main Phone
• Customize the Associated View. Add Account Number as the first

column displayed in the Account Associated view.
• Customize the Advanced Find View. Add Account Number as the
first column displayed in the default Advanced Find view

• Customize the Lookup View. Include City in the Find Columns for
the Account Lookup.
• Customize the Quick Find View. Include the City field from the
account's address along with the account's telephone number as
search fields for the Quick Find view
Step by Step
Each of these steps begins on the Forms and Views list for Accounts. To locate
this form, click Settings, click Customization, click Customize Entities,
double-click Account, and then click Forms and Views.
Step 1: Create a new Public View
1. Click New to define a new view. Enter the following view

properties:
a. Name: Active Service Cases
b. Description: A public view requested by the Service team. This
will display Accounts with open Service Cases.
2. Click Add columns and select the following attributes from the
Account entity:
a. Account Number
b. Primary Contact
c. Main Phone
3. Click OK.
4. Position the Account Number column to the left by selecting it (if it
is not already selected) and using the green Left arrow to move it.
5. Click Edit Filter Criteria, then click Select and enter the following
search criteria:
a. Related : Cases (Customer)
b. Status = Active
6. Click OK.
7. Save and Close the New: View window.
8. Save and Close the Account's Forms and Views.
9. Publish the customizations to the Account entity.
10. Confirm that view is available in the View menu for Accounts.

Step 2: Associated Views
1. Open the Account's Associated view.

2. Click Add columns and add the Account Number field. Click OK.
3. Move the Account Number column to the left by using the left green
arrow to move it.
4. Save and Close the view.
6. Publish Account customizations.
7. Confirm the new associated view displays the Account number
column by locating an Account with Sub-Accounts. In the sample
data, Lots of Bikes Storehouse has The Cycle Store as a sub-account.
8. When viewing a parent account record, verify that the list of
accounts viewed from the Sub-Accounts side-tab displays the
Account Number on the far left side.
Step 3: Advanced Find View
1. Open the Account's Advanced Find view.

2. Click Add columns and add the Account Number field.
3. Position the Account Number Column to the left by selecting it and
using the left green arrow to move it.
4. Save and Close the view.
7. Confirm that the new default Advanced Find view displays the
Account number column by performing an Advanced Find search.
When you perform the Search, select “[new]” before you construct a
query.
Step 4: Lookup View
1. Open the Account's Lookup View.

2. Click Add Find Columns and select Address 1: City.
3. Click Add View Columns and select Address 1: City. Click OK.
4. Save and Close the Account Lookup View.
7. Test that the Find Column functionality works by performing a
Lookup and entering Redmond in the search field. Verify that the
records displayed have Redmond listed as the city of each account.

Step 5: Quick Find View
1. Open Quick Find Active Accounts.

2. Click Add Find Columns and select Owner. Click OK.
3. Click Add View Columns and select Owner. Click OK.
4. Save and Close the Quick Find Active Account View.
7. From the Navigation Pane, select Sales, then Accounts.
8. Test that the Find Column functionality works by performing a
Quick Find search on a specific owner. Enter alan in the Look For
field, then click Find. Verify that the records displayed have Alan
Jackson listed as the owner of each account.

Lab 6.2 - View Customization

• Explain to a customer what Microsoft Dynamics CRM views are and

how the parameters on views can be changed during the
implementation
• Make changes to an existing view
• Add columns to a view from related entities
• Create new public views
• Make changes to the Preview form
• Make changes to an Associated View
• Add a “find column” to the Quick Find View
• Change which view is designated as the default view for an entity
• Make changes to an Advanced Find View
Scenario

Adventure Works Cycle, has recently had Microsoft Dynamics CRM installed,
but it is not yet customized to meet their business requirements. You are in a
CRM design review meeting with the customer team members who are
responsible for changes to the User Interface but who have no exposure to
Microsoft Dynamics CRM view customizations or how views can be used to
filter and display their data.
The members of Adventure Works’ project team wants to understand the extent
to which Microsoft Dynamics CRM views can be used and customized. Once
they understand the concept of views, they will be able to inform you about the
views they want created or changed in order to make the system easier to use.
They want to watch you make the changes so they can learn how to maintain
views on their own.
You decide to start with the Account entity to explain to the project team how
views are used and can be customized.
Goal Description
Since the customer has not yet seen the extent to which Microsoft Dynamics
CRM views can be used and customized, you start the exercise with a
demonstration of Account views.

What basic features of CRM views do you decide to show the customer?
Based on your demonstration, Adventure Works’ project team asks you to make
the following changes to Account views. You make these changes while the team
members observe the customization process.
• Make the following changes to the Active Accounts view:

– Add Relationship Type as a column
– Add Owner as a column
– Remove the Main Phone column
– Add the Primary Contact’s Job Title as a “related column” to the
immediate right of the Primary Contact column
– Expand the width of the Job Title column heading to display the
entire text
• Create a new public view with the title “Active Customers”. The
view should have the following columns (in this order):
– Account Name
– Primary Contact
– Job Title (Primary Contact)
– Address 1: City
– Owner
– Relationship Type
• The view should have the following properties:

– Filter of Relationship Type = Customer only
– Sort by Address 1: City in ascending sequence
• Set the default view for Accounts to be Active Accounts instead of

My Active Accounts.
• Add the “Address 1: City” attribute and “Main Phone” attribute as
Find Columns on the Quick Find Active Accounts view.

• Add the column “Relationship Type” to the Account's Advanced

Find view.
• Use Advanced Find to create a personal Accounts view that has the
following properties:
– Filter on Status = Active and Credit Hold = Yes
– Add the column “Credit Limit” and display it to the right of
Account Name
– Name this new view “Accounts on Credit Hold”
– Test that it appears in the Account's View menu under My
Views, and validate that it functions properly
• Add Job Title and Role columns to the Contact's Associated View.
Change the following properties for this view:
– The column order left to right must be Full Name, Job Title,
Role, and Business Phone
– Job Title must have a width of 150px
You must publish and test each change as it is made.
Challenge Yourself
complete this lab:
1. Modify the Active Accounts view.

2. Create a new public view titled Active Customers.
3. Change the Account's default view.
4. Modify the Account's Quick Find view.
5. Modify the Account's Advance Find view.
6. Create an Advanced Find query and save it as a personal Accounts
view.
7. Modify the Contact's Associated view.
You can either publish and test the changes that you make following each step, or
complete all of the changes first, then publish and test the changes at one time.
Need a Little Help?

Step 1 - Modify the Active Accounts view
1. In the Account entity, make the following changes to the Active

Accounts view:
a. Add Relationship Type as a column
b. Add Owner as a column

c. Remove the Main Phone column

d. Add the Primary Contact’s Job Title as a “related column” to the
immediate right of the Primary Contact column
e. Expand the width of the Job Title column heading to display the
entire text
2. Publish and test the new functionality.
Step 2 - Create a new Accounts view
1. Create a new public view titled Active Customers that has the
properties defined in the Goal Description.
Step 3 - Change the Account's default view
1. Set the default view for Accounts to be Active Accounts instead of

My Active Accounts.
Step 4 - Modify the Account's Quick Find view
1. Add the “Address 1: City” attribute and “Main Phone” attribute to

the Quick Find Active Accounts’ “Find Columns”.
Step 5 - Modify the Account's Advanced Find query
1. Modify the Account's Advanced Find query by adding the column

“Relationship Type”.
2. Publish the change and test following completion of the next step.
Step 6 - Save an Advanced Find query as a personal view
1. Create a new Advanced Find query to display all Accounts with the
a. Status = Active and Credit Hold = Yes
b. Add the column “Credit Limit” and display it to the right of the
Account Name.
2. Save this query as a personal Account view with the name “Accounts
on Credit Hold”.
3. Publish and test the new functionality. Verify that this view appears
in the Account View menu under the My Views section. Verify that
the Relationship Type field that was added in the prior step to the
Account's Advanced Find view appears.

Step 7 - Modify the Contact's Associated view
1. Apply the following changes to the Contact Associated view:

a. Add columns to display the Job Title and Role to the Contact's
Associated View.
b. The column order left to right must be Full Name, Job Title,
Role, and Business Phone.
c. Job Title must have a width of 150px.
Step by Step
Step 1 - Modify the Active Accounts view
In the Account entity, make the following changes to the Active Accounts view:
1. In the Navigation Pane, click Settings, click Customization, then

click Customize Entities.
2. Double-click on the Account entity to open it. Click Forms and
Views.
3. Double-click on the Active Accounts view.
4. Click Add Columns in the Common Tasks area. Select the
following fields:
a. Relationship Type
b. Owner
5. Click OK.
6. To remove the Main Phone column, click on its column heading,
then click Remove. Click OK to confirm the deletion.
7. Click Add Columns to add the Primary Contact’s Job Title as a
“related column”. Display this field to the immediate right of the
Primary Contact column.
8. In the Record Type field at the top of the Add Columns dialog box,
select Primary Contact (Contact).
9. In the list of Primary Contact attributes, select Job Title and click
OK.
10. Select the Job Title (Primary Contact) column heading to select it.
Click the green left arrow as needed to move the column to the
immediate right of the Primary Contact column.
11. With the Job Title (Primary Contact) heading still selected, click
Change Properties.
12. Select 150px as the column width. Click OK.
13. Click Save and Close on the Active Accounts view.

14. Click Save and Close on the Account's Forms and Views.
15. Because Account is already selected on the Customize Entities list,
click Publish to publish all Account customizations.
16. Test the change by opening an existing account. If the Primary
Contact field is empty, click the lookup button on the Primary
Contact field.
17. Click New and create a new contact. Enter the contact's name and
primary job title. Click Save and Close.
18. On the Accounts view, select Active Accounts from the View menu.
19. Verify the primary contact and his or her job title is displayed in the
Active Accounts view.
Step 2 - Create a new Accounts view
Create a new public view titled Active Customers with the properties defined in
1. Navigate back to Settings, then Customization, then Customize

Entities. Double-click Account, and then click Forms and Views.
2. Click New.
3. In the Provide Information for this View dialog box, enter Active
Customers as the name of the view. Click OK.
4. Click Add Columns and select the following columns:
a. Primary Contact
b. Address 1: City
c. Owner
d. Relationship Type
e. Change the Record Type to Primary Contact (Contact) and
select Job Title
5. Move the Primary Contact heading to the right of Account Name.

Move the Job Title (Primary Contact) heading to the right of the
Primary Contact.
6. Expand the width of the Job Title (Primary Contact) heading so
that the entire text is displayed. Click Change Properties and
change the width of the Job Title column to 150px. Click OK.
7. To customize the filter properties, click Edit Filter Criteria in the
Common Tasks area.
8. In the Edit Filter Criteria dialog box, click Select. From the list of
Fields, select the Relationship Type field. Click OK.
9. Click the Enter Value link. Click the ellipsis button to the right of
the value field. In the Select Values dialog box, click on Customer,
then click the right arrow to move it into the Selected Values
column. Click OK.
10. Click OK to close the Edit Filter Criteria window.

11. To change the sort properties, click Configure Sorting in the

Common Tasks area.
12. In the Configure Sort Order dialog box, click the Column drop-
down arrow and select Address 1: City from the list. Click OK.
13. Click Save and Close on the Active Customers view.
16. To test the new view, click Sales, click Accounts, and then Active
Customers from the View menu.
17. Verify that the view is available in the Account's View menu, and
that it functions as it is supposed to.
Step 3 - Change the Account's default view
Set the default view for Accounts to be Active Accounts instead of My Active
Accounts.

2. In the Forms and Views list, select the Active Accounts view.
3. On the Actions toolbar, click More Actions, and then click Set
Default.
6. To test the new default view, click Sales, and then click Accounts.
The Active Accounts view will be displayed instead of the My
Active Accounts view.
Step 4 - Modify the Account's Quick Find view

2. In the Forms and Views list, and double-click Quick Find Active
Accounts.
3. Click Add Find Columns on the Common Tasks area.
4. In the Add Find Columns dialog box, select Address 1: City and
Main Phone, then click OK.
5. Click Save and Close on the Quick Find Active Accounts view.
8. To test the Preview form, click Sales, then click Accounts. In the
Quick Find lookup field, enter one of the cities or a phone number to
one of the accounts. Click the Lookup icon. Verify the results/

Step 5 - Modify the Account's Advanced Find view

2. In the Forms and Views list, double-click Account Advanced Find
View.
3. Click Add Columns. In the Add Columns dialog box, select the
Relationship Type field, then click OK.
4. Click Save and Close on the Account Advanced Find View.
7. You will test the change in the next step.
Step 6 - Save an Advanced Find query as a personal view
Create a new Advanced Find query to display all accounts on credit hold.
1. On the menu bar, click Advanced Find.

2. On the Advanced Find window, the Look For field is already set to
Accounts.
3. Hold your mouse on the Select link and click to display the list of
available field. Select Credit Hold.
4. Click the Enter Value option. Click the Ellipsis button.
5. In the Select Values dialog box, select Yes and click the right arrow
to move it to the Selected Values column. Click OK.
6. Repeat the process by selecting the Status field, and set its value
equal to Active.
7. Click on Edit Columns.
8. Click Add Columns in the Common Tasks area. In the Add
Columns dialog box, select Credit Limit, then click OK.
9. Use the green arrows to move the Credit Limit field to the right of
the Account Name. Click OK.
10. To save this query as a personal Account view, click Save. In the
Provide Information for this View dialog box, enter Accounts on
Credit Hold as the name. Click OK.
11. Close the Advanced Find dialog box.
12. Verify this view appears in the Account View menu under the My
Views section. Click Sales, then click Accounts. Click the drop-
down arrow for the View menu. Verify that the new view appears
under the My Views group. Select the view to verify it functions
properly. If no accounts appear, then change the view to Active
Accounts, open an account, change its Credit Hold status to Yes, and
then re-test the view.

Step 7 - Modify the Contact's Associated view
Make the following changes to the Contact's Associated view:

Entities. Double-click Contact, and then click Forms and Views.
2. In the Forms and Views list, double-click the Contact Associated
View.
3. Click Add Columns on the Common Tasks area.
4. In the Add Columns dialog box, select Job Title and Role, then click
OK.
5. Using the green arrows in the Common Tasks area, arrange the
columns in the following order (left to right): Full Name, Job Title,
Role, and Business Phone.
6. Select the Job Title column heading and click Change Properties.
7. In the Change Column Properties dialog box, select 150px as the
column width. Click OK.
8. Click Save and Close on the Contact Associated view.
9. Click Save and Close on the Contact's Forms and Views.
10. Because Contact is already selected on the Customize Entities list,
click Publish to publish all Contact customizations.
11. To test the new view, click Sales, click Accounts, and then open an
account record.
12. In the Details pane, click Contacts. This should open the Contact
Associated view. Verify that the changes you made to the view are
present.

Summary
One of the strengths of Microsoft Dynamics CRM is its built-in customization
tool that allows organizations to tailor the application's user interface to meet its
business requirements. This training examined how to customize the Microsoft
Dynamics CRM user interface using this tool. Included in this discussion were
lessons on how to customize the following areas:
• Forms. Forms are used to enter and update data. When customizing
forms, this training examined how to customize the form
components, including tabs, sections within a tab, and fields within a
section.
• Views. This training examined how to customize public views and
several system views, including the Associated View, Advanced
Find View, Lookup View, and Quick Find View.
• Preview forms. Microsoft Dynamics CRM uses Preview forms to
display additional data for each record without actually opening the
record. This training examined how to customize the fields displayed
within a Preview form.

Test Your Knowledge

1. Bob and Lisa are both in the Microsoft Dynamics CRM System
Administrators role. Bob developed some customizations to the Task entity
and saved the changes. Later, Lisa views the Task entity in the
Customizations area. Will she see the changes Bob made?
( ) Yes. She will see the customizations because they were saved
( ) No. She will not see the customizations because they were not published
( ) No. She will not see the customizations because she does not have
privileges to view them
( ) Yes. She will see the customizations but will not be able to make changes
until they are published
2. Which of the following are not customizable on a form?

( ) Tabs
( ) Sections
( ) Fields
( ) Font
3. Which of the following is a difference between the Variable Field Width and
the Fixed Field Width Section Layout options?
( ) The Fixed Field Width option lets you control the height of ntext and
IFrame fields
( ) The Variable Field Width option lets you have three columns in a section
( ) The Variable Field Width option allows ntext and IFrame elements to
expand to fill available space
( ) None of the above.
4. Is it possible to set form fields as "Read-only"?

( ) Yes. This is a field behavior display property on the form.
( ) Yes. You must use client-side code in the form onLoad event.
( ) Yes. You must modify the Attribute definition.
( ) No. Setting a field to Read-only on a form is not possible.
5. How can you control the tab order of fields in the form?
( ) Arrange them with the default tab order: Top to bottom, left column, and
then right column within each section.
( ) Arrange them with the default tab order: Left to right across each row.
( ) Set the TabIndex value in the Attribute definition.
( ) Modify the .aspx page to set the TabIndex property for the field.

6. Which of the following is true about views?

( ) Personal Views and Private views are the same thing.
( ) Each user can set his or her own default view per entity in their personal
options.
( ) Each entity has several Associated Views.
( ) You cannot change the filter criteria for System views.
7. Users want to be able to search for a record using a custom attribute. How
can you make this happen? Choose the best answer.
( ) Save an Advanced Find query using that attribute as a filter criteria and
share the query with every user.
( ) Create a custom application to prompt the user to enter the criteria for a
search.
( ) Add the attribute as a column displayed in the view.
( ) Add the attribute as a Find Column on the entity's Quick Find view.


chapter:
1.
2.
3.

Solutions
Test Your Knowledge
1. Bob and Lisa are both in the Microsoft Dynamics CRM System
Administrators role. Bob developed some customizations to the Task entity
and saved the changes. Later, Lisa views the Task entity in the
Customizations area. Will she see the changes Bob made?
(•) Yes. She will see the customizations because they were saved
( ) No. She will not see the customizations because they were not published
( ) No. She will not see the customizations because she does not have
privileges to view them
( ) Yes. She will see the customizations but will not be able to make changes
until they are published
2. Which of the following are not customizable on a form?

( ) Tabs
( ) Sections
( ) Fields
(•) Font
3. Which of the following is a difference between the Variable Field Width and
the Fixed Field Width Section Layout options?
( ) The Fixed Field Width option lets you control the height of ntext and
IFrame fields
( ) The Variable Field Width option lets you have three columns in a section
(•) The Variable Field Width option allows ntext and IFrame elements to
expand to fill available space
4. Is it possible to set form fields as "Read-only"?

(•) Yes. This is a field behavior display property on the form.
( ) Yes. You must use client-side code in the form onLoad event.
( ) Yes. You must modify the Attribute definition.
( ) No. Setting a field to Read-only on a form is not possible.

5. How can you control the tab order of fields in the form?
(•) Arrange them with the default tab order: Top to bottom, left column, and
then right column within each section.
( ) Arrange them with the default tab order: Left to right across each row.
( ) Set the TabIndex value in the Attribute definition.
( ) Modify the .aspx page to set the TabIndex property for the field.
6. Which of the following is true about views?

( ) Personal Views and Private views are the same thing.
( ) Each user can set his or her own default view per entity in their personal
options.
( ) Each entity has several Associated Views.
(•) You cannot change the filter criteria for System views.
7. Users want to be able to search for a record using a custom attribute. How
can you make this happen? Choose the best answer.
( ) Save an Advanced Find query using that attribute as a filter criteria and
share the query with every user.
( ) Create a custom application to prompt the user to enter the criteria for a
search.
( ) Add the attribute as a column displayed in the view.
(•) Add the attribute as a Find Column on the entity's Quick Find view.
Lab 6.1 - Form Customization

What basic form changes do you decide to show the customer?
MODEL ANSWER - Your answer should include some or all of the
following: •Remove unused /unnecessary fields from the form •Adding a
field onto the form that is already defined in the database •Changing or
hiding a field label •Changing a field to appear as read-only •Moving a field
within a section or to a different section •Changing the format of an field
(such as changing from one column to two, or the number of rows in a multi-
line text field) •Creating a new section •Moving a section within the tab or to
a different tab •Renaming or hiding a section name •Creating a new tab
•Changing the order of tabs •Renaming a tab

Upon further review of the Administration tab, Adventure Works is concerned

that it is overloaded with fields and will require the user to scroll down too far to
enter data. They have asked you to rearrange the Contact Methods section so that
the fields are in two columns instead of one. By having two fields per line, the
length of the tab can be reduced by three lines.
What is your response to Adventure Works, and how can you accommodate their
request?
MODEL ANSWER - You cannot change the layout of the section from one
column to two. Once a section is added to a form, you cannot change its
layout. To accommodate their request, you will have to delete the section,
then add it back to the tab. When you add the section, you would configure
its layout for two columns. Each line in the section could then hold two
fields, which would satisfy Adventure Works’ request.
Adventure Works previously developed their own sales force automation system.
Because of their experience in developing this legacy system, they have asked for
the following user interface customizations to the Contact form:
• Placing all fields on the Account form on one tab

• Adding fields on this form from other entities
• Displaying the same field multiple times on different tabs on the
Contact form
• Changing field colors and fonts
• Adding their company logo to the form

After studying their request, you realize the requested changes are not part of the
standard customization toolkit and are both unsupported and not recommended.
How do you explain the advantages and constraints of the Microsoft Dynamics
CRM user interface design to the customer?
MODEL ANSWER - The answer should include some or all of the
following: •Microsoft Dynamics CRM is not a custom application written
with programmers •It is quick to deploy and easy to customize •No
programming experience needed to customize •By design, the data is
organized on the forms by tabs •Hyperlinks for jumping to other entities
•Further advanced customization is possible using jScripts and .NET
development
Lab 6.2 - View Customization

What basic features of CRM views do you decide to show the customer?
MODEL ANSWER - You answer should include some or all of the
following: - Default views when switching between entities - Switching
views and other available public views - Filtering data - Sorting columns -
Previews - Associated views (e.g. views Contacts from within Accounts) -
Quick Find views - Look Up views - Advanced find and saving personal
views - Changing existing views including adding columns and changing sort
order - Creating new system views


Chapter 7: Customizing Entities and Attributes
CHAPTER 7: CUSTOMIZING ENTITIES AND

ATTRIBUTES
Objectives
The objectives are:
• Review the types of entities and attributes available in system

• Create and edit attributes to meet the business needs of your
organization
• Examine how to create, configure, and delete custom entities
• Configure security settings to control access to and maintenance of
custom entities
Introduction
Microsoft Dynamics CRM allows you to create new entities and attributes
through the application's built-in customization tools. Adding custom entities and
attributes greatly extends your ability to make Microsoft Dynamics CRM support
the business processes for a wide range of organizations. This can be done
quickly and inexpensively because no programming is required.

Customization Concepts
The terms “Table” and “Column” (or “Field”) are oftentimes used in reference to
data that is processed within business applications. However, because Microsoft
Dynamics CRM's foundation is built upon the use of XML, the following terms
are used:
• Entity instead of Table

• Attribute instead of Column or Field
NOTE: The important structures in Microsoft Dynamics CRM are found in the
Microsoft Dynamics CRM platform. The platform is defined in XML, so XML
terms are used when referencing database schema elements.
Entity Types
Microsoft Dynamics CRM allows you to work with the following types of
entities:
• System. System entities are default, or out-of-the-box entities that

are not customizable because the application uses them internally.
Organization, License, and Workflow are examples of System
entities. System entities cannot be deleted.
• Customizable. Customizable Entities are default entities that can be
customized. Account, Contact, Opportunity, and Case are examples
of customizable entities. Customizable entities cannot be deleted.
• Custom. Custom entities are entities that you add to the system.
Once a custom entity has been created, you can modify it using the
same techniques used to modify Customizable entities. Custom
entities can be deleted.
Attributes
Each entity has a number of attributes. In a database, an attribute represents a
particular column within a table. When attributes are presented within a form for
end-users to update, they are referred to as fields.
Attributes can be grouped into the following two types:
• System. System attributes are the default, or out-of-the box attributes

already defined for each entity in Microsoft Dynamics CRM. System
attributes cannot be deleted, <a>but they can be modified.
• Custom. Custom attributes are attributes that you add to the system.
Custom attributes can be modified and deleted.

The definition of an attribute controls how it is displayed in the application. For

example, attribute definition controls the valid values for a picklist. Configuring
attributes is described later in this training.
WARNING: Custom attributes do not work with the Mail Merge feature in
Microsoft Dynamics CRM for Microsoft Office Outlook. The suggested work-
around is to export the results of a view or Advanced Find query containing the
custom attribute data into Microsoft Excel. A Mail Merge can then be prepared
using that document as a data source.
Customizing Attributes
You have two options if Microsoft Dynamics CRM does not have a field that can
be used to fit a specific purpose required by your organization:
• Create a new field by adding a custom attribute; or

• Edit the properties of an existing attribute
After creating a new attribute, you must expose it on the entity's form to make the
attribute available for use on views, reports, and workflow rules. A custom
attribute can be deleted if you later decide that it is no longer needed.
Adding a custom attribute is easy. But consider if any of the existing attributes
that have not been revealed on the entity's form can be used first before creating a
new attribute. The space available to add attributes to entities is not unlimited.
SQL Server Limitations

Custom attributes that are added to an entity are stored in an extension table for
that entity. Although a Microsoft SQL Server table is reserved for entity
extensions on each entity, the number of attributes you can add to the table is not
infinite. Microsoft SQL Server allows up to 1024 columns per table and the
amount of data stored in any row cannot exceed 8060 bytes. It is much more
common to exceed the amount of bytes per row than the number of columns.

The following figure describes the number of bytes used for each attribute data
type.
FIGURE 7.1 SQL SERVER ATTRIBUTE SIZE PER DATA TYPE
NOTE: Each attribute with a Money data type uses 8 bytes. However, when an
attribute with a Money data type is added, a corresponding Base Currency
attribute is automatically added by the system. Therefore, every Money attribute
actually consumes 16 bytes, which consists of the attribute plus its base
currency.
Determine Space Available
If you decide to add a custom attribute to an entity, you can determine if there is
space available for the attribute in the entity's extension table by running this
Transact-SQL query on the <organization>_CRM database.
FIGURE 7.2 TRANSACT-SQL QUERY TO DETERMINE NUMBER OF BYTES

AVAILABLE
Determine Space Used
Alternatively, you can determine the number of bytes already used by custom
attributes for an entity by running this Transact-SQL query on the
<organization>_CRM database:
FIGURE 7.3 TRANSACT-SQL QUERY TO DETERMINE NUMBER OF BYTES

USED

Available Attribute Types

The table titled “Available Attribute Types” lists each of the different attribute
types that you can add to an entity. These attribute types are based on eight
different Attribute types and their related Format options.
NOTE: Some of the attribute type options can be modified after creation in the
Attribute window. The exception is the bit attribute types, which are set through
the form editor.
FIGURE 7.4 AVAILABLE ATTRIBUTE TYPES

Some system attribute types cannot be manually added. However, they may be
automatically created as a by-product from when you create a new entity or
relationship. For example, an entity Lookup field can be created at the time you
create a relationship (relationships are covered later in this training). The attribute
types that you cannot manually add include:
• Status
• State
• Primarykey
• Owner
• Lookup
Attribute Schema Name Prefix

All custom attributes and custom entities have a schema name prefix to
differentiate them from the default entities and attributes. This prefix is used to
coordinate custom entities and attributes during upgrades.
The default schema name prefix is “new.” The prefix and the entity or attribute
name is separated by an underscore, resulting in a default prefix of “new_”
NOTE: You can set the value of this prefix in the System Settings. Click
Settings, then Administration, then System Settings. Select the Customization
tab to locate the Schema Name Prefix field. Configuring this field along with
all other System Settings was covered in the training titled Configuring
Organization Settings.
The value of this prefix can be changed at any time. This gives you the ability to
organize the attributes for a specific project by changing the prefix to a value
representative of the project. This can include custom projects you and/or your
staff complete in-house, as well as custom projects completed by consultants off-
site and imported into your deployment.
EXAMPLE: If a consultant applies a set of customizations, he or she can set

the prefix to a unique value before beginning work and set it back when
completed. This “tags” the entities and attributes to tie them to the group of
customizations the consultant applied. This can differentiate a group of
attributes that were imported together.
Attribute Properties
The figure titled “Primary Attribute Properties” describes the properties available
when creating or editing an attribute. Those items marked with an asterisk cannot
be modified on default attributes or after a custom attribute has been created. The
exception to this is the format for the bit attribute type which is set using the
Form Editor field properties. This is examined later in the training.

NOTE: You cannot change the schema name or type of an attribute after it has
been saved.
FIGURE 7.5 PRIMARY ATTRIBUTE PROPERTIES
The figure titled “Additional Attribute Properties” displays the remaining

attribute properties that are available depending on the attribute type.
FIGURE 7.6 ADDITIONAL ATTRIBUTE PROPERTIES

Attribute Requirement Levels

The figure titled “Requirement Levels” describes the different requirement levels
that can be assigned to an attribute. An attribute's requirement level applies when
a user adds a new record for the given entity. It also controls if the system
administrator or customizer can remove the attribute from the entity's form.
FIGURE 7.7 REQUIREMENT LEVELS
Adding a Custom Attribute

Perform the following steps to add a custom attribute to an existing entity:

2. Open the entity for which you want to create attributes.
3. In the Details pane, click Attributes.
4. To add a new attribute, on the Actions toolbar, click New, and enter
the Display Name. Tab into the Name field. Note that when you tab
into the field, the Name field is automatically filled in for you with
Display Name, less any blank spaces.
5. In Requirement Level, select one of the available requirement
levels.
6. For new attributes, select the Type, and then enter required
information for the specified type.
7. Click Save and Close to close the Attribute form. Note: you do not
have to publish this change because schema changes do not require
publishing.

Editing a System or Custom Attribute

You can edit both custom and system attributes; however, you cannot change the
attribute's schema name or attribute type. Refer to the Attribute Properties table
for information on properties that can be modified.
Perform the following steps to edit an existing system or custom attribute:

2. Open the entity for which you want to edit attributes.
4. To edit an attribute, select the attribute, then on the Actions toolbar,
click More Actions, and then click Edit.
5. Make desired modifications.
6. Click Save and Close to close the Attribute form. Note: you do not
have to publish this change because schema changes do not require
publishing.
Deleting a Custom Attribute

Because of the built-in dependencies between attributes for each entity, the
system has the following guidelines in place that control which attributes can be
deleted:
• Only custom attributes can be deleted.

• System attributes cannot be deleted.
• If a custom attribute that you want to delete has been published on
the entity's form, you must remove the attribute from the form and
publish the form before you can delete the attribute.
• The attribute must be removed from any reports that contain the
attribute.
WARNING: When a custom attribute is deleted, all data stored in that column
of the physical database table in the attribute is irretrievably lost.

If a custom attribute that you want to delete has been referenced by another
object, then all references must be removed before the attribute can be deleted.
The figure titled Reference Error when Deleting an Attribute is an example of an
error message received when attempting to delete an attribute that is still used on
another object.
FIGURE 7.8 REFERENCE ERROR WHEN DELETING AN ATTRIBUTE
Perform the following steps to delete a custom attribute from an existing entity:

2. Open the entity that contains the attribute you want to delete.
4. To delete an attribute, select the attribute, then on the Actions menu
click Delete.
-OR-
Click the Delete button on the toolbar.
5. Click OK on the confirmation message.
IMPORTANT: You cannot delete an attribute that is being used elsewhere in

the application. If you attempt to do this, you will receive an error message
according to the figure titled Reference Error when Deleting an Attribute. The
error message will display all instances where the attribute you are trying to
delete exists.

Demonstration - Creating a Custom Attribute

This instructor demonstration illustrates how to create a custom attribute. Steps
are provided so you can follow along with the instructor.
Scenario
Adventure Works Cycle wants to track the relative difficulty of Tasks that are
assigned to users in Microsoft Dynamics CRM. By analyzing this performance
data, they hope to focus their efforts on process improvements that allow them to
better serve their customers.
Goal Description
As Adventure Works’ implementation consultant, you have been asked to create
a custom attribute on the Task entity that allows end-users to track the difficulty
of each assigned task. The goals of this project include:
• Creating a custom picklist attribute called “Difficulty” on the Task

entity and exposing it on the Task form.
• Making this attribute a required field. This allows each Adventure
Works Cycle user to rate the difficulty of each Task record he or she
creates.
• Assigning a schema prefix of “test_” to this custom picklist field.
The purpose of this prefix is to differentiate the attribute from other
custom entities and attributes that may be added at a later date.
The available values for this Difficulty picklist field include:
FIGURE 7.9 DIFFICULTY PICKLIST ATTRIBUTE VALUES
The default picklist value will be “Moderate”.

Step by Step
Step 1: Set the Schema Name Prefix
Prior to adding a custom attribute, verify that the prefix that will be assigned to
schema name matches your business requirements. For the purposes of this
demonstration, the prefix “test” will be used.
1. Click Settings, click Administration, and then click System

Settings.
2. Select the Customization tab to locate the Schema Name Prefix.
3. Set the Prefix = test.
4. Click OK.
Step 2: Create the Custom Attribute
Perform the following steps to add the custom attribute to the Task entity:
1. From the Navigation Pane, click Settings, click Customization,

click Customize Entities, and then double-click the Task entity to
open it.
3. Click New.
4. Enter the attribute values located in the table titled Difficulty
Attribute Properties.
5. Leave the New Attribute form open to complete to the next step that
assigns picklist values to the new attribute.
FIGURE 7.10 DIFFICULTY ATTRIBUTE PROPERTIES
Step 3: Configure Picklist Options
After adding a picklist attribute, you must then assign each of the possible values
for the picklist field. Perform the following steps to add the Difficulty picklist
attribute values from the table displayed in the Goal Description titled “Difficulty
Picklist Attribute Values.”
1. With the New Attribute form still open, perform the following steps
to add values to the picklist attribute:
a. Click Add.
b. Enter the Label value that corresponds to the numeric value.
c. Click OK.

2. Set the Default Value =“Moderate”

3. Click Save and Close to save the Difficulty attribute form. This
returns you to the Task entity.
NOTE: Before saving the attribute, observe the formats and properties
available for each type of attribute. Notice the options available for each data
type.
Step 4: Add Attribute to the Task form
Once the attribute has been added to the schema for the target entity, you must
then expose the attribute on the entity's form. This enables the attribute so that it
is available for use throughout the rest of the application.
1. Perform the steps covered in the prior training titled Customizing

Forms and Views that describe how to add a field to a form. In this
case, select the form for the Task entity.
2. Add the new Difficulty picklist attribute on the Task tab. Place the
field below the Priority field.
Step 5: Verify Your Work and Publish the Customizations
Prior to saving the change that you made to the form, you should preview the
change to verify that it appears and functions properly.
1. Perform the steps that were covered in the prior training titled
Customizing Forms and Views on how to preview customizations to
the Create form.
2. Select the Difficulty picklist field and verify that the picklist values
appear in the proper order. Also verify that “Moderate” is displayed
as the default value.
3. Save and Close the Task form.
4. Because you customized the Task form, you must Publish the
changes that you made to the Task entity.
5. Test the change by adding a Task Activity record for an Account and
setting the Difficulty value.

Lab 7.1 - Creating a Custom Attribute

• Create a new attribute on a customizable entity

• Add the attribute to the entity's form
• Publish and test the attribute
Scenario

Adventure Works Cycle, has recently had Microsoft Dynamics CRM installed
and it is currently in the beginning stages of customizing the system to meet its
business requirements.
You are in a CRM design review meeting with members of the Customer Service
team. Stefan Del Marco, the Customer Service Manager, discusses a potential
customization to the database schema. Stefan notes that his department's policy
for cases related to service contracts is based on the following service levels
which the customer can purchase:
• Gold. Response time = one hour or less.

• Silver. Response time = two hours or less.
• Bronze. Response time = three hours or less.
Stefan notes that the Microsoft Dynamics CRM Case form already has a service
level field that is related to the service contract. However, the form lacks the
ability to track the length of time (in hours) that it takes the Customer Service
Representative to return the customer's call.
Goal Description
Stefan has requested that you add a new Response Time attribute to the Case
entity and Case form. He further requested that the Response Time field be
displayed on the Case Preview pane.
Furthermore, because Adventure Works’ customers with Gold service levels are
typically their most valuable customers, Stefan has asked you to create a new
view that displays the Cases with Gold level service plans that did not meet the
one hour or less response time. Stefan will use this view to identify the customers
that he needs to contact due to Adventure Works’ poor service performance.
To complete Stefan's request, you have proposed the following customizations:
• Add a new Case entity attribute that has the following properties:
– Display name = Response Time
– Schema Name = new_ResponseTime
– Requirement Level = No Constraint

– Description = Time in hours it takes for a Customer Service

Representative to return the customer's call
– Type = float
– Default the remaining fields
• Add the Response Time attribute to the Case form. Add the field to
the Assignment Information section of the General tab. Change the
label of the field to display “Response Time (hours)”.
• Add the Response Time attribute to the Case Preview pane. Display
it directly below the Service Level field.
• Create a new Case view with the following properties:
– View name: Unachieved Gold Level Responses
– Filter criteria: Service level = Gold, and Response Time > 1.0.
– Display columns:
• Case Number
• Response Time
• Severity
• Owner
• Responsible Contact
– Sort by Response Time in descending order
• To test the customizations, open two cases, change their service level
to Gold and enter response times greater than 1.0 for each case.
Update a third case by changing its service level to Gold, but enter a
response time of .5 for this case. Verify that the response times
appear in the cases’ preview pane and that the new view displays the
proper records and in the correct order. Also verify that the third case
does not appear in the view.
Log on as the CRM Administrator and make the requested changes.
Challenge Yourself
complete this lab:
1. Create a new attribute in the Case entity with the properties defined
2. Add the field to the Case form and customize its appearance
according to the Goal Description.
3. Create a new Case view with the properties defined in the Goal
Description. Publish your changes.

4. To test the results, change two existing cases to Gold service levels
and enter values greater than 1.0 as the response times. Make a third
case a Gold service level, but enter .5 as its response time.
5. Verify that the response times appear in each case's preview pane.
6. Verify that the Unachieved Gold Level Responses view displays the
proper cases and in the correct sort order. Verify that the third case
with a response time of .5 does not appear.
Need a Little Help?

Step 1 - Add Custom Attribute
Perform the following steps to add the Response Time attribute to the Case
entity:
1. Navigate to Customize Entities and open the Case entity. Open the
list of Case attributes.
2. Create a new attribute and enter the following properties:
• Display name = Response Time
• Schema Name = new_ResponseTime
• Requirement Level = No Constraint
• Description = Time in hours it takes for a Customer Service
Representative to return the customer's call
• Type = float
• Default the remaining fields
3. Save and Close the attribute.
Step 2 - Add Attribute to Form
Perform the following steps to add the Response Time to the Case form:
1. Add the Response Time attribute to the Case form. Add the field to
the Assignment Information section of the General tab.
2. Change the label of the field to display Response Time (hours).
As a best practice, verify the changes that you made to the form by using the
Preview menu option.
Step 3 - Add Attribute to Preview Pane
Perform the following steps to add the Response Time to the Case Preview pane:
1. Add the Response Time attribute to the Case Preview pane.

2. Display the Response Time field directly below the Service Level
field.

Step 4 - Create View
Create a new Case view that displays the cases for Gold level customers that did
not meet the one hour or less response time rule. The view must have the
• View name = Unachieved Gold Level Responses

• Filter criteria:
– Service level = Gold
– Response Time > 1.0.
• Display columns:
– Case Number
– Response Time
– Severity
– Owner
– Responsible Contact
• Sort by Response Time in descending order
Publish all Case customizations.
Step 5 - Test the Changes
Perform the following steps to test the results:
1. To test the new view, open an existing Case, change its Service
Level to Gold and enter a value greater than 1.0 in the Response
Time field. Repeat this step with a second case.
3. Open a third case, change the Service Level to Gold, but this time
enter .5 as the Response Time.
4. Navigate to Cases and select the Unachieved Gold Level Responses
view. Verify that the two cases you updated appear, and that they are
displayed in the proper sort order. Verify that the third Gold Level
case with a response time of .5 does not appear in the view.

Step by Step
Step 1 - Add Custom Attribute
Perform the following steps to add the Response Time attribute to the Case
entity:

click Customize Entities, double-click the Case entity, and then
click Attributes.
2. On the Case Attributes list, click New on the Actions toolbar.
3. In the New Attribute form, enter the Response Time attribute
properties as outlined in the Goal Description.
5. Click Save to save the changes and keep the Case entity open.
Step 2 - Add Attribute to Form
Perform the following steps to add the Response Time to the Case form:
1. If the Case entity form is not open, then open it now. Click Forms
and Views. Double-click Form.
2. Click Add Fields. Select the Response Time field, and add it to the
Assignment Information section of the General tab. Click OK.
3. Select the Response Time field if it is not already selected. Click
Change Properties.
4. On the Display tab, change the value of the Label field to Response
Time (hours). Click OK.
5. Click Save.
6. As a best practice, verify the changes that you made to the form by
using the Preview menu option. Click Preview on the menu bar.
Select Create form. Verify the changes appear as they should. Close
the preview form.
8. Click Actions on the menu bar, and then click Publish.
Step 3 - Add Attribute to Preview Pane
Perform the following steps to add the Response Time to the Case Preview pane:
1. If the Case Forms and Views window is not open, then open it now.
Double-click Preview.
2. Click Add Fields. Add the Response Time field to the preview pane.
Click OK.

3. Use the green arrows to move the Response Time field directly
below the Service Level field.
5. Click Actions, then click Publish.
Step 4 - Create View
Perform the following steps to create a new view that displays the cases for Gold
level customers that did not meet the one hour or less response time rule:
1. If the Case Forms and Views window is not open, then open it now.
Click New on the Actions toolbar.
2. In the Provide Information for this View dialog box, enter
Unachieved Gold Level Responses as the name of the view. Click
OK.
3. Click Add Columns, select the following columns, then click OK:
a. Case Number
b. Response Time
c. Severity
d. Owner
e. Responsible Contact
4. To customize the filter properties, click Edit Filter Criteria in the

Common Tasks area.
Fields, select the Service Level field.
6. Click the Enter Values link. Click the ellipsis button to the right of
the value field. In the Select Values dialog box, click on Gold, then
click the right arrow to move it into the Selected Values column.
Click OK.
Fields, select the Response Time field. Click OK.
8. Click on the Operator (Equals) field. Select the Is Greater Than
option.
9. Click the Enter Values link. Enter 1.00 in the field.
11. To change the sort properties, click Configure Sorting in the
Common Tasks area.
12. In the Configure Sort Order dialog box, click the Column drop-down
arrow and select Response Time from the list. Select the
Descending Order sort option. Click OK.
13. Click Save and Close on the Unachieved Gold Level Responses
view.

14. Click Save and Close on the Case's Forms and Views.
15. Because Case is already selected on the Customize Entities list, click
Publish to publish all Case customizations.
Step 5 - Test the Changes
Perform the following steps to publish the customizations and test the results:
1. To test the new view, open an existing Case.

2. Double-click on one of the cases to open the Case record. Change the
Service Level to Gold and enter a value greater than 1.0 in the
Response Time field. Save and Close the record.
3. Repeat this prior step with another case.
5. Open a third case, change the Service Level to Gold, but this time
enter .5 as the Response Time. Save and Close the record.
6. From the Navigation Pane, click Service, and then click Cases.
7. On the View drop down list, select Unachieved Gold Level
Responses. Verify that the two cases you updated appear, and that
they are displayed in the proper sort order. Verify that the third Gold
Level case with a response time of .5 does not appear in the view.

Creating a Custom Entity

Customizing the Microsoft Dynamics CRM schema includes not only adding
attributes to existing entities, but also creating your own custom entities and
customizing existing system entities. These latter tasks essentially provide the
ability to build your own application within Microsoft Dynamics CRM.
Creating a custom entity is a simple process; however, fully configuring the

entity once it is created takes a little more effort. To create a new entity, just enter
a name and plural name for the entity, then save the entity to accept all the
default settings. Fully configuring the entity requires an understanding of how to
change the default settings, how and when to create relationships with other
entities, how to create mappings between entities and entity relationships, and so
on.
Configuring a Custom Entity

When you create a custom entity, there are several properties you cannot change
once you save the entity. Therefore, it is essential that you carefully plan your
entity configuration prior to actually creating it. As a best practice, it is
recommended that you plan your configuration of the following properties on the
entity Form before creating the entity:
Entity Definition section
• Display Name, Plural Name and (Schema) Name. These fields

need to be intuitive, unique, and meaningful. The schema name can
only contain alphanumeric characters and the underscore symbol, but
the display name and plural name can contain any international or
extended characters. These fields cannot be changed once the entity
has been created.
NOTE: The schema name is prefixed by the value defined in the System
Settings’ Customization tab. The default prefix setting is “new_”. You can
change the prefix at any time and it can be any alphanumeric value except
“MSCRM.”
• Ownership Type. The property defines some of the system

relationships that are created when a new entity is created. There are
two ownership options:
– Organization owned. An entity that is owned by the
organization cannot be assigned to a particular user.
Organization owned entities typically contain data involving
something that belongs to the organization. Product is an
example of an organization owned system entity.

– User Owned. A user owned entity must be associated with a

user. User owned entities typically contain data relating to
customers. The user is the primary owner of the relationship
between the related customers and the organization. Account is
an example of a user owned system entity.
Areas that display this entity section
• Areas showing this Entity. This parameter allows you to select the
areas in which the entity must appear within the Navigation Pane.
The following options are available:
– Workplace
– Sales
– Marketing
– Customer Service
– Settings
This property can be further configured using the SiteMap tool.

Modifying the SiteMap can include modifying existing areas and
adding new areas. SiteMap is an advanced customization tool for
developers and is introduced in the training offering titled
Introduction to Advanced Customizations.
• Offline Availability. Selecting the Show in Microsoft Dynamics

CRM client for Outlook when offline option enables your custom
entity to participate in full offline processing with Microsoft
Dynamics CRM for Outlook. However, no default offline filters are
created. Users need to manually subscribe to records in the custom
entity to take them offline.
• Enable Duplicate Detection. This option enables duplicate
detection for this entity. If this option is set, then every new record
created for this entity is automatically checked against the duplicate
detection rules.
Relationship section
• Associated Entities. Notes and Activities are two system entities

that can be useful related objects to any custom entity. Selecting
these items automatically enables users to add notes to an entity and
create activity records associated with the entity. These associations
between a custom entity and the Note and Activity entities can only
be made when the custom entity is created; they cannot be added
later.
• Primary Attribute. The primary attribute is a string attribute
displayed on lookups in relationships referring to this entity.
Although it is possible to use other Requirement Level options, the
Requirement Level for the primary attribute is usually set to
“Business Required”.

Default Entity Attributes and Features

When a custom entity is saved, the following types of attributes are automatically
created for it.
• Standard Attributes. The standard attributes are automatically

created by the system for every new entity. The standard attributes
include:
– PrimaryAttributeSchemaName (this is the primary attribute
name)
– <EntitySchemaName>ID (this is the GUID key of the primary
attribute)
– CreatedBy
– CreatedOn
– Import Sequence Number
– ModifiedBy
– ModifiedOn
– StateCode
– StatusCode
– Timezoneruleversionnumber
– utcconversiontimezonecode
• Variable Attributes. The variable elements that are automatically

created for an entity are based on if the entity is Organization Owned
or User Owned.
– Organization owned. In this case the system creates an
Organization ID attribute on the entity.
– User owned. In this case the system creates owningbusinessunit
and ownerid attributes on the entity.
• Visible Elements. When a custom entity is saved, the following

visible elements are automatically created for it:
– Form
– Preview
– Public Views (such as Active Accounts and My Active
Accounts)
– Lookup View
– Associated View
– Quick Find View
– Advanced Find View

• Filtered Views When an entity is created, a filtered view named

“Filtered<EntitySchemaName>” is automatically created in the
<OrganizationName>_MSCRM database. This filtered view allows
you to include custom entities within reports.
• Web Service. When an entity is created, it is automatically declared
to the Microsoft Dynamics CRM Platform Web Services. This
allows you to utilize the methods described in the SDK so that you
can directly access this custom entity through your own program
calls.
Creating a Custom Entity

Perform the following steps to create a custom entity:

2. Click New.
3. Enter the Name and Plural Name that will be used for this entity
throughout Microsoft Dynamics CRM.
4. In the Ownership list, select either User or Organization.
5. In the Name box, enter the name for the schema table where data for
this entity will be stored.
6. In the Offline Availability section, select if users can create, read,
update, or delete records while offline in Microsoft Dynamics CRM
for Outlook with Offline Access.
7. In the Duplicate Detection section, select whether Duplicate
Detection is enabled.
8. In the Relationships section, indicate if Notes and Activities must be
associated with the custom entity.
9. In the Areas that display this entity section, select the areas where
you want the entity to appear in the Microsoft Dynamics CRM user
interface.
10. Click the Primary Attribute tab. The primary attribute is a string
attribute that is displayed when relationships to this entity are
identified or displayed, such as in the Look Up Records dialog box.
To make sure an easily recognizable name is used when this entity is
referenced, enter a descriptive Display Name, and then as a best
practice in the Requirement Level list, select Business Required.
11. Click Save.
IMPORTANT: You do not have to publish custom entities; they become

available immediately after being saved. However, while a custom entity is
visible from the area(s) in which it is displayed once you have saved it, nothing
happens if you select the entity. In order for Microsoft Dynamics CRM to access
the entity, you must exit the web application and launch it again before you can
access the entity.

Once these steps are completed, you can then configure the custom entity by
configuring its attributes, icons, form, views, relationships, mappings, and
messages. Unlike the custom entity itself, these objects must be published once
they have been configured.
The final step in the entity creation process includes defining the security
permissions to access the entity. You must add the appropriate privileges to each
security role that requires access to the entity. Updating custom entities within
security roles is examined in the next section.
Entity Security and Customizations

When a new entity is created, it automatically appears in the Custom Entities tab
of each security role. Except for the System Administrator or System Customizer
roles, all remaining roles have None selected as their default access rights for
custom entities. This means that no user other than those assigned the default
System Administrator and the System Customizer can see the new entity.
Before users are able to work with the custom entity, their appropriate security
roles need to be modified to set the access levels for the specific privileges
pertaining to the entity. If you want to implement an entity for a specific
Business Unit, you must create one or more custom security roles in that
Business Unit that allow users to access the entity. These custom roles must then
be assigned to the appropriate user accounts.
For more information on configuring security roles, refer to the training titled
Configuring Security.
Entity Icons
Microsoft Dynamics CRM assigns every custom entity the same generic icon. If
you want to customize the application by displaying a unique icon for a custom
entity, you can upload graphic files to replace the default icons.
NOTE: You cannot customize the icons for system entities.
The following types of icons can be customized for each custom entity:
• Icon in Web application. This icon is visible within views for the
custom entity. The icon must be:
– 16x16 pixels in size
– In .gif format

• Shortcut icon in Microsoft Dynamics CRM for Microsoft Office

Outlook. This icon is visible in Microsoft Dynamics CRM for Office
Outlook. The icon must be:
– In an .ico format
– With 16 colors
• Icon in Entity Forms. This icon is visible on the entity's form. The
icon must be:
– In .gif format
NOTE: All image files cannot be larger than 10 KB in size, and they must have
transparency for best results.
Applying Custom Icons

Perform the following steps to apply a custom icon to a custom entity:
1. In the Customize Entities pane, select the custom entity, click More
Actions on the Actions toolbar, and then click Update Icons.
2. In the Icon in Web application section, click Browse and select the
icon.
3. In the Shortcut icon in Microsoft Dynamics CRM client for
Outlook section, click Browse and select the icon.
4. Click OK. The Unpublished Icon is updated and is displayed for the
unpublished entity. When you publish customizations, the Published
Icon is automatically updated to your new icon.
Deleting a Custom Entity

You can delete a custom entity, although entity deletion is irreversible. Deleting a
custom entity results in:
• Loss of all data stored in the physical database table.

• Deletion of all relationships without any update post-callouts being
called.
• Silent deletion of all activities and notes associated with this entity.
Any entity that is referenced by another entity cannot be deleted until the
references to it are removed. For example, if your custom entity is the primary
entity in a relationship, the related entity will have a Relationship Attribute that
may be displayed as a lookup field on the related entity form. Your custom entity
can only be deleted after the lookup field is removed from the related entity form
and the related entity is published.

Perform the following steps to delete a custom entity:
1. Select the entity in the Customize Entities window.

2. On the Actions toolbar, click Delete.
3. Click OK to confirm the deletion.
4. If an error is displayed that indicates other objects exist that
reference the entity, you must remove those references before you
can delete the entity.

Demonstration - Creating a Custom Entity

This instructor demonstration illustrates how to create a custom entity. Steps are
provided so you can follow along with the instructor.
Scenario
Adventure Works Cycle sells their products through a network of resellers. These
resellers place orders to Adventure Works Cycle on behalf of their customers.
Adventure Works Cycle fulfills the orders and provides service after the sale.
Because of the 1-to-Many relationship between Resellers and Accounts,
Adventure Works has decided to create a custom “Reseller” entity to separate the
resellers from their Customer records.
The Reseller entity will be associated with several other system and custom
entities, but the first step is to create the entity.
Goal Description
The Reseller entity will be created according to the specification in the table
titled Reseller Entity Specification.
FIGURE 7.11 RESELLER ENTITY SPECIFICATION
The Reseller entity will have the additional attributes described in the table titled
Reseller Entity Attributes.
FIGURE 7.12 RESELLER ENTITY ATTRIBUTES

Step by Step
Perform the following steps to create a new entity and add entity attributes.
Step 1: Set the Schema Name Prefix
In the previous demonstration, the prefix for new entities and attributes was
changed to ‘test’. Adventure Works has requested that for this project the prefix
be changed back to ‘new’.

then click System Settings.
2. Select the Customization tab to locate the Schema Name Prefix.
3. Set the Prefix = new
4. Click OK.
Step 2: Create the Entity
1. From the Navigation Pane, click Settings, click Customization, then

2. Click New from the Actions bar.
3. Enter the information from the table.
4. Save the Entity.
Step 3: Set the Entity Attributes
1. Click the Attributes side tab to view the attributes for the entity.
2. For each of the Attributes in the next table
3. Click New.
a. Enter the Attribute information.
b. Click Save and Close.
Step 4: Form & View Customization
1. Click the Forms and Views side tab.

2. Open the Form.
3. Create a Section with the following properties:
a. Name = Address
b. Show the name of this section on the form
c. Show divider line below the section name
d. Layout = Variable Field Width

4. Add the fields created in Step 3 to the Address section.

5. Modify the field properties and position the field so that the Section
looks similar to the following figure:
FIGURE 7.13 RESELLER ADDRESS SECTION

6. Save your changes.
Step 5: Publish and Confirm Changes
1. Because changes were made to the Reseller's form and views, you
need to publish the Reseller customizations.
2. View the Resellers entity from the Sales area.
3. Create a new Reseller record.

Lab 7.2 - Creating a Custom Entity

In addition to creating a new entity, this lab directs you to create a second lookup
to the User table (the first is the Owner lookup, which was automatically created
by the system). This lookup is used here to look up the event coordinator (a CRM
user) from the Event custom entity.
In many Microsoft Dynamics CRM deployments, an important and often

overlooked step when creating custom entities is changing the security
permissions associated with these entities. Without a change, only the
Administrator can view and use the entities. Although this lab functions without
changes to the security permissions, it does ask you to make some security
adjustments at the end.
The objectives of this lab are:
• Create a custom entity

• Create new attributes for the custom entity and expose the attributes
on the entity's form
• Create a lookup to the CRM User entity
• Change attribute settings that are part of entity schema customization
(such as adding values to a choice list, setting requirement level, and
changing the format)
• Configure security settings for the custom entity
Scenario
Adventure Works Cycle is already using Microsoft Dynamics CRM for

managing their prospects and customers. However, they host a series of customer
events and they want a means of tracking these events. As their Microsoft
Dynamics CRM implementation and support consultant, you have been asked to
what extent CRM can be used to support their event management coordination. It
appears to them there is no place in CRM to record all of their events.
You explain that CRM can be used for event management by simply adding a
new custom entity to the Microsoft Dynamics CRM platform. You suggest the
entity be named “Events”, and explain how it can be customized with required
fields, it can use the same customization tools as the rest of Microsoft Dynamics
CRM, and it can even be linked to other CRM “people” entities such as Leads
and Contacts. The customer likes your approach for creating a custom entity and
provides you with a list of fields they want included.

Goal Description
Adventure Works has submitted the following list of information that must be
tracked for each event. Accept all default properties for each attribute except for
those mentioned below:
• Start Date and Time (Business Required; Type = datetime; Format =

Date and Time)
• End Date and Time (Business Required; Type = datetime; Format =
Date and Time)
• Location (Business Recommended)
• Category (Type = picklist; picklist values include Workshop,
Seminar, Luncheon, and Other; Default Value = Unassigned Value)
• Rental Costs (Type = money, zero precision)
• Catering Required (Type = bit; sequence of values = No, Yes;
default value = No)
• Miscellaneous (Type = ntext)
After reviewing Adventure Works’ requirements, you have designed the

following customizations to meet their business needs. Adventure Works has
reviewed and approved your plan.
• Create a custom entity named “Event” that is user owned, is

available offline in Microsoft Dynamics CRM for Outlook, includes
CRM Notes and Activities, and is displayed in the Sales area.
• Create the custom Event attributes as requested by the customer
including their requirement level and choice list values and expose
the attributes on the Event form. Rearrange the fields on the form to
match the following figure:
FIGURE 7.14 EVENT FORM

• Update the Active Event view to include the columns: Start date,
Location, and Owner. The columns should appear in the following
sequence: Name, Location, Start Date, Owner, and Created On.
Expand the width of the Start Date and Time column to 125px.
• Import a new graphic file to replace the default custom entity icon
for the Event entity. The graphic files are located in the following
folder:
C:\Class Materials\Customization\Ch.7
• Update the Marketing Manager role to provide full permissions for
this custom entity. Update the Marketing Representative role to
provide Organization Read access only for the Event entity.
• Test the functionality of Events.
– Log on as Patricia San Juan (username = patricia; password =
Pa$$w0rd), who is assigned the Marketing Manager role. Verify
that Patricia can access and update the Events entity. Create two
event records.
– Log on as Gail Erickson (username = gail; password =
Pa$$w0rd), who is assigned the Marketing Representative role.
Verify that Gail can view the events that Patricia just created.
Also verify that Gail cannot create or update an event.
Challenge Yourself
complete this lab:
1. Create a custom entity named “Event”.

2. Add the custom Event attributes requested by the customer.
3. Expose the attributes on the Event form so that it matches the layout
displayed in the Goal Description.
4. Update the Active Events view based on the instructions in the Goal
Description.
5. Add the custom icons for the Event entity using the icons specified
6. Update the Marketing Manager security role to provide full
permissions for the Event entity. Update the Marketing
Representative role to only provide Organization Read access for
Events.
7. Test the functionality of Events. Log on as Patricia San Juan and
create two events. Verify the Active Events view functionality. Log
on as Gail Erickson and verify that while she can view the events,
she cannot update them.

Need a Little Help?

Step 1 - Create Custom Entity
Create a custom entity named “Event” that has the properties outlined in the Goal
Description.
1. Create a new custom entity.

2. On the General Tab, enter Event in the Display Name field.
3. Tab into the Plural Name field. Enter Events as the plural Name.
4. Select User as the Ownership.
5. Select the option to show the entity in Microsoft Dynamics CRM for
Outlook when offline.
6. Accept the default options for duplicate detection and creating
relationships with Notes and Activities.
7. Select Sales as the area in which to display this entity.
8. Click Save.
Step 2 - Create Custom Attributes
Add the custom attributes specified in the Goal Description to the Event entity.
1. For the Event entity, select Attributes and create a new attribute.
2. In the New Attribute form, enter Start Date and Time as the
Display Name. Enter the remaining fields as specified in the Goal
Description.
3. Save the record and open a new one. Repeat for each attribute listed
in the Goal Description. Apply the specific properties for each
attribute as defined in the list.
Step3 - Update Entity Form
Expose each of the custom attributes on the Event form.
1. Open the Event Form.

2. Add each of the new attributes to the General tab.
3. Use the green arrows in the Common Tasks pane to rearrange the
fields to match the form layout displayed in the Goal Description.
4. Save the form and verify its appearance using the Preview option.
5. Publish the Event entity.

Step 4 - Update Entity View
Update the Active Events view to include the columns Start date, Location, and
Owner. Update the view based on the instruction in the Goal Description.
1. In the Event's Forms and Views, open the Active Events view.
2. Add the following fields to the view: Location, Owner, and Start
Date and Time. Click OK.
3. Using the green arrows, rearrange the columns in the following
sequence: Name, Location, Start Date, Owner, Created On.
4. Change the width of the Start Date and Time column to 125px.
5. Save the view.
Step 5 - Apply Custom Icon and Publish the Entity
Import a new graphic file to replace the default custom entity icon for the Event
entity. Publish customizations for the Event entity.
1. In the Customize Entities pane, select the Event entity and click
More Actions on the Actions toolbar. Click Update Icons.
2. For each icon type, browse to the folder location specified in the
Goal Description and select the corresponding icon.
Step 6 - Update Custom Entity Permissions
Update the Marketing Manager and Marketing Representative roles to provide

permissions for this custom entity.
1. Navigate to the Security Roles and open the Marketing Manager

role.
2. In the Custom Entities tab, use the Entity shortcut method to quickly
change the access levels for all Event privileges to Organization.
3. Save the role, then open the Marketing Representative role.
4. Set the Read Event access level to Organization. Leave all other
permissions set to None.
5. Save the role.
Step 7 - Test and Verify Results
Test the functionality of Events.
1. Close Microsoft Dynamics CRM.

2. Log off the system.
3. Log on as Patricia San Juan (username = patricia; password =
Pa$$w0rd).

4. In Microsoft Dynamics CRM, navigate to Sales and then Events.

5. Create two new events.
6. Verify the changes made to the Active Events view and the data that
is displayed.
8. Log on as Gail Erickson (username = gail; password = Pa$$w0rd).
9. In Microsoft Dynamics CRM, navigate to Events. Gail's security role
has Organization Read access for Events, so she can view the events
Patricia created.
10. Open one of the events.
11. Because Gail's role does not provide Write capability, the Read-only
form is displayed. Click Close.
12. On the Events page, note how the New button and the Delete icon
are missing from the Action toolbar. Because Gail's security role
does not provide create and delete access for the Event entity, these
actions are not displayed on the Action toolbar.
14. Log on as the CRM Administrator (username = crmadmin; password
= Pa$$w0rd).
15. Open Microsoft Dynamics CRM.
Step by Step
Step 1 - Create Custom Entity
Create a custom entity named “Event” that has the properties outlined in the Goal
Description.
1. From the Navigation Pane, click Settings, click Customization, and

3. On the General Tab, enter Event in the Display Name field.
4. Tab into the Plural Name field. Enter Events as the plural Name.
6. When you tabbed out of the Display Name field, the Name field was
automatically filled in for you with new_event.
8. Accept the default options for duplicate detection and creating
relationships with Notes and Activities.
9. Select Sales as the area in which to display this entity.
10. Click the Primary Attribute tab. The Name field is pre-filled as the
primary attribute. No change is required on this tab.
11. Click Save.

Step 2 - Create Custom Attributes
Add the custom attributes specified in the Goal Description to the Event entity.
1. The Event entity should be open after saving it in the prior step.
4. In the New Attribute form, enter Start Date and Time as the
Display Name.
5. Tab into the Name field. Note how the schema name is pre-filled
with new_startdateandtime. Do not change this default schema name.
6. In the Requirement Level field, select Business Required.
7. In the Type field, select datetime.
8. In the Format field, select Date and Time.
10. Repeat for each attribute listed in the Goal Description. Apply the
specific properties for each attribute as defined in the list. Click Save
and Close following the final attribute.
Step3 - Update Entity Form
Expose each of the custom attributes on the Event form.
1. The Event entity form will still be open after closing the final
attribute window. If the Event entity form is not open, then open it
now.
2. Click Forms and Views.
3. Double-click Form.
4. Add each of the new attributes to the General tab.
5. Use the green arrows in the Common Tasks pane to rearrange the
fields to match the form layout displayed in the Goal Description.
6. Click Save.
the changes.
8. If the customizations are correct, close the Create Form, and then
click Save and Close.
9. Click Actions on the menu bar, then click Publish.
Step 4 - Update Entity View
Update the Active Events view to include the columns Start date, Location, and
Owner. Update the view based on the instruction in the Goal Description.
1. The Event entity should be open after saving it in the prior step.
2. In the Details pane, click Forms and Views.
3. Double click the Active Events view to open it.

4. Click Add Columns from the Common Tasks area.

5. In the Add Columns dialog box, select Location, Owner, and Start
Date and Time. Click OK.
6. Using the green arrows, rearrange the columns in the following
sequence: Name, Location, Start Date, Owner, Created On.
7. Select the Start Date and Time column and click Change
Properties. Change the column width to 125px. Click OK.
8. Click Save and Close on the Active Events view.
9. Click Actions on the menu bar, then click Publish.
10. Click Save and Close on the Event Forms and Views.
Step 5 - Apply Custom Icon and Publish the Entity
Import a new graphic file to replace the default custom entity icon for the Event
entity. Publish customizations for the Event entity.
1. In the Customize Entities pane, select the Event entity and click
More Actions on the Actions toolbar. Click Update Icons.
2. In the Select New Icons dialog box, specify the icon file for three of
the icon types. For each icon, click Browse, navigate to the folder
specified in the Goal Description, and select the corresponding icon
file (based on the icon size). Click OK.
3. On the Customize Entities pane, select the Event entity and click
Publish on the Action toolbar.
Step 6 - Update Custom Entity Permissions
Update the Marketing Manager and Marketing Representative roles to provide

permissions for this custom entity.

2. Double-click the Marketing Manager role to open it.
3. Select the Custom Entities tab.
4. For the Event entity, set the access level for each privilege to
Organization. Use the Entity shortcut method by clicking on the
Event name until all the permissions are set to Organization.
6. Double-click the Marketing Representative role to open it.
7. Select the Custom Entities tab.
8. Click on the Read Event access level until it is set to Organization.
Leave all other permissions set to None.

Step 7 - Test and Verify Results
Test the functionality of Events.
1. Close Microsoft Dynamics CRM.

3. Log on as Patricia San Juan (username = patricia; password =
Pa$$w0rd).
4. Start Internet Explorer and open Microsoft Dynamics CRM.
5. From the Navigation Pane, click Sales, and then click Events.
7. Enter information for an upcoming event.
9. Enter information for a second event.
11. Verify the changes made to the Active Events view and the data that
is displayed.
13. Log on as Gail Erickson (username = gail; password = Pa$$w0rd).
15. From the Navigation Pane, click Sales, and then click Events. Gail's
security role has Organization Read access for Events, so she can
view the events Patricia created.
16. Double-click on one of the events to open it.
17. Because Gail's role does not provide Write capability, the Read-only
form is displayed. Click Close.
18. On the Events page, note how the New button and the Delete icon
are missing from the Action toolbar. Because Gail's security role
does not provide create and delete access for the Event entity, these
actions are not displayed on the Action toolbar.
20. Log on as the CRM Administrator (username = crmadmin; password
= Pa$$w0rd).

Summary
This training introduced customizing the Microsoft Dynamics CRM schema by
customizing system and custom entities. Custom entities are a powerful feature
that allows a person without programming skills to build entirely new
functionality into Microsoft Dynamics CRM. This capability demonstrates the
design focus of affordable adaptability and provides alternatives to purchasing
additional systems, developing extensions or overloading existing entities.
Custom entities possess many of the same capabilities as system entities,

although with some limitations. Careful planning will help ensure that your
custom entities perform as expected.

Test Your Knowledge

1. When discussing Microsoft Dynamics CRM entities, what kind of ownership

does the Product entity represent?
( ) user-owned
( ) organization-owned
( ) customer-owned
( ) business unit-owned
2. The Organization wants to use a custom icon for the Account entity. Is it
possible to do this in a supported way? Choose the best answer.
( ) Yes. While viewing the Account entity, on the Actions menu select
"Update Icons..."
( ) No. The image is embedded in a .dll file
( ) No. Modifying system icons is not supported.
3. Which of the following is not true when you create a new custom entity?
( ) Several relationships are created with the User entity.
( ) A new filtered view is created in SQL Server
( ) All users can immediately begin to use the new entity.
( ) There is no need to publish custom entities.
4. If a consultant applies a set of customizations, he or she can set the schema

prefix to a unique value before beginning work and set it back when
completed. What is the purpose of doing this?

5. Microsoft Dynamics CRM allows you to work with which types of entities?
(Select all that apply.)
( ) System
( ) Native
( ) Custom
( ) Customizable


chapter:
1.
2.
3.

Solutions
Test Your Knowledge
1. When discussing Microsoft Dynamics CRM entities, what kind of ownership
does the Product entity represent?
( ) user-owned
(•) organization-owned
( ) customer-owned
( ) business unit-owned
2. The Organization wants to use a custom icon for the Account entity. Is it
possible to do this in a supported way? Choose the best answer.
( ) Yes. While viewing the Account entity, on the Actions menu select
"Update Icons..."
( ) No. The image is embedded in a .dll file
(•) No. Modifying system icons is not supported.
3. Which of the following is not true when you create a new custom entity?
( ) Several relationships are created with the User entity.
( ) A new filtered view is created in SQL Server
(•) All users can immediately begin to use the new entity.
( ) There is no need to publish custom entities.
4. If a consultant applies a set of customizations, he or she can set the schema

prefix to a unique value before beginning work and set it back when
completed. What is the purpose of doing this?
MODEL ANSWER - This “tags” the entities and attributes to tie them to the
group of customizations the consultant applied. This can differentiate a group
of attributes that were imported together.
5. Microsoft Dynamics CRM allows you to work with which types of entities?
(Select all that apply.)
(√) System
( ) Native
(√) Custom
(√) Customizable

Chapter 8: Customizing Relationships and Mappings
CHAPTER 8: CUSTOMIZING RELATIONSHIPS AND

MAPPINGS
Objectives
The objectives are:
• Identify the various types of supported relationships that can link

system and custom entities
• Identify the types of relationships that are not supported by the
system
• Understand how 1:N relationship rules control how certain actions
taken on a record affect related records
• Create entity relationships and configuring relationship behavior
• Discuss how attribute mapping facilitates data entry when creating
new records that are related to a parent record
Introduction
The most critical element in planning a custom entity is understanding the
relationships that link entities together. Entity relationships represent how entities
are related to each other within the Microsoft Dynamics CRM platform. The
Microsoft Dynamics CRM customization tools make it easy to create custom
entities with no programming experience, but the concepts behind establishing
the relationships must be understood if the custom and system entities are to
work together.
This training focuses on identifying the different types of supported relationships

in Microsoft Dynamics CRM, as well as the types of behavior that control how
certain actions taken on a record affect related records. This training also
examines entity mapping. Mappings facilitate data entry when creating new
records that are related to a parent record.

Supported Entity Relationships

An integral aspect of defining custom entities is defining their relationships with
other entities. Organizing relationships with other entities establishes
connections. For example, the existing system entities in Microsoft Dynamics
CRM have relationships. An Activity can be related to an Opportunity. An
Opportunity must be related to either an Account or Contact. Every Account or
Contact is associated with a User, and every User is associated with an
Organization.
Your custom entities are more useful if you relate them to other entities in a
similar way. And although some of the system entities already have relationships,
you can create additional relationships that have not been defined out-of-the-box.
You can also change the behavior of these relationships.
NOTE: See the Microsoft Dynamics CRM SDK for APIs that allow you to
determine if an entity is available for a given relationship type.
1-to-Many Relationships
1-to-Many relationships (1:N) are relationships between a primary entity and a
related entity. In other words, a given primary entity record can be linked to
multiple records within the related entity. The relationship is maintained by a
relationship attribute that is automatically stored by the platform on each related
entity record.
This relationship attribute, which is always a Lookup type, stores a reference to

the primary entity record's unique ID. When creating a 1:N relationship, you
must enter a Display Name and a schema Name for this relationship attribute,
just as you do when creating a custom attribute outside of a relationship.
FIGURE 8.1 ONE-TO-MANY RELATIONSHIP STRUCTURE

You can create a new 1:N relationship from either the primary or related entity.
The terminology used when creating this type of relationship depends on if you
are creating the relationship from the related entity or the primary entity.
• 1-to-Many Relationship. When you select a 1-to-Many (1:N)

relationship, the entity being viewed must be the primary entity.
From this entity, you select the related entity that completes the 1:N
relationship.
• Many-to-1 Relationship. When you select a Many-to-1
(N:1)relationship, the entity being viewed must be the related entity.
From this entity, you select the primary entity that completes the N:1
relationship.
From a technical database standpoint, there is no difference between 1:N and N:1
relationships. The difference is really from a terminology perspective. In both
cases, the primary entity is the “1” and the related entity is the “Many”.
For example, an organization creates a custom Reseller entity for tracking the
reseller who sells their products to each Account. This is a typical 1:N
relationship; that is, each reseller sells to multiple accounts, but any given
account only has one reseller that sells to it.
• If you create this relationship from the Reseller entity, you create a
1:N relationship.
• If you create this relationship from the Account entity, you create a
N:1 relationship.
NOTE: Whichever way the relationship is created, Microsoft Dynamics CRM

automatically creates the inverse entry on the associated entity.
Technically, the 1:N relationship is the only relationship created between the two
entities. However, the terminology used to describe the relationship from a user
interface standpoint depends upon which entity is the focal point of the
discussion.
Microsoft Dynamics CRM supports the following types of 1:N relationships:
• 1 to Many, System to Custom. This is where a custom entity is

related to a system entity. This can be a relational or parental
relationship. For example, you can create a custom entity called
“Pet” to associate with a contact; this allows you to track the number
and type of pets owned by the contact.

• 1 to Many, Custom to System. This represents when a Custom

entity is the primary entity to a system entity. This cannot be a
Parental relationship type; it can only be a Referential relationship
type.
For example, you might create a custom entity that stores

information about a specialized association or group that a Contact
might belong to. The custom entity can store information about that
association.
Viewing the custom entity shows all Contacts associated with that
group and allows easy creation of new Contacts associated with that
group. However, this can only allow a single relationship to be
established, so the custom primary entity must represent something
that the related entity has an exclusive relationship with.
• 1 to Many, Custom to Custom. You can create relationships
between your custom entities. However, only one relationship can be
a parental relationship.
• 1 to Many, Custom to Activity/Note. This common relationship can
be created automatically when you select to have Notes and
Activities associated with a custom entity. You can only create this
relationship when the entity is created.
Many-to-Many Relationships
Many-to-Many (N:N) relationships can be created in Microsoft Dynamics CRM
using any combination of eligible system and custom entities. Not every system
entity can be included in a N:N relationship. Therefore, to create a N:N
relationship, both entities must be eligible for N:N relationships.
In a 1:N relationship, there is a primary entity and a related entity. There is no

such relationship in a N:N because both entities are considered related entities. In
order to create a N:N relationship, the implementer's security role(s) must have
Append and Append To privileges on both entities. The same privileges are
required to disassociate entities.
There are two ways in which you can create a N:N relationship in Microsoft
Dynamics CRM. Each of the following methods offers its own unique benefits:
• Native N:N relationship

• Manual N:N relationship

Native N:N Relationship

Microsoft Dynamics CRM automatically creates N:N relationships between two
eligible entities. This type of system created N: N relationship utilizes a “hidden”
intersect entity. This intersect entity (or intersect table) contains the following
information:
• Primary Key GUID of the intersect record

• Entity 1 GUID
• Entity 2 GUID
The intersect entity is created by the platform at the time the entity relationship is
defined. Users merely provide the names of the related entities and the table
relationship is built for them by the platform. Because the intersect entity is
“hidden” from implementers:
• It is not available for inclusion in workflow rules

• It cannot be customized
• The Associated view is displayed from the second entity in the
relationship and not the intersect entity. Because a N:N relationship
is symmetrical, you can optionally modify each entity's Associated
view to display the other entity.
Create, update, and delete permissions for the intersect entity are controlled by
the related entity's Append and Append To privileges. There are no privileges
associated directly with the intersect entity.
Manual N:N Relationship

This type of N:N relationship is actually a combination of two N:1 relationships
that share a common intersect entity. This type of relationship is referred to as a
manual N:N relationship because the system does not maintain the intersect
entity. Instead, the intersect table is actually an intermediate entity that must be
manually created by the system customizer. This entity acts as the related entity
used in both N:1 relationships. Creating a series of N:1 relationships in this
manner creates a de-facto N:N relationship.
The benefit of creating a N:N relationship in this manner is that you can also add
custom attributes on the intersect entity. In a native N:N relationship, the
intersect entity is hidden from the customizer and custom attributes cannot be
maintained on this entity.
For the system customizer, the decision as to which type of N:N relationship to
create must be based on whether the organization requires tracking of
information related to the intersect entity.

EXAMPLE: Adventure Works Cycle creates a custom entity called Event that is
used to track marketing events. They also want to associate their Contacts with
Events. They want the ability for each Contact to be associated to multiple
Events, and for each Event to have associated multiple Contacts.
In addition, they want to track specific registration information for each
Contact associated with an Event. Tracking this registration information is a
key requirement for their organization; therefore, Adventure Works has decided
to manually create this N:N relationship. Adventure Works accomplishes this by
creating a custom entity called Registration. This entity acts as the intersect
entity in their manually created N:N relationship.
From within the Registration entity, Adventure Works creates a new N:1
relationship to Contact. From still within the Registration entity, Adventure
Works creates a second N:1 relationship to Event.
By using the Registration entity as a de-facto intersect entity, Adventure Works
is able to track registration information related to both Events and Contacts
(for example, the contact’s registration status for an event, who took their
registration information, how they registered, if they have any special
requirements at the event, and so on). Creating two N:1 relationships that share
a common intersect entity in this manner effectively becomes a N:N
relationship.
System to System Relationships

You can create new 1:N and N:N relationships that have not already been
established between eligible system entities. For example, a new relationship can
be created between Product and Account to indicate the product is a “branded”
product for that customer.
Self-Referential Relationships
A self-referential relationship is a relationship from one entity to itself. Self-
referential relationships are frequently used to create parenting hierarchies.
Examples of self-referential relationships include:
• A master Case that has child Cases related to it

• A parent Opportunity that is the source of additional sales
Opportunities
A parental self-referential relationship is permitted, although it cannot be

circular. In other words, you can link a record to other records within the same
entity, but you cannot link a record to itself.

A self-referential relationship can be created as a 1:N relationship or a N:N

relationship.
• When creating a self-referential 1:N relationship, the entity must

be selected as both the Primary and Related entity, and the behavior
type must be set to "Referential." Note: Relationship behaviors are
discussed later in this training.
• When creating a self-referential N:N relationship, the entity must be
selected as both the Current and Other entity.
Unsupported Entity Relationships

Any relationship that is not explicitly supported will be unsupported. Microsoft
Dynamics CRM does not allow you to create unsupported relationships, but you
must understand what relationships are not supported when planning
customizations. These include:
• 1 to Many Customer (Contact or Account) to Custom Entity.

Contact and Account make up a composite Customer entity. Only
system entities like Opportunity or Case can be associated with the
Customer composite entity.
• 1 to 1 Any to Any. This represents a lookup field capable of linking
to any other record, regardless of its entity.
1:N Relationship Behavior

In 1-to-Many (1:N) relationships in Microsoft Dynamics CRM you can control
how certain actions taken on a record affect any related records. This makes it
easier to perform actions on a hierarchy of records and helps prevent “orphan”
records. Orphan records are those who lose a linkage with their primary record.
Relationship Behavior refers to the actions that are performed on related entities
when actions are performed on the primary entity. For example, when re-
assigning an account to a new sales representative, you must determine if you
want:
• All the opportunities related to that account to automatically be re-

assigned to the same new sales representative
• The open opportunities to be re-assigned
• The opportunities that are were owned by the previous owner of the
account to be re-assigned
• None of the opportunities to be re-assigned

The following figure describes the actions that affect 1:N relationship behavior.
FIGURE 8.2 ACTIONS AFFECTING RELATIONSHIP BEHAVIOR
NOTE: You can configure System Settings to automatically share reassigned

records with the previous owner. The default behavior is not to share the
records.
Cascading Rules
For each action affected by the relationship, the rules may be applied separately
or as a group according to some pre-defined types of behavior. These rules are
said to “cascade” down the relationship, affecting not only the primary entity but
also each of its related entities.
FIGURE 8.3 CASCADING RULES
When a cascading action is applied in a 1:N relationship, the user must be

assigned the privileges to perform the action on all affected entities - that is, on
both the primary entity and the related entity. The change will fail if the user's
security role(s) do not provide these privileges.

EXAMPLE: The owner of an account possesses the privilege to delete the

account. But if the owner does not have the necessary privilege to delete any
related entities, the owner will not be able to delete the account.
Cascading rules are also controlled by the following restrictions:
• Custom Entity Cannot be ‘Parent’ to System Entity. A custom

entity cannot be the primary entity in a relationship with a related
system entity that cascades. This means you cannot have a
relationship with any action set to Cascade All, Cascade Active, or
Cascade User-Owned between a primary custom entity and a related
system entity.
• Each Entity Can Only Have One ‘Parent’. A new relationship
cannot have any action set to Cascade All, Cascade Active, or
Cascade User-Owned if the related entity in that relationship already
exists as a related entity in another relationship that has any action
set to Cascade All, Cascade Active, or Cascade User-Owned. This
avoids relationships that create a multi-parent relationship.
Example: Account → Opportunity Relationship Behavior
When an Account is assigned to a different user, should this affect the

Opportunities associated with that Account? The answer will vary according to
the policy the organization assigns to the 1:N relationship.
• Cascade All. In some organizations, the answer is to automatically

re-assign every opportunity associated with the account to the new
owner of the account. This saves a lot of steps that may otherwise be
required to manually re-assign each opportunity, including closed
opportunities. If an opportunity were ever re-opened it may already
be assigned to the right person.
• Cascade Active. In other organizations, opportunities that are closed
are not expected to re-open. It also may be important for reporting
purposes to preserve the information about who was assigned to the
record when it closed. This option only reassigns open opportunities
to the new owner of the account.
• Cascade User-Owned. Other organizations may expect that
opportunities associated with an account will have different owners.
The owners of these opportunities do not expect for them to be re-
assigned just because the account was re-assigned. This option only
re-assigns those opportunities that are assigned to the same owner as
the account. This is useful when a user takes over the responsibilities
of another.
• Cascade None. Some organizations insist on granular control over
how their opportunities are assigned; they do not want any actions to
be taken automatically. With this option, the re-assignment of the
account will not affect ownership of related opportunities.

Types of Behavior
Typically, you do not have to set the cascading rule for each of the actions
defined in a 1:N relationship. Microsoft Dynamics CRM provides a number of
pre-defined types of behavior. When selecting a pre-defined type of behavior, the
appropriate cascading rules are set for you. The figure titled Pre-defined Types of
Behavior describes these behavior types.
FIGURE 8.4 PRE-DEFINED TYPES OF BEHAVIOR
You can use the Configurable Cascading type to set the behavior for each type of
action. The primary entity is considered a “parent” of the related entity when any
of the actions use anything other than the “Cascade None” cascading rule.
IMPORTANT: The default behavior for the out-of-the-box Account

relationships is Parental. Therefore, any change to an account is affected in the
child entity records to which it is related. For example, if the owner of an
account is changed, the owner attribute on all related opportunities, leads, and
so on is automatically changed to the new owner. Similarly, if an account is
deleted, all related entity records are also deleted.
Use the following guidelines to determine when to use each behavior type:
• Parental. Use the Parental behavior type when there is strong

concept of ownership in the hierarchy of related records and the
related records depend on the primary record to establish context for
their existence. Parental behavior facilitates greater ease of managing
records, particularly when a single assigned user owns all interaction
with the primary record.

• Referential. A Referential relationship simply allows the user to

navigate from the primary record to the related records. Any changes
to the primary record will not affect the related records. Referential
behavior is appropriate when the related record already has a
parental relationship with another entity type and the purpose is
simply to allow navigation to the related record.
• Referential, Restrict Delete. Use Referential, Restrict Delete when
the related record has some dependencies on the Primary record but a
parental relationship exists with another entity. The dependency may
be a key interaction that must be preserved for reference.
• Configurable Cascading. Use Configurable Cascading when you
want to define the cascading rules separately.
Creating Entity Relationships

Perform the following steps to create, edit, and view a relationship:

2. Open the entity you want to customize, and then under Details, click
the relationship type that applies to the transaction. The options
include:
a. 1:N Relationship
b. N:1 Relationship
c. N:N Relationship
3. To edit a relationship or view the details for a relationship, select the

relationship, and on the Actions toolbar, click More Actions, and
then click Edit.
4. To add a new relationship, click New on the Action toolbar.
At this point, the selected 1:N, N;1, or N:N relationship form is returned. The
following lessons examine the properties you define when creating an entity
relationship. Some of the properties are dependent upon if you create a 1:N or
N:N relationship. Other properties are common to both relationship types.
Changes to relationships, like all other schema changes, do not have to be

published. These changes are applied immediately by the system.

1:N Relationship Properties

A 1:N relationship can be defined from the perspective of either the primary
entity (as a 1:N) or from the related entity (as a N:1). In both cases the
relationship that is created is a 1:N relationship; the only difference is the 1:N or
N:1 form from which the relationship is defined.
FIGURE 8.5 1:N RELATIONSHIP FORM
The following properties must be defined on a 1:N relationship.
Relationship Definition section
• Primary Entity. If the relationship is being created from the

perspective of the primary entity (as a 1:N), then this field is pre-
filled with the entity and disabled on the form. If the relationship is
being created from the perspective of the related entity (as a N:1),
then select the primary entity from the drop down list.
• Related Entity. If the relationship is being created from the
perspective of the primary entity (as a 1:N), then select the primary
entity from the drop down list. If the relationship is being created
from the perspective of the related entity (as a N:1), then this field is
pre-filled with the entity and disabled on the form.
• Name. This is the schema name of the relationship. The system will
automatically fill this with a concatenation of the primary and related
entity names.

Relationship Attribute section
• Display Name. When a 1:N relationship is created, the system

automatically creates a relationship attribute on the related entity.
This is implemented as a ‘lookup’ field.
This attribute stores a reference to the primary entity record's unique

ID. The Display Name field specifies the label that is used for this
relationship attribute on the related entity. The figure shows several
examples from existing relationships:
FIGURE 8.6 REFERENCES BETWEEN ENTITIES

• Name. This is the schema name of the attribute entity. This is
automatically filled in by the system based on the primary entity,
although you can change the value.
• Type. This is the field type for the relationship attribute. The default
pick list value is a Lookup field type.
• Requirement Level. The requirement level specifies if the related
entity must be related. Remember, the process of creating a
relationship creates a new attribute on the related entity. These
requirement levels are the same as when you create a new attribute.
You can also modify these values directly on the attribute.
Navigation Pane Item for Primary Entity section
• Display Option. This option controls if the relationship is displayed

on the navigation pane for the primary entity. The option also
controls the format of the name that is used if you elect to display the
relationship.
• Custom Label. Instead of using the system supplied entity name,
you can enter a custom label to describe the relationship on the
navigation pane for the primary entity. This field is only enabled if
“Use Custom Label” is selected in the Display Option field.
• Display Area. If you elect through the Display Option to display the
relationship, this field identifies the location on the navigation pane
where the relationship will be displayed.
• Display Order. Enter an integer value that determines the order in
which the related custom entity appears in the Display Area of the
Navigation Pane. Numbers below 10000 are reserved, which
prohibits you from displaying custom entities above system ones.

Relationship Behavior
• Type of Behavior. This field identifies the nature of the relationship

between the primary and related entities. It also controls the
cascading rules applied to each type of action that can be performed
on entity records affected by the relationship. The types of behavior
were examined in the prior lesson concerning 1:N Relationship
Behavior.
• Assign, Share, Unshare, Reparent, Delete, and Merge. For each of
these actions that can be performed on related entity records affected
by the relationship, these fields identify the cascading rule that is
applied to each action.
N:N Relationship Properties

A N:N relationship can be defined from either entity in the relationship. Both the
Current Entity and Other Entity sections on the form provide the same properties.
For each entity, you can define the properties that control how the relationship is
displayed on the entity's form.
FIGURE 8.7 N:N RELATIONSHIP FORM
Current and Other Entity
• Entity Name. This field is prefilled and disabled for the Current
Entity, which is the entity from which the N:N Relationship option
was selected. For the Other Entity, select the entity to which the
relationship applies.

• Display Option. This option controls if the relationship you create is

displayed on the navigation pane for each respective entity. The
option also controls the format of the name that is used if you elect to
display the relationship.
• Custom Label. Instead of using the system supplied entity name,
you can enter a custom label to describe the relationship on the
navigation pane for the respective entity.
• Display Area. If you elect through the Display Option to display the
relationship, this field identifies where on the navigation pane the
relationship will be displayed.
• Display Order. Enter an integer value that determines the order in
which the relationship is displayed on the Navigation Pane.
Relationship Definition
• Name. This is the schema name for the relationship intersect entity.
Deleting Relationships
Relationships can be deleted in two ways.
• Selecting the 1:N, N:1, or N:N Relationship option on the entity's

information page. In the Relationship window, select the relationship
and delete it.
• Deleting the relationship attribute in the related entity for a 1:N
relationship.
Deleting the relationship permanently removes the data that described the
relationship. This includes the following for each relationship type:
• N:N relationship. This removes the relationship's intersect entity.

• 1:N relationship. If you exposed the relationship attribute lookup
field on the related entity form, you must first remove the field from
the form. Because of this change made to the related entity's form,
you must republish the related entity once the relationship has been
deleted.
IMPORTANT: Before a relationship can be deleted, all references to attributes

from the resulting relationship on published forms and views must first be
removed.

Demonstration - Creating an Entity Relationship

This instructor demonstration illustrates how to create a relationship between a
custom entity (Reseller) and a system entity (Account). Steps are provided so you
can follow along with the instructor.
NOTE: This demonstration requires that the prior demonstration on Creating a

Custom Entity has been completed.
Scenario
Adventure Works Cycle sells their products through a network of resellers. These
resellers place orders to Adventure Works Cycle on behalf of their customers.
Adventure Works Cycle fulfills the orders and provides service after the sale.
Because of the 1-to-Many relationship between Resellers and Accounts, you
created a custom “Reseller” entity in the prior demonstration that separates the
resellers from their Customer records. Now that the Reseller entity has been
created, your next step is to create the 1:N relationship with the Account entity.
Goal Description
The goal of this demonstration is to create a 1:N custom-to-system relationship
with the Reseller as the primary entity and Account as the related entity. This
relationship must be a referential relationship. The only cascading action is that
the link on the Account must be removed if the related Reseller is deleted.
Creating this relationship must result in:
• A lookup field exposed on the Account form.

• All accounts associated with this reseller will be found in the
Accounts Associated view on the Reseller record.
Step by Step
Perform the following steps to create a new 1:N relationship, expose the
relationship attribute on the related entity form, and test the relationship:
Step 1: Create the 1:N Relationship

click Customize Entities, and then double-click the Reseller entity
to open it.
2. On the Details Pane, click 1:N Relationships.

3. On the 1:N Relationship view, click New 1-to-Many Relationship

on the Action toolbar.
4. Enter the following properties on the New Relationship form, then
click Save and Close:
• Relationship Definition:
– Related Entity = Account
– Name = new_Reseller_Account
• Relationship Attribute:
– Display Name = Reseller
– Type = lookup
– Name = new_ResellerID
– Requirement Level = No Constraint
– Description = The reseller who serves the account
Navigation Pane for Primary Entity
• Navigation Pane item for Primary Entity

– Display Option = Use Plural Name
– Display Area = Details
– Display Order = 10,000
• Relationship Behavior
– Type of Behavior = Referential
– Assign = Cascade None
– Reparent = Cascade None
– Share = Cascade None
– Delete = Remove Link
– Unshare = Cascade None
– Merge = Cascade None
Step 2: Expose the Lookup Field in the Account
1. On the Customize Entities view, double-click the Account entity to

open it.
2. Click Forms and View.
3. Double-click the Form to open it.
4. Select the Business Information section on the Details tab.
5. Add the Reseller ID Field.
6. Preview the form.
7. Save and Close the form.
8. Publish the Account entity.

Step 3: Test the Relationship
1. From the Navigation Pane, click Sales, and then click Account.
2. Click the Active Accounts view.
3. Open an account record and associate it with a reseller.
4. Open the reseller and confirm that the account is available from the
Accounts Associated View.
5. Create a new account from the Accounts Associated View. Notice
that the reseller is pre-populated.

Lab 8.1 - Create a Manual N:N Relationship

The objective of this lab is to manually create a N:N relationship by way of a
custom (intersect) entity that has its own custom attributes for tracking details
about the relationship.
This lab is dependent upon completion of the previous lab (Creating a Custom
Event Entity).
Scenario
Adventure Works Cycle likes their new entity for coordination of Events. Using
a single application, CRM users can now manage customers and events.
As their Microsoft Dynamics CRM implementation and support consultant,

Adventure Works has asked you to set up CRM so their Contacts can be
associated with Events. The goals of this project include:
• Associate contacts with multiple events.

• Allow events to have multiple contacts.
• Track specific registration information for each contact associated
with an event.
You explain that it will not be a problem for Microsoft Dynamics CRM to deliver
this functionality, which is known effectively as a many-to-many relationship;
that is, many Contacts associated with many Events.
Since Adventure Works wants to track registration information in the relationship

between Contacts and Events, you decide to create a de-facto N:N relationship
using a series of 1:N relationships. You will accomplish this by creating an
intersect entity with a N:1 relationship to Contacts and another N:1 relationship
to Events. The registration information can be tracked on the intersect entity.
This effectively becomes a N:N relationship.
Goal Description
During your planning session, Adventure Works Cycle tells you they want to
track the following registration information for each Contact associated with an
Event:
• The contact’s registration status (a picklist field with the following

options: invited, registered, attended, no show)
• How they registered (a picklist field with the following options:
phone, email, mail, in person)
• If they have any special requirements at the event (an ntext field)
• How much money they have paid to-date (a money field)

Adventure Works also wanted to add a field to store who recorded the
registration information and the date the Contact was registered. However, you
noted that this information is already being tracked. How is this information
tracked in the Registration entity?
After studying the situation, you propose the following customizations:
• Create a custom entity called Registration that is user owned, is

available in Microsoft Dynamics CRM for Outlook when offline,
includes CRM Notes (but no activities), is displayed in the Sales
area, and the primary attribute requirement level is No Constraint
(this is important).
• From within the Registration entity:
– Create a new N:1 relationship to Contact, with Contacts as the
Display Name, and Referential as the Relationship Behavior
– Create a second N:1 relationship to Event, with Events as the
Display Name, and Parental as the Relationship Behavior (use
parental instead of referential so that if the Event is deleted, all
the event’s registration records are also deleted).
• Create the new attributes in the Registration entity as requested by

the customer (see customer requirements above)
• Add the Event and Contact IDs to the Registration form, along with
the new attributes requested by the customer. Also add the Created
By, Created On, Modified By, and Modified On fields; remove the
Name field from the form; change the Special Requirements field to
3 rows; rearrange the fields on the form as necessary per your
creative judgment (although the important Event and Contact fields
must be on the top row).

• Edit the Registration Associated View and the Active Registrations

View to remove the Name column and add the columns for Contact,
Event, and Registration Status; ensure the Contact and Event
columns are positioned left most, and change the width of the
Contact and Event columns to 150px.
• To help track the events in which VIP contacts are registered to

attend, create a new Registration view titled VIP Event
Registrations.
− Display the following fields in this sequence: Contact,

Event, Start Date and Time (Event), Registration Status,
and Paid To Date.
− Change the width of the Contact and Event columns to
150px, and the Start Date and Time and Registration
Status columns to 125px.
− The view should filter on the following conditions:
Status Reason equals Active, and the VIP Contact
code for the related Contact equals Yes.
− Sort the records in ascending Event sequence.
− Make this the default view for the Registration entity.
Perform the following steps to test this functionality once the customizations
have been applied:
• Create a sample Event.
• Create a new Contact or open an existing Contact and set its VIP
contact code to Yes. Save the contact, and then click on Registration.
Create a new Registration record. Use the Event lookup to find and
select your new Event, and fill in the other fields.
• Register another contact for the same event. Do not make this a VIP
contact.
• Each Contact’s registration information can be viewed either from
the Event or the registered Contact.
• If the Event is deleted, all the event’s registration records are also
deleted (parental relationship).
• Create several other sample Events. Register VIP contacts for some
of the events, but leave one or two events without any contacts or
with contacts that are not VIPs.
• Test the new VIP Event Registrations view. This should be the
default view for Registrations. Verify the appropriate contacts are
displayed.

Challenge Yourself
complete this lab:
1. Create a custom entity called Registration.

2. From within the Registration entity, create a new many-to-one (N:1)
relationship to Contact.
3. From within the Registration entity, create a second many-to-one
relationship to Event.
4. Create the new attributes in the Registration entity as requested by
the customer.
5. Add these new attributes to the Registration form. As a best practice,
verify your changes using the Preview menu option.
6. Edit the Registration Associated View and the Active Registrations
View.
7. Create a new Registration view titled VIP Event Registrations. Make
this the default Registration view.
8. Test the functionality of the Registration entity and the new N:N
relationships by performing the steps in the Goal Description.
9. Test the functionality of the new VIP Event Registrations view.
Need a Little Help?

Step 1 - Create Intersect Entity
Create a custom entity named “Registration” that has the properties outlined in
1. Navigate to Settings and Customize Entities.

2. Create a new entity titled Registration.
4. Show the entity in Microsoft Dynamics CRM for Outlook when
offline.
5. Create a relationship with Notes, but not with Activities.
6. Select the Sales display area.
7. For the Primary Attribute, select No Constraint as the Requirement
Level.
Step 2 - Create a N:1 Relationship
1. With the entity page still open for the Registration entity, create a
N:1 Relationship.
2. The Primary Entity will be Contact, and the Type of Behavior must
be Referential.

Step 3 - Create a Second N:1 Relationship
1. With the entity page still open for the Registration entity, create a
N:1 Relationships in the Details pane.
2. The Primary Entity field will be Event, and the Type of Behavior
field must be Parental.
Step 4 - Add Attributes to the Intersect Entity
Add the additional Registration attributes based on the instructions in the Goal
Description. The Display Name for each attribute will match its database schema
name.
1. The Registration entity window should still be open after you saved
the second N:1 relationship in the prior step.
2. Select Create a Registration Status attribute. This will be a picklist.
Add the picklist values specified in the Goal Description.
3. Create a Registration Method attribute. This will also be a picklist.
Add the picklist values from the values specified in the Goal
Description.
4. Create a Special Requirements attribute. This will be an ntext field.
5. Create a Paid To Date attribute. This will be a money field.
Step 5 - Update the Intersect Entity Form
Update the form for the Registration entity based on the instructions in the Goal
Description.
the last attribute in the prior step.
2. Open the registration's Form.
3. Add the following fields: Contact, Created By, Created On, Event,
Modified By, Modified On, Paid to Date, Registration Method,
Registration Status, and Special Requirements.
4. Remove the Name field.
5. Select the Special Requirements field and change its properties. In
the Formatting tab, change the Number of Rows to 3.
6. Use the green arrows to rearrange the fields as you feel they should
appear. The only stipulation from Adventure Works is that the Event
and Contact fields appear on the first row.
7. Preview the Create Form to verify the form appears as it should.
8. Save the changes and publish the customizations.

Step 6 - Edit the Registration views
Update the Associated View on the Registration entity based on the instructions
1. The Registration Forms and Views window should still be open after
you saved the form in the prior step.
2. Open the Registration Associated View.
3. Remove the Name column.
4. Add the following columns: Contact, Event, and Registration Status.
5. Use the green arrows to position the Contact and Event columns to
the left most position on the line.
6. Change the width of the Contact column to 150px. Repeat for the
Event column.
7. Save the changes.
8. Repeat these steps for the Active Registrations view.
9. Publish the customizations.
Step 7 - Create a new Registration view
Create a new view for the Registration entity titled VIP Event
Registrations.
1. Open the Registration entity and create a new view.

2. The name of the view should be VIP Event Registrations.
3. Add the following columns from the Registration entity: Contact,
Event, Paid To Date, and Registration Status. Add the Start Date
and Time column from the related Event entity.
4. Using the green arrows, display the columns in the following
sequence: Contact, Event, Start Date and Time (Event),
Registration Status, Paid To Date.
5. Change the width of the Contact and Event columns to 125px.
Change the width of the Start Date and Time and Registration
Status columns to 125px.
6. The view should filter on Status Reason = Active, and the VIP
Contact code on related Contacts = Yes.
7. Sort the records in ascending Event sequence.
8. Save the view.
9. Make this view the default view for the Registration entity.
10. Publish the changes.

Step 8 - Test the Relationship Functionality
1. Create an Event.
2. Open an existing Contact and set its VIP contact code to Yes. Save
the contact, and then create a new Registration record for the contact.
Use the Event lookup to find and select your new Event, and fill in
the other fields with data of your choice.
3. Open another contact and register him or her for the same event. Do
not make this a VIP contact.
4. Create several other sample Events. Register VIP contacts for some
5. From the Sales menu, select Registrations. The VIP Event
Registration view should be displayed as the default view. Verify the
appropriate Contacts are displayed.
6. From the Sales menu, select Events. Each of the events that you
created should be displayed.
7. Open the first event record that you created, and select Registrations.
This displays the Registration Associated View that you modified
earlier. The contacts that you registered for the event should be
displayed.
8. To test the parental relationship between Events and Registrations,
delete this first event that you created.
9. From the Sales menu, select Registrations. Select the Active
Registrations view. No registration records should exist for the event
that you deleted.
Step by Step
Step 1 - Create Intersect Entity
Create a custom entity named “Registration” that has the properties outlined in

3. On the General Tab, enter Registration in the Display Name field.
4. Tab into the Plural Name field. Enter Registrations as the plural
Name.
6. When you tabbed out of the Display Name field, the Name field was
automatically filled in for you with new_registration.
8. Accept the default options for duplicate detection.

9. Select the option to create a relationship with Notes, but not with
Activities.
10. Select the Sales display area.
11. Click the Primary Attribute tab.
12. In the Requirement Level field, select No Constraint.
13. Click Save. This leaves the Entity page open for the new
Registration entity.
1. With the entity page still open for the Registration entity, click N:1
Relationships in the Details pane.
2. On the N:1 Relationships page, click New Many-to-1 Relationship.
3. In the Primary Entity field, select Contact from the drop down list.
This automatically fills in the schema Name for this relationship.
4. In the Relationship Attribute section, enter Contact as the Display
Name. When you tab out of this field, the schema name is
automatically created for you.
5. Do not change any of the default values for the remaining fields. The
Type of Behavior defaults to Referential, which was the last
requirement in the Goal Description.
Step 3 - Create a Second N:1 Relationship
1. With the entity page still open for the Registration entity, click N:1
Relationships in the Details pane.
2. On the N:1 Relationships page, click New Many-to-1 Relationship.
3. In the Primary Entity field, select Event from the drop down list.
This automatically fills in the schema Name for this relationship.
4. In the Relationship Attribute section, enter Event as the Display
Name. When you tab out of this field, the schema name is
automatically created for you.
5. In the Type of Behavior field, select Parental.
Step 4 - Add Attributes to the Intersect Entity
Add the additional Registration attributes based on the instructions in the Goal
Description.
the second N:1 relationship in the prior step.
3. On the Attributes window, click New.
4. Create a Registration Status attribute. In the Display Name field,
enter Registration Status.

5. In the Type field, select picklist.

6. Add the picklist values specified in the Goal Description.
8. Create a Registration Method attribute. In the Display Name field,
enter Registration Method.
9. In the Type field, select picklist.
10. Add the picklist values specified in the Goal Description.
12. Create a Special Requirements attribute. In the Display Name field,
enter Special Requirements.
13. In the Type field, select ntext.
15. Create a Paid To Date attribute. In the Display Name field, enter
Paid to Date.
16. In the Type field, select money.
Step 5 - Update the Intersect Entity Form
Update the form for the Registration entity based on the instructions in the Goal
Description.
the last attribute in the prior step.
2. In the Details pane, click Forms and Views.
3. Double-click on the Form.
5. Select the following fields: Contact, Created By, Created On,
Event, Modified By, Modified On, Paid to Date, Registration
Method, Registration Status, and Special Requirements. Click
OK.
6. Select the Name field and click Remove. Click OK to confirm the
removal.
7. Select the Special Requirements field and click Change
Properties. Click the Formatting tab and change the Number of
Rows to 3. Click OK.
8. Use the green arrows to rearrange the fields as you feel they should
appear. The only stipulation from Adventure Works is that the Event
and Contact fields appear on the first row.
9. Click Preview on the menu. Click Create Form. Close the Preview
form.
11. On the Registration entity window, click Actions on the menu and
click Publish.
Step 6 - Edit the Registration views

Update the Registration entity's Associated View and Active Registrations

view based on the instructions in the Goal Description.
1. The Registration Forms and Views window should still be open after
you saved the form in the prior step.
2. Double-click Registration Associated View.
3. Select the Name column and click Remove. Click OK to confirm
the removal.
4. Click Add Columns. Select the Contact, Event, and Registration
Status. Click OK.
5. Use the green arrows to position the Contact and Event columns to
the left most position on the line.
6. Select the Contact column and click Change Properties. Select
150px and click OK. Repeat for the Event column.
8. Repeat these steps for the Active Registrations view.
9. Leave the Forms and Views window open in order to complete the
next set of steps.
Step 7 - Create a new Registration view
Create a new Registration view titled VIP Event Registrations. Make this
the default Registration view.
1. The Registration entity's Forms and Views window should still be

open after completing the prior step.
2. Click New.
3. In the Provide Information for this View dialog box, enter VIP
Event Registrations. Click OK.
4. Click Add Columns. Select the following Registration attributes:
Contact, Event, Paid To Date, and Registration Status.
5. Click the Record Type drop down arrow. From the list of related
entities, select Event (Event).
6. Select the Start Date and Time field. Click OK.
7. Using the green arrows, display the columns in the following
sequence: Contact, Event, Start Date and Time (Event),
Registration Status, Paid To Date.
8. Click the Contact column heading and select Change Properties.
Select 150px and click OK. Repeat for the Event column heading.
9. Click the Start Date and Time column heading and select
Change Properties. Select 125px and click OK. Repeat for the
Registration Status column heading.
10. Click Edit Filter Criteria.
11. In the Edit Filter Criteria dialog box, hold your mouse over the
Select field and click the drop down arrow. Click the Status
Reason field.

12. Click Enter Value. Click on the Ellipsis button. Select Active and
click the >> arrow to move the value to the Selected Values
column. Click OK.
13. Hold your mouse over the new Select field and click the drop
down arrow. In the Related entities list, click Contact.
14. Under the Contact row, hold your mouse over the Select field and
click the drop down arrow. Select the VIP contact field.
15. Click Enter Value. Click on the Ellipsis button. Select Yes and
click the >> arrow to move the value to the Selected Values
column. Click OK.
17. Click Configure Sorting.
18. Select the Event column and click OK (ascending is the default
sort order).
20. On the Registration Forms and Views window, select the VIP
Event Registrations view that you just created.
21. Click More Actions on the Action toolbar and click Set Default.
22. Click Save and Close on the Registration Forms and Views
window.
23. On the Customize Entities window, the Registration entity is
already selected. Click Publish on the Action toolbar.
Step 8 - Test the Relationship Functionality
1. Create an event. From the Navigation Pane, click Sales, then click
Events.
2. Click New. Fill in information for an event of your choice. Click
Save and Close.
3. From the Sales menu, click Contacts. Open an existing contact
record.
4. Click on the Details tab and click Yes for the VIP contact field.
Click Save.
5. From within the Contact record, click Registrations in the Details
Pane. Click New Registration on the Action toolbar.
6. Click the lookup icon for the Events field. In the Look Up Records
dialog box, select the event that you just created. Click OK.
7. Fill in the remaining fields on the Registration form. Click Save and
Close.
8. Open another contact record and register him or her for the same
event. Do not make this a VIP contact.
9. Create several other sample Events. Register VIP contacts for some
10. From the Sales menu, click Registrations. The new VIP Event
Registrations view should be displayed as the default view for
Registrations. Verify the appropriate contacts are displayed.
11. From the Sales menu, click Events. Each of the events that you
created should be displayed.

12. Open the first Event record that you created. In the Details
pane, select Registrations. This displays the Registration Associated
View that you modified earlier. The contacts that you registered for
the event should be displayed. Click Save and Close.
13. To test the parental relationship between Events and Registrations,
select this first Event that you created and click the Delete icon on
the Action toolbar. Click OK to confirm the deletion.
14. From the Sales menu, click Registrations. Click the View drop
down arrow and select the Active Registrations view. No
registration records should exist for the event that you deleted.

Lab 8.2 - Create a Native N:N Relationship

The objectives of this lab include performing many of the platform
customizations covered earlier in this training, as well as the application
customization covered in the prior training. The prior lab created a de-facto N:N
relationship manually through a series of 1:N relationships that shared an
intersect entity. This lab creates a native N:N relationship using the standard
customization tool, along with a 1:N relationship.
• Create a custom entity.

• Create a N:N and 1:N relationship between this entity and another
entity.
• Modify the form for the new custom entity to include specific
attributes
• Modify views involving this new entity
• Enter data per scenario requirements to implement the
customizations made in the prior steps
Scenario
You are a Microsoft Dynamics CRM implementation consultant for Adventure

Works Cycle. You have been asked to plan and execute an expansion of the
current CRM functionality. The Adventure Works subject matter experts explain
that some of their customers are designated as distributors. They are tracked in
Microsoft Dynamics CRM as Accounts, but need a new Customer Type field
created with a value set to “Distributor”. They also want to view only Active
Accounts that are Distributors.
After reviewing the existing Account schema, you realize that a picklist attribute
already exists called ‘Relationship Type’. While you could add an extra picklist
value called ‘Distributor’, this prohibits Adventure Works from modeling the
situation where a Distributor can also be a Customer.
You also discover that distributors are assigned geographic regions as their
territories. Therefore, you suggest adding a new custom entity titled Sales
Region. A distributor can cover multiple regions, and a region can have multiple
distributors. Each Sales Region has some information that needs to be tracked
separately, such as regulations, dates, fees, contacts, description, notes, and
activities. However, because no additional information needs to be tracked
regarding the relationship between Accounts and Sales Regions, you suggest to
the planning team that this is an excellent opportunity to create a native N:N
relationship using the system customization tools.

Although Microsoft Dynamics CRM has an existing entity called ‘Territory’ that
is already on the Account entity, Adventure Works want to differentiate between
Territory and Sales Region. “Territory” will be used by the inside sales team to
define their geographic regions, and “Sales Region” will be used to define the
geographic territory assigned to a Distributor.
Goal Description
In your planning sessions with Adventure Works, you have outlined the
following changes that must be made to satisfy their business requirements:
• To track distributors, create a new bit-type attribute in Accounts

named “Distributor” with a default value of No. Expose this attribute
in the Account Information section of the Account form.
• Create a new Account view called “Active Distributors Only”. This
view will filter on Status Reason = Active, Relationship Type =
Customer, and Distributor = Yes. You have also agreed to add the
Address 1: City and Owner columns to the view.
• Save the Account entity, publish it, and test it.
• Create a custom entity named Sales Region that is user owned,
available offline, includes Notes, and is displayed in the Sales area.
• Create several attributes for this new entity: regulation details,
renewal date, application fee, and description (multi-line text).
• From the Sales Region entity, create a N:N relationship between
Sales Region and Accounts. For each entity on the Relationship
form, set the Display Option to “Use Plural Name”, and set the
Display Area to “Details”. Do not change the default value of the
Display Order, the relationship Name, or the Relationship Entity
Name.
• In the Sales Region entity, create a new N:1 relationship to Contact
for tracking the Regional Chairman. Set the relationship attribute's
Display Name to Regional Chairman and the Type of Behavior to
“Referential”. Set the Display Option to “User Plural Name”, and the
Display Area to “Details”.
• Expose the Regional Chairman attribute on the Sales Region form.
• Once the relationship between Sales Region and Contact is created,
add these new attributes on the Sales Region form, along with the
following attributes: Application Fee, Created By, Created On,
Description, Modified By, Modified On, Regulation Details, and
Renewal Date. Format the Regulation Details field to display as two
columns and rearrange the fields as necessary.
• Set up the view of Active Sales Regions to include the columns
Regional Chairman, Owner, and Renewal date. Remove the Created
On column. Change the Name column to 200px and the Regional
Chairman column to 125px.

• Add the Regulation Details attribute to the preview form and change
it to display in two columns instead of one.
• Publish all the entities that were changed.
• To test this functionality, create some Sales Regions and make some
assignments.
Challenge Yourself
complete this lab:
1. Add a new Distributor attribute to the Account entity and expose it

on the Account form.
2. Create a new Account view called “Active Distributors Only”.
3. Test the Account changes.
4. Create a custom entity named Sales Region and add several
attributes to the entity.
5. Create a N:N relationship between Sales Region and Accounts.
6. In the Sales Region entity, create a N:1 relationship to Contact for
tracking the Regional Chairman.
7. Expose the Regional Chairman attribute on the Sales Region form.
8. Add new attributes to the Sales Region form.
9. Update the Active Sales Regions view.
10. Update the Sales Region Preview form.
11. Test the functionality by creating some Sales Regions and making
some assignments.
Need a Little Help?

Perform the following steps to complete this lab.
Step 1 - Update Account Attribute and Form

2. Open the Account entity.
3. Add a new attribute titled Distributor. The Type is bit, with a Default
value of No.
4. Add this field to the Account form. Double-click on Form to open
the Account form.
5. Add this field to the Account Information section of the Account
Form.
6. Save and publish your changes.

Step 2 - Create a new Account View
1. Create a new Account view titled Active Distributors Only.

2. The Filter Criteria should check for Status Reason = Active,
Relationship Type = Customer, and Distributor = Yes.
3. Add the Address 1:City and Owner fields to the view.
4. Save and publish the changes.
Step 3 - Test the Account Changes
1. Navigate to Sales, then Accounts.

2. Open the Bike Products and Accessories account.
3. Change its Relationship Type to Customer and set the Distributor
field to Yes.
4. Save the account.
5. Create a new account.
6. Enter an Account Name and City of your choice.
7. Set the Relationship Type to Customer and the Distributor to Yes.
8. Save the account
9. When viewing Accounts, change the View to display the new Active
Distributors Only view.
10. Verify that the two accounts you updated are displayed.
Step 4 - Create a Custom Entity
1. Navigate back to the Customization menu, and then click Customize

Entities.
2. Create a new entity titled Sales Region. Enter Sales Regions as the
Plural name.
3. This is a User owned entity that must be displayed when the
Microsoft Dynamics CRM for Microsoft Office Outlook is offline.
4. This entity should be related to Notes but not Activities, and it
should be displayed in the Sales area.
5. Save the entity.
6. For this Sales Region entity, add a new attribute titled Regulation
Details. This is an nvarchar type attribute.
7. Add another attribute titled Renewal Date. This is a datetime type,
but the format should be for the Data only.
8. Add another attribute titled Application Fee. This should be a money
type field with 2 decimal precision.
9. Finally, add a Description attribute that is an ntext field type.
10. Save the changes.

Step 5 - Create a N:N Relationship
1. Create a N:N Relationship for the Sales Region entity.

2. The other entity will be Account.
3. For both entities, set the Display Option to User Plural Name, and set
the Display Area to Details.
4. Save the relationship.
1. Create a N:1 Relationship for the Sales Region entity.

2. The Primary Entity will be Contact.
3. For the Relationship Attribute section, enter Regional Chairman as
the Display Name.
4. Set the Type of Behavior to Referential.
5. Accept all other default values, including Use Plural Name as the
Display Option, and Details as the Display Area.
6. Save the relationship.
Step 7 - Update the Custom Entity Form
1. In Sales Region's Forms and Views window, open the Sales Region
Form.
2. Add the following fields to the form: Application Fee, Created By,
Created On, Description, Modified By, Modified On, Regional
Chairman, Regulation Details, and Renewal Date.
3. Change the formatting property of the Regulation Details field to
Two columns.
4. Use the green arrows to rearrange the fields to your satisfaction.
5. Save the form.
Step 8 - Update a View and the Preview form
1. In Sales Region's Forms and Views window, open the Active Sales
Regions view.
2. Add the following columns to the view: Owner, Regional Chairman,
and Renewal Date.
3. Remove the Created On column.
4. Change the column width of the Name column to 200px.
5. Change the column width of the Regional Chairman column to
125px.
6. Save the view.
7. Open the Sales Region Preview form.

8. Add the Regulation Details field to the form, then change its
formatting property to Two columns.
9. Save the view, then save Sales Region Forms and Views.
10. Publish all customizations.
Step 9 - Test the Functionality
1. Navigate to Sales and then Sales Regions. If Sales Regions does not
appear in the Sales menu, close Internet Explorer and then re-open it.
Navigate back to Sales, and the Sales Regions should appear.
2. Create a new sales region titled Western Region.
3. Set the Regional Chairman to Alan Waxman.
4. Save the record.
5. Add three existing Accounts for this Sales Region.
6. Save the region, then create a new sales region titled Eastern Region.
7. For the Regional Chairman, create a new Contact record with
your name as the contact name. Enter Boston as the City.
8. Search for your name in the Look Up Records dialog box. Select
your contact record when it appears.
9. Save the Sales Region form.
10. Add an Account to the region. In the Look Up dialog box, search all
accounts and select several that should be assigned to this region.
11. Save the region.
12. Navigate back to Sales, and then Accounts.
13. Open an account that you previously assigned to a sales region.
14. Select the Sales Regions assigned to the account to view the account
that you previously assigned.
Step by Step
Perform the following steps to complete this lab.
Step 1 - Update Account Attribute and Form

2. Double-click Account to open the Account entity.
3. Click Attributes, and then click New to add a new attribute.
4. Enter Distributor as the Display Name.
5. Click the Type drop down arrow and select bit.
6. Set the Default Value to No.

9. Double-click on Form to open the Account form.

10. Select the Account Information section and click Add Fields.
11. In the Add Fields dialog box, select the new Distributor field and
click OK.
13. On the Account Forms and Views window, click Actions in the
menu bar and click Publish.
Step 2 - Create a new Account View
1. The Account Forms and Views window should still be open after
publishing the Account in the prior step.
2. Click New.
3. In the Provide Information for this View dialog box, enter Active
Distributors Only as the view name. Click OK.
4. Click Edit Filter Criteria.
5. Hold your mouse over the Select link and click the drop down arrow.
Select Status Reason.
6. Hold your mouse over the Enter Value link and click the Ellipsis
button. Select Active and click the >> arrow to move the value to
the Selected Values column. Click OK.
Select Relationship Type.
button. Select Customer and click the >> arrow to move the value
to the Selected Values column. Click OK.
Select Distributor.
button. Select Yes and click the >> arrow to move the value to the
Selected Values column. Click OK.
11. Click OK.
12. Click Add Columns.
13. Select the Address 1:City and Owner fields. Click OK.
15. Click Save and Close on the Forms and Views window.
16. The Account entity is already selected on the Customize Entities
window. Select Publish from the Actions toolbar.
Step 3 - Test the Account Changes
2. Double-click Bike Products and Accessories to open it.
3. Click the Relationship Type drop down arrow and select Customer.
4. Click Yes on the Distributor field.


6. Click New.
7. Enter an Account Name and City of your choice.
8. Click the Relationship Type drop down arrow and select Customer.
9. Click Yes on the Distributor field.
11. Click on the View drop down arrow and select Active Distributors
Only.
12. Verify that the two accounts you updated are displayed.
Step 4 - Create a Custom Entity

2. Click New.
3. Enter Sales Region in the Display Name field. Enter Sales Regions
in the Plural field.
4. The default Ownership value is already set to User. Do not change
this value.
5. Select the option to show this entity when the Microsoft Dynamics
CRM for Microsoft Office Outlook is offline.
6. Select only the Notes relationship. Uncheck Activities.
7. Select the Sales area to display the entity.
8. Click Save.
9. Click Attributes.
10. Click New.
11. Enter Regulation Details in the Display Name field.
12. Select nvarchar as the Type.
14. Enter Renewal Date in the Display Name field.
15. Select datetime as the Type.
16. Select Date Only as the Format.
18. Enter Application Fee in the Display Name field.
19. Select money as the Type.
20. Select 2 as the Precision.
22. Enter Description in the Display Name field.
23. Select ntext as the Type.

Step 5 - Create a N:N Relationship
1. The Sales Region entity window should still be open following the
last attribute that you added in the prior step.
2. Click N:N Relationships in the Details Pane.
3. Click New Many-to-Many Relationship.
4. For the Current Entity, select Use Plural Name as the Display
Option and accept the default value of Details as the Display Area.
5. For the Other Entity, click the drop down arrow for the Entity Name
and select Account.
6. Select Use Plural Name as the Display Option and accept the
default value of Details as the Display Area.
7. Accept the default values for the remaining fields. Click Save and
Close.
N:N relationship you created in the prior step.
2. Click N:1 Relationships in the Details Pane.
3. Click New Many-to-1 Relationship.
4. In the Primary Entity field, select Contact from the drop down list.
5. In the Relationship Attribute section, enter Regional Chairman as
the Display Name.
6. In the Relationship Behavior section, select Referential as the Type
of Behavior.
7. Accept all other default values, including Use Plural Name as the
Display Option, and Details as the Display Area.
Step 7 - Update the Custom Entity Form
N:1 relationship you created in the prior step.
2. Click Forms and Views in the Details Pane.
3. Double-click Form to open the Sales Region form.
5. In the Add Fields dialog box, select the following fields:
Application Fee, Created By, Created On, Description, Modified
By, Modified On, Regional Chairman, Regulation Details, and
Renewal Date. Click OK.
6. Select the Regulation Details field and click Change Properties.

7. Select the Formatting tab and select the Two columns option. Click
OK.
8. Use the green arrows to rearrange the fields to your satisfaction.
Step 8 - Update a View and the Preview form
1. The Sales Region's Forms and Views window should still be open
after updating the form in the prior step.
2. Double-click the Active Sales Regions view to open it.
3. Click Add Columns.
4. In the Add Columns dialog box, select Owner, Regional Chairman,
and Renewal Date. Click OK.
5. Select the Created On column and click Remove. Click OK to
confirm the deletion.
6. Select the Name column and click Change Properties. Change the
column width to 200px. Click OK.
7. Select the Regional Chairman column and click Change
Properties. Change the column width to 125px. Click OK.
9. Double-click Preview to open the Sales Region's Preview form.
11. In the Add Fields dialog box, select Regulation Details and click
OK.
12. Select the Regulation Details field and click Change Properties.
13. Select the Formatting tab and select Two columns. Click OK.
15. Click Save and Close on the Sales Region Forms and Views
window.
16. On the Customize Entities window, click More Actions and click
Publish All Customizations.
Step 9 - Test the Functionality
1. From the Navigation Pane, click Sales, and then click Sales Regions.
If Sales Regions does not appear in the Sales menu, close Internet
Explorer and then re-open it. Navigate back to Sales, and the Sales
Regions should appear.
2. Click New.
3. Enter Western Region as the Sales Region Name.
4. Click on the lookup icon for the Regional Chairman field. In the
Look Up Records dialog box, select Alan Waxman. Click OK.
5. Click Save (not Save and Close)on the Sales Region form.
6. Click Accounts in the Details pane.
7. Click Add Existing Account.

8. In the Look Up Records dialog box, click the Search icon to display
all Accounts.
9. Select an account and click the >> arrow to move it to the Selected
Records column. Repeat this step for several additional accounts.
Click OK.
11. Enter Eastern Region as the Sales Region Name.
12. Click on the lookup icon for the Regional Chairman field. In the
Look Up Records dialog box, select New.
13. Create a new Contact record. Enter your name in the contact name
fields, enter Boston as the City, and click Save and Close.
14. In the Look Up Records dialog box, enter your name in the Search
field at the top of the form and click the Search icon. Your contact
record should appear. Click OK.
15. Click Save (not Save and Close)on the Sales Region form.
16. Click Accounts in the Details pane.
17. Click Add Existing Account.
18. In the Look Up Records dialog box, click the Search icon to display
all Accounts.
19. Select an account and click the >> arrow to move it to the Selected
Records column. Repeat this step for several additional accounts.
Click OK.
22. Double-click an Account that you previously assigned to a sales
region.
23. In the Details pane, click Sales Regions. The sales region to which
the account was assigned should be displayed.

Entity Mapping
Entity mapping facilitates data entry when creating new records that are related
to a parent record. When a form for new record that is not associated with a
parent record is opened, all the fields in the form are blank. If there are any
required relational constraints to another entity, those fields must be manually
filled in before the record can be saved. This is why it is usually easier for the
user to add new records from the Parent record.
For example, when an opportunity is created from within an existing account, the
Potential Customer and Price List fields are pre-populated with the account's
information because a mapping exists between Account and Opportunity. The
mapping pre-populates defined fields in a new record with information from the
parent object. Users can overwrite any of the mapped values before saving the
record.
Microsoft Dynamics CRM allows the mapping of one source attribute to many
attributes in the target entity. For example, address fields in an Account can be
mapped to both the Billing Address and the Shipping Address fields on an Order.
Limitations of Mapping
The following limitations are associated with attribute mapping:
• Mapping only works when a new record is created in the context of a

parent record. Mapping does not apply if a user creates a new record
outside of the context of a parent record.
For example, if a user creates an opportunity and then manually

performs a lookup to add an Account as the potential customer,
mapping will not be applied. Also, the Price List information from
the account will not be automatically added to the opportunity in the
same way that it is if the opportunity had been created in the context
of the account.
• Mapping does not apply when an existing record is updated; it only
pre-populates the form of a new record before it is saved.
• Mapping does not maintain any relationships after the record is
created, and does not keep data synchronized.
For example, if a user later changes the Price List value on an

account, the price list value in any opportunities attached to that
account will not change.

Attribute Mapping Restrictions

The following restrictions apply to attributes that can be mapped:
• Both attributes must be of the same data type.

• The length of the target attribute must be equal to or greater than the
length of the source attribute.
• The target attribute must not be involved in another mapping.
• You cannot map to or from a disabled field.
Finally, it is not necessary to explicitly map the Owner field. The application will
automatically map this attribute.
Mapping Picklists
If both attributes are picklists, special consideration must be given to their
corresponding value mappings. Microsoft Dynamics CRM automatically assigns
an index value to each picklist entry. The index value assigned to each entry
cannot be changed. When a picklist entry is deleted, the assigned index value
associated with that entry cannot be reused.
In each attribute, the picklist entry has a corresponding text display value. When
picklists are mapped, the index value of each picklist entry is transferred to the
target record, regardless if they share the same display value, or if the value of
the parent attribute is valid in the target picklist. If you map picklist values, you
must manually confirm that the values and display values of the two fields match.
FIGURE 8.8 MAPPING NON-EQUIVALENT PICKLISTS
In the figure titled Mapping Non-Equivalent Picklists, the picklist attributes from
Attribute A can be mapped to Attribute B. But because the index values and
descriptions are not identical, the mapping can cause inaccurate or bad data to be
entered into Attribute B. For example, if the Attribute A value for “Cold” was
mapped to Picklist Attribute B, the index value “4” is displayed because there is
no corresponding display value.

Automatic Attribute Mapping

Microsoft Dynamics CRM can automatically generate mappings between the
attributes in two entities. On the Mapping screen, click More Actions, then
Generate Mapping. This automatically generates mappings based on the name
and data type of the attributes.
This feature is provided as a convenience when there are a large number of fields
to map and they share the same naming conventions. Rather than manually
mapping each attribute, they can be automatically mapped. Any unwanted
mappings can then be removed.
NOTE: Care must be taken when using this feature. The convenience it
provides applies to a specific situation and it will override any existing
mappings.
Add a Mapping
Perform the following steps to map attributes between two entities:

2. Before mapping attributes, publish customizations to entities that
contain the source and target attributes you plan to map.
3. Open the entity you want to customize, and then under Details, click
1:N Relationships.
4. Select Mappings in the Details Pane.
5. Click New.
6. In the Create Attribute Mapping dialog box, select the source
attribute from Source Entity Attributes. Then select the target
attribute from Target Entity Attributes and click OK.
7. Click Save and Close to close the Relationship form.
8. Publish the customizations.
NOTE: After publishing customizations, mappings will be available for all

users. If you reset Internet Information Services for any reason before you
publish customizations, mappings will be available for all users, even though
other customizations will not be available.

Demonstration - Entity Mapping

This instructor demonstration illustrates how to define mappings between
entities. Steps are provided so you can follow along with the instructor.
NOTE: This demonstration requires that Demonstration: Create a Custom

Entity and Demonstration: Creating Relationships be completed.
Scenario
Adventure Works Cycle wants to streamline data entry by using mapping. They
have identified that most Accounts associated with a Retailer are in the same
Postal Code as the reseller. If the Postal Code value of the Reseller were copied
to any new account record created from it, the user does not need to enter that
data.
Goal Description
The goal of this demonstration is to map the Postal Code field from the Reseller
entity to the Postal Code field on the Account entity.
Step by Step
Perform the following steps to create and test a new mapping:
Step 1: Create a Mapping
1. From the Navigation pane, click Settings, click Customization, and

2. Open the Reseller entity and click 1:N Relationships.
3. Select the relationship where Account is the Related Entity.
4. Click Mappings.
5. Click New.
6. From the Source entity Attributes grid, select new_postalcode.
7. From the Target Entity Attributes grid, select address1_postalcode.
8. Click OK.
Step 2: Test
1. Open a Reseller record that has data in the postal code field.
2. Click the Accounts side tab.
3. Click New Account from the Accounts Associated View.
4. Note that the Account Zip/Postal Code field has the value from the
Reseller Postal Code field.

Lab 8.3 - Add a Mapping

• For two picklist attributes that are mapped together through a

relationship, add additional picklist values to both attributes
• For two entities that already have a relationship, add new attributes
and define the mapping between these attributes
Scenario
Adventure Works Cycle likes the fact that in Microsoft Dynamics CRM, many
fields in Leads are copied to Accounts, Contacts, and Opportunities when a lead
is converted to each of these entities. However, Adventure Works wants to
change and expand the list of Industries, and have the correct values appear in
Accounts when the Lead is converted. The company also wants to create some
new fields in Leads for tracking prospect interests, and have them appear in
Contacts when the Lead is converted.
As their Microsoft Dynamics CRM implementation and support consultant, you

have been asked you to make this improvement. You document the required
changes to Industries, and then explain to the customer the importance of keeping
mapped picklist fields manually in sync on both sides of the relationship since
CRM maps a reference number rather than the value itself when Leads are
converted. You also document what type of interests the customer wants
recorded.
Goal Description
Adventure Works Cycle informs you that they want to add the industries of
Manufacturing, Leisure & Travel, and Healthcare, and eliminate the industry
listed as SIG Affiliations. They also want to track a person’s interests in Racing
and Fitness.
• For changing the Industries, make the same changes to the Industries
picklist in both Leads and Accounts.
• For tracking interests, create several new attributes in Leads for the
interests listed above. Each interest must have a format type of bit.
Place these attributes on the form using a checkbox format type and
repeat the process for Contacts.
• Find the 1:N relationship from Lead to Contact. Add mappings for
these two interest fields. When a contact is created from a lead, the
values in these two fields on the Lead record will be stored in the
Contact record.
• To test this functionality, create a new Lead that incorporates one of
these Industries and several of the Interests, and then convert the
Lead to an Account and Contact to verify that the values carry
forward to the new entities.

Challenge Yourself
complete this lab:
1. Apply the requested changes to the Industries picklist values in both

Leads and Accounts.
2. Add the requested attributes to the Lead entity for tracking the
personal interests of the lead.
3. Expose these new interest attributes on the Lead form using a
checkbox format type. Repeat the process for Contacts.
4. Find the relationship from Lead to Contact and add the mapping
between these new interest attributes.
5. To test this functionality, create a new Lead that incorporates one of
these Industries and Interests. Convert the Lead to an Account and
Contact to verify that the values carry forward to the new entities.
Need a Little Help?

Step 1 - Update Picklists for Leads and Accounts
Adventure Works Cycle wants to add the industries of Manufacturing, Leisure &
Travel, and Healthcare, and eliminate the industry listed as SIG Affiliations.

2. Open the Lead entity.
3. Select Attributes, and then open the industrycode attribute.
4. In the Industry of Lead attribute form, update the picklist values by
adding Manufacturing, Leisure and Travel, and Healthcare.
5. Remove the SIG Affiliations picklist value.
6. Sort the picklist values in ascending sequence.
7. Save the entity.
8. Repeat the same steps as above to make the same changes to the
industrycode attribute on the Account entity.
Step 2 - Add New Attributes for Leads and Contacts
Create attributes in Leads for tracking a person’s interests in Racing and Fitness.
Each interest must have a format type of bit. Place these attributes on the form
using a checkbox format type and repeat the process for Contacts.
1. Open the Lead entity on the Customize Entities view.

2. Add new attributes for Racing and Fitness. Select bit as the Type for
each attribute.
3. Close the entity.

4. Open the Lead form.

5. Select the Contact Information section.
6. Add fields titled Racing and Fitness.
7. On the Lead form, change the properties of the Fitness field from a
Yes/No field to a Check box. Repeat for the Racing field.
8. Preview the changes, then save the form.
9. Repeat these steps for the Contact entity. Add the Fitness and Racing
attributes, then expose them on the Contact form in the Professional
Information section of the Details tab.
10. On the Customize Entities window, publish the customizations for
both entities by clicking More Actions, and then clicking Publish All
Customizations.
Step 3 - Create a Mapping
Find the 1:N relationship from Lead to Contact. Add mappings for these two
interest fields. In the Lead to Account relationship, the industrycode field is
already mapped between the two entities.
1. Open Lead on the Customize Entities window.

2. Open 1:N Relationships.
3. Open the existing contact_originating_lead relationship.
4. Select Mappings in the Details Pane. Click New.
5. In the Create Attribute Mapping From Lead To Contact dialog box,
select new_fitness from Source Entity Attributes. Then select
new_fitness from Target Entity Attributes. Repeat for the
new_racing attribute.
6. Save the Relationship form.
7. Save the Lead entity.
8. On the Customize Entities window, Publish the changes to the Lead
entity.
Step 4 - Test the Mapping
To test this functionality, create a new Lead that incorporates one of the new
Industry values and one or both of the Interests. Then convert the Lead to an
Account and Contact to verify that the values carry forward to the new entities.
1. Select Lead from the Sales module.

2. From the list of Active Leads, double-click Brian Johnson to open
the record for his Lead.
3. Select Interest in Fitness.
4. In the Industry field, select Manufacturing.
5. Convert the Lead to an Account and Contact.
6. Navigate to Contacts and open Brian Johnson.

7. The Interest in Fitness checkbox should be checked.

8. Navigate to Accounts.
9. Open the Extras Sporting Goods, which is the company name that
was on Brian Johnson's Lead.
10. The Industry field should be set to Manufacturing.
Step by Step
Step 1 - Update Picklists for Leads and Accounts
Adventure Works Cycle wants to add the industries of Manufacturing, Leisure &
Travel, and Healthcare, and eliminate the industry listed as SIG Affiliations.

2. Double-click Lead.
3. Click on Attributes in the Details pane.
4. Double-click on the industrycode attribute.
5. In the Industry of Lead attribute form, update the picklist values by
clicking Add, then entering Manufacturing. Click OK. Repeat for
two additional picklist values: Leisure and Travel, and then
Healthcare.
6. Select the SIG Affiliations picklist value. Click Delete, then click
OK to confirm the deletion.
7. Click Sort Ascending to sort the values in alphabetical sequence.
9. Click Save and Close to save the Lead attributes.
10. On the Customize Entities view, double-click on Account.
12. Repeat the same steps as above to make the same changes to the
industrycode attribute on the Account entity.
Step 2 - Add New Attributes for Leads and Contacts
Create attributes in Leads for tracking a person’s interests in Racing and Fitness.
Each interest must have a format type of bit. Place these attributes on the form
using a checkbox format type and repeat the process for Contacts.
1. On the Customize Entities view, double-click on Lead.

3. Click New.
4. Enter Racing as the Display Name. Click the Type drop down arrow
and select bit. The Default Value is No.

6. Enter Fitness as the Display Name. Set the Type drop down arrow
and select bit. The Default Value is No.
10. On the General tab, select the Contact Information section.
12. Select the Racing and Fitness attributes that you just created. The
Details tab and Company Information section should prefilled as the
location. Click OK.
13. Select the Fitness field and click Change Properties.
14. Change the Label from Fitness to Interest in Fitness. Click the
Formatting tab. In the Control Formatting field, click the drop down
arrow and select Check box. Click OK. Repeat for the Racing field.
15. Click Preview on the menu bar to preview your changes. Close the
preview, then click Save and Close on the form.
16. Click Save and Close to close the entity.
17. Repeat these steps for the Contact entity. Add the Fitness and
Racing attributes, then expose them on the Contact form in the
Professional Information section of the Details tab.
18. On the Customize Entities window, publish the customizations for
both entities by clicking More Actions, and then clicking Publish
All Customizations.
Step 3 - Create a Mapping
Find the 1:N relationship from Lead to Contact. Add mappings for these two
interest fields. In the Lead to Account relationship, the industrycode field is
already mapped between the two entities.
1. On the Customize Entities window, double-click Lead.

2. Click 1:N Relationships.
3. Double-click the contact_originating_lead relationship to open it.
4. In the Details Pane, click Mappings.
5. Click New.
6. In the Create Attribute Mapping From Lead To Contact dialog box,
select new_fitness from Source Entity Attributes. Then select
new_fitness from Target Entity Attributes. Click OK.
7. Repeat for the new_racing attribute.
8. Click Save and Close to close the Relationship form.
9. Click Save and Close on the Lead entity.
10. On the Customize Entities window, the Lead entity is already
selected. Click Publish on the Action toolbar.

Step 4 - Test the Mapping
To test this functionality, create a new Lead that incorporates one of the new
Industry values and one or both of the Interests. Then convert the Lead to an
Account and Contact to verify that the values carry forward to the new entities.
1. From the Navigation Pane, click Sales, and then click Lead.
2. Double-click Brian Johnson.
3. Select the Details tab.
4. Select Interest in Fitness.
5. In the Industry field, select Manufacturing.
7. Click Convert Lead.
8. In the Convert Lead dialog box, select Account and Contact. Click
OK.
9. Click Close.
10. From the Sales menu, click Contacts.
11. Double-click Brian Johnson.
12. Select the Details tab. The Interest in Fitness checkbox should be
checked.
13. Close the Contact.
14. From the Sales menu, click Accounts.
15. Double-click Extras Sporting Goods, which is the company name
that was on Brian Johnson's Lead.
16. Select the Details tab. The Industry field should be set to
Manufacturing.

Lab 8.4 - Case Study

The objectives of this lab include performing many of the platform
customizations covered earlier in this training, as well as the application
customization covered in the prior training. This lab focuses around planning,
creating, and configuring a custom entity.
Scenario
Adventure Works Cycle wants to track some of the internal departments within
their Accounts. They want to know who the Primary Contact is within each
department and which Contacts are associated with that department. Adventure
Works also wants to maintain a current description of the department's address
and a description of the department's function.
The following solutions were originally proposed:
• Department Attribute
• Department Picklist Attribute
• Departments as Accounts
Upon further examination, the project team rejected each of these proposed
solutions. They based their decisions on the following criteria:
• Department Attribute. The Contact entity has an nvarchar

Department Attribute that is already exposed on the Contact form.
What is the problem with this approach?

• Department Picklist Attribute. To allow standardized aggregation

of departments, using a custom picklist with common department
groups was considered.
• Departments as Accounts. Accounts can contain sub-accounts. The

account entity can be overloaded by storing information about a
department within the Account entity. This provides an easy way to
link Contacts to a Department.

Goal Description
During your planning meetings with the Sales Management team, you have
agreed upon making the following changes.
Department Entity
Create a new Department entity with the properties shown in the following
figure:
FIGURE 8.9 DEPARTMENT ENTITY VALUES
Add the attributes shown in the following figure to the Department entity:
FIGURE 8.10 DEPARTMENT ENTITY ATTRIBUTES

Create Relationships
Create the 1:N relationships shown in the following figure:
FIGURE 8.11 RELATIONSHIP PROPERTIES
Modify the Entities
Expose the new Department attributes on the Department form. Then add the
Account column to the Department Lookup View as both a View column and a
Find column.
In the Contact entity, replace the text Department field with the lookup
Department field. Because the Department ID is a required field, Adventure
Works wants it located on the General tab. In the Contact Lookup view, add
Parent Customer to the Find Columns.
Create Mappings
Create the following mappings in the Account→Department relationship:
• address1_line1 → new_street1
• address1_city → new_city
• address1_postalcode → new_postalcode

Create the following mappings in the Department→Contact relationship:
• new_street1 → address1_line1
• new_city → address1_city
• new_postalcode → address1_postalcode
Secure the Entity
For the Sales Manager role, assign Organization access to all privileges for the
Department custom entity.
For the Salesperson role, apply the customizations to the Department entity as
shown in the following figure:
FIGURE 8.12 DEPARTMENT PERMISSIONS FOR SALESPERSON ROLE
Test the entities and relationships
Perform the following steps to test the functionality:
1. Open an existing Account record.

2. Verify that “Departments” appears in the Navigation pane.
3. Open the Department form and create a Department Record.
4. Designate Primary Contacts for the Departments.
5. Associate Contacts with Departments.
6. Log on as a user that does not have the Sales Manager or Salesperson
role and attempt to create a department record.
Challenge Yourself
Use the information in the Scenario and Goal Description to complete these
steps:
1. Create the new Department entity.

2. Create 1:N relationships between the following entities: Account and
Department, Contact and Department, and Department and Contact
3. Modify the Department form, Department Lookup View, Contact
entity and form, and Contact Lookup View.

4. Create Mappings between Account and Department and between

Department and Contact.
5. Update the Sales Manager and Salespersons roles.
6. Test the functionality.
Need a Little Help?

steps:
Step 1 - Create Department Entity
1. Navigate to Settings, Customization, and then Customize Entities.

2. Create a new entity.
3. The values to enter for this entity are displayed in the Goal
Description in the figure titled Department Entity Values.
4. Save the entity(not Save and Close) to add additional attributes to
the entity in the next step.
Step 2 - Add Department Attributes
1. Select Attributes for the new Department entity.

2. There are five attributes to enter for the Department entity. The
values to enter for each attribute are displayed in the Goal
Description in the figure titled Department Entity Attributes. Add the
five attributes.
Step 3 - Create 1:N Account to Department Relationship
1. From the Customize Entities window, select Account.

2. Create a new 1-to-Many Relationship.
3. The values to enter for this relationship are displayed in the Goal
Description in the figure titled Relationship Properties.
4. Save and Close the Relationship and then the Account entity.
NOTE: Instead of navigating from Department to Accounts, you could have

also created this relationship by remaining within the Department entity and
creating a N:1 Relationship with Account.
Step 4 - Create 1:N Contact to Department Relationship
1. From the Customize Entities window, select Contact.


4. Save and Close the Relationship and then the Contact entity
5. Click Save and Close to close the Relationship.
6. Click Save and Close to close the Contact entity.
NOTE: Instead of navigating from Department to Contact, you could have also
created this relationship by remaining within the Department entity and
creating a N:1 Relationship with Contact.
Step 5 - Create 1:N Department to Contact Relationship
1. From the Customize Entities window, select Department.

4. Save and Close the Relationship.
5. Do not close the department entity.
Step 6 - Modify the Department Form and View
Find column.
1. Open the Department's Form.

2. Add the following fields: Street 1, City, State\Province, ZIP\Postal
Code, and Description fields.
3. Use the green arrows to arrange the address fields above the
Description.
4. Save the form.
5. Open the Department Lookup View.
6. Add the Account column as a View column and a Find Column.
7. Save and Close the Department Lookup View.
8. Save and Close the Department entity.
Step 7 - Modify the Contact Form and View
Department field. In the Contact Lookup view, add Parent Customer to the Find
Columns.
1. From the Customize Entities window, open the Contact entity.

2. Select Forms and Views and open its form.
4. Remove the Department field.
5. Add the new Department ID field.

6. Because the Department ID is a required field, Adventure Works

wants it located on the General tab.
7. Save the form.
8. Open the Contacts Lookup View.
9. Select Parent Customer as one of the Find Columns.
10. Save and Close the view and the Contact entity.
11. Because all customizations to the user interface components are
complete, you must publish all of the customizations. On the
Customize Entities window, click More Actions, and then click
Step 8 - Create Mappings
Create the mappings in the Account→Department relationship and the

Department→Contact relationship that are specified in the Goal Description.
1. Open the Account entity and display the 1:N Relationships.

2. Open the new_account_new_department relationship.
3. Create mappings for the three attributes that are specified in the Goal
Description.
4. Save and close once the mappings are complete.
5. From the Customize Entities window, open Department.
6. Repeat the steps above to create mappings for the
new_new_department_contact relationship. The three attributes to be
mapped are displayed in the Goal Description.
Step 9 - Secure the new Entity
For the Sales Manager role, assign Organization access level to the Delete
privilege for the Department custom entity. For the Salesperson role, apply the
customizations to the Department custom entity that are displayed in the Goal
Description.
1. Navigate to Settings, Customization, and then Security Roles.

2. Verify the Business Unit is Adventure Works Cycle.
3. Open the Sales Manager role.
4. In the Custom Entities tab, set the access level for all Department
entity privileges to Organization.
5. Save and Close.
6. Open the Salesperson role.
7. Set the access levels for each Department/privilege combination
based on the figure titled Department Permissions For Salesperson
Role in the Goal Description.
8. Save and Close.

Step 10 - Test the New Functionality
1. Close Internet Explorer, then re-open it and start Microsoft

Dynamics CRM.
2. Navigate to Sales and then Accounts.
3. Open an account and verify that Departments appears in the Details
pane.
To associate a primary contact for each department:

4. From Sales, click Contact.
5. Open an existing contact that is the primary contact for a department.
6. Create a new department in the Department lookup field. Select this
department as the department for the contact.
7. Save and Close.
8. Repeat these steps for each several departments.
To associate additional contacts with each department (besides the

primary contact):
9. From Sales, click Departments.
10. Create a new Department.
11. Enter information for a new department and click Save (not Save and
Close).
12. Select Contacts on the Details pane and add an existing contact to the
department.
13. Select the contact for the department from the Look Up Records
dialog box. Select additional contacts for the department.
14. Repeat these steps for each department that has additional contacts.
Step by Step
Step 1 - Create the Department Entity

2. Click New.
3. The values to enter for this entity are displayed in the Goal
Description in the figure titled Department Entity Values.
4. Click Save (not Save and Close) to leave this entity open.

Step 2 - Add Department Attributes
1. The Department entity should still be open after the prior step.
2. Click Attributes in the Details pane.
3. There are five attributes to enter for the Department entity. The
values to enter for each attribute are displayed in the Goal
Description in the figure titled Department Entity Attributes. Repeat
the following steps for each attribute.
4. Click New.
5. Enter the attribute values.
6. Click Save and New (click Save and Close following the last
attribute, then click Save and Close to close the Department entity).
Step 3 - Create 1:N Account to Department Relationship
1. From the Customize Entities window, double-click Account.

3. Click New 1-to-Many Relationship.
6. Click Save and Close to close the Account entity.
NOTE: Instead of navigating from Department to Accounts, you could have

also created this relationship by remaining within the Department entity and
creating a N:1 Relationship with Account.
Step 4 - Create 1:N Contact to Department Relationship
1. From the Customize Entities window, double-click Contact.

6. Click Save and Close to close the Contact entity.
NOTE: Instead of navigating from Department to Contact, you could have also
created this relationship by remaining within the Department entity and creating
a N:1 Relationship with Contact.

Step 5 - Create 1:N Department to Contact Relationship
1. From the Customize Entities window, double-click Department.

6. Leave the department entity open for the next step.
Step 6 - Modify the Department Form and View
Find column.
1. On the Department entity window, click Forms and Views.

4. In the Add Fields dialog box, select the Street 1, City,
State\Province, ZIP\Postal Code, and Description fields. Click
OK.
5. Use the green arrows to arrange the address fields above the
Description.
7. Double-click the Department Lookup View.
8. Click Add View Columns.
9. In the Add View Columns dialog box, select Account and click OK.
10. Click Add Find Columns.
11. In the Add Find Columns dialog box, select Account and click OK.
12. Click Save and Close to close the Department Lookup View.
13. Click Save and Close to close the Department entity.
Step 7 - Modify the Contact Form and View
Department field. In the Contact Lookup view, add Parent Customer to the Find
Columns.
1. From the Customize Entities window, double-click Contact.

4. Select the Details tab.
5. Select the Department field. Click Remove. Click OK to confirm
the deletion.


7. In the Add Fields dialog box, select the Department field that has
the Name of new_departmentid.
8. Because the Department ID is a required field, Adventure Works
wants it located on the General tab. In the Location area, select
General as the Tab and Name as the Section. Click OK.
10. Double-click Contacts Lookup View.
11. Click Add Find Columns.
12. In the Add Find Columns dialog box, select Parent Customer and
click OK.
13. Click Save and Close to close the Contact Lookup View.
14. Click Save and Close to close the Contact entity window
15. Because all customizations to the user interface components are
complete, you must publish all of the customizations. On the
Customize Entities window, click More Actions, and then click
Step 8 - Create Mappings
Create the mappings in the Account→Department relationship and the

Department→Contact relationship that are specified in the Goal Description.
1. From the Customize Entities window, double-click Account.

3. Double-click the new_account_new_department relationship.
4. Click Mappings in the Details pane.
5. There are three attributes to be mapped. These attributes are
displayed in the Goal Description. Repeat the following steps for
each attribute mapping.
6. Click New.
7. In the Create Attribute Mapping From Account To Department
dialog box, select the source and target attributes per the Goal
Description. Click OK.
8. Click Save and Close once the mappings are complete.
9. From the Customize Entities window, double-click Department.
10. Repeat the steps above to create mappings for the
new_new_department_contact relationship. The three attributes to
be mapped are displayed in the Goal Description.

Step 9 - Secure the new Entity
For the Sales Manager role, assign Organization access level to the Delete
privilege for the Department custom entity. For the Salesperson role, apply the
customizations to the Department custom entity that are displayed in the Goal
Description.

2. Verify the Business Unit is Adventure Works Cycle.
3. Double-click on the Sales Manager role.
4. Click the Custom Entities tab.
5. For all Department entity privileges, set the access levels to
Organization.
7. Double-click the Salesperson role.
8. Set the access levels for each Department/privilege combination
based on the figure titled Department Permissions For Salesperson
Role in the Goal Description.
Step 10 - Test the New Functionality
1. Close Internet Explorer, then re-open it and start Microsoft

Dynamics CRM.
3. Double-click one of the accounts.
4. Verify that Departments appears in the account's Details pane.
To associate a primary contact for each department:

5. From Sales, click Contact.
6. Open an existing contact that is the primary contact for a department.
7. In the Department lookup field, click New.
8. In the New Department form, enter the department information.
Click Save and Close.
9. In the Look Up Records window, this department is selected. Click
OK.
11. Repeat these steps for several departments.
To associate additional contacts with each department (besides the

primary contact):

12. From Sales, click Departments.

13. Click New Department.
14. Enter information for a new department and click Save (not Save and
Close).
15. Click Contacts on the Details pane.
16. Click Add Existing Contact.
17. In the Look Up Records dialog box, click the Search icon.
18. Select the additional contacts associated with the department and
click the >> arrow for each. Click OK.
19. Click Save and Close to close the department entity.
20. Repeat these steps for each department that has additional contacts.

Summary
This training introduced entity relationships and the relationship types supported
by Microsoft Dynamics CRM. From a broad perspective, the two types of
supported relationships are one-to-many (1:N) and many-to-many (N:N). N:1
relationships are simply 1:N relationships created from the perspective of the
related entity. Within this framework, 1:N and N:N relationships can be created
between almost any combination of custom and system entities.
This training also examined entity mappings, and how this feature is designed to
reduce the data entry load on users that create new records related to a parent
record. Attributes from a source entity can be mapped to attributes on a target
entity either manually or automatically. During the actual data entry process,
end-users can override any of the system-created mappings.

Test Your Knowledge

1. The organization where you are implementing Microsoft Dynamics CRM

uses the concept of a project to group their work. One approach they
considered involved creating a Project entity with a Parental relationship for
all Cases. They felt this would allow them to use the Case entity to track the
work related to the Project. After further analysis, the company realized it
could not pursue this approach. What was the reason that forced this
decision?
2. The organization wants to link all Opportunities to the User entity to create a
new lookup field called Sales Manager. Can this be done?
( ) Yes. Create a new Many-to-1 Relationship from the Opportunity using
referential relationship and expose the lookup field on the Opportunity
form.
( ) No. You cannot create a new relationship between system entities.
( ) Yes. Create a new 1-to-Many relationship from the User employing a
referential relationship. Make the relationship attribute a required field.
( ) No. You cannot create a new relationship between the Organization-
owned User entity and the User-owned Opportunity entity.
3. You are viewing relationships for the Account entity. You create a new 1:N
relationship with a custom entity. Which of the following scenarios is true as
a result of this relationship?
( ) A new lookup field will be created on the custom entity form so that the
Account can be related to it.
( ) A new relationship attribute will be added to the custom entity.
( ) A new lookup field will be added to the Account form to add it to the
custom entity.
( ) A new relationship attribute will be added to the Account

4. What steps must you first perform before you can delete a relationship?
5. You modify the 1:N relationship between a Custom entity and Opportunity
where the Custom entity is the primary entity. You set the type of behavior to
referential, restrict delete. Which of the following is true?
( ) Custom entity records cannot be deleted.
( ) Opportunities related to the custom entity records cannot be deleted.
( ) Custom entity records related to deactivated opportunities can be deleted
( ) Custom entity records related to opportunities cannot be deleted.
6. What must you do before you can delete a custom entity or a custom 1:N
relationship?
( ) Remove the lookup field for the relationship attribute in the primary entity
form and publish the primary entity.
( ) Truncate the SQL Server table that stores data for the entity you want to
delete.
( ) Remove the lookup field for the relationship attribute in the related entity
form and publish the related entity.
( ) Publish the custom entity.
7. What is the purpose of Mapping?

( ) To streamline data entry when adding related records.
( ) To maintain relationships between records of related entities.
( ) To assign default values for all new records
( ) To synchronize data when the records of Primary entities are updated.

8. The owner of an account possesses the privilege to delete the account.

However, when the owner attempts to delete the account, the system does not
allow the transaction. What would be the probable cause for this error?
9. When an Account is assigned to a different user, your organization only

wants the open opportunities associated with the account to be assigned to
the account's new owner. What cascading rule provides this 1:N relationship
behavior?
( ) Cascade All
( ) Cascade Active
( ) Cascade User-Owned
( ) Cascade None
10. When would you typically assign a Parental behavior type to a 1:N
relationship?


chapter:
1.
2.
3.

Solutions
Test Your Knowledge
1. The organization where you are implementing Microsoft Dynamics CRM
uses the concept of a project to group their work. One approach they
considered involved creating a Project entity with a Parental relationship for
all Cases. They felt this would allow them to use the Case entity to track the
work related to the Project. After further analysis, the company realized it
could not pursue this approach. What was the reason that forced this
decision?
MODEL ANSWER - A custom entity (Project) cannot be made a parent of a
system entity (Case).
2. The organization wants to link all Opportunities to the User entity to create a
new lookup field called Sales Manager. Can this be done?
(•) Yes. Create a new Many-to-1 Relationship from the Opportunity using
referential relationship and expose the lookup field on the Opportunity
form.
( ) No. You cannot create a new relationship between system entities.
( ) Yes. Create a new 1-to-Many relationship from the User employing a
referential relationship. Make the relationship attribute a required field.
( ) No. You cannot create a new relationship between the Organization-
owned User entity and the User-owned Opportunity entity.
3. You are viewing relationships for the Account entity. You create a new 1:N
relationship with a custom entity. Which of the following scenarios is true as
a result of this relationship?
( ) A new lookup field will be created on the custom entity form so that the
Account can be related to it.
(•) A new relationship attribute will be added to the custom entity.
( ) A new lookup field will be added to the Account form to add it to the
custom entity.
( ) A new relationship attribute will be added to the Account

4. What steps must you first perform before you can delete a relationship?
MODEL ANSWER - You must remove all references to attributes from the
resulting relationship on published forms and views.
5. You modify the 1:N relationship between a Custom entity and Opportunity
where the Custom entity is the primary entity. You set the type of behavior to
referential, restrict delete. Which of the following is true?
( ) Custom entity records cannot be deleted.
( ) Opportunities related to the custom entity records cannot be deleted.
( ) Custom entity records related to deactivated opportunities can be deleted
(•) Custom entity records related to opportunities cannot be deleted.
6. What must you do before you can delete a custom entity or a custom 1:N
relationship?
( ) Remove the lookup field for the relationship attribute in the primary entity
form and publish the primary entity.
( ) Truncate the SQL Server table that stores data for the entity you want to
delete.
(•) Remove the lookup field for the relationship attribute in the related entity
form and publish the related entity.
( ) Publish the custom entity.
7. What is the purpose of Mapping?

(•) To streamline data entry when adding related records.
( ) To maintain relationships between records of related entities.
( ) To assign default values for all new records
( ) To synchronize data when the records of Primary entities are updated.
8. The owner of an account possesses the privilege to delete the account.

However, when the owner attempts to delete the account, the system does not
allow the transaction. What would be the probable cause for this error?
MODEL ANSWER - The owner does not have the necessary privilege to
delete any related entities.

9. When an Account is assigned to a different user, your organization only

wants the open opportunities associated with the account to be assigned to
the account's new owner. What cascading rule provides this 1:N relationship
behavior?
( ) Cascade All
(•) Cascade Active
( ) Cascade User-Owned
( ) Cascade None
10. When would you typically assign a Parental behavior type to a 1:N
relationship?
MODEL ANSWER - When there is a strong concept of ownership in the
hierarchy of related records, and the related records depend on the primary
record to establish context for their existence.
Lab 8.1 - Create a Manual N:N Relationship

Adventure Works also wanted to add a field to store who recorded the
registration information and the date the Contact was registered. However, you
noted that this information is already being tracked. How is this information
tracked in the Registration entity?
MODEL ANSWER - This information is automatically recorded in system
attributes when each Registration record is created. - The “owner” of the
record is the person who recorded the information. - The “created on” date is
the date the Contact was registered; that is, the date on which the
Registration record was created..

Lab 8.4 - Case Study

• Department Attribute. The Contact entity has an nvarchar
Department Attribute that is already exposed on the Contact form.
MODEL ANSWER - The problem with using a text attribute is that there is
no control over what the user might enter in that field. This makes it difficult
to aggregate the Contacts who belong to the department. Also, if the
Department were re-named during reorganization, each contact record needs
to be updated.
• Department Picklist Attribute. To allow standardized aggregation

of departments, using a custom picklist with common department
groups was considered.
MODEL ANSWER - The problem with using a picklist attribute is that it is
impossible to capture the unique names that each department might choose to
use.
• Departments as Accounts. Accounts can contain sub-accounts. The

account entity can be overloaded by storing information about a
department within the Account entity. This provides an easy way to
link Contacts to a Department.
MODEL ANSWER - The problem with this approach is that Adventure
Works Cycle wants to track all interactions with their accounts on a single
account record.

Chapter 9: Renaming Entities and Translating Customizations
CHAPTER 9: RENAMING ENTITIES AND

TRANSLATING CUSTOMIZATIONS
Objectives
The objectives are:
• Examine the steps that need to be performed to rename a

customizable entity.
• Understand how to translate customized labels in a multilingual
deployment
Introduction
This training examines the final two elements related to customizing entities -
renaming a customizable entity and, in a multilingual deployment, translating
customized labels into the required languages.
Many times organization use terminology that is different from that presented in
Microsoft Dynamics CRM. In order to customize the UI experience so that the
application uses terminology requested by the organization, organizations can
rename customizable entities to match their terminology. As you will see in the
training, the process of renaming a customizable entity is quite involved. Make
sure that you pay particular attention to each step in process so that all UI
components are renamed.
In order to customize the UI experience in a multilingual deployment, all

customizations involving UI components must be translated into the additional
MUI languages that have been installed and enabled. Failure to do so will result
in a mixed-language experience for users that select one of the MUI languages.
In other words, the application itself will appear in the selected MUI language,
but the customizations will appear in the base language.

Renaming a Customizable Entity

When implementing Microsoft Dynamics CRM, it is useful to be able to adapt
the application to fit the terminology used by the organization. It is easy to
change the name of a customizable entity. However, changing every place where
the name of the entity is referenced is a process that includes some manual
changes.
Areas that need to be changed include:
• Entity Name
• Entity Form Labels
• Entity View Names
• Entity Attribute Display Names
• System Messages
• Online Help Content
• Reports
Some areas that cannot be changed include:
• Platform error messages and messages that are displayed in Trace or

the Event Log. These messages cannot be edited.
• Add Users Wizard for adding multiple users at one time. The strings
in this wizard cannot be edited.
• Environment Diagnostics Wizard. The strings in this wizard cannot
be edited.
Steps Required to Rename a Customizable Entity

Changing the name of a customizable entity is a seven step process:
Step 1: Change Entity Name
1. From the Entity Customization screen, select Information.

2. In the Entity Definition section, change the Name and Plural Name
to the new name.
Step 2: Edit Entity Forms and Views to Display the New Entity Names
1. From the Entity Customization screen, select Forms and Views.

2. Change Form Labels.
3. Change View Names.

Step 3: Change Attribute Display Names for the Entity that is Renamed
Use Customize Entities tool to change attribute display names associated with
renamed entity. This will update any other parts of the application that uses these
attributes, such as View headings.
Step 4: Customize Messages and Strings Associated with Entity that is

Renamed
Use the Customize Entities tool to customize messages and strings associated
with the renamed entity.
Step 5: Publish Changes
Use the Publish Customizations tool to publish the changes.
NOTE: The name of the entity in the Navigation Pane may not respond to the
changes because the information in the SiteMap is cached on the browser.
Users may need to exit and then re-enter the application (or press F5) to see the
changes.
Step 6: Edit affected Help content to Display the New Entity Name
Manually edit entity names in Help content and re-deploy the Help content. For
more information on this refer to the topic Customizing Online Help in the Client
Programming Guide of the Microsoft Dynamics CRM SDK.
Step 7: Modify Affected Reports to Display the New Entity Name
Manually modify entity names in reports and re-deploy the modified reports.
Changing System Messages

Because you have the ability to rename customizable entities within Microsoft
Dynamics CRM, the customization tools include a way for you to modify the
related system entities to reflect your changes. Changing system messages is a
relatively straightforward process of individually modifying each of the related
messages for the entity and then publishing the changes.
Perform the following steps to edit the messages displayed for an entity:

2. In the list of entities, open the entity that you want to rename.
3. Click Messages.

4. For each message you want to change, double-click the message, and
then in the Custom Display String box, enter the new message.
5. In the message form, click Save and Close.
6. In the entity form, click Save.
7. Publish your customizations when complete.
Some system messages have parameter placeholders. These are incrementing

numbers placed within curly braces “{0}.” Parameter placeholders are replaced
with an appropriate text reference when the message is displayed. This reference
is usually dependant on the context in which the system message is displayed.
FIGURE 9.1 CHANGING A MESSAGE DISPLAY STRING
Modifying the Online Help

It is common for a Microsoft Dynamics CRM implementation to offer users a
site to get information about their deployment. This may be a Microsoft
Windows SharePoint Services site, a custom website, or even Microsoft Word
documents on a shared directory. These resources may document how to report
issues or make suggestions. They may also provide guidance for how users can
best make use of Microsoft Dynamics CRM.
The Microsoft Dynamics CRM online Help can be customized to meet the needs
of the deployment. Two common reasons to modify the Online help include:
• Synchronize Content to meet customizations. A common need is

to change the terminology used in the help files to match changes to
entity and attribute display names.
• Provide organization-specific guidance. An organization may wish
to extend the available content in the online help to provide a
contextual reference to organization tasks that need to be performed.
All of the online Help content is available in HTML files that can be customized
and extended. Depending on the degree of modification, customizing the online
Help may require an in-depth understanding of the online Help structure.

The advantages to extending the online Help over developing a new Web site for
Microsoft Dynamics CRM users are that it:
• Is already embedded in the application.

• Includes an indexed find capability so users can easily find topics.
• Contains the key information describing the core application
functionality.
• Is fully available for you to customize.
Extending the online Help also offers several disadvantages that have to be
weighed against the advantages of modifying the Help files. These disadvantages
include:
• Changes to Microsoft Dynamics CRM for Outlook with Offline

Access have to be installed with Microsoft Dynamics CRM for
Outlook or manually copied to Microsoft Dynamics CRM for
Outlook after it has been installed.
• Reinstalling Microsoft Dynamics CRM overwrites changes to the
online help. As a best practice, you must back up any customizations
prior to reinstalling Microsoft Dynamics CRM.

Lab 9.1 - Renaming a Customizable Entity

This lab requires that you change the name of an entity and make other related
changes. In this lab you will change the name of the Case entity and many of the
areas of the application that use the name “Case”, including the online Help.
Some of the steps in this process are time consuming to perform completely.
Therefore, this lab only performs a set of selected tasks necessary to illustrate the
process.
Scenario
Adventure Works Cycle has decided to use the term “Incident” rather than
“Case” throughout their Customer Service organization. As their implementation
consultant, you have been asked to apply this change throughout Adventure
Works Microsoft Dynamics CRM deployment.
These changes will be made on a development server so they can be exported and
applied to Adventure Works’ production server.
Goal Description
During your planning meetings with the Customer Service team, you have
agreed upon making the following changes:
• Exporting your existing Case configuration in the event you need to

use this as a backup and restore your production server to its original
state. Use the following file name and location for the export
process:
C:\Class Materials\Customization\Ch. 9\BackupBeforeChange.zip
• Changing the Case entity name, form, views and messages to use
"Incident" rather than Case.
• Exporting the customized Incident entity to the following file:
C:\Class Materials\Customization\Ch. 9\BackupAfterChange.zip
• Changing the Online Help files to use the term "Incident" rather than
"Case."
Challenge Yourself
steps:
1. Back up your current Case entity customizations.

2. Change the Case entity name to Incident.

3. Change the View names.

4. Change the Case form labels.
5. Change the Attribute Display Names.
6. Change the Messages.
7. Publish and export the Incident entity.
8. Change the Online help.
Need a Little Help?

Step 1: Back Up your Current Case Entity Customizations
Export your current Case entity customizations. Save your Case entity
customizations to the file and location specified in the Goal Description.
Step 2: Change the Entity Name
On the Case entity information Area, change the Name and Plural Name to
“Incident” and “Incidents” respectively.
Step 3: Change the View and Form Names
In the Forms and Views area, change the name of each of the views to replace
“Case” with “Incident” and “Cases” with “Incidents”
NOTE: You do not need to change them all for the purpose of this Lab. Change
as many view names as you need to understand the process.
Open the Case Form and modify the following field labels
• Case Origin
• Case Type
Step 4: Change the Attribute Display Names
In Attributes, Modify the Display Name for the appropriate attributes to replace
“Case” with “Incident.”
Step 5: Change the Messages
In Messages, approximately 70 messages contain the word “Case.” Change the

word “Case” to “Incident.”
NOTE: You do not need to change all of the messages for the purpose of this
lab. Change as many as you need to understand the process.

Step 6: Publish and Export the Entity
Publish the Case entity. Then open a Case to confirm that the changes you have
made have been applied.
NOTE: You may need to refresh your browser by pressing F5 to see changes in
the Navigation pane.
Once you have confirmed you changes are working correctly, export your
customized “Incident” entity to the file and location specified in the Goal
Description.
Step 7 Change the Online Help
NOTE: For the purpose of this lab, modifications will be made to only one of
the online Help files.
Click Help on this page while viewing the Case form and note the information.
Then navigate to where the Help files are located at:
C:\Inetpub\wwwroot\Microsoft CRM\Help\1033\OP\Content.
Open the online Help file titled: ui_cs_Case_list.htm.
Edit the original file using Notepad (or Visual Studio if you prefer). Replace for
every instance of the word “Case” that is used as content text and replace it with
“Incident.”
NOTE: The goal is to replace every instance of content text that uses “Case”
with “Incident.” But the word “Case” is used in the DHTML properties of the
documents to point to other documents. Replacing every instance will break
these links. Each instance should be examined before replacing the text.
Save the modified file back into the folder listed above and overwrite the existing
file. Finish by testing the page. At first, you may not see the change because it
has been cached. You may need to press F5 to see the changes.
Step by Step
Step 1 - Back up the Case configuration

2. On the Export Customizations view, click More Actions on the
Action toolbar, and then click Export All Customizations.

3. In the File Download window, click Save.

4. In the Save As window, select the location and name of the export
file. For this exercise, use the location and file name specified in the
Goal Description.
5. Click Save.
6. When the download is complete, click Close.
Step 2 - Change the Entity Name

2. Double-click the Case entity.
3. On the Case Information window, change the Name to Incident and
change the Plural Name to Incidents.
Step 3 - Change the Form and View Names
1. The Incident (formerly Case) Information window should still be

open.
3. Double-click the first view or form in the list.
4. Click View Properties.
5. Change the Name of the view using Incident instead of Case (for
example, Active Incidents). Click OK.
7. In a normal environment, you would repeat these steps for every
view. For the purposes of this lab exercise, only perform this step on
the Active Cases view, All Cases view, and Case Associated View.
Open the Case Form and modify the following field labels: Case
Origin and Case Type.
Step 4 - Change the Attribute Display Names
For any of the attributes that have Case in its Display Name, modify the Display
Name to replace “Case” with “Incident”.
1. With the Forms and Views window still open, click Attributes in the
Details pane.
2. Click on the Display Name column heading to sort the attributes in
Display Name sequence. This will help to quickly locate any
attributes with Case in the display name.
3. In an actual production environment, you would change the display
name for any attribute with Case in the display name. For the
purposes of this exercise, change the display name for the following
attributes: Case, Case Number, Case Origin, Case Stage, and Case
Type.

4. Double-click the attribute you want to change.

5. Change the Display Name (for example, from Case Number to
Incident Number).
7. Repeat these steps for the attributes that need to be changed.
Step 5 - Change the Messages
Use the Customize Entities tool to customize messages and strings associated
with the renamed entity.
1. With the Forms and Views window still open, click Messages in the
Details pane.
2. In an actual production environment, you would change the display
name for any message and string with Case in the default or Custom
display string. For the purposes of this exercise, change the display
name for the first three messages.
3. Double-click the message you want to change.
4. Change the message in the Custom Display String to reflect the
new name.
6. Repeat these steps for the messages that need to be changed.
7. When all messages are complete, click Save and Close to close the
entity window.
Step 6 - Publish and Export the Changes
1. From the Customize Entities window, click More Actions on the

toolbar, and then click Publish All Customizations.
2. From the Navigation pane, click Service, and then click Incidents.
Open an Incident to confirm that the changes you have made have
been applied.
NOTE: You may need to refresh your browser by pressing F5 to see changes in
the Navigation pane.
3. Once you have confirmed you changes are working correctly, export
your customized “Incident” entity. From the Navigation pane, click
Settings, click Customization, and then click Export
Customizations.
4. On the Export Customizations view, select the Incident entity, and
then click Export Selected Customizations on the Action toolbar.
Click OK to acknowledge the message in the dialog box.
5. In the File Download window, click Save.

6. In the Save As window, select the location and name of the export
file. For this exercise, use the location and file name specified in the
Goal Description.
7. Click Save.
8. When the download is complete, click Close.
Step 7 - Change the Online Help
1. From the Navigation pane, click Service, and then click Incidents.
2. Click New to open an Incident form.
3. Click the Help drop down, and then click Help on this page.
4. Open Windows Explorer, and then navigate to where the Help files
are located at: C:\Inetpub\wwwroot\Microsoft
CRM\Help\1033\OP\content
5. This particular help file is titled: ui_cs_Case_list.htm.
6. Edit the original file using Notepad (or Visual Studio if you prefer).
7. Replace every instance of the word “case” that is used as content text
and replace it with “Incident.”
8. Save the modified file back to its original location in the folder listed
above and overwrite the existing file. Finish by testing the page. At
first, you may not see the change because it has been cached. You
may need to press F5 to see the changes.
NOTE: Our goal is to replace every instance of content text that uses “Case”
with “Incident.” But the word “case” is used in the DHTML properties of the
documents to point to other documents. Replacing every instance will break
these links. Each instance should be examined before replacing the text.

Translate Customized Labels

In a multilingual deployment, end-users can view Microsoft Dynamics CRM in
any of the supported language translations. The language edition that is
purchased by the organization is considered the application's base language. This
is the default language in which the application is presented. In addition to the
base language, end-users can view the application in any of the languages that
have a corresponding multiuser interface (MUI) language pack. The system
administrator must install and enable each MUI pack, and then each end-user can
identify one of the MUI languages as his or her default language.
Because the base language and MUI language packs apply to the out-of-the-box
UI components, how are customizations translated so that end-users can view
customized entities and attributes in the language of their choice? The answer to
that question is topic of this training discussion.
Exporting and Importing Translations

MUI language packs include translations for all the system's UI components.
However, because customizations are made in the organization's base language,
the labels associated with customized UI components must be manually
translated into each installed MUI language. UI components that can be
translated include custom:
• Entities
• Attributes
• Picklist values
• Messages
• Forms
• Views
The following process should be followed when translating customizations:
• Publish all entities before exporting customizations for translation

• Export the customizations to a Microsoft Office Excel 2003 or 2007
XML file
• Translate the customized labels (typically through a third-party
vendor familiar with the required language)
• Import the updated Excel worksheet into the application
• Publish all customizations following the import

EXAMPLE: Sean has installed two additional MUI language packs on his
Microsoft Dynamics CRM system. He has customized the system and must add
labels for his new customizations. Sean exports the translations to a Microsoft
Office Excel 2003 XML file. He then sends the file to a vendor who adds the
translated versions of each exported label. Sean then imports the updated file
back in to his Microsoft Dynamics CRM installation and publishes all
customizations.
The menu options for exporting and importing customized labels for translation
is located on the Settings > Customization page. The options are titled Export
Labels for Translation and Import Labels for Translation, respectively. You can
only export and import labels for translations when active MUI language packs
have been installed on the system.
When you select the Export option, you are immediately prompted to download a
Microsoft Excel XML file. The default name for the file is
CrmTranslations.XML.
After the exported labels have been translated, the export file must be imported
back into the system. Selecting the Import Labels for Translation menu option
initiates an import process similar to the one used to import customizations.
The Export File

When the customized labels are exported, an Organization ID (GUID) identifies
the labels within the export file. The purpose of this identifier is to prevent the
importing of translations from other organizations. The import process validates
the Organization ID contained in the file. An error occurs if the Organization ID
in the file does not match the organization into which the translated file is being
imported.
The Excel worksheet that is created by the export process contains the following
three tabs:
• Information tab. Contains basic information about the organization,

the export date, and the base language.
• Display Strings tab. Contains the data from the DisplayStrings table
in the CRM database.
• Localized Labels tab. Contains the data from the LocalizedLabel
table in the CRM database.
In the Display Strings tab and Localized Labels tab, the base language is
displayed first, followed by each MUI language in alphabetical order.

The following label strings are exported for translation:
• Entity Display Name

• Entity Plural Name
• Entity Description
• Entity Message
• Attribute Display Name
• Attribute Description
• Picklist Value Labels
• Status Value Labels
• State Value Labels
• 1:N Relationship Menu Label
• N:N Entity 1 Menu Label
• N:N Entity 2 Menu Label
• Form Tab Label
• Form Section Label
• Form Field Label
• Preview Field Label
• View (Saved Query) Name
This data is stored in both the Display Strings and Localized Label tabs.
Summary
This training focused on the key two areas of customizing the end-users’ user
interface (UI) experience - renaming a customizable entity and, in a multilingual
deployment, translating customized labels into the required languages.
The process of renaming a customizable entity is quite involved. In order to make

sure that all UI components are changed, pay particular attention to the sequence
of tasks outlined in this training. If any of the steps are missed, the end-user will
see the missed UI components referred to in the original terminology instead of
the custom terminology.
A similar situation exists when creating customizations in a multilingual

deployment. All customizations involving UI components must be translated into
the additional MUI languages that have been installed and provisioned. If you
fail to translate the customizations, the end-user will experience the application in
the language of their choice, but the customized entities, attributes, and so on will
appear in the base language.

Test Your Knowledge

Reusable Short Answer Question

1. When changing the name of a customizable entity, what at are some of the
additional areas that need to be changed?
additional areas that cannot to be changed?

3. Once changes to the entity name have been published, the Name of the entity
in the Navigation Pane may not respond to the changes. Why might this
occur, and what is the solution?
4. If the MUI language packs include translations for all the system's UI
components, why must labels be translated?


chapter:
1.
2.
3.

Solutions
Test Your Knowledge
additional areas that need to be changed?
MODEL ANSWER - Areas that must be changed include: - Entity Name -
Entity Form Labels - Entity View Names - Entity Attribute Display Names -
System Messages - Online Help Content - Reports
additional areas that cannot to be changed?
MODEL ANSWER - Some areas that cannot be changed include: Platform
error messages and messages that are displayed in Trace or the Event Log.
These messages cannot be edited. Add Users Wizard for adding multiple
users at one time. The strings in this wizard cannot be edited. Environment
Diagnostics Wizard. The strings in this wizard cannot be edited.
3. Once changes to the entity name have been published, the Name of the entity
in the Navigation Pane may not respond to the changes. Why might this
occur, and what is the solution?
MODEL ANSWER - This occurs because the information in the SiteMap is
cached on the browser. Users may need to exit and then re-enter the
application (or press F5) to see the changes.

4. If the MUI language packs include translations for all the system's UI
components, why must labels be translated?
MODEL ANSWER - Because customizations are made in the organization's
base language. If users have implemented MUI language packs, the labels
associated with customized UI components must be manually translated into
each installed MUI language so that all UI components are in the same
language.


Chapter 10: Maintaining Organizations Through Deployment Manager
CHAPTER 10: MAINTAINING ORGANIZATIONS

THROUGH DEPLOYMENT MANAGER
Objectives
The objectives are:
• Identify how the multi-tenancy feature enables you to have more

than one organization installed on a single Microsoft CRM Server
• Understand how the Deployment Manager's Deployment
Administrators tool is used for viewing users with the Administrator
license
• Examine how the Deployment Manager's Organizations tool is used
for maintaining connectivity between the Microsoft CRM Server(s),
the Reporting Server, and the Microsoft CRM database
• Identify how to use the Deployment Manager's Server tool to take
Microsoft CRM Servers offline and online
• Use the Deployment Manager's License tool to maintain server and
client licenses
Introduction
Microsoft Dynamics CRM provides the flexibility needed so that a business of
any size can create a deployment model that closely mirrors its actual
organizational structure. Once the initial organization has been installed and
configured, larger enterprises may decide that adding additional business units
into the existing organization does not serve the long-term needs of the business.
This may result in the need to create multiple organizations within one Microsoft
Dynamics CRM installation. This training examines how the application supports
this multi-tenancy model.
This training also examines the tools that are available in Microsoft Dynamics
CRM's Deployment Manager utility. Deployment Manager is a Microsoft
Management Console (MMC) snap-in that system administrators and
implementers use to administer and customize Microsoft Dynamics CRM.
Because it is located on the Microsoft CRM Server, Deployment Manager is
typically restricted to CRM system administrators or implementers who have
access to the server. Deployment Manager provides access to the following
configuration tools:
• Deployment Administrators
• Organizations

• Servers
• Licenses
FIGURE 10.1 DEPLOYMENT MANAGER
NOTE: This training applies to on-premise and partner-hosted deployments

only. Microsoft Dynamics CRM Live installations do not have access to the
Microsoft CRM Server and the Deployment Manager utility.
Creating Multiple Organizations

In the Microsoft Dynamics CRM Enterprise Edition, multiple organizations are
supported on a single Microsoft CRM Server. This is referred to as multi-
tenancy. Only the Enterprise Edition of Microsoft Dynamics CRM supports
multi-tenancy; both the Workgroup and Professional editions support only one
organization per deployment.
In Microsoft Dynamics CRM, the Microsoft CRM Server is independent of the

physical server and derives all of its settings from a central configuration
database. This involves finding where the database resides when responding to
the input request for a given CRM organization, as well as retrieving the
organization settings from the CRM database itself.
The result of this design is that a collective set of Microsoft CRM servers can
together service multiple Microsoft Dynamics CRM organizations. This provides
the following advantages to multi-tenant customers:
• Departmental Microsoft Dynamics CRM installations can be

combined into a centrally managed set of Microsoft CRM Server(s)
with fewer servers.
• The organization's data center can optimize the number of servers it
uses and effectively plan for phased deployment and growth of its
operations.
• Potential reduction of total cost of ownership due to hardware
optimization.

Multi-Tenancy and the Microsoft CRM Platform

Another goal of multi-tenancy is to enable the Microsoft Dynamics CRM
platform to provide the following deployment features:
• Economies of scale in the data-center and in corporate deployments

through sharing Microsoft CRM Servers for multiple Microsoft
Dynamics CRM organizations.
• Comparable response times for user requests even though a single
server may be servicing requests for more than one Microsoft CRM
organization.
• A predictable scale-out model for the data center so that the data
center administrator can easily plan ahead for additional customers
by merely bringing a block of CRM servers online.
• Scale-out flexibility so that data center administrators/operators can
manage service spikes by redistributing incoming requests more
evenly across server blocks.
NOTE: The components in a block of servers are unique to each data center or
corporate deployment. A block of servers includes a select number of servers in
prescribed roles that are capable of servicing a predetermined number of
organizations and therefore a predetermined number of total users for that
deployment. For example, an enterprise may determine that a block of servers
consisting of two CRM Application Servers, one CRM Platform Server, one
CRM Asynchronous Server, and one CRM Reporting Server can satisfactorily
service two organizations with a maximum of 200 users. An advantage of multi-
tenancy is that a block of servers is no longer restricted to serving one
organization.

Configuration Database
One of the key components in the multi-tenancy design is the addition of a new,
site-wide configuration database. All organization-wide settings from the local
registry, the IIS metabase, and all other server dependent locations are located
here. The name of this database is MSCRM_CONFIG.
FIGURE 10.2 MSCRM_CONFIG DATABASE
Note in this figure there are two organization databases - one for Adventure
Works Cycle and another for Northwind Traders. There is one Report Server
database and one CRM Configuration database serving both organizations.
For organizations that upgrade from Microsoft Dynamics CRM 3.0, the
application's registry and IIS metabase settings are migrated away from the
Microsoft CRM Server in the 3.0 deployment to the new configuration database
in the 4.0 installation. This enables the physical Microsoft CRM Servers to be
stateless and remappable from one organization to another. This means that a
Microsoft CRM Server is no longer tied or restricted to a given organization, but
rather, can now be configured to service multiple CRM organizations.
EXAMPLE: Northwind Traders has three organizations running Microsoft

Dynamics CRM 3.0, each of which must have its own dedicated Microsoft CRM
Server. In upgrading to Microsoft Dynamics CRM, Northwind is able to use the
two larger servers to service all three organizations. The third server is now
available for use in another capacity within the company's data center.

When an administrator creates a new organization in the Enterprise Edition of

Microsoft Dynamics CRM, the organization information is stored in the
configuration database. Similarly, the administrator can remove an existing
organization from the configuration database, although the organization must be
disabled first before it can be deleted. And if there are no more organizations left
in the configuration database, the administrator can uninstall Microsoft Dynamics
CRM from the server(s).
Once the organizations are defined for a business, administrators can perform the
following organization maintenance on the Microsoft CRM servers:
• Attach a new Microsoft CRM organization to existing Microsoft

CRM Servers
• Install a fresh set of servers for a new organization
• Reconfigure existing servers to service a new organization
Adding new organizations and maintaining the information for each organization
is performed through Deployment Manager's Organizations tool.
Creating Additional Organizations

When Microsoft Dynamics CRM is installed, the Microsoft CRM Server Setup
wizard prompts the Administrator for the default organization information. The
wizard, in turn, creates the organization record and adds it into the configuration
database.
Following installation of the Microsoft Dynamics CRM Enterprise Edition, any

additional organizations must be added by the CRM Administrator through a new
Organizations tool in Deployment Manager.

The Organizations tool is visible in Deployment Manager for all editions of

Microsoft Dynamics CRM. However, the ability to create, delete, and disable
organizations is disabled in the Workgroup and Professional Editions since these
versions are limited to one organization.
FIGURE 10.3 ADDING A NEW ORGANIZATION
Perform the following steps to create a new organization using the Deployment
Manager's Organizations tool:
1. On your desktop, click the Start menu, click All Programs, click
the Microsoft Dynamics CRM program group, then click
Deployment Manager.
2. Click on the Organizations folder to view the existing
organizations.
3. To add a new organization, either right click on the Organizations
folder and select New Organization, or click Action on the menu bar
and select New Organization.
4. In the New Organization Wizard, on the Specify the Organization
Name window, enter the Organization name. The name cannot
include blank spaces or any unsupported characters.
5. When you tab out of the Organization name field, the same name is
prefilled in the Friendly name field. Change this value if required.
Note: You can add blank spaces back in to the Friendly name if
necessary. For example, if adding an organization record for
Northwind Traders, the organization name might be
“NorthwindTraders”, but the Friendly name could be “Northwind
Traders”.
6. The ISO currency code field specifies the base currency for the new
organization. Click the Browse button and select the new
organization's base currency. Click OK.

7. The Currency name and Currency symbol are prefilled based on the
selected base currency. Click Next.
8. On the Help Us Improve the Customer Experience window, select
whether this organization is willing to participate in the Customer
Experience Improvement program. Click Next.
9. On the Select SQL Server window, select from the drop down list the
Microsoft SQL Server that contains the CRM database. Click Next.
10. On the Specify Reporting Services Server window, the report server
URL is prefilled for you. Change this value if necessary. Click Next.
11. On the System Requirements window, review the results of the
verification tasks. If any errors occur, click Details for more
information. If necessary, click Back to correct any previously
entered information. If no errors occurred, click Next.
12. On the Ready to Create window, verify the organization information.
If anything requires change, click Back to correct the information. If
all the information is correct, click Create.
13. Click Finish once the New Organization is successfully created.
14. The new organization will appear in the Organizations folder.
There are two ways in which you can add additional organizations to your
existing Microsoft Dynamics CRM deployment. The first method is by adding a
new organization through the New Organization Wizard that was discussed in the
prior lesson. The second method involves moving an existing organization and its
Microsoft CRM database from one Microsoft Dynamics CRM installation to
another. This is accomplished through the Import Organization option in the
Deployment Manager's Organizations tool.
FIGURE 10.4 IMPORT AN ORGANIZATION
Importing an existing organization initiates an Import Organization Wizard. This

wizard prompts you for the Microsoft CRM database of the organization that you
want to import. Importing a Microsoft Dynamics CRM organization means
copying all the data in the implementation and moving it to another environment.
But this process is more than just restoring the database.

Microsoft Dynamics CRM uses Active Directory for storing information

regarding:
• Users
• Client computers
• The Organizational Unit
• Security groups
FIGURE 10.5 ACTIVE DIRECTORY DATA USED BY MICROSOFT

DYNAMICS CRM
Each installation of Microsoft Dynamics CRM is tightly coupled to Active

Directory user accounts via the user account’s assigned GUID. The challenges
faced in importing a Microsoft Dynamics CRM organization that was linked into
another Active Directory includes the following:
• Microsoft Dynamics CRM leverages Active Directory to manage

Microsoft Dynamics CRM security principals; in other words, the
generation of users’ and groups’ GUIDS and managing
authentication.
• Having two Microsoft Dynamics CRM installations sharing the same
Active Directory users and groups causes risks that have been
determined to be unacceptable for most usage scenarios.
Importing Microsoft Dynamics CRM and Active Directory Data
Importing a Microsoft Dynamics CRM organization not only requires moving

customer data from one installation to another, but also moving the Active
Directory information. This preserves key information about the business and
ensures the proper operation of the application.

In order to import an existing Microsoft CRM database into a new Microsoft

CRM installation, the database must be:
1. De-coupled from the original Active Directory user identification

GUIDs
2. Re-coupled to new Active Directory's GUIDs for the appropriate
Microsoft CRM users and groups.
NOTE: There is no export process involved when importing an existing

Microsoft Dynamics CRM database. The entire CRM database is imported, so
no data is exported from the database prior to the import.
This requires the following solution:
• Update the imported Microsoft Dynamics CRM database so that the

records owned by users point to the correct GUIDs in the new
installation's Active Directory structure.
• Some database tables have indexes based on user GUIDs, and these
indexes must be updated in the new installation to utilize the new
GUIDs.
The Import Organization Wizard provides the following functionality with regard
to the import process:
• You can use the Import Organization Wizard to import an

organization from any domain within the Active Directory forest.
• When you import an organization, you must select an existing
Microsoft Dynamics CRM database. Previous versions of Microsoft
Dynamics CRM databases are not supported.
IMPORTANT: Only Microsoft Dynamics CRM Enterprise Edition supports

multiple organizations in a deployment. If you import an organization into
either the Professional or Workgroup editions of Microsoft Dynamics CRM that
already have an organization in place, the existing organization will be
replaced by the imported organization.
• The Import Organization Wizard provides the ability to map all

Active Directory Microsoft Dynamics CRM users from the source
installation to valid Active Directory users in the new Microsoft
Dynamics CRM installation.
• After Microsoft Dynamics CRM users are mapped from one
installation to another, the Import Organization Wizard replaces all
instances of user GUIDs that were copied from the source
installation with the correct user GUIDs in the new installation.

• After Microsoft CRM users are mapped from the source installation
to the new installation, the Import Organization Wizard updates all
primary and foreign keys in the imported Microsoft Dynamics CRM
database so that these primary and foreign keys use the correct
GUIDs for users in the new installation.
Mapping Users
When you run the Import Organization wizard, you must select on the User
Mapping page the method to be used to map Microsoft Dynamics CRM users
from the existing organization to the new organization. The mapping options
include:
• Keep Existing User Mappings. Your new organization will have

the exact same users as the imported organization.
• Manually Map Users. Selecting this option and clicking Next
displays the Edit User Mapping page. On this page you can manually
map users from your imported organization to the new organization.
• Generate New Mapping File. This option generates a new mapping
file that can be edited and then used to do the actual user mapping.
• Auto-map Users. This option forces the Import Organization wizard
to automatically map users from the imported organization to the
new organization based on one of the following parameters:
– Active Directory Account Name
– Microsoft Dynamics CRM Full Name to Active Directory Full
Name
– Prefix and a start value
– An existing mapping file
FIGURE 10.6 OPTIONS FOR MAPPING USERS IN THE IMPORT

ORGANIZATION WIZARD

On the Edit User Mappings page, you can manually map users and adjust the
automatically mapped users from the imported organization to the new
organization.
FIGURE 10.7 MAPPING USERS IN THE IMPORT ORGANIZATION WIZARD
Importing Reports
During the import process, the Import Organization Wizard does not prompt you
for information related to the existing organization's reports. This does not mean
that all reports created for the existing organization are lost when it is imported
into the new installation. On the contrary, the reports are imported along with the
existing organization's CRM data because the .rdl files for the existing reports are
stored in the organization's CRM database. Following the import, whenever a
report is accessed for the first time by a user, the report is copied from the CRM
database to the Reporting Services database.
Users and Multiple Organizations

An Active Directory user account can be mapped to a Microsoft Dynamics CRM
user account in more than one organization. However, the user can only access
one organization at a time. The method by which a user selects the organization
he or she wishes to access depends on the deployment type.
• When users sign into a Microsoft Dynamics CRM on-premise or

partner-hosted system, they must enter the URL of the specific
organization they want to access.
FIGURE 10.8 EXAMPLES OF ORGANIZATION URL'S

• When users sign into Microsoft Dynamics CRM Live, the
application prompts them for the organization they want to log into.

Similar logic applies for users of the Microsoft Dynamics CRM for Outlook with
Offline Access. Each user:
• Can only service one organization at a time.

• Can change their organization setting in their laptop, and upon
successful logon, view the data for the new organization.
• Can go offline with the data for a specific organization. When
offline, users cannot switch their organization.

Lab 10.1 - Maintaining Multiple Organizations

This lab requires you to create an additional organization on the Microsoft CRM
server using the Organizations tool in Deployment Manager. As you perform the
instructions, use the information in the Scenario and Goal Description to
complete the lab.
Scenario

Adventure Works Cycle, has decided to broaden their business operations by
purchasing a regional chain of clothing stores in Canada called Northwind
Traders. Northwind sells hip, trendy, “beach ware” clothing lines under the
Northwind logo. The product lines are targeted toward the 13 to 25 year old
demographic that is interested in outdoor sports such as bicycling, windsurfing,
skateboarding, and sailing.
Just as they have done with their bicycle operation, Adventure Works plans to
use Microsoft Dynamics CRM as their business application software platform for
driving sales for their new organization. In order to achieve economies of scale,
Adventure Works has decided to run the deployments of both Microsoft
Dynamics CRM organizations on their existing Microsoft CRM Server.
Adventure Works has asked you to create the new organization on their existing
Microsoft CRM Server, as well as build the initial organizational hierarchy.
Goal Description
Adventure Works has asked you to create a second organization running
Microsoft Dynamics CRM on their existing Microsoft CRM Server. Begin by
using the Organizations tool in Deployment Manager to create a new Microsoft
Dynamics CRM organization titled Northwind Traders.
• Name = NorthwindTraders.
• Display name = Northwind Traders (note the space)
• Base currency = Canadian Dollars
• SQL Server = London
• SQL Reporting Services Server URL = http://london/reportserver
• This organization will be deployed on Adventure Works’ existing
London server, alongside their Adventure Works Cycle organization.

Use your knowledge of creating and maintaining business units to build

Northwind Trader's organizational hierarchy in Microsoft Dynamics CRM based
on the figure below.
FIGURE 10.9 NORTHWIND TRADERS ORGANIZATION CHART
Challenge Yourself
1. Use the Organizations tool in Deployment Manager to create a new

Microsoft Dynamics CRM organization titled Northwind Traders.
Deploy this organization on Adventure Works’ existing London
server alongside their Adventure Works Cycle organization. Use the
information outlined in the Goal Description to complete the New
Organization Wizard.
2. Switch organizations by entering the Northwind Traders’ URL.
3. Build Northwind Trader's organizational hierarchy in Microsoft
Dynamics CRM based on the figure displayed in the Goal
Description.
4. When complete, switch back to the Adventure Works Cycle
organization.
Need a Little Help?

1. In the Organizations tool in Deployment Manager, create a new

organization titled Northwind Traders.
2. Use the information outlined in the Goal Description to complete the
New Organization Wizard.
3. Switch organizations by entering the Northwind Traders’ URL. In
Internet Explorer, type http://crm/NorthwindTraders in the address
bar.

4. Navigate to the Business Units settings area in Microsoft Dynamics

CRM.
5. On the Business Units view, add the three child business units below
the Northwind Traders root business unit as shown in the Goal
Description.
6. When complete, switch back to the Adventure Works Cycle
organization by typing http://crm/AdventureWorksCycle in the
address bar.
Step by Step
Step 1 - Add a new organization
1. On your desktop, click the Start menu, click All Programs, click
the Microsoft Dynamics CRM program group, then click
Deployment Manager.
2. Click on the Organizations folder to view the existing
organizations.
3. To add a new organization, either right click on the Organizations
folder and select New Organization, or click Action on the menu
bar and select New Organization.
4. In the New Organization Wizard, on the Specify the Organization
Name window, enter the Organization Display name. Use the value
defined in the Goal Description.
5. When you tab out of the Organization name field, the same name is
prefilled in the name field. Change this value if required.
6. The ISO currency code field specifies the base currency for the new
organization. Click the Browse button and select the new
organization's base currency. Click OK.
7. The Currency name and Currency symbol are prefilled based on the
selected base currency. Click Next.
8. On the Help Us Improve the Customer Experience window, select
whether this organization is willing to participate in the Customer
Experience Improvement program. Click Next.
9. On the Select SQL Server window, select from the drop down list the
Microsoft SQL Server that contains the CRM database. Click Next.
10. On the Specify Reporting Services Server window, enter the value
from the Goal Description. Change this value if necessary. Click
Next.
11. On the System Requirements window, review the results of the
verification tasks. If any errors occur, click Details for more
information. If necessary, click Back to correct any previously
entered information. If no errors occurred, click Next.

12. On the Ready to Install window, verify the organization information.

If anything requires change, click Back to correct the information. If
all the information is correct, click Create.
13. Click Finish once the New Organization is successfully created.
14. The new organization will appear in the Organizations folder.
Step 2 - Add business units for the new organization
1. Switch organizations by entering the Northwind Traders’ URL. In

Internet Explorer, type http://crm/NorthwindTraders.
2. From the Navigation Pane of Microsoft Dynamics CRM, click
Settings, click Administration, then click Business Units.
4. Enter Sales and Marketing as the business unit name. Northwind
Traders will be displayed as the parent business unit.
6. Repeat this step for the Product Design and Procurement business
units.
7. When complete, click Save and Close.
8. After creating all three business units, switch back to the Adventure
Works Cycle organization by typing
http://crm/AdventureWorksCycle in the Internet Explorer address
bar.

Deployment Manager - Deployment Administrators

Deployment Administrators have complete and unrestricted access to perform
Deployment Manager tasks on all organizations and servers in a Microsoft
Dynamics CRM deployment. For example, Deployment Administrators can
create a new organization or disable a server within the deployment.
To run Deployment Manager, you must have the Deployment Administrator role.
During Microsoft Dynamics CRM Server Setup, the user running the Setup is
automatically added as a member of this role and can grant Deployment
Administrator membership to other users found in Active Directory.
NOTE: Members of this role do not automatically become Microsoft Dynamics

CRM users and do not consume a Client Access License (CAL). Additionally,
the Deployment Administrators role cannot be managed in the Microsoft
Dynamics CRM client applications.
FIGURE 10.10 DEPLOYMENT ADMINISTRATORS
Add and Remove a Deployment Administrator

The Deployment Administrator role is granted or removed in the Deployment
Administrators node in Deployment Manager. Perform the following steps to add
a deployment administrator:
1. To access Deployment Manager, from the Start menu click the

Microsoft Dynamics CRM program group, then click Deployment
Manager.
2. Right click Deployment Administrators, and then click New
Deployment Administrator.

3. In the Select User dialog box, type the name of the user that you
want to add. Click Check Names, and then click OK. Note: The user
must exist in Active Directory.
FIGURE 10.11 ADDING A NEW DEPLOYMENT ADMINISTRATOR
Perform the following steps to remove a deployment Administrator:
1. Expand Deployment Administrators.

2. Right click the user that you want to remove. In the Actions pane
click Delete, and then click Yes to confirm the action.
Deployment Manager - Organizations

This training already examined how the Deployment Manager's Organization
tool is used for adding multiple organizations in the same installation. However,
this is not the full extent of the tool's capabilities. The Organization tool is also
used perform the following functions:
• Connect a Microsoft CRM Server(s) to a previously restored

Microsoft Dynamics CRM database.
• Edit an existing organization deployment.
Organizations tool
The following tasks can be performed in the Deployment Manager's
Organizations tool:
• Add a new organization. This starts the New Organization Wizard,

which prompts the user for all of the information needed to create a
new organization. The wizard performs the following functions:
– It creates a new CRM database for the organization.
– It registers the new organization in the Configuration and SQL
Reporting Services databases.
– It creates the root business unit for the organization (using the
organization's name).

• Import an organization. This option is used to move an

organization and its existing Microsoft CRM database from one
Microsoft Dynamics CRM deployment to another. Note: an
Organization Export option is not included because an organization's
entire CRM database is imported and not just a subset of the
database.
• Disable and enable an organization. If an organization's CRM
database has to be moved from one SQL Server to another (for
example, due to high usage on the current SQL Server), all access to
the database must be stopped during the scheduled maintenance
window. This is accomplished by disabling the organization. When
users try to access a disabled organization, they receive a message
that indicates the organization is unavailable and undergoing
scheduled maintenance. As soon as the database move is complete,
the organization can be enabled.
• Delete an organization. Although the organization is deleted from
the configuration database, the organization's CRM database is not
deleted from the SQL Server. As soon as the organization's CRM
database has been backed up, the database administrator can use the
SQL Server tools to delete the database. Note: An organization must
first be disabled before it can be deleted.
Restoring a SQL Server Connection

Earlier in this training, the Import Organizations option was discussed as one of
the possible ways in which a business could add a new organization to its
Microsoft Dynamics CRM deployment. A second use of the Import Organization
option is to maintain connectivity between the SQL Server holding the CRM
database and the Microsoft CRM Server(s). This typically occurs during the
following scenarios:
• Following failure and restoration of the SQL Server on which the

CRM database(s) is located
• When the Microsoft Dynamics CRM database(s) is moved to a new
physical server.
If either of these scenarios occur, you must use the Import option within the
Organizations tool to connect the Microsoft CRM Server to the restored CRM
database. If multiple CRM databases existed on the original SQL Server, then the
Import Organization option must be run against each restored CRM database.
EXAMPLE: The SQL Server machine that contains Adventure Works Cycle's
CRM database has been experiencing problems and must be replaced. The
administrator must restore the databases to another SQL server and update
Microsoft Dynamics CRM to point to the new SQL Server.

In the event of a SQL Server failure, you must restore the CRM databases from
your most recent backup and re-associate the restored databases with the
Microsoft CRM Servers.
This begins by verifying the new SQL Server is in the same domain as the
Microsoft CRM Server(s). The same server name and disk structure should be
used. If you must change either of these, additional steps are required to properly
restore the SQL Server. See Microsoft SQL Server 2005 documentation for
details on restoring SQL Server.
Before performing the organization import, you should verify whether the correct
SQL Logins exist in the new SQL Server instance. In the Security node of
Microsoft SQL Server Management Studio, verify the following logins exist and
add any that are missing:
• SQLAccessGroup
• PrivReportingGroup
• ReportingGroup
Deployment Manager - Servers

The Deployment Manager Server tool is used to perform the following functions:
• Displays the status of each Microsoft CRM Server

• Allows administrators to take Microsoft CRM Servers online and
offline
If you have multiple Microsoft CRM Servers running on your network and you
want to take one offline, use the Server Manager tool to disable the server.
Conversely, you can enable a server to bring a previously disabled server back
online.
FIGURE 10.12 DEPLOYMENT MANAGER'S SERVERS TOOL

Perform the following steps to change the status of a Microsoft CRM Server:
1. From the desktop, click Start, click the Microsoft Dynamics CRM
program group, then click Deployment Manager.
2. In Deployment Manager, click on the Servers folder.
3. Right click on the server whose status you want to change.
4. Select either Enable or Disable.
Deployment Manager - License

The Deployment Manager License tool provides the ability to view your
Microsoft Dynamics CRM licenses and add and delete them as necessary.
License Manager allows you to perform the following tasks:
• Upgrade a trial license

• Add a license to a deployment
• Remove a license from a deployment
• View the license summary for a deployment
FIGURE 10.13 LICENSE SUMMARY
The License Code page is used for adding new server and client licenses and
upgrading trial licenses. The guidelines for this page include:
• After entering each license key, you should click Add to validate the
key.
• A server license key will have zero (0) user licenses.
• If your organization purchases additional user licenses, you can enter
one or more client license keys.

• Each validated server and client license key is displayed on the page,
together with the license count associated with the key.
• A validated key can be deleted from the page.
FIGURE 10.14 DEPLOYMENT MANAGER'S LICENSE TOOL
Summary
This training reviewed the ability in Microsoft Dynamics CRM to maintain
multiple CRM deployments on a single Microsoft CRM server. This allows
businesses that have installed the Enterprise Edition to achieve economies of
scale with regard to hardware expenses for each additional organization. This is a
critical step toward reducing total cost of ownership for customers who
implement Microsoft Dynamics CRM across multiple organizations.
Also examined in this training were the following Deployment Manager

configuration tools:
• Deployment Administrators. This tool displays all of the user

accounts that are assigned an Administrator license.
• Organizations. In addition to adding new organizations, this tool is
also used in times of system failure when the Microsoft CRM Server
must be reconfigured with the SQL Server or the SQL Reporting
Server.
• Servers. This tool allows you to view the status of each Microsoft
CRM Server and online Help server. This tool can also be used to
take these servers offline and online.
• License. This tool allows you to maintain the Microsoft CRM Server
license and client licenses. It also provides the ability to convert a
trial license to a standard server license.

Test Your Knowledge

1. What are some of the functions performed by the New Organization Wizard?
2. What is unique about the Deployment Administrator role?
3. Which of the following are key functionality of the Server Manager? Mark
all that apply. (Select all that apply.)
( ) Takes Microsoft CRM Servers online and offline.
( ) Restores crashed SQL databases to their most recent backup.
( ) Display connection information relating to the Microsoft CRM Server.
( ) Set the Reporting Server URL.
4. What are some of the reasons why you would disable an organization? Mark
( ) You plan to delete the organization.
( ) You plan to edit the organization's properties.
( ) You plan to delete the organization's Microsoft CRM Server.
( ) An organization's CRM database has to be moved from one SQL Server to
another.

5. All organization-wide settings from the local registry, the IIS metabase, and
all other server dependent locations are located in which database?
( ) CRM database
( ) Metadata database
( ) Configuration database
( ) Reporting Services database


chapter:
1.
2.
3.

Solutions
Test Your Knowledge
1. What are some of the functions performed by the New Organization Wizard?
MODEL ANSWER - The wizard performs the following functions: - It
creates a new CRM database for the organization. - It registers the new
organization in the Configuration and SQL Reporting Services databases. - It
creates the root business unit for the organization (using the organization's
name).
2. What is unique about the Deployment Administrator role?
MODEL ANSWER - Members of this role do not automatically become
Microsoft Dynamics CRM users and do not consume a Client Access
License (CAL). Additionally, the Deployment Administrators role cannot be
managed in the Microsoft Dynamics CRM client applications.
3. Which of the following are key functionality of the Server Manager? Mark
(√) Takes Microsoft CRM Servers online and offline.
( ) Restores crashed SQL databases to their most recent backup.
(√) Display connection information relating to the Microsoft CRM Server.
( ) Set the Reporting Server URL.
4. What are some of the reasons why you would disable an organization? Mark
(√) You plan to delete the organization.
(√) You plan to edit the organization's properties.
( ) You plan to delete the organization's Microsoft CRM Server.
(√) An organization's CRM database has to be moved from one SQL Server
to another.

5. All organization-wide settings from the local registry, the IIS metabase, and
all other server dependent locations are located in which database?
( ) CRM database
( ) Metadata database
(•) Configuration database
( ) Reporting Services database


Chapter 11: Introduction to Advanced Customizations
CHAPTER 11: INTRODUCTION TO ADVANCED

CUSTOMIZATIONS
Objectives
The objectives are:
• Introduce Workflow features, including Workflow events, actions

and conditions
• Identify the form and field events that can be customized with client-
side code
• Examine some of the common uses of client-side code within
Microsoft Dynamics CRM
• Explore the advantages of using Form events, and which form
Events can include client-side code
• Explore the advantages of using Field events, and which field Events
can include client-side code
• Examine where the JScript code for Form and Field events is entered
• Identify the issues to be aware of when adding client-side code
• Examine how IFrames provide the ability to display the web page
from another application within a Microsoft Dynamics CRM form
• Examine how you can link Microsoft Dynamics CRM into other
applications and reports using URL Addressable forms
• Explore how to add custom menus, side tabs, and buttons to the
Microsoft Dynamics CRM application
• Identify where you can add custom buttons, menus, and side-tabs in
Microsoft Dynamics CRM
• Examine how to customize the Navigation Pane by modifying the
SiteMap
• Review the structure of the SiteMap so that you can customize the
correct areas according to your business requirements
• Introduce the Software Development Kit (SDK) that is used by
developers when integrating Microsoft Dynamics CRM with other
applications
• Identify where an organization can locate ISV solutions

Introduction
The purpose of this training is to introduce you to a variety of advanced
customization features that are available with Microsoft Dynamics CRM.
Specifically, this training introduces you to application event programming,
client extensions, and workflow. Because this training is not intended for
developers, it simply introduces these topics by limiting its scope to the
following:
• Microsoft Dynamics CRM workflow using Microsoft Windows

Workflow Foundation.
• The basic framework of application event programming
• Integrating Microsoft Dynamics CRM into other applications using
client extensions
Workflow can be one of the most powerful types of customization in Microsoft

Dynamics CRM. Workflow allows organizations to automate their business
processes by implementing workflow rules. The goal for using workflow is to
ensure that customers receive a consistent experience with the organization. This
training introduces you to the Workflow features and systematically covers each
of the components that comprise workflow rules.
This training also focuses on how client-side code is used with the available
Form and Field events in Microsoft Dynamics CRM. The training also discusses
how client-side code can be used to manipulate the behavior of the Microsoft
Dynamics CRM application. Implementation of client-side code is also possible
through some application integration features, including buttons and menu items.
The ability to integrate Microsoft Dynamics CRM with other web applications
allows you to consolidate related applications into a single, easily navigable
portal for employees. The tools included for Microsoft Dynamics CRM to be
integrated into other applications are designed for use by ISVs, implementation
consultants, developers, and customers.
Introduction to Workflow
Microsoft Dynamics CRM Workflow is a powerful tool that can help business
managers define, automate, and enforce specific business rules, policies, and
procedures. One of the primary goals of implementing Workflow rules is to
simplify and streamline current business processes so that businesses become
more efficient in their day-to-day operations.

Workflow enables actions to occur without direct interaction by the users, based
on rules set up by the business. Workflow rules are triggered by events within
Microsoft Dynamics CRM when specific actions are performed and specified
conditions are met. Some of the key features of Microsoft Dynamics CRM
Workflow include:
• Integration with the Windows Workflow Foundation and Visual

Studio
• Ability of end-users to access and create workflow rules
• Child workflows and workflow templates
• Enriched event model
• Support for dynamic values and conditionals
• Stages, which compartmentalize logic segments
• A robust, asynchronous service-oriented architecture
Creating a Workflow Rule

Each workflow is created for a specific entity. As soon as the workflow is
created, you can define it by adding actions and conditions. As soon as
workflows have been created, users can run them from several places in the user
interface. How the workflows start depends on which of the following workflow
types is being used:
• Automatic. These workflows are designed to start automatically

without requiring user intervention.
• On-Demand. These workflows can be started at any time by a user
who has sufficient permissions. They can be run from the view of the
relevant record type or from within an individual record form.
• Child. These workflows are designed to be run inside other
workflows. They frequently contain logic that is common to multiple
business processes. They can be run by including them in other
workflows at design time, and then running a workflow that contains
them.
• Workflow Templates. Templates are created by an administrator to
provide basic structures for commonly requested workflows. Users
can create a new workflow from a template and add details specific
to their needs. Templates are not intended to be run as stand-alone
workflows.
Triggering Events for Automatic Workflows

Automatic workflows can be configured to run when one or more of the
following events occur:
• A record is created
• A record's status is changed

• A record is assigned
• A record's attributes are changed
• A record is deleted
Microsoft Dynamics CRM supports using multiple events to trigger a single

workflow. When selecting a triggering event, a user may select more than one
event.
For example, a workflow can be created that runs if a contact record is created,
updated, or deleted. Also, the list of triggering events can be changed after the
workflow is created.
Assigning Scope to a Workflow

A workflow's scope determines the records that the workflow can take action
upon. A workflow's scope is limited by the following two factors:
• the permissions that the workflow's owner has

• the view the owner selects for the scope when he or she creates the
workflow
The scope options that can be assigned to a workflow are identical to the access
levels that can be assigned to privileges in security roles. When you create a
workflow, you can assign one of the following scopes to the workflow rule:
• User
• Business unit
• Parent: child business units
• Organization
Workflow Conditional Statements

Conditionals are the “if, then, else” statements used to branch logic based on
possible conditions. For example, a workflow can be written to create an
opportunity only if the company's revenue is more than $1 million per year.
Key features supported by workflow conditionals include:
• Else conditions. Else conditions have been added to prior support

for “if and then” conditions. This makes it easier to handle
exceptions and errors.

• Branches to wait conditions. Wait conditions, which specify that no

action can occur until certain conditions are met, are not new. What
is new is that they can be included within if, then, or else branches.
This makes it possible to include timeouts as part of exception
handling.
• Date-time support. Specific times and due dates can be included
within conditions. For example, a workflow can close an opportunity
if there is no action on it for one month after it is created.
Workflow Stages
Stages enable users to encapsulate and label segments of a workflow. This is
useful for defining and monitoring the parts of a complex process, such as sales
or service. In Microsoft Dynamics CRM, support for stages has been enhanced to
allow:
• Stages in any workflow

• Conditional statements within stages
• Multiple concurrent processing on a single record
• Skipping of stages
• Exiting from the workflow
Stages must not be confused with workflow steps. Steps are the individual
actions that comprise a workflow. Stages are top-level containers that organize
and label one or more steps. Steps, however, cannot contain stages.
Users must provide a description for each stage, whereas descriptions for steps
are optional. This is because stage descriptions appear in the user interface when
a user checks on the status of a workflow that contains them.
Example: Sales Process with Stages

The following is an example of a scenario in which a workflow that uses stages
can be useful.
Charlie, a company CEO, wants to make sure that he always has access to a
current view of the sales pipeline. He also wants to have a view that breaks the
sales process into a series of stages, including:
• How much of the sales process has been completed, either in terms
of elapsed time or the probability of sale.
• Completed and uncompleted activities that comprise the current
stage
• How much time remains in the current stage

Keeping these objectives in mind, Charlie wants the following sales process to be
implemented:
• Opportunity Assignment. If the opportunity is worth more than $5

million, it is assigned to Kevin. If it is not, it is assigned to Susan.
• Confirm Requirements. The owner of the opportunity makes a
telephone call to the customer to gather requirements and buying
intent. At this point, probability of sale is expected to be 25 percent.
All activities for the first stage must be completed within two days.
• Submit RFP. The owner of the opportunity submits an RFP to the
customer. At this point, the probability of sales is expected to be 50
percent. All activities for the middle stage must be completed within
five days.
• Complete the Deal. The owner of the opportunity closes the deal. At
this point, the probability of sale is expected to be 75 percent. All
activities for the final stage must be completed within five days.
• Log the Deal. The owner of the opportunity logs the deal into the
system. At this point, the probability of sale is expected to be 100
percent. All activities for this stage must be completed within one
day.
In case the opportunity is lost at any point in the process, the salesperson closes
the opportunity as lost. That pushes the opportunity out of the sales process,
which in turn causes the workflow to end.

Demonstration - Activity Creation in a Workflow

This demonstration creates a phone call activity for a new contact.
Scenario
When a new contact is created, management wants to ensure that the person who
created the contact record in Microsoft Dynamics CRM is reminded to call the
contact and introduce himself or herself to the contact. This telephone call must
take place within five days of the creation of the contact record.
Goal Description
Create a phone call activity for a new contact.
Step by Step
Step 1 – Creating the rule
1. In Microsoft Dynamics CRM, navigate to Settings-> Workflows.

Click New to create a new workflow.
2. Record the following details about the workflow
a. Workflow name: Create welcome phone call.
b. Entity: select Contact.
c. Ensure that the radio button New blank workflow is selected.
3. Click OK.
4. In the workflow properties section, record the following properties
a. Apply to: Organization
b. Publish as: Workflow
c. Triggering Event: Create
d. Accept all other default values
5. Click on ‘Select this row and click Add Step’ and click Add Step.
6. Select Create Record.
7. In the drop-down, select Phone Call.
8. Click Set Properties. The Create Phone Call page appears.
9. Type ‘Welcome Phone Call’ in the Subject field.
10. Click into the Sender field. In the Form Assistant pane, select Owner
(User) in the first ‘Look For’ picklist, and select User in the second
‘Look For’ picklist. Still in the Form Assistant pane, click Add, and
then click OK.

11. Use the process in the previous step to populate the following fields
a. Phone Number: with the Contact’s Business phone number.
b. Recipient: with the Contact’s Full Name – this displays as
‘Contact(Contact)’.
c. Regarding: with the Contact’s Full Name – this displays as
‘Contact(Contact)’.
12. Click in the Due field. In the Form Assistant pane, select 5 in the
Days picklist, and After in the picklist below it. Ensure that Contact
is selected in the first ‘Look For’ picklist, and then select Created On
in the second ‘Look For’ picklist. Still in the Form Assistant pane,
click Add, and then click OK.
13. Click Save and Close to close the ‘Create Phone Call’ page.
14. In the Workflow: Create welcome phone call page, click Publish,
and then click OK to confirm publication of the workflow, and click
Close to close the workflow page
Step 2 – Testing the workflow
1. In the main Microsoft Dynamics CRM window, click New Record,

and select Contact.
2. Enter your own first name, last name, and business telephone
number in the form, and click the Save button.
3. In the Details navigational area, click Activities. Note the new phone
call. Because workflows are executed asynchronously, it may not
appear immediately. After a few moments, click the refresh icon at
the top of the grid.

Introduction to Application Event Programming

A web application must balance where processing occurs to achieve optimum
performance. Although some processing can be performed most efficiently on
the web server, this type of processing requires that information be sent and
returned from the browser to the server. This exchange of data can result in a
performance lag. There is also the danger that the capacity of the server may be
overwhelmed, leading to performance problems.
When discussing client-side code, the “client” in question is the user's machine.
Including business logic on the client helps minimize these issues by using the
resources of the client machine. Another advantage of client-side code is that the
processing is immediate, resulting in better performance. Because of this, client-
side code is commonly used to respond to user actions, validating data, and
manipulating the user interface based on user actions.
Events
Microsoft Dynamics CRM allows custom programming logic to be applied when
specific events occur within the application. When the user performs an action
resulting in the execution of one of these events, the custom programming logic
tied to the event is designed to interact with the Microsoft Dynamics CRM web
form. The web form, in turn, is displayed in either the browser window or
another web application or web service.
The following table outlines the events available on each form in Microsoft
Dynamics CRM. These events are on either the Form or Field level events.
FIGURE 11.1 FORM AND FIELD EVENTS SUPPORTED BY MICROSOFT

DYNAMICS CRM
Client-side code is best applied in solutions that require immediate feedback to

the user. If this immediate feedback is not necessary, Microsoft Dynamics CRM
Workflow may provide more powerful solutions requiring less coding.
Transportability and Supportability

Many web applications allow you to modify files on the web server that store the
code. Microsoft Dynamics CRM does not support direct modification of the
.aspx .css, .htc or .js files that make up the web application.

Instead, Microsoft Dynamics CRM provides areas to enter client-side code for
specific events. This allows the code to be stored with the application metadata
so that it can be easily transported. This provides the following advantages:
• When you import or export customizations for a specific entity, the

client-side code can be imported and exported with all the other
entity customizations.
• Because all the client-side code is stored in the application metadata
rather than in separate files on the web server, the application is
easier to support and maintain. This is particularly true during
upgrades.
Client-side customizations work in both the Web application and Microsoft

Dynamics CRM for Outlook without having to be deployed separately.
Developers have the capability to determine if a Microsoft Dynamics CRM for
Outlook user is off-line and disable any functionality that assumes a network
connection.
Skills Needed to Write Client-Side Code

To create client-side customizations within Microsoft Dynamics CRM, a
developer needs to be familiar with the JScript scripting language.
NOTE: JScript is the name for the Microsoft implementation of the scripting
language that is also known as JavaScript and ECMAScript. VBAScript cannot
be used in Microsoft Dynamics CRM client-side customizations.
Developers need to be familiar with Dynamic HTML (DHTML) and how to

interact with the elements of the Document Object Model (DOM) in Internet
Explorer. These are commonly combined and referred to as the DHTML DOM.
Common Uses for Event Programming

Some common areas where client-side code is used to develop application events
include:
• Data validation
• Extending functionality
Data Validation
Microsoft Dynamics CRM is designed to leave organizations with a lot of
flexibility for data validation. Many applications include built-in capabilities to
perform data validation. Unfortunately, these built-in capabilities often restrict
deployment to a specific method of validation that might be a poor fit for a
particular deployment. Not providing a built-in method allows easier integration
with whatever validation is a best fit for the organization.

Some examples include:
• Dynamic Picklist
• Phone Number formatting
Example - Dynamic Picklist
A picklist provides a way to categorize items into specific categories. But

sometimes the number of categories requires a picklist with so many options that
it can become difficult to use. It is often desirable to have at least two picklist
fields that work together to provide a larger category to group items and a
specific category list to capture more detailed information.
For this to work, the specific category picklist needs to react to options chosen in
the larger category picklist so that only valid options are available. For validity
purposes, it is necessary that every possible option in the specific category
picklist be included as an option in the picklist attribute. Making the specific
category picklist responsive to changes in the larger category picklist is a process
of dynamically adding or removing available options.
Example - telephone number Formatting
Formatting telephone numbers makes them easier for people to read. The
telephone number (425) 555-1234 is much easier to read than 4255551234. But
the exact formatting to apply varies internationally and depends on the number of
characters found in the telephone number. But this is a problem that many web
developers have addressed by evaluating patterns in numbers so that the correct
formatting can be applied. The OnChange event of a telephone number field
provides the mechanism to perform the formatting.
Example - Clone Contact
When users are working with contacts for a particular account, they often need to
create a new contact that works at the same company. Normally, a user navigates
to the Account record and chooses to add a related Contact. The mapping from
the Account to the Contact populates any fields that are normally expected to be
the same, such as the address information.
However, users may expect or desire something that does not require them to
navigate to the Account record. The ability to clone a contact directly from the
Contact form provides a simpler approach and less training. This is achieved by
adding a custom button that takes values from the current form and opens a new
Contact form with the data pre-populated. All the user needs to do is add the data
unique to that contact - such as name, telephone number and e-mail address - and
then click Save.

The Clone contact feature is a good example of a solution that appears to offer
some strong advantages while at the same time introducing several
disadvantages. For example, the process of requiring users to go to the account
before adding a new contact related to that account provides them with the
opportunity to confirm that the contact they are adding does not already exist in
the system. Introducing a way for users to quickly add contacts without this
check increases the possibility for duplicate contact records to be added. The best
practice in this situation is to always consider the possible disadvantages before
implementing a new customization.

Demonstration - Examples of Client-Side Code

This demonstration displays some of the example solutions described in the
preceding lesson titled Common Uses for Event Programming.
Scenario
You have asked a developer to create a set of customizations. You need to import
and test the customizations to confirm that they conform to the specification you
provided the developer.
Goal Description
There are three different customizations:
Dynamic Picklists
Entity: Phone Call
Two new fields, Call Type and Call Description, are used to classify calls. Call
Type is a picklist that includes options to describe the purpose of the call. The
value ‘Other’ is provided if none of the options apply.
When ‘Other’ is selected, the Call Description field is enabled. If Call Type =
‘Other’ and the Call Description field does not contain data, the user cannot save
the record until data is provided in the Call Description. A message is displayed
to the user explaining what he or she must do when this occurs.
Entity: Account
A custom field called Sub-Industry is activated when the Industry value is set to
“Accounting” or “Consulting.”’ This allows for the selection of valid values for
each industry.
Format telephone number
Entity: Account
The following rules are applied to the telephone number fields on the form:
• For every telephone number field on the form, if the first character is
a plus sign (+), the number is assumed to be international and will
not be formatted.
• If the number starts with a “1”, it will not be formatted.
• If the number has ten characters, it will be modified to be formatted
like this (###) ###-####, where the pound (#) symbol represents a
number.
• If an “x” character is included after the tenth character, it will be
formatted as an extension. For example: (###) ###-#### x####

Step by Step
Step 1: Import the Customizations
1. Import the ClientSideCustomizations.xml file from

C:\Class Materials\Customization\Ch.11.
2. Publish the Account and Phone Call entities.
Step 2: Test the Dynamic Picklists
1. Open a phone call record and confirm the behavior found in the goal
description for the Call Type and Call Description fields.
2. Open an Account and confirm the behavior found in the Goal
Description for the Industry and Sub-Industry fields. These can be
found on the Details tab.
Step 3: Test the telephone number Formatting
1. In an Account form, enter a telephone number in any of the

telephone number fields. The telephone number must have ten digits
and must not start with the number one.
2. Confirm that the telephone number fields apply the formatting
described in the Goal Description.

Using Form Events

The Form Editor is used for adding custom code for client-side Form events. The
Form Properties dialog box includes an Events tab that displays the OnLoad and
OnSave Events. Editing the event displays a window you can use to enter the
code for the event.
• Using the OnLoad Event. This event occurs after the form has
loaded; therefore, it cannot prevent the window from loading. The
OnLoad event is valuable because it can:
– Apply logic about how the form must be displayed
– Set certain fields to read-only or business required
• Using the OnSave Event. This event does not correspond to the
standard OnSubmit event exposed by DHTML. It is started when a
user presses the Save or Save and Close button on the form. The
event is started whether the data in the form has been modified or
not.
FIGURE 11.2 FORM EVENT
Perform the following steps to add client-side code to a Form event:

2. Open the entity containing the form, and then click Forms and
Views.
3. Click Form, then on the Actions toolbar, click More Actions, and
then click Edit.
4. Click Form Properties.
5. Click onSave or onLoad, and then click Edit.

6. On the Details tab, select the Event is enabled check box to enable
the event, and in the text box, enter the body of the script that you
want to use when the selected event is run.
7. On the Dependencies tab, in the Available Fields list, select any
fields you have used in scripts, and then click >> to move the
selected fields to the Dependent fields list.
8. Before saving the form, test your script in the three modes a form
can be used: Create, Update, and Read-only:
a. On the Preview menu, click Create Form, Update Form, or
Read-Only Form.
b. If you have added an onLoad event for the form, when you open
the form in each mode, verify that your event executed as
expected.
c. If you have added an onSave event for the form, for create and
update modes, on the Form toolbar, click Simulate Form Save
to see if the event executes as expected.
d. Click Close on the File menu to close the Preview form.
9. Click OK to close the Form Properties dialog box.

10. Click Save and Close to close the form.
11. Click Save and Close to close the entity.
12. Publish you customizations when finished.
Using Field Events

As with Form events, client-side code for field events is entered using the Form
Editor. The OnChange event is the only event available for fields. It can be found
on the Events tab of the field properties.
FIGURE 11.3 FIELD EVENT

Each field in Microsoft Dynamics CRM supports the OnChange event. The code
is run when the value has changed and the focus has been lost. Focus exists when
the field is active; it is lost when you tab or use your mouse to enter data in a
different field.
After the code has been executed, the data in the field is re-validated. This means
you cannot make your code change the value of a field to an invalid value.
Perform the following steps to enter client-side code for a Field event:

2. Open the entity containing the form, and then click Forms and
Views.
3. Click Form, then on the Actions toolbar, click More Actions, and
then click Edit.
4. Select a field on the form and click Change Properties.
5. On the Events tab, select onChange, and then click Edit.
6. On the Details tab, select the Event is enabled check box to enable
the event, and in the text box, enter the body of the script that you
want to use when the selected event is run.
7. On the Dependencies tab, in the Available Fields list, select any
fields you have used in scripts, and then click >> to move the
selected fields to the Dependent fields list.
8. Test your script in the two modes a form can be used: create and
update.
a. On the Preview menu, click Create Form or Update Form.
b. Enter the data in the field and verify that the event executes as
expected.
c. Click Close on the File menu to close the Preview form.
9. Click Save and Close to close the form.

10. Publish you customizations when finished

Demonstration - Referencing Form and Field Values

This demonstration illustrates how to reference a variety of Microsoft Dynamics
CRM field and form values.
Scenario
You are developing client-side code for Microsoft Dynamics CRM events using
the Account entity. You want to confirm your ability to reference a number of
form and field values.
Goal Description
The goal of this demonstration is to:
• Display a message showing the form and field values for a number
of Microsoft Dynamics CRM Account fields
• Change these form and field values
Step 1: Review crmForm_reference.js Code
1. In Windows Explorer, navigate to the following folder:
C:\Class Materials\Customization\Ch.11
2. Open the file crmform_reference.js.

3. Note how the different types of fields are referenced.
Step 2: Apply Code to the OnSave Event

2. Double-click the Account entity.
6. Select the OnSave event and click Edit.
7. Copy and paste the code from the crmform_reference.js file into
the code window.
NOTE: If you completed the previous demonstration, there will be code

already present in the OnSave event. Replace any existing code with the
code in crmform_reference.js.

8. Click the Event is enabled checkbox.

9. Select the Dependencies tab and add the following fields to the list
of Dependant fields for the event: Account Name, Parent Account,
and Relationship Type.
10. Click OK to close the Event Detail Properties window.
11. Click OK to close the Form Properties window.
Step 3: Test the Code by Previewing the Form
1. Click Preview, then click Create Form.

2. Enter an Account Name.
3. Enter a Parent Account.
4. Select a Relationship Type.
5. Click Simulate Form Save.
6. Confirm that the message displays as expected.
7. For the purpose of this demonstration, do not save or publish these
changes to the Account form.

Configuring Event Detail Properties

Use the Event Detail Properties window to enter the JScript that includes the
logic you want to apply on the event. When using this window you must pay
attention to the following:
• No validation of code
• Enable Event
• Dependencies
No Validation of Code
Microsoft Dynamics CRM does not perform any validation of the JScript code
you enter for an event. Also be aware that JScript is case sensitive. Therefore, if
the code you enter uses the wrong case or has a syntax error, an error appears on
the page when the event is triggered.
When a syntax error occurs, you will see a small alert icon in the bottom left
corner of the frame. If you click the icon to view more details, you will typically
see the following message: “Problems with this Web Page might prevent it from
being displayed properly or functioning properly.”
It is recommended that you write your code using an appropriate development

program, like Microsoft Visual Studio or Microsoft Front Page and then paste
your code into the Event Detail properties window. The Event Detail properties
window does not include Intellisense or syntax checking.
As a best practice, store your scripts in a separate location in case you want to re-
apply them or reference them.
Enable Event
You must enable the event by checking the Event Enabled check box. When
developers first begin to use the Event Detail properties window it is not unusual
for them to forget this step. The code associated with an event will not be
triggered if this check box is left blank.
Dependencies
If the code you enter references a field in the form, removal of that field causes
your code to break. Adding fields to the list of dependant fields prevents you or
another person from breaking the code by removing the field. However, there is
no actual dependency with respect to the code itself. Failure to list the dependant
field does not affect the code you write.

Scripts created for custom buttons and menu items may also reference form
fields. There is a Non-Event Dependencies tab on the Form that is not
associated with any event. This is where dependencies created by scripts that are
not associated with an event can be entered. Creating custom buttons and menu
items is covered later in this training.

Demonstration - Creating Simple Event Scripts

This demonstration illustrates how to add simple event scripts using the Jscript
alert() method to display messages. The alert() function is a valuable tool in
learning JScript and troubleshooting client-side code.
Scenario
The Vice President of Sales at Adventure Works Cycle has asked for a warning
to be given when an Account is opened if the Account has the Credit Hold field
set to ‘Yes’. In addition, to prevent accidental changes to Account names, he has
asked that a warning message be displayed when an account name is changed.
Finally, he wants an informational message to be displayed when an Account is
saved.
Goal Description
You want to display a message when the following events occurs.
• When the Account form loads, a dialog box with the message “This
Account is on Credit Hold” must appear if the account's Credit Hold
field is set to ‘Yes’.
• When the account is saved, a dialog box with the message “The
Account is saving” appears.
• When the value of the Account Name is changed, a dialog box with
the message “The Account Name has changed” appears.
Step by Step
Step 1: Configure the OnLoad Event

2. 2. Select the OnLoad event from the Events tab and click Edit.
3. Enter the code displayed below in the function OnLoad() area. The
code can also be found in the following folder:
C:\Class Materials\Customization\Ch. 11\CheckCreditHold.js
var CreditOnHold = crmForm.all.creditonhold.DataValue;
if (CreditOnHold == true)
alert(‘This Account is on Credit Hold’);

4. Check the Event is enabled check box.

5. Click OK.
NOTE: If you followed the steps in Demonstration: Examples of Client, Side

Code you will see that some code already exists for this event. Simply include
your code above or below the existing code.
NOTE: Type the code exactly as it appears. JScript is case sensitive and there
is no validation of the code.
Step 2: Configure the OnSave Event
1. Select the OnSave event from the Events tab and click Edit.
2. Enter the following code in the function OnSave() area:
alert(‘The Account is saving’);
3. Check the Event is enabled check box. Click OK.

4. Click OK to close the Form Properties window.
Step 3: Configure the OnChange Event for the Account Name
1. Select the Account Name field.

2. Click Change Properties.
3. Click the Events tab.
4. Select the onChange event and click Edit.
5. Enter the following code in the OnChange() area:
alert(‘The Account name has changed’);
6. Check the Event is enabled check box. Click OK.

7. Click OK again to close the Field Properties window.
Step 4: Publish the changes
1. Save and Close the Account form.

2. Publish the Account entity.

Step 5: Test the changes
1. Create a new Account.

2. Enter a name in the Account Name field and then click the Account
number field. Note that the message ‘The Account Name has
changed’ appears.
3. Click OK to close the message.
4. On the Administration tab, set the Credit Hold field to Yes.
5. Save and Close the account. Note that the message “The Account is
saving” appears.
7. Reopen the Account you just created. Note that the message “This
Account is on Credit Hold” appears.

Introduction to IFrames
The term IFrame refers to “Inline Frame”. An IFrame allows you to display the
web page of another application within a Microsoft Dynamics CRM form. The
figure shows an Internet Explorer window. Inside the window three frames are
presented inside a frameset. An IFrame is included inside the Main Frame.
FIGURE 11.4 WINDOW - FRAMESET - FRAME - IFRAME
A simple HTML document is displayed in the browser window. A more

sophisticated website hosts several different HTML pages within a single
window, each within a frame defined in a frameset. An IFrame is an “inline
frame”, or “floating Frame.” This is a frame that can be inserted within an HTML
document. An IFrame is basically a document within a document.
IFrame Usage
You can use an IFrame for a variety of purposes, such as displaying:
• Another web site. Static web content can be displayed from an

intranet or extranet site. For example, if an Account has a website,
you can configure an IFrame on an Account form to display that
website so the user can view it without leaving Microsoft Dynamics
CRM.

• Dynamic web application. The URL for the IFrame can be

manipulated using Dynamic HTML (DHTML) to pass arguments to
a web application to display information related to the record within
the IFrame.
For example, you can pass address information to a website such as

Live Search Maps (http://maps.live.com/default.aspx) to use address
information to display a map.
• Dynamic help. The IFrame can interact with the CRM form to
display information relevant to the data found on the form or to
respond to events triggered by the user's actions within the form.
For example, you may want to provide specific business process

guidance to users within the form without opening up a separate web
site. When client-side validation rules are not met, you can display
messages in the IFrame instead of using an alert.
Cross Frame Scripting

Cross frame scripting is when you display web content from another domain or
include scripts that interact with a web site on another domain. At issue is the fact
that cross frame scripting poses a security risk because you are interacting with
an application that resides outside your secured domain.
Since a browser can simultaneously display unrelated documents in its various

windows and frames, certain rules must be enforced to protect data integrity and
privacy of information. Default restrictions are in place to prevent certain types
of content interaction.
EXAMPLE: A typical page on www.microsoft.com can freely script content on

any other page on www.microsoft.com, but cannot script to pages that are
located on a different Web domain.
By default, Microsoft Dynamics CRM does not allow this type of cross frame
scripting. However, if you feel you need this type of interaction, and that you can
trust the site on the other domain, then you can choose to allow this type of
transaction.
The DHTML Object Model uses the document.domain property to enforce this
restriction. Only pages with identical domain properties are allowed free
interaction.
WARNING: Removing these default restrictions can allow a rogue page to

collect data on another page or, using DHTML, manipulate its content.
In addition to restricting interactions to the same domain, interactions are also

restricted by default to the same URL protocol.

EXAMPLE: An HTTP page cannot access HTTPS or FTP content.
With the default restrictions in place, scripts that attempt to access parts of the
object model to which they do not have access are blocked with a “permission
denied” error. With restricted interactions turned on, a user can view a static
HTML page on another domain, but any capabilities of that site beyond simple
display of HTML will not work. Frames, style sheets, and any interactive
elements will not work.
Internet Explorer Security Settings

Internet Explorer uses the following configurable security zones:
• Internet
• Intranet
• Trusted Sites
• Restricted Sites
Within each of these security zones is a setting called “Launching programs and
files in an IFrame”. This option controls if users can launch programs and files
from an IFrame element (containing a directory or folder reference) in Web
pages within the zone. This option has the following settings:
• Disable – Prevents programs from running and files from

downloading from IFrame elements on Web pages in the zone.
• Enable – Runs programs and downloads files from IFrame elements
on Web pages in the zone without user intervention.
• Prompt – Prompts users to choose to run programs and download
files from IFrame elements on Web pages in the zone.
Passing Parameters
Each Microsoft Dynamics CRM entity has a corresponding object type. For
example: Account = 1, Contact=2. Each record also has a globally unique
identifier (GUID). When you create an IFrame, you can indicate if it needs to
pass these parameters to the target URL. This will cause these parameters to be
added to the URL.
EXAMPLE: Without parameters, the URL will likely be:

http://myAccountLookupApp.aspx. With parameters, the URL will be:
http://myAccountLookupApp.aspx?type=“1”&id=“<GUID>”

If your target application is configured to search for records by the Microsoft

Dynamics CRM GUID, the target application can use these parameters to look up
a record that corresponds to the CRM record the user is viewing.
Procedure: Add or Edit an IFrame

Perform the following steps to add or edit an IFrame:

click Customize Entities, and then double-click the entity you want
to customize.
2. On the entity form, click Forms and Views. Double-click Form to
open the entity's form.
3. To add an IFrame, in the Common Tasks area, click Add IFrame.
4. To edit an existing IFrame, select a tab and then the IFrame in the tab
you want to edit. Then in the Common Tasks area, click Change
Properties.
5. On the IFrame Properties dialog box, on the General tab, enter the
information you want. In particular, note the following:
• In the Name box, enter a unique name for the IFrame. The name
can only contain alphanumeric characters and the underscore
character.
• In the URL box, enter a full URL for the IFrame, and optionally
select the Pass record object-type code and unique identifier
as parameters check box.
• The Restricted check box is selected by default for security
purposes. Exercise great caution in allowing cross-frame
scripting.
6. On the Formatting tab, the formatting options displayed depend on

the section formatting options.
7. On the Dependencies tab, from the Available Fields list, select the
fields you want to designate as dependent fields in the IFrame.
8. Click OK.
Dynamic IFrame
In addition to passing parameters, there are two other ways that an IFrame can be
dynamic:
• Change the src attribute. The src attribute is used to set or retrieve
a URL to be loaded by an IFrame.
• Reference Form Field values. Another way to make an IFrame
dynamic is to pull the form values from the crmForm. A script in the
target of the IFrame can access objects in the parent.

Demonstration - Add an IFrame

This demonstration illustrates how to add an IFrame to a form. The next
demonstration shows how to make that IFrame dynamic.
Scenario
Adventure Works Cycle wants to display the Account’s web site in an IFrame on
the Account form. If the account’s web site URL is not known, Adventure Works
Cycle wants the IFrame to display a static page.
NOTE: This demonstration only displays a static picture. In the next

demonstration, code will be used to make the IFrame dynamic.
An IFrame will be added to a new section in a new tab on the Account form.
Step by Step
Step 1: Open the Account Form

click Customize Entities, and then double-click Account.
3. Double-click Form to open the Account form.
Step 2: Add a Tab and Section
1. On the Account form, add a tab named “Web site”.

2. Within this new tab, add a section named “Web site”. Do not display
the section name.
Step 3: Add an IFrame
1. Select the Web Site Section and click Add an IFrame.

2. Add an IFrame with the following properties:
a. Name: WebSite
b. URL: http://CRMExt/Internet/NoSite.htm
c. Auto-expand to fill up available window space: checked
d. Accept the default values for other properties
Step 4: Preview
Confirm that the page loads and the NoSite page is displayed.

Step 5: Save and Publish Changes
1. Click Save.
2. Click Actions, then click Publish.
Step 6: Test IFrame
1. Open one of the following accounts: ‘A Bike Store’, ‘Cash and Carry
Bicycles’, or ‘Bike Universe’.
2. Confirm that the No Web site page is displayed in the IFrame.
3. Open one of the other accounts listed above.
4. Confirm that the No web site page is displayed in the IFrame on this
account.

Demonstration - Creating a Dynamic IFrame

This demonstration illustrates how to create a dynamic IFrame.
Scenario
Adventure Works Cycle wants to allow users to view an account's website within
Microsoft Dynamics CRM if that account has a web site URL in Microsoft
Dynamics CRM. The previous demonstration showed how to create an IFrame.
This demonstration shows how to make the content of the IFrame dynamic.
Use the URL stored in the Account Web Site field to display the Account's web
site in an IFrame in a tab on the Account Form. The OnLoad event will load the
URL from the Account Web Site field to be the target of the IFrame.
Step by Step
Step 1: Open the Account Form

3. Double-click Form to open the Account form.
Step 2: Set the IFrame Src in the OnLoad Event
1. Click Form Properties, select the OnLoad event and click Edit.
2. Below any existing code, paste the code found in the following file:
C:\Class Materials\Customization\Ch.11\SetAccountURL.txt.
var AccountURL = crmForm.all.websiteurl.DataValue;

if (AccountURL != null)
{
crmForm.all.IFrame_WebSite.src=AccountURL;
}
3. Close the OnLoad Event Detail Properties window.

4. On the General tab, open the Web Site field properties, click the
Events tab and modify the Onchange event by adding the same code
used in instruction 2.
5. Enable the event.
6. Save the changes to the Web Site field.
7. Publish the Account customizations.

Step 3: Test the Changes
1. Open one of the following accounts: ‘A Bike Store’, ‘Cash and Carry
Bicycles’, or ‘Bike Universe’.
2. Confirm that the web site page for that account is displayed in the
IFrame.
3. Open one of the other accounts in this list.
4. Confirm that the No web site page is displayed in the IFrame on this
account.

Introduction to URL Addressable Forms

You can link other applications into Microsoft Dynamics CRM using IFrames.
Conversely, you can link Microsoft Dynamics CRM into other applications and
reports using URL Addressable forms.
Each entity in Microsoft Dynamics CRM has a unique Object Type Code and a
web page that is used to edit the record. This table lists selected entities with their
URL extension and Object Type Code. The URL begins with http://<server
name>.
FIGURE 11.5 SELECTED ENTITY URL EXTENSIONS AND OBJECT TYPE

CODES
NOTE: You can find the Object type code for any entity by referencing the entity
definition from the metadata browser for the first (default) organization at
http://<server name>/sdk/list.aspx. You can access the different organization
metadata browsers by going to http://<servername>/<orgname>/sdk/list.aspx.
You can view the URL in the address bar of any record if Microsoft Dynamics
CRM is not running in Application mode; you can configure this in the System
Settings. If your deployment is in Application mode, you can either click F11 or
use Ctrl+N to open a new Internet Explorer window that will show the address
bar.

You can use URL Addressable forms to:
• Create new records. You can create new Microsoft Dynamics CRM
records from within another application by creating a link or opening
a window to the URL of the entity's form.
• Access existing records. You can use the same page to open an
existing record if you include a reference to the GUID for the record.
This is usually done by programmatically generating an HTML page
that concatenates the entity's URL with Microsoft Dynamics CRM
GUID values stored in another application.
• Copy and Send Shortcuts. For many entities you can copy and send
the URL of the entity's form by performing the ‘Copy Shortcut’ and
‘Send Shortcut’ actions from within Microsoft Dynamics CRM
application. These are available through the More Actions menu.
The URL can be formatted using:
• HTML Link. This approach opens a new window with the Internet
Explorer Menu, address bar, and any other items the user typically
has visible in Internet Explorer.
• Window.open() method. A better approach is to use a script that
uses the window.open() method and attach it to a button or any other
object the user can click. This allows you control over how the
window opens, including the size, position, and if the menu bars are
displayed.

Demonstration - URL Addressable Forms

This demonstration illustrates how to access specific Microsoft Dynamics CRM
forms using URLs.
Scenario
The Vice President of Sales is concerned that his sales team are not entering
Leads into Microsoft Dynamics CRM and would like to raise an Announcement
to highlight this.
In this Announcement, he would like to link to the Microsoft Dynamics CRM

form to create a new Lead.
Goal Description
Create a new Announcement which provides a hyperlink to a Microsoft
Dynamics CRM form.
Step by Step
Step 1: Create a new Announcement

then click Announcements.
2. Click New.
3. Enter the following details:
a. Title: Please enter all of your Leads into Microsoft Dynamics
CRM
b. Body: Please do not forget to enter all Leads into Microsoft
Dynamics CRM. To create a Lead, click the link below.
c. More Information URL:
http://crm/AdventureWorksCycle/sfa/leads/edit.aspx
Step 2: View Announcement
1. From the Navigation Pane, click Workplace, and then click

Announcements.
2. Display the newly created Announcement
3. Click the More Information link to open the New Lead form.

Introduction to Creating Custom Menus, Navigation Items,

and Buttons
Custom menus, navigation items, and buttons allow you to display or access
another application from within Microsoft Dynamics CRM. These
customizations are defined for the Web application and Microsoft Dynamics
CRM for Outlook by exporting the ISV.Config from the customization area,
editing it, and re-importing it.
WARNING: Improper modifications to configuration files such as ISV.Config

can cause serious problems that might cause your Microsoft Dynamics CRM
application to become inaccessible. Always take care to back up your
configuration files before making any modifications so that you will be able to
return to a known working configuration.
ISV.config is not a file that you can manipulate and save. Because the ISV.config
information is generated from the metadata, you must export the ISV.config
configuration just as you would any customizations that you want to move from
one deployment to another. However, in this case you will export the ISV.config
parameters, customize them, and then import them back into the application. The
following steps must be performed to customize the ISV.config:
1. Export the ISV.config using the Export customizations tool.

2. Modify the ISV.config XML configuration.
3. Import the revised ISV.config.xml file using the Import
Customization tool.
NOTE: When you use Notepad to open an XML document that has been
exported from Microsoft Dynamics CRM, it will not be formatted for
readability. Visual Studio allows you to apply formatting by using
Ctrl+K,Ctrl+D. With Microsoft Office Expression Web use the Reformat XML
(Alt+M) button from the XML View Toolbar.
As a best practice, you should back up the ISV.config that you export from
Microsoft Dynamics CRM before customizing it. This allows you to re-import
the backed up copy in case of errors. The import tool performs validations on the
ISV.config, but it is still possible that some errors could cause problems.
Because the ISV.config controls the Navigation Pane of the application, an error
in the ISV.config could cause the Navigation Pane to be unusable. In that case,
you will need to type the URL to the Import customization window. That URL
is: http://<server name>/tools/systemcustomization/
importcustomizations/importcustomizations.aspx.

NOTE: You can include the <orgname> after the <servername> bit to go to
the import screen for any particular organization’s import screen.
Enabling your Customizations

To enable your customizations, set the ISVIntegration setting in the System
Settings. The setting is provided for performance optimization. This was
discussed in the earlier training titled Configuring Organizational Settings. From
the Navigation Pane, click Settings, click Administration, click System
Settings, and then click the Customization tab.
The field titled “Select the clients that will display custom buttons and menu
items configured in ISV.Config.” allows you to select any combination of the
following client options:
• Web
• Outlook Workstation Client
• Outlook Laptop Client
ISV Extensions Privileges

After you have enabled your customizations, you need to set the ISV Extensions
privilege for any security roles that need to use the customizations. By default,
the security roles that do not represent a management position do not have ISV
Extensions privilege.
NOTE: Because the access rights and privileges a user enjoys are the union of
all the security roles they belong to, you can create a specialized role that only
grants ISV Extensions privilege. To control access to ISV extensions on an
individual basis, remove the ISV Extensions privilege from other roles and
assign this role to selected users along with their regular security role(s).
Perform the following steps to set the ISV Extensions privilege on a security
role:

2. Double-click the role that you want to edit.
3. Select the Customization Tab.
4. Under Miscellaneous Privileges, click the ISV Extensions privilege
to change it to Organization.

Demonstration - Integrating Applications

This demonstration illustrates how a custom application can be integrated into
Microsoft Dynamics CRM to provide additional functionality.
Scenario
Adventure Works Cycle has asked you to create some additional functionality for
Microsoft Dynamics CRM utilizing the Call Timer tool. You will need to follow
the developer's instructions to enable these customizations.
Call Timer
Call Timer allows a user to launch a window that contains a timer. This timer lets
the caller keep track of how long they are on the telephone and update the
duration field in Microsoft Dynamics CRM when they are done.
A custom button called Time this call is displayed on the Phone Call Menu bar.
When the Time this call button is pressed, it opens a page called Timer.htm.
When the user presses Start the timer will begin.
FIGURE 11.6 CRM PHONE CALL TIMER
When the phone call is over, the user can press OK and the time will be added to
the Duration field, rounded to the nearest minute.
In order to enable this customization you will need to:
• Back up your current ISV.Config.

• Add the Developer's files as a virtual directory for the Microsoft.
Dynamics CRM Web site.
• Import the ISV.Config that the developer has provided.
• Enable the customizations.
• Test the Phone Call timer feature.
• Give users the ISV Extensions Privilege.

Step 1: Backup your Current ISV.Config settings
1. From the Navigation Pane, click Settings, then click Customization,

2. In the list of exportable items, select ISV Config.
3. Click More Actions, and then click Export Selected
Customizations.
4. Click OK to acknowledge the dialog box describing what will be
5. The file download dialog box appears. Click Save.
6. In the Save As dialog box, in File name, enter ISVConfig. Click
Save.
7. Click Close.
Step 2: Add the Developer's Files as a Virtual Directory for the Microsoft
Dynamics CRM Web Site
1. From the Start menu, click All Programs, click Administrative

Tools, and then click Internet Information Services Manager.
2. Expand Web Sites on the Server LONDON.
3. Right-click on the Microsoft Dynamics CRM v4.0 web site.
4. Click on New, and then click Virtual Directory.
5. In the Virtual Directory Configuration Wizard, click Next.
6. On the Virtual Directory Alias page, enter CallTimer as the alias.
7. On the Web Site Content Directory page, click the Browse button,
select the following folder, and then click Next.:
C:\Class Materials\Customization\Ch.11\CallTimer
8. Click the box next to Run scripts (such as ASP), and then click
Next.
9. Click Finish.
10. In Internet Information Services (IIS) Manager, right-click on the
server name, then click All Tasks, and then click on Restart IIS.
11. Click OK on the confirmation dialog.
12. Wait until IIS restarts before beginning Step 3.
Step 3: Import the ISV.Config that the developer has provided
1. From the Microsoft Dynamics CRM Navigation Pane, click

Settings, click Customization, and then click Import
Customizations.
2. Click Browse and select the following file:
C:\Class Materials\Customization\Ch.11\CallTimer ISV
config.xml
3. Click Upload.
4. Click Import All Customizations.

Step 4: Enable the Customizations
1. Navigate to Settings, then Administration, then System Settings.

2. Choose the Customization tab.
3. In the section Custom menus and toolbars, ensure that all available
options are included.
Step 5: Test the Phone Call Timer Feature
1. In Microsoft Dynamics CRM, click New Activity, and select Phone

Call.
2. Confirm that the Time this call button is visible.
3. Test the application to confirm that it meets the behavior described in
the Scenario.
Step 6: Give Users the ISV Extensions Privilege (Optional)
For the purpose of this course you do not need to give users the ISV Extensions
Privilege. Because you are logged in as a user with the System Administrator
role, you will be able to view the custom buttons.

Introduction to ISV.Config Integration Points

You can add custom menus, side-tabs, and buttons in seven different places in
Microsoft Dynamics CRM. These can be grouped by:
• Application Level
• Detail Level
• Entity Grid Level
Application Level
There are two places you can add buttons or menus at the application level using
ISV.Config:
• Global Menu Bar. You can configure hierarchical menus to provide

choices for users in the Global Menu Bar.
• Application Level Tool Bar. You can configure buttons in the
Application Level Tool Bar.
These integration points are available in both the Web interface and the
Microsoft Dynamics CRM for Microsoft Office Outlook.
Detail Level
There are three places you can add menus, buttons, or navigation items at the
detail level using ISV.Config:
• Form menu bar. Add menus to the left of the Help menu.
• Form toolbar. Add buttons to the toolbar.
• Form navigation pane. Add navigation items in the Detail Form
navigation pane on the left.
FIGURE 11.7 ISV.CONFIG DETAIL LEVEL INTEGRATION POINTS
Detail level integration points exist for virtually every entity that has a detail
screen. This includes custom entities.

Entity Grid Level

A view contains a grid displaying rows of records. Buttons and Action Menu
items placed in the grid can access selected items in the grid and perform actions
on them. A developer can access the selected ID values in the grid. These ID
values can be used to reference the selected items when performing actions on
them using custom JScript code.
Entity Grid level controls include:
• Entity Grid buttons. These buttons appear to the left of the More
Actions menu.
• Entity Grid Action Menu. Additional items can appear to in the
More Actions menu. The More Actions menu supports sub-menus.

Demonstration - ISV.Config structure and custom button

This demonstration illustrates how to configure the isv.config to display a custom
button, navigation items and menu items in Microsoft Dynamics CRM.
IMPORTANT: If you completed Demonstration: Integrating Applications you

will need to return to your default isv.config to observe the sample
customizations in this demonstration.
Scenario
While developing customizations for the Account entity, you get tired of
navigating to the Account Entity Customization screen. To make this navigation
a little faster while you develop customizations, you create a button from the
Account form to take you directly to the Account Entity Customization window.
After you finish your customizations, you must remove the button so it will not
be accessible to users.
Goal Description
This demonstration has two goals:
• Familiarize you with the structure of the isv.config and the default
sample customizations.
• Create a custom button to launch the Account Entity Customization
window from the Account Form
Step by Step
Step 1: Enable Customizations

then click System Settings.
2. Select the Customization tab.
3. Locate the Custom Menus and Toolbars section and click the
lookup button.
4. Select all of the available values.
5. Click OK.
6. Click OK to save the System Settings.
7. Close and re-open Microsoft Dynamics CRM

8. Note the following Customizations:

a. In the Global Menu Bar there is an ISV menu with submenus
b. In the Application Toolbar there are three new buttons: Test,
Web Only and Both.
9. Navigate to the Accounts Grid and note the following

customizations:
a. Three buttons called Test, Test and Web Only
b. Three Additional Menu items under the More Actions menu:
Coming Soon, Sub test and Web Only.
IMPORTANT: If you completed Demonstration: Integrating Applications, you

need to return to the default isv.config that you saved during Step 1 of that
demonstration.
Step 2: Export isv.config

2. Select the ISV Config
3. On the Actions toolbar, click select Export Selected
Customizations.
4. Click OK to acknowledge the dialog box describing what will be
exported.
5. The file download dialog box appears. Click Save.
6. In the Save As dialog box, enter ‘ISVConfig’ in File name. Click
Save.
7. Click Close.
8. Make a copy of the ISVConfig.zip file and rename to
ISVConfigBackup.zip.
9. Open the ISVConfig.zip file.
10. Extract the customizations.xml file to a convenient location.
NOTE: In a deployment you should copy the ISVConfigBackup.zip file to a

location where they would be preserved in case of a catastrophic failure of the
server.
Step 3: Examine isv.config
1. Navigate to the customizations.xml file and open it with Internet

Explorer.
2. Internet Explorer will restrict the file from opening active content.
Click the information bar at the top and select <b>Allow Blocked
Content</strong>. Then click <b>Yes</strong> in the Security
Warning dialog.

3. Collapse the <Root>,<Entity> and <ServiceManagement> nodes to

see the structure of the document.
4. Expand the Root Node and locate the <CustomMenus> node.
5. Compare the <Menu> and <SubMenu> nodes with the custom ISV
menus in the Application Menu bar.
6. Locate the <ToolBar> element and compare the <Button> elements
with the buttons you see in the Microsoft Dynamics CRM
application level toolbar.
NOTE: One of the buttons <Button Icon=“/_imgs/ico_18_debug.gif”

JavaScript=“alert('test‘);” Client=“Outlook” AvailableOffline=“true”> is not
visible in the web application because the Client Attribute specifies “Outlook”.
7. Expand the <Entities> Node and locate the <Entity

name=”account”>.
8. Note the <MenuBar>,<ToolBar>,<NavBar> and <Grid> nodes and
compare them to the custom menus, buttons and side tabs you see in
the Account Form and the Account Grid.
Step 4: Get the URL for Account Entity Customization.

2. Press CTRL+N to open a new window. This will expose the address
bar so you can see the URL to this page. It should look something
like this:
http://crm/AdventureWorksCycle/Tools/SystemCustomization/Entiti
es/manageEntity.aspx?entityId={70816501-EDB9-4740-A16C-
6A5EFBC05D84}
(http://crm/AdventureWorksCycle/Tools/SystemCustomization/Entit
ies/manageEntity.aspx?entityId={70816501-EDB9-4740-A16C-
6A5EFBC05D84})NOTE: The GUID for your deployment will be
unique. You cannot use the one in the sample above.
3. Copy this URL and paste it into Notepad. You will need it in the next
step.

Step 5: Implement a custom button on the Account Object.
In this step you use the approach of copying an existing XML element from your
isv.config customization file, pasting it into a different location, and modifying
the attributes.
1. Open the customization.xml file using a text editor such as Notepad.

2. In the <Entities><Entity name=“account”> area of the document,
copy the entire element containing the button called Test. The text
should appear like this:
FORMAT IN BOX
<Button Icon=“/_imgs/ico_18_debug.gif”
Url=“http://www.microsoft.com” PassParams=“1” WinParams=“”
WinMode=“1”>
<Titles>
<Label LCID=“1033” Text=“Test” />
</Titles>
<ToolTips>
<Label LCID=“1033” Text=“Info on Test” />
</ToolTips>
</Button>
3. Paste this element below the “Outlook Only” button element.

4. Modify the following attributes of the Button elements:
FIGURE 11.8 ACCOUNT BUTTON ATTRIBUTES
NOTE: It can be difficult to edit a very long line of text. You can add carriage
returns after each attribute to make editing easier. XML ignores this type of
formatting.

5. Save your Customizations.xml file.

7. Click the Browse button and select the Customizations.xml file.
8. Click the Upload button.
9. Click the Import All Customizations button.
10. Navigate to an existing Account and look for the Account
Customization button. Confirm that it launches the Account Entity
Customization form.

Introduction to SiteMap
It is possible to achieve granular oversight of the controls placed in the
Navigation Pane by modifying the SiteMap entity.
The following are examples of how you can customize the Navigation Pane by
customizing the SiteMap:
• Create a Home Page with a custom page or dashboard

• Customize Workplace profiles to better match with user
responsibilities
• Add custom entities and display them at particular locations in the
Navigation Pane.
• Remove an unused top level Area.
• Add a new top level Area.
When you add a custom entity, you can configure where it appears in the
Navigation Pane. The Go To menu and User Settings for the Start Page of the
web client can also be customized to reflect the navigation areas and sub-areas
defined in the SiteMap. This information is stored in the application metadata.
SiteMap combines the information in the metadata to generate the Navigation
Pane.
When you add new entities to the metadata, the order in which they are displayed
is the order in which they were entered. However, you can override this default
placement by customizing the SiteMap and specifying the exact location of the
entities.
NOTE: The SiteMap only defines the Application Navigation Pane. The form
for each entity also has a similar navigation pane, but this is defined in the
ISV.Config.
SiteMap also allows organizations to configure custom workplace profiles that

users can select. Some of these have already been included in Microsoft
Dynamics CRM. The existing Workplace profiles include:
• Sales
• Marketing
• Customer Service
• Scheduling
All of these groups and profiles are customizable through the SiteMap. You can
add, remove, modify, and rename profiles to best meet the needs of the CRM
users.

The Areas, Workplace Groups, and Sub-Areas defined in the SiteMap are also
reflected in the Outlook folder hierarchy under the Microsoft Dynamics CRM
folder. Note that Microsoft Dynamics CRM for Outlook represents the folders
alphabetically, and the order defined in the SiteMap does not apply.
Configuring the SiteMap Attribute

SiteMap is not a file that you can manipulate and save. Because the SiteMap
information is generated from the metadata, you must export the SiteMap
configuration just like any other customizations that you want to move from one
deployment to another. However, in this case you will export the SiteMap
parameters, customize them, and then import them back into the application. The
following steps must be performed to customize the SiteMap:
1. Export the SiteMap using the Export customizations tool.

2. Modify the SiteMap's XML configuration.
3. Import the revised SiteMap's .xml file using the Import
Customization tool.
NOTE: When you use Notepad to open an XML document that has been
exported from Microsoft Dynamics CRM, it will not be formatted for
readability. Visual Studio allows you to apply formatting by using
Ctrl+K,Ctrl+D. With Microsoft Office FrontPage use the Reformat XML
(Alt+M) button from the XML View Toolbar.
Recovering From Errors

As a best practice, back up the SiteMap .xml file that you export from Microsoft
Dynamics CRM before customizing it. This allows you to re-import the backed
up copy in case of errors. The import tool performs validations on the SiteMap,
but it is still possible that some errors may cause problems.
Because the SiteMap controls the Navigation Pane of the application, an error in
the SiteMap can cause the Navigation Pane to be unusable. In that case, you will
need to type the URL to the Import customization window. That URL is:
http://<server name>/tools/systemcustomization/
importcustomizations/importcustomizations.aspx.
NOTE: As with the earlier comment about the metadata browser, you can
include the <orgname> after the <servername> bit to go to the import screen
for any particular organization’s import screen.

SiteMap Structure
The following figure displays the structure of the SiteMap.
FIGURE 11.9 SITEMAP STRUCTURE
Each element in SiteMap has attributes to control the behavior and appearance of
the element. SiteMap has five different elements:
• SiteMap
• Area
• Group
• Sub-area
• Privilege
SiteMap
SiteMap is the root node for the SiteMap. The SiteMap element appears as
follows in the XML:
<SiteMap Url=“/Home/home_home.aspx” >
Area
The Area controls the individual panes found in the Navigation pane. The Sales
Area element appears as follows in the XML:
<Area Id=“SFA” ResourceId=“Area_Sales”>

The following figure shows six areas displayed in the Navigation pane of the
Web application.
FIGURE 11.10 AREAS IN THE NAVIGATION PANE
New areas can be added or existing areas can be removed. However, removing
the Settings area is not recommended; instead, use permissions to control access
to the Settings area. You can override the default labels by using the Title
attribute to specify the Label value you want. You can change the Icon to point to
a different image and can specify how different groups are displayed within the
area.
Group
Groups organize elements in the workplace area of the navigation pane. For
example, the Sales group includes the Leads, Opportunities, Quotes, Orders, and
Invoices. The Sales Group element appears as follows in the XML:
<Group Id=“SFA” ResourceId=“Area_Sales” IsProfile=“true”>

<SubArea Id=“nav_leads” Entity=“4” />
<SubArea Id=“nav_oppts” Entity=“3” />
<SubArea Id=“nav_quotes” Entity=“1084” />
<SubArea Id=“nav_orders” Entity=“1088” />
<SubArea Id=“nav_invoices” Entity=“1090” />
</Group>
The following figure shows how the Sales group appears in the Navigation Pane.
FIGURE 11.11 SALES GROUP AREA

Groups are used to aggregate Sub-Areas and can be shown or hidden as defined
by the Area. Additionally, groups defined within the Workplace Area can be
marked as a user selectable profile.
Sub-area
Sub-areas represent the items in the Navigation pane that show new content in
the main frame of the application. The Knowledge Base Sub-Area element
appears as follows in the XML:
<SubArea Id=“nav_managekb” ResourceId=“Homepage_KBManager”

Icon=“/_imgs/ico_18_126.gif” Url=“/cs/home_managekb.aspx”
Client=“Web”>
<Privilege Entity=“kbarticle” Privilege=“Read,Write,Create” />
</SubArea>
The following figure shows what the Knowledge Base Sub-area looks like in the
Navigation Pane of the Web application.
FIGURE 11.12 KNOWLEDGE BASE SUB-AREA

Demonstration - Apply Site Map Customizations

This demonstration illustrates how SiteMap is use to control the appearance of
Scenario
Adventure Works Cycle wants to modify the way that information is organized in
the Navigation pane. They have a group that focuses on service scheduling and
another group that provides technical support. They want to separate these areas
from the Service area.
Goal Description
Scheduling Area
A new area called Scheduling will be displayed beneath the current Service area.
The Scheduling area will display the Service calendar and a link to the Services
Management area which is normally found under the Service module.
Support Area
The Service area will be renamed Support to match the terminology used at
Adventure Works Cycle. The Service Scheduling sub-area will be removed from
this area.
Step by Step
Step 1: Export and Backup the SiteMap

2. Select SiteMap.
3. On the Action toolbar, click More Actions, and then click Export
Selected Customizations.
4. Save the zipped configuration file to the following location:
C:\Class Materials\Customization\Ch.11\Exported SiteMap.zip.

5. Open the Exported SiteMap.zip file.
6. Extract the customizations.xml file to a convenient location.

Step 2: Examine the Exported SiteMap
1. Open the customizations.xml file using Internet Explorer.

2. Expand and contract the nodes to understand the structure of the
document.
3. Note the structure of:
SITEMAP→AREA→GROUP→SUB-AREA.
Compare this to the Navigation Pane in Microsoft Dynamics CRM.
Step 3: Import the New Site Map

2. Browse to the following file:
C:\Class Materials\Customization\Ch.11\New SiteMap.xml
3. Click <b>Upload</strong>.
4. Click <b>Import All Customizations</strong>.
Step 4: Confirm Customizations
1. Press F5 to refresh Microsoft Dynamics CRM.

2. Confirm that the Scheduling area exists and that it allows access to
the Service Calendar and the Services Definition.
3. Confirm that the Support area exists and does not include the Service
Calendar.
Step 5: Review New SiteMap.xml
1. Open the New SiteMap.xml file that you just imported using
Internet Explorer.
2. Note the changes that were made to create new areas.

Introduction to SDK Capabilities

The term Software Development Kit, or SDK, is often used to refer to both the
documentation and the framework by which solutions are created. The Microsoft
Dynamics CRM SDK is strictly documentation. It describes the different
Application Programming Interfaces (APIs) that allow a developer to interact
with another application from within Microsoft Dynamics CRM. The APIs in the
Microsoft Dynamics CRM platform are exposed as .NET web services, so they
are likely familiar with a wide range of developers.
SDK Components
There are three parts to the SDK:
• Server Programming Guide. The focus of this area is on working

with the Microsoft Dynamics CRM platform.
• Client Programming Guide. The Client Programming Guide
includes much of the information that has been presented thus far in
this training, although at a more detailed level.
• Report Writers Guide. This guide describes information a person
needs to modify standard Microsoft Dynamics CRM reports or create
new Microsoft SQL Reporting Services reports for Microsoft
Dynamics CRM.
Server Programming Guide Scope

The Server Programming Guide focuses on creating solutions that interact with
the Microsoft Dynamics CRM platform. The core of the Server Programming
Guide is the following reference material that describes the methods used to
interact with the platform:
• Web Services. All the Microsoft Dynamics CRM APIs are

accessible through web services. These web services include Web
Service Definition Language (WSDL - pronounced “Whiz-dul”)
definitions, which provide a development experience similar to using
the standard .NET assemblies that developers are accustomed to.
• Sample Code. The Server Programming Guide provides many

examples and even some sample solutions to show how to use the
Microsoft Dynamics CRM methods.
If the information you need is not in the SDK, it is generally not supported. For
example, the SDK does not include information about how to access the inner
workings of Microsoft Dynamics CRM for Outlook or the Microsoft Dynamics
CRM Web application.

Server Programming Guide Capabilities

Some of the tasks that can be performed using the SDK include:
• CRUD APIs. “CRUD” is a term that refers to methods to “Create,

Retrieve, Update, and Delete” records. These are the most common
types of methods relating to Microsoft Dynamics CRM objects.
• Query. Microsoft Dynamics CRM also includes powerful
capabilities to create queries. You can see this capability in the
Advanced Find tool.
The Server Programming Guide documents the APIs that developers

can use when querying the Microsoft Dynamics CRM platform in
their own applications.
• Plug-ins. To enable deep integrations with other applications,
Microsoft Dynamics CRM supports a plug-in model. This allows a
developer to create listeners for specific events occurring in the
platform.
The Microsoft Dynamics CRM Plug-in model allows both Pre and
Post-Plug-ins. Pre-Plug-in code is run before an operation occurs,
whereas Post-Plug-in code is run after an operation has been
completed. Plug-in components can be written in any .NET
compliant language such as C# and VB.NET. Component assemblies
are defined in an XML based configuration file on the Microsoft
Dynamics CRM server. This configuration file determines which
methods are tied to which entity events.
• Metadata Service. Because of Microsoft Dynamics CRM's ability to
be extended, the entities and attributes available at each deployment
might be different. The Metadata Service provides the ability for a
developer to read the current definition of the platform metadata.
This information is usually cached and referenced in code.
• Workflow .NET Assemblies. The Server Programming Guide
contains details about how to create and configure .NET assemblies
for Workflow.
Microsoft Dynamics CRM External Connector License

The External Connector License is only necessary when external users access
data. The term “external users” means that users are not:
• The organization's employees

• The organization's contractors or agents
• Employees of a company affiliated to the organization
• Contractors or agents of a company affiliated with the organization
For example, an organization cannot set up an external connector license for

users in a call center environment.

Example A - License required
An organization must have an External Connector License if it wants to create a

web site where the organization's customers can view and maintain their contact
information that is stored in Microsoft Dynamics CRM.
Example B - License not required
An External Connector License is not required if an organization wants to create

a web site that only displays a form that allows the public to enter information
that will be saved in Microsoft Dynamics CRM. The key difference is that in
Example A, the external users have access to Microsoft Dynamics CRM data. In
Example B, external users will enter data that is saved in Microsoft Dynamics
CRM, but they do not have access to Microsoft Dynamics CRM data.
ISV Solutions
Many Independent Software Vendors (ISVs) have developed solutions that
extend Microsoft Dynamics CRM. ISV solutions can be found at the following
locations:
• In the Microsoft Dynamics CRM website available from the Help

menu in the Web Application.
• At the following web site: https://solutionfinder.microsoft.com/
For organizations planning to invest in an ISV solution, it is important that the

solution use only supported methods. ISVs can earn the “Designed for Microsoft
Dynamics CRM” Certification by submitting their solution for testing. This
certification checks for use of supported methods, not suitability of purpose.

Summary
This training described Microsoft Dynamics CRM features that enable
application integration. There will be times when the basic customization
features may not be enough to meet a particular requirement, or when other
applications simply need to be made more easily accessible from within
The ability to extend functionality to include other applications, or just bring

other applications together, provides the opportunity to make Microsoft
Dynamics CRM into an efficient portal for users. The following additions help
make the system straightforward for the user:
• Integrations can be made at the form level through the use of

IFrames and ISV.Config.
• Application Navigation can be modified using ISV.Config.
• Custom menus, buttons, and navigation areas can be added
throughout the application.
• Other applications can be configured to allow Microsoft Dynamics
CRM users to access Microsoft Dynamics CRM Forms through URL
Addressable forms.
ISVs provide a variety of add-on products for Microsoft Dynamics CRM. These
products will use the application integration features with their solutions;
however, you do not need to be an ISV to use them. You may need to work with
a developer to create a solution that you will manually integrate with Microsoft
Dynamics CRM using these features. Knowledge of how these features are
integrated can help you troubleshoot problems that may arise and help you
provide greater value to the organizations where you customize Microsoft
Dynamics CRM.

Test Your Knowledge

1. When is client-side code better than workflow? Choose all that apply. (Select
all that apply.)
( ) When the same logic needs to be applied regardless of where the
transaction originates.
( ) When the logic depends on user actions.
( ) When logic needs to be implemented by someone who is not a developer.
( ) When latency is unacceptable
2. You want to include logic that will check existing values in a form and
perform a calculation in another field. The information in the fields may
change due to actions taken in Workflow. What event should you use to
include this logic?
( ) Field OnChange Event
( ) Form OnSave Event
( ) Form OnChange Event
( ) Form OnLoad event
3. You want to include logic that will respond to user input to a particular field.
When the value in the field is modified, a calculation will need to be
performed to update another field. What event should you use to include this
logic?
4. You have some validation logic that you want to apply. This logic will make
sure that information has been provided in all the fields that require it. The
fields that may require data change, so they have not been set as "Business
Required." What event should you use to include this logic?

5. You are working with a developer who is new to Microsoft Dynamics CRM
and have explained how to include client-side code. This developer feels that
this process is will hinder his work and strongly recommends modifying the
.aspx pages so that he can link to .js files where he can develop his
customizations in the manner he is accustomed. Other than the fact that this
is not supported, why should he not do this? Choose all that apply. (Select all
that apply.)
( ) The customizations will be overwritten during an upgrade or if Microsoft
Dynamics CRM needs to be re-installed.
( ) It will not be possible to export or import the customizations.
( ) The customizations will not work for Microsoft Dynamics CRM for
Outlook when it is offline.
( ) It will not work.
6. What conditions must be met for the OnChange event to be triggered?

Choose all that apply. (Select all that apply.)
( ) The user must put their cursor in the field.
( ) The data in the field must change.
( ) Existing value must be deleted.
( ) The user must move their cursor out of the field.
7. You add code to an event, but when you test it in the preview window,
nothing happens. What is the likely reasons for this?
( ) You forgot to enable the event.
( ) There is a syntax error in your code.
( ) You have not published your form customizations.
( ) You have not saved your form customizations.
8. Why do you configure an IFrame to pass parameters?

( ) It will prevent cross-frame scripting.
( ) It will allow the web application at the Target URL to perform a lookup in
the Microsoft Dynamics CRM platform to get a reference to a Microsoft
Dynamics CRM record.
( ) You will want to view these parameters when using the IFrame.
( ) These parameters will identify the user and this information can be used to
restrict access to the information displayed in the IFrame.


chapter:
1.
2.
3.

Solutions
Test Your Knowledge
1. When is client-side code better than workflow? Choose all that apply. (Select
all that apply.)
( ) When the same logic needs to be applied regardless of where the
transaction originates.
(√) When the logic depends on user actions.
( ) When logic needs to be implemented by someone who is not a developer.
(√) When latency is unacceptable
2. You want to include logic that will check existing values in a form and
perform a calculation in another field. The information in the fields may
change due to actions taken in Workflow. What event should you use to
include this logic?
(•) Form OnLoad event
3. You want to include logic that will respond to user input to a particular field.
When the value in the field is modified, a calculation will need to be
performed to update another field. What event should you use to include this
logic?
(•) Field OnChange Event
4. You have some validation logic that you want to apply. This logic will make
sure that information has been provided in all the fields that require it. The
fields that may require data change, so they have not been set as "Business
Required." What event should you use to include this logic?
(•) Form OnSave Event

5. You are working with a developer who is new to Microsoft Dynamics CRM
and have explained how to include client-side code. This developer feels that
this process is will hinder his work and strongly recommends modifying the
.aspx pages so that he can link to .js files where he can develop his
customizations in the manner he is accustomed. Other than the fact that this
is not supported, why should he not do this? Choose all that apply. (Select all
that apply.)
(√) The customizations will be overwritten during an upgrade or if Microsoft
Dynamics CRM needs to be re-installed.
(√) It will not be possible to export or import the customizations.
(√) The customizations will not work for Microsoft Dynamics CRM for
Outlook when it is offline.
( ) It will not work.
6. What conditions must be met for the OnChange event to be triggered?

Choose all that apply. (Select all that apply.)
( ) The user must put their cursor in the field.
(√) The data in the field must change.
( ) Existing value must be deleted.
(√) The user must move their cursor out of the field.
7. You add code to an event, but when you test it in the preview window,
nothing happens. What is the likely reasons for this?
(•) You forgot to enable the event.
( ) There is a syntax error in your code.
( ) You have not published your form customizations.
( ) You have not saved your form customizations.
8. Why do you configure an IFrame to pass parameters?

( ) It will prevent cross-frame scripting.
(•) It will allow the web application at the Target URL to perform a lookup
in the Microsoft Dynamics CRM platform to get a reference to a
Microsoft Dynamics CRM record.
( ) You will want to view these parameters when using the IFrame.
( ) These parameters will identify the user and this information can be used to
restrict access to the information displayed in the IFrame.


Appendix A: Permissions Required For Customization Tasks
APPENDIX A: PERMISSIONS REQUIRED FOR

CUSTOMIZATION TASKS
Customization tasks generally require the default System Administrator or System Customizer security roles. Some other
default security roles also provide privileges to perform certain customization tasks or provide access to certain
customizations. The following table shows the privileges necessary to perform each task or to have access to certain
customizations. Customization tasks are never performed while using the Microsoft Dynamics CRM for Outlook offline.
Customization Tasks Default Security Roles and Required Comments

Privileges
Access customization area Security roles: The Entity Read privilege controls access
System Administrator to the customization area.
System Customizer
CEO-Business Manager
Customer Service Manager
Marketing Professional
Marketing Manager
Vice President of Marketing
Sales Manager
Vice President of Sales
Privilege:
Entity: Read
Publish customizations Security roles: Customizations that change the schema
System Administrator must be published. The Publish
System Customizer Customizations privilege is separate from
other customization privileges because it
Privilege: Publish Customizations allows user-interface elements to be
customized by several people but
published only by someone who has
reviewed the customizations.
Customize entities Security roles:
These privileges allow you to change the
System Administrator
Display Name of the entity. Modification
System Customizer
of the entity attributes, form, views, or
messages require additional privileges.
Privileges:
Entity: Read Editing entity messages requires the
Entity: Write privilege:
Form: Organization Write.
Create custom entities Security roles: These privileges allow you to create a
System Administrator custom entity. Modification of the entity
System Customizer attributes, form, views, or messages
require additional privileges.
Privileges:
Entity: Read
Entity: Create
Entity: Write
A-1

Privileges
Set privileges for custom entities Example Privileges
When a custom entity is created, the
<Custom Entity>: Create
access level is set to None for all
<Custom Entity>: Read
privileges in all security roles other than
<Custom Entity>: Write
System Administrator and System
<Custom Entity>: Delete
Customizer. Change the access level as
<Custom Entity>: Append
appropriate to enable other users to use
<Custom Entity>: Append To
custom entities.
<Custom Entity>: Assign
<Custom Entity>: Share The settings shown here are default
privileges for core user-owned entities
Security roles: that store customer data. These settings
System Administrator represent a common pattern for user-
System Customizer owned entities.
Organization-owned custom entities do

not have the Assign or Share privilege.
Export customizations Security roles:

You are able to export only
customizations and settings for which
System Customizer
you have read privileges.
Privilege: Export Customizations To export ISV.Config you must have the

ISV Extensions privilege.
Import customizations Security roles:

Some customizations must be published
after they are imported before they are
System Customizer
available to users.
Privilege: Import Customizations You are able to import only

customizations and settings for which
you have read, create, and write
privileges.
Only the System Administrator can

import security role definitions or
organizational settings.
Modify entity attributes Security roles: These privileges allow for modification of
System Administrator existing entity attributes only. Creation
System Customizer of new attributes requires additional
privileges.
Privileges:
Entity: Read
Attribute: Read
Attribute: Write
A-2 Microsoft Official Training Materials for Microsoft Dynamics ™


Privileges
Create entity attributes Security roles: New entity attributes are not visible to
System Administrator users until they have been added to the
System Customizer entity form. Modifying the entity form
requires the Form: Write privilege.
Privileges:
Entity: Read
Attribute: Read
Attribute: Write
Attribute: Create
Edit entity relationships Security roles: These privileges allow for modification of
System Administrator existing entity relationships only. This
System Customizer includes the ability to create new
mappings. Creation of new entity
Privileges: relationships requires additional
Entity: Read privileges.
Relationship: Read
Relationship: Write
Create entity relationships Security roles: New entity relationships cannot be used
System Administrator until the relationship attribute is added
System Customizer to the related entity form. Modifying the
entity form requires the Form: Write
Privileges: privilege.
Entity: Read
Relationship: Read
Relationship: Write
Relationship: Create
Use custom entity relationships Security roles:
At a minimum, users must have User
Depends on the entities participating in
level access to the records
the relationship.
participating in the relationship.
Privileges: Users with the Create privilege on the

primary entity record: Read related entity record will be able to
primary entity record: Append create new associated records from the
primary entity.
related entity record: Read
related entity record: Write
related entity record: Append To
related entity record: Create
Modify entity forms Security roles: Form: Read privilege is set to
System Administrator Organization and cannot be changed.
System Customizer
Privileges:
Entity: Read
Form: Write
A-3

Privileges
Modify system views Security roles:
These privileges allow for modification of
existing views only. Creation of new
System Customizer
views requires additional privileges.
Customer Service Manager The View: Read privilege is set to
Marketing Professional Organization and cannot be changed.
Marketing Manager
Sales Manager
Privileges:
Entity: Read
View: Write
Create system views Security roles:
The View: Read privilege is set to
Organization and cannot be changed.
System Customizer
Marketing Professional
Marketing Manager
Sales Manager
Privileges:
Entity: Read
View: Write
View: Create
Delete system views Security roles:
The View: Read privilege is set to
Organization and cannot be changed.
System Customizer
Marketing Manager
Sales Manager
Privileges:
Entity: Read
View: Delete


Privileges
View client extensions Security roles: This privilege grants users the ability to
System Administrator see client extensions configured using
System Customizer ISV.Config.
Marketing Manager
Sales Manager
Privilege: ISV Extensions

Edit entity messages Security roles:
System Customizer
Privileges:
Entity: Read
Entity: Write
Form: Write
Download Web Services Description Security roles: The entity Read privilege is necessary
Language files System Administrator only to gain access to the URLs in the
System Customizer customization area. It is not necessary to
download the Web Services Description
Privilege: Entity: Read Language files.
A-5

Index
INDEX
1-to-Many relationships.............................8-2, 8-3 Managing users............................................... 3-2

Access levels ............................................2-4, 2-6 Manual N :N relationship ................................. 8-4
Active Directory................................................3-3 Many-to-1 Relationship ................................... 8-3
Add a business unit..........................................1-6 Many-to-Many relationship .............................. 8-4
Add Users wizard.............................................3-7 Microsoft Dynamics CRM architecture ............ 5-6
Adding a custom attribute ................................7-3 Microsoft Dynamics CRM security model........ 2-2
Adding a single user ........................................3-6 MUI language pack ....................................... 4-21
Application event programming .....................11-2 Multicurrency ................................................. 4-32
Auto Numbering.............................................4-15 Multilingual User Interface (MUI)................... 4-21
Base language ...............................................4-22 Multi-tenancy ........................................ 10-1, 10-2
Business Unit access.....................................2-10 Native N :N relationship................................... 8-4
Business units..................................................1-2 None access level ........................................... 2-8
Cascading ........................................................8-8 Organization access...................................... 2-12
Child business units.........................................1-5 Parent:Child Business Unit access ............... 2-11
Client extensions............................................11-2 Parent Business Unit....................................... 1-5
Client-side code .............................................11-9 Personal views .............................................. 6-31
Configuration database..................................10-4 Preview form ................................................. 6-15
Copy an existing role .....................................2-22 Privileges.................................................. 2-3, 2-4
Create a new role...........................................2-23 Public views................................................... 6-30
Create a new team.........................................3-19 Publishing...................................................... 5-18
Creating a custom entity ................................7-21 Relationship Behavior ..................................... 8-7
Customizing an existing view.........................6-35 Renaming a customizable entity ..................... 9-1
Deployment Administrators..........................10-17 Reorganizing a business unit .......................... 1-7
Deployment Manager.....................................10-1 Role-based security model.............................. 2-2
Disabling a business unit .................................1-7 Root business unit........................................... 1-2
Enable the MUI pack......................................4-23 Security role .................................................. 2-12
Enabling a disabled business ..........................1-8 SiteMap ....................................................... 11-48
Entity mapping ...............................................8-42 System Administrator role ............................. 2-16
Exchange rates..............................................4-34 System Settings .............................................. 4-2
Export customizations....................................5-21 System views ................................................ 6-30
Export/import..................................................5-19 Task-based privileges ..................................... 2-6
Field events..................................................11-16 Teams ........................................................... 3-18
Filtered views...................................................5-9 Types of customizations................................ 5-11
Fiscal year settings ........................................4-16 Types of entities .............................................. 7-2
Form customization..........................................6-3 Types of views............................................... 6-30
Form events.................................................11-15 Unsupported relationships............................... 8-7
Form Preview.................................................6-15 URL Addressable forms .............................. 11-33
Implementation methodology...........................5-2 User access..................................................... 2-9
Import Organization .......................................10-7 User authentication ......................................... 3-3
Importing customizations ...............................5-23 User licenses................................................... 3-3
Intersect entity..................................................8-5 User maintenance ........................................... 3-4
ISV.Config....................................................11-36 Workflow........................................................ 11-2
Manager...........................................................3-9 System Customizer role ................................ 2-17
Microsoft Official Training Materials for Microsoft Dynamics ™ Page i

Page ii Microsoft Official Training Materials for Microsoft Dynamics ™


8912-En Customization and Configuration Student Manual

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

8912-En Customization and Configuration Student Manual

Hochgeladen von

Copyright:

Verfügbare Formate

COURSE 8912:

CUSTOMIZATION AND CONFIGURATION IN

Microsoft Official Training Materials for Microsoft Dynamics ™

Microsoft Official Training Materials for Microsoft Dynamics ™

Introduction to Customization and Configuration in Microsoft

Microsoft Official Training Materials for Microsoft Dynamics ™ Page i

Chapter 4: Configuring Organizational Settings 4-1

Page ii Microsoft Official Training Materials for Microsoft Dynamics ™

Quick Interaction: Lessons Learned .................................................................6-53

Microsoft Official Training Materials for Microsoft Dynamics ™ Page iii

Page iv Microsoft Official Training Materials for Microsoft Dynamics ™

INTRODUCTION TO CUSTOMIZATION AND

Microsoft Official Training Materials for Microsoft Dynamics ™ 0-1

0-2 Microsoft Official Training Materials for Microsoft Dynamics ™

Microsoft Certified Business Management Solutions

Microsoft Certified Business Management Solutions

Certification Exam Preparation Guides

• The target audience

Microsoft Official Training Materials for Microsoft Dynamics ™ 0-3

Certification Exam Preparation Guides help you determine which learning

NOTE: For more information on E-Learning, instructor-led training, training materials

Elements of Training Materials for Microsoft Dynamics

Test your Knowledge

0-4 Microsoft Official Training Materials for Microsoft Dynamics ™

Quick Interaction: Lessons Learned

Microsoft Official Training Materials for Microsoft Dynamics ™ 0-5

About This Training Material

0-6 Microsoft Official Training Materials for Microsoft Dynamics ™

• URL Addressable Forms

At Training Material Completion

Microsoft Official Training Materials for Microsoft Dynamics ™ 0-7

List three main objectives below.

0-8 Microsoft Official Training Materials for Microsoft Dynamics ™

CHAPTER 1: CREATING YOUR ORGANIZATIONAL

• Identify why an organizational hierarchy is defined in Microsoft

This training examines how to set up your organizational structure by

Microsoft Official Training Materials for Microsoft Dynamics ™ 1-1

When defining your organizational structure in Microsoft Dynamics CRM, you

Root Business Unit

• There is only one root business unit in Microsoft Dynamics CRM.

1-2 Microsoft Official Training Materials for Microsoft Dynamics ™

• The name of the root business unit cannot be changed.

FIGURE 1.1 ROOT BUSINESS UNIT

All other Business Units

FIGURE 1.2 BUSINESS UNIT MAINTENANCE RESTRICTIONS

Microsoft Official Training Materials for Microsoft Dynamics ™ 1-3

Caution - Creating Business Units

• Accept the misspelled name in your organizational structure

BEST PRACTICE: When creating the organization hierarchy, it is important

Managing Business Units

• Follow an implementation methodology when you plan and

• Use an existing organization chart when defining your business units

1-4 Microsoft Official Training Materials for Microsoft Dynamics ™

• Consider naming conventions, future reorganizations, and any other

Guidelines for Maintaining Business Units

WARNING: Double-check spelling and naming of the business unit before

Microsoft Official Training Materials for Microsoft Dynamics ™ 1-5

Creating a Business Unit

1. From the Navigation Pane, click Settings, click Administration,

Maintaining a Business Unit

1. From the Navigation Pane, click Settings, click Administration,

4. Click Save or Save and Close.

1-6 Microsoft Official Training Materials for Microsoft Dynamics ™