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

Page i

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 Test Your Knowledge .......................................................................................3-27 Quick Interaction: Lessons Learned.................................................................3-29 Solutions...........................................................................................................3-30


Customization and Configuration in Microsoft Dynamics™ CRM 4.0

Page ii

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 Test Your Knowledge .......................................................................................4-54 Quick Interaction: Lessons Learned.................................................................4-56 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 Test Your Knowledge .......................................................................................5-31 Quick Interaction: Lessons Learned.................................................................5-33 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 Test Your Knowledge .......................................................................................6-51


Table of Contents

Page iii

Quick Interaction: Lessons Learned.................................................................6-53 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 Test Your Knowledge .......................................................................................7-41 Quick Interaction: Lessons Learned.................................................................7-43 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 Test Your Knowledge .......................................................................................8-67 Quick Interaction: Lessons Learned.................................................................8-70 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 Test Your Knowledge .......................................................................................9-15 Quick Interaction: Lessons Learned.................................................................9-17 Solutions...........................................................................................................9-18

Chapter 10: Maintaining Organizations Through Deployment Manager10-1 Objectives.........................................................................................................10-1



Page iv

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


Introduction

0 - 1

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.



0 - 2

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.


Introduction

0 - 3

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



0 - 4

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

0 - 5

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.



0 - 6

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

0 - 7

• 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.



0 - 8

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

1-1

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.



1-2

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.



1-3

• 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



1-4

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.



1-5

• 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.



1-6

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.



1-7

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.



1-8

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.



1-9

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



1-10

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.



1-11

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.



1-12

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.



1-13

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.



1-14

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



1-15

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?



1-16

Quick Interaction: Lessons Learned Take a moment and write down three key points you have learned from this chapter:

1.

2.

3.



1-17

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.




1-18

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

2-1

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.



2-2

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.



2-3

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



2-4

• 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.



2-5

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



2-6

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



2-7

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



2-8

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



2-9

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



2-10

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



2-11

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



2-12

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.



2-13

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



2-14

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.



2-15

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.



2-16

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.



2-17

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.



2-18

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.



2-19

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.



2-20

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.



2-21

• 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.



2-22

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.



2-23

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:


2. On the Actions toolbar, click New. 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.



2-24

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.



2-25

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.



2-26

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, then click Security Roles.

2. On the Actions toolbar, click New. 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.



2-27

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.




2-28

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, then click Business Units.

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. 5. Click Save and Close. 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.



2-29

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.



2-30

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.



2-31

Need a Little Help?


Step 1 - Copy the Marketing Professional role


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


2. From the Navigation Pane, click Settings, click Administration, then click Security Roles.

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.



2-32

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. 16. Click Save and Close.

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.




2-33

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. 10. Click Manage Roles on the Action toolbar. 11. Select the OEM Support role and click OK. 12. Click Save and Close.



2-34

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.



2-35

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.



2-36

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.



2-37

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?



2-38

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.



2-39

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



2-40


1.

2.

3.



2-41


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.




2-42

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.



Chapter 3: Configuring Users and Teams

3-1

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.



3-2

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.



3-3

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.



3-4

• 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.



3-5

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.

2. On the Actions toolbar, click New. 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.



3-6

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.



3-7

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.



3-8

• 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 Microsoft Dynamics CRM.

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.



3-9

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


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.

3. In the confirmation message, click OK. 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.



3-10

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



3-11

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.


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.



3-12

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



3-13

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-14

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.



3-15

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.


2. On the Actions toolbar, click New. 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.



3-16

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. 7. Click Manage Roles on the Action toolbar. 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.



3-17

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.



3-18

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.



3-19

• 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:

1. In the Navigation Pane, click Settings, click Administration, and then click Teams.

2. On the Actions toolbar, click New. 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.



3-20

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.


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.



3-21

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



3-22

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.



3-23

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 Microsoft Dynamics CRM.

2. In the Navigation Pane, click Settings, click Administration, and then click Teams.

3. On the Actions toolbar, click New. 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. 11. Click Save and New. 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.



3-24

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.


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.

1. From the Navigation Pane, click Settings, click Administration, 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 Microsoft Dynamics CRM.



3-25

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?



3-26

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.



3-27

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.



3-28

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.




3-29


1.

2.

3.



3-30


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.


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.




3-31

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.



3-32


Chapter 4: Configuring Organizational Settings

4-1

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.



4-2

• 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



4-3

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.



4-4

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.



4-5

• 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.



4-6

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.



4-7

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.



4-8

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.



4-9

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.



4-10

• 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_”.



4-11

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.



4-12

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.



4-13

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.



4-14

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.



4-15

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



4-16

• 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.



4-17

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.



4-18

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



4-19

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.



4-20

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.



4-21

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.



4-22

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.



4-23

• 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.



4-24

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.



4-25

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



4-26

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



4-27

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-28

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 the Goal Description.

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.



4-29

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 CRM for Microsoft Office Outlook

Once the MUI languages have been enabled, you can select the language for your 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 the Goal Description.

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 MUISetup_1036.msi file.



4-30

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.

1. From the Navigation Pane, click Settings, click Administration, and 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

Once the MUI languages have been enabled, you can select the language for your Microsoft Dynamics CRM Web browser user interface.

1. Click Tools on the Microsoft Dynamics CRM menu. 2. Click Options. 3. Select the Languages tab. 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 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. Right click on the Start menu button and click Explore to open

Windows Explorer. Navigate to the folder specified in the Goal Description.



4-31

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

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 CRM for Microsoft Office Outlook

Once the MUI languages have been enabled, you can select the language for your 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. 5. Select the Languages tab. 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.



4-32

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.



4-33

• 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



4-34

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.



4-35

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.



4-36

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.



4-37

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.



4-38

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.



4-39

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.



4-40

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.



4-41

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.



4-42

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.



4-43

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



4-44

• 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: – Product Description = seat – 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: – Product Description = seat – 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.



4-45

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).



4-46

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:

a. Product Description = seat b. Price per unit = 50.00 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.



4-47

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-48

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. 5. Click Save and Close.



4-49

Step 3 - Test Default Account Currency

1. From the Navigation Pane, click Sales, and then click Accounts. 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.

11. Click Save and Close. 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: a. Product Description = seat b. Price per unit = 50.00 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.



4-50

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. 2. Click New on the Actions toolbar. 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.

6. On the Order form, click Save (not Save and Close). 7. Click Write-In Products in the Details pane. 8. Click New Order Product. On the New Order Product form, enter

the following information: a. Product Description = seat b. Price per unit = 50.00 c. Quantity = 10

9. Click Save and Close on the New Order Product form. 10. Click Save and Close on the Write-In Products page. 11. From the Navigation Pane, click Sales, and then click Accounts. 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.



4-51

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. 2. Click New on the Actions toolbar. 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.

8. Click Save and Close. 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.

10. On the Order form, click Save (not Save and Close). 11. Click Write-In Products in the Details pane.



4-52

12. Click New Order Product. On the New Order Product form, enter the following information: a. Product Description = seat b. Price per unit = 50.00 c. Quantity = 10

13. Click Save and Close on the New Order Product form. 14. Click Save and Close on the Write-In Products page. 15. From the Navigation Pane, click Sales, and then click Accounts. 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.



4-53

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.



4-54

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



4-55

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?



4-56


1.

2.

3.



4-57


1. System Settings are personal settings that are configurable on a per-user basis.


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.


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.



4-58


Chapter 5: Customizing Microsoft Dynamics CRM Overview

5-1

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.



5-2

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.



5-3

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.



5-4

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)



5-5

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



5-6

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.



5-7

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.



5-8

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.



5-9

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.



5-10

• 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



5-11

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.



5-12

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



5-13

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.



5-14

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.



5-15

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



5-16

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.



5-17

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.



5-18

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.



5-19

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.



5-20

• 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



5-21

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



5-22

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.



5-23

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.



5-24

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:

1. On the Navigation Pane, click Settings, click Customization, and 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).



5-25

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.



5-26

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

You are a Microsoft Dynamics CRM implementation consultant. Your customer, 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.



5-27

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.



5-28

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.



5-29

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.

1. On the Navigation Pane, click Settings, click Customization, and then click Import Customizations.

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-30

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.

1. On the Navigation Pane, click Settings, click Customization, and then click Export Customizations.

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

specified in the Goal Description. 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.



5-31

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-32

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



5-33


1.

2.

3.



5-34


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



5-35

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



5-36


Chapter 6: Customizing Forms and Views

6-1

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.



6-2

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.



6-3

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



6-4

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:

1. On the Navigation Pane, click Settings, click Customization, and 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.



6-5

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.



6-6

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.

3. In the confirmation message, click OK.

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.



6-7

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.



6-8

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.



6-9

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. 2. In the Common Tasks area, click Remove. 3. In the confirmation message, click OK.

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



6-10

• 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.



6-11

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



6-12

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.



6-13

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.



6-14

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. 2. In the Common Tasks area, click Remove. 3. In the confirmation message, click OK.

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



6-15

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.



6-16

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



6-17

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



6-18

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.



6-19

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.”



6-20

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. 4. Click Save and Close.

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..



6-21

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

You are a Microsoft Dynamics CRM implementation consultant. Your customer, 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.



6-22

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.



6-23

• 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.



6-24

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.



6-25

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.



6-26

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-27

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 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.

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.



6-28

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 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.



6-29

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. 11. On the menu bar, click Preview, then click Create Form to preview

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.



6-30

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



6-31

• 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.



6-32

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.



6-33

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.



6-34

• 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 then click Customize Entities.

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.



6-35

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.



6-36

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.



6-37

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



6-38

• 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.



6-39

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. 5. Save and Close the Account's Forms and Views. 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. 5. Save and Close the Account's Forms and Views. 6. Publish Account customizations. 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. 5. Save and Close the Account's Forms and Views. 6. Publish Account customizations. 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.



6-40

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. 5. Save and Close the Account's Forms and Views. 6. Publish Account customizations. 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.



6-41

Lab 6.2 - View Customization The objectives of this lab include:

• 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

You are a Microsoft Dynamics CRM implementation consultant. Your customer, 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.



6-42

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.



6-43

• 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


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



6-44

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 following properties: 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.



6-45

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.



6-46

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 the Goal Description.

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.



6-47

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. 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. 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. 4. Click Save and Close on the Account's Forms and Views. 5. Because Account is already selected on the Customize Entities list,

click Publish to publish all Account customizations. 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. 6. Click Save and Close on the Account's Forms and Views. 7. Because Account is already selected on the Customize Entities list,

click Publish to publish all Account customizations. 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/



6-48

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. 5. Click Save and Close on the Account's Forms and Views. 6. Because Account is already selected on the Customize Entities list,

click Publish to publish all Account customizations. 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.



6-49

Step 7 - Modify the Contact's Associated view

Make the following changes to the Contact's Associated view:

1. Navigate back to Settings, then Customization, then Customize 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.



6-50

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.



6-51

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-52

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.



6-53


1.

2.

3.



6-54


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.



6-55

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



6-56

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



6-57

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



6-58


Chapter 7: Customizing Entities and Attributes

7-1

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.



7-2

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.



7-3

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.



7-4

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



7-5

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



7-6

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.



7-7

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



7-8

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.



7-9

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. 3. In the Details pane, click 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.



7-10

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. 3. In the Details pane, click Attributes. 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.



7-11

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”.



7-12

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.

2. In the Details pane, click Attributes. 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.



7-13

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.



7-14

Lab 7.1 - Creating a Custom Attribute The objectives of this lab include:

• Create a new attribute on a customizable entity • Add the attribute to the entity's form • Publish and test the attribute

Scenario

You are a Microsoft Dynamics CRM implementation consultant. Your customer, 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



7-15

– 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


1. Create a new attribute in the Case entity with the properties defined in the Goal Description.

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.



7-16

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.



7-17

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 following properties:

• 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.

2. Verify that the response times appear in each case's preview pane. 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.



7-18

Step by Step


Step 1 - Add Custom Attribute

Perform the following steps to add the Response Time attribute to the Case entity:

1. From the Navigation Pane, click Settings, click Customization, 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. 4. Click Save and Close. 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.

7. Click Save and Close. 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.



7-19

3. Use the green arrows to move the Response Time field directly below the Service Level field.

4. Click Save and Close. 5. Click Actions, then click Publish. 6. Click Save and Close.

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. 5. In the Edit Filter Criteria dialog box, click Select. From the list of

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.

7. In the Edit Filter Criteria dialog box, click Select. From the list of 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. 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 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.



7-20

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. 4. Verify that the response times appear in each case's preview pane. 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.



7-21

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.



7-22

– 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”.



7-23

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



7-24

• 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.



7-25

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



7-26

• 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: – 32x32 pixels in size – In an .ico format – With 16 colors

• Icon in Entity Forms. This icon is visible on the entity's form. The

icon must be: – 66x48 pixels in size – 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.



7-27

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.



7-28

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



7-29

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’.

1. From the Navigation Pane, click Settings, click Administration, and 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 click Customize Entities.

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



7-30

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.



7-31

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.



7-32

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



7-33

• 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


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

in the Goal Description. 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.



7-34

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.



7-35

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. 6. Publish the Event entity.

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.

3. Publish the Event entity.

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).



7-36

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. 7. Log off the system. 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.

13. Log off the system. 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 then click Customize Entities.

2. Click New on the Action toolbar. 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. 5. Select User as the Ownership. 6. When you tabbed out of the Display Name field, the Name field was

automatically filled in for you with new_event. 7. Select the option to show the entity in Microsoft Dynamics CRM for

Outlook when offline. 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.



7-37

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. 2. In the Details pane, click Attributes. 3. Click New on the Action toolbar. 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. 9. Click Save and New. 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. 7. On the menu bar, click Preview, then click Create Form to preview

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.



7-38

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.

5. Click Save and Close. 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. 9. Click Save and Close.



7-39

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. Start Internet Explorer and open Microsoft Dynamics CRM. 5. From the Navigation Pane, click Sales, and then click Events. 6. Click New on the Action toolbar. 7. Enter information for an upcoming event. 8. Click Save and New. 9. Enter information for a second event. 10. Click Save and Close. 11. Verify the changes made to the Active Events view and the data that

is displayed. 12. Log off the system. 13. Log on as Gail Erickson (username = gail; password = Pa$$w0rd). 14. Start Internet Explorer and open Microsoft Dynamics CRM. 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.

19. Log off the system. 20. Log on as the CRM Administrator (username = crmadmin; password

= Pa$$w0rd). 21. Start Internet Explorer and open Microsoft Dynamics CRM.



7-40

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.



7-41


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. ( ) None of the above.

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?



7-42

5. Microsoft Dynamics CRM allows you to work with which types of entities? (Select all that apply.)

( ) System ( ) Native ( ) Custom ( ) Customizable



7-43


1.

2.

3.



7-44


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. ( ) None of the above.

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

8-1

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.



8-2

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



8-3

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.



8-4

• 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



8-5

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.



8-6

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.



8-7

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



8-8

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.



8-9

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.



8-10

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.



8-11

• 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.



8-12

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.



8-13

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.



8-14

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.



8-15

• 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.



8-16

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

1. From the Navigation Pane, click Settings, click Customization, click Customize Entities, and then double-click the Reseller entity to open it.

2. On the Details Pane, click 1:N Relationships.



8-17

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.



8-18

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.



8-19

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)



8-20

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).



8-21

• 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.



8-22

Challenge Yourself


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 the Goal Description.

1. Navigate to Settings and Customize Entities. 2. Create a new entity titled Registration. 3. Select User as the Ownership. 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.



8-23

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.

1. The Registration entity window should still be open after you saved 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.



8-24

Step 6 - Edit the Registration views

Update the Associated View on the Registration entity 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. 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.



8-25

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 of the events, but leave one or two events without any contacts or with contacts that are not VIPs.

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 the Goal Description.


2. Click New on the Action toolbar. 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. 5. Select User as the Ownership. 6. When you tabbed out of the Display Name field, the Name field was

automatically filled in for you with new_registration. 7. Select the option to show the entity in Microsoft Dynamics CRM for

Outlook when offline. 8. Accept the default options for duplicate detection.



8-26

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. 6. Click Save and Close.

Step 4 - Add Attributes to the Intersect Entity

Add the additional Registration attributes based on the instructions in the Goal Description.

1. The Registration entity window should still be open after you saved the second N:1 relationship in the prior step.

2. In the Details pane, click Attributes. 3. On the Attributes window, click New. 4. Create a Registration Status attribute. In the Display Name field,

enter Registration Status.



8-27

5. In the Type field, select picklist. 6. Add the picklist values specified in the Goal Description. 7. Click Save and New. 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. 11. Click Save and New. 12. Create a Special Requirements attribute. In the Display Name field,

enter Special Requirements. 13. In the Type field, select ntext. 14. Click Save and New. 15. Create a Paid To Date attribute. In the Display Name field, enter

Paid to Date. 16. In the Type field, select money. 17. Click Save and Close.

Step 5 - Update the Intersect Entity Form

Update the form for the Registration entity based on the instructions in the Goal Description.

1. The Registration entity window should still be open after you saved the last attribute in the prior step.

2. In the Details pane, click Forms and Views. 3. Double-click on the Form. 4. Click Add Fields. 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.

10. Click Save and Close. 11. On the Registration entity window, click Actions on the menu and

click Publish.

Step 6 - Edit the Registration views



8-28

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. 7. Click Save and Close. 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.



8-29

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.

16. Click OK to close the Edit Filter Criteria window. 17. Click Configure Sorting. 18. Select the Event column and click OK (ascending is the default

sort order). 19. Click Save and Close. 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 of the events, but leave one or two events without any contacts or with contacts that are not VIPs.

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.



8-30

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.



8-31

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.

The objectives of this lab include:

• 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.



8-32

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.



8-33

• 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


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

1. Navigate to Settings and Customize Entities. 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.



8-34

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.



8-35

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-36

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. 7. Click Save and Close. 8. Click Forms and Views.



8-37

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. 12. Click Save and Close. 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.

7. Hold your mouse over the Select link and click the drop down arrow. Select Relationship Type.

8. Hold your mouse over the Enter Value link and click the Ellipsis button. Select Customer and click the >> arrow to move the value to the Selected Values column. Click OK.

9. Hold your mouse over the Select link and click the drop down arrow. Select Distributor.

10. Hold your mouse over the Enter Value link and click the Ellipsis 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. 14. Click Save and Close. 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

1. From the Navigation Pane, click Sales, and then click Accounts. 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.



8-38

5. Click Save and Close. 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. 10. Click Save and Close. 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. 13. Click Save and New. 14. Enter Renewal Date in the Display Name field. 15. Select datetime as the Type. 16. Select Date Only as the Format. 17. Click Save and New. 18. Enter Application Fee in the Display Name field. 19. Select money as the Type. 20. Select 2 as the Precision. 21. Click Save and New. 22. Enter Description in the Display Name field. 23. Select ntext as the Type. 24. Click Save and Close.



8-39

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.


1. The Sales Region entity window should still be open following the 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. 8. Click Save and Close.

Step 7 - Update the Custom Entity Form

1. The Sales Region entity window should still be open following the 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. 4. Click Add Fields. 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.



8-40

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. 9. Click Save and Close.

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. 8. Click Save and Close. 9. Double-click Preview to open the Sales Region's Preview form. 10. Click Add Fields. 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. 14. Click Save and Close. 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-41

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.

10. Click Save and New. 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.

20. Click Save and Close. 21. From the Navigation Pane, click Sales, and then click Accounts. 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.



8-42

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.



8-43

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.



8-44

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.



8-45

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 then click Customize Entities.

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. 9. Click Save and Close.

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.



8-46

Lab 8.3 - Add a Mapping The objectives of this lab include:

• 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.



8-47

Challenge Yourself


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.

1. Navigate to Settings and Customize Entities. 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.



8-48

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.



8-49

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. 8. Click Save and Close. 9. Click Save and Close to save the Lead attributes. 10. On the Customize Entities view, double-click on Account. 11. Click on Attributes in the Details pane. 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. 2. Click on Attributes in the Details pane. 3. Click New. 4. Enter Racing as the Display Name. Click the Type drop down arrow

and select bit. The Default Value is No. 5. Click Save and New.



8-50

6. Enter Fitness as the Display Name. Set the Type drop down arrow and select bit. The Default Value is No.

7. Click Save and Close. 8. Click Forms and Views. 9. Double-click Form. 10. On the General tab, select the Contact Information section. 11. Click Add Fields. 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.



8-51

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. 6. Click Save (not Save and Close). 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.



8-52

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?



8-53

• Department Picklist Attribute. To allow standardized aggregation of departments, using a custom picklist with common department groups was considered. What is the problem with this approach?

• 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. What is the problem with this approach?



8-54

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



8-55

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



8-56

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.



8-57

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?


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. 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.



8-58

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. 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. 5. Do not close the department entity.

Step 6 - Modify the Department Form and View


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

In the Contact entity, replace the text Department field with the lookup 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. 3. Double-click Form. 4. Remove the Department field. 5. Add the new Department ID field.



8-59

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 Publish All Customizations.

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.



8-60

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

1. From the Navigation Pane, click Settings, click Customization, click Customize Entities.

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.



8-61

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. 2. Click 1:N Relationships. 3. Click New 1-to-Many Relationship. 4. The values to enter for this relationship are displayed in the Goal

Description in the figure titled Relationship Properties. 5. Click Save and Close to close the 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. 2. Click 1:N Relationships. 3. Click New 1-to-Many Relationship. 4. The values to enter for this relationship are displayed in the Goal

Description in the figure titled Relationship Properties. 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.



8-62

Step 5 - Create 1:N Department to Contact Relationship

1. From the Customize Entities window, double-click Department. 2. Click 1:N Relationships. 3. Click New 1-to-Many Relationship. 4. The values to enter for this relationship are displayed in the Goal

Description in the figure titled Relationship Properties. 5. Click Save and Close to close the Relationship. 6. Leave the department entity open for the next step.

Step 6 - Modify the Department Form and View


1. On the Department entity window, click Forms and Views. 2. Double-click Form. 3. Click Add Fields. 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.

6. Click Save and Close. 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

In the Contact entity, replace the text Department field with the lookup Department field. In the Contact Lookup view, add Parent Customer to the Find Columns.

1. From the Customize Entities window, double-click Contact. 2. Click Forms and Views. 3. Double-click Form. 4. Select the Details tab. 5. Select the Department field. Click Remove. Click OK to confirm

the deletion.



8-63

6. Click Add Fields. 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.

9. Click Save and Close. 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 Publish All Customizations.

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. 2. Click 1:N Relationships. 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.



8-64

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. 6. Click Save and Close. 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.

2. From the Navigation Pane, click Sales, and then click Accounts. 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. 10. Click Save and Close. 11. Repeat these steps for several departments.

To associate additional contacts with each department (besides the primary contact):



8-65

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.



8-66

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.



8-67


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



8-68

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-69

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?



8-70


1.

2.

3.



8-71


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



8-72

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.



8-73

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..



8-74

Lab 8.4 - Case Study • 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?

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. What is the problem with this approach?

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. What is the problem with this approach?

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

9-1

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.



9-2

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.



9-3

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.



9-4

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.



9-5

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.



9-6

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


1. Back up your current Case entity customizations. 2. Change the Case entity name to Incident.



9-7

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.



9-8

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

1. From the Navigation Pane, click Settings, click Customization, and then click Export Customizations.

2. On the Export Customizations view, click More Actions on the Action toolbar, and then click Export All Customizations.



9-9

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. 4. Click Save (not Save and Close).

Step 3 - Change the Form and View Names

1. The Incident (formerly Case) Information window should still be open.

2. Click Forms and Views. 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. 6. Click Save and Close. 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.



9-10

4. Double-click the attribute you want to change. 5. Change the Display Name (for example, from Case Number to

Incident Number). 6. Click Save and Close. 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. 5. Click Save and Close. 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.



9-11

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.



9-12

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



9-13

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.



9-14

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.



9-15


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?

2. When changing the name of a customizable entity, what at are some of the additional areas that cannot to be changed?



9-16

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?



9-17


1.

2.

3.



9-18


1. When changing the name of a customizable entity, what at are some of the 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

2. When changing the name of a customizable entity, what at are some of the 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.



9-19

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.



9-20


Chapter 10: Maintaining Organizations Through Deployment Manager

10-1

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



10-2

• 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.



10-3

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.



10-4

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.



10-5

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.



10-6

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.



10-7

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.



10-8

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.



10-9

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.



10-10

• 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



10-11

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.



10-12

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.



10-13

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

You are a Microsoft Dynamics CRM implementation consultant. Your customer, 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.



10-14

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.



10-15

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.



10-16

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.

3. Click New on the Actions toolbar. 4. Enter Sales and Marketing as the business unit name. Northwind

Traders will be displayed as the parent business unit. 5. Click Save and New. 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.



10-17

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.



10-18

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).



10-19

• 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.



10-20

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



10-21

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.



10-22

• 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.



10-23

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 all that apply. (Select all that apply.)

( ) 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.



10-24

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



10-25


1.

2.

3.



10-26


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 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 all that apply. (Select all that apply.)

(√) 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.



10-27

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



10-28


Chapter 11: Introduction to Advanced Customizations

11-1

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



11-2

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.



11-3

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



11-4

• 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.



11-5

• 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



11-6

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.



11-7

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-8

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.



11-9

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.



11-10

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.



11-11

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.



11-12

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.



11-13

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####



11-14

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.



11-15

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.



11-16

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



11-17

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



11-18

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. 3. Click Forms and Views. 4. Double-click Form. 5. Click Form Properties. 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.



11-19

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.



11-20

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.



11-21

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.



11-22

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

1. Click Form Properties. 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’);

}



11-23

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.



11-24

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. 6. Click OK to close the message. 7. Reopen the Account you just created. Note that the message “This

Account is on Credit Hold” appears. 8. Click OK to close the message.



11-25

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.



11-26

• 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.



11-27

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>”



11-28

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:

1. From the Navigation Pane, click Settings, click Customization, 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.



11-29

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

1. From the Navigation Pane, click Settings, click Customization, click Customize Entities, and then double-click Account.

2. Click Forms and Views. 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.



11-30

Step 5: Save and Publish Changes

1. Click Save. 2. Click Actions, then click Publish. 3. Click Save and Close.

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.



11-31

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


2. Click Forms and Views. 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.



11-32

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.



11-33

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.



11-34

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.



11-35

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

1. From the Navigation Pane, click Settings, click Administration, and 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.



11-36

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.



11-37

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. 5. Click Save and Close.



11-38

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.



11-39

Step 1: Backup your Current ISV.Config settings

1. From the Navigation Pane, click Settings, then click Customization, then click Export Customizations.

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.



11-40

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.



11-41

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.



11-42

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.



11-43

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

1. From the Navigation Pane, click Settings, click Administration, and 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



11-44

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

1. From the Navigation Pane, click Settings, then click Customization, then click Export Customizations.

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.



11-45

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/Entities/manageEntity.aspx?entityId={70816501-EDB9-4740-A16C-6A5EFBC05D84} (http://crm/AdventureWorksCycle/Tools/SystemCustomization/Entities/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.



11-46

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.



11-47

5. Save your Customizations.xml file. 6. From the Navigation Pane, click Settings, then click Customization,

then click Import Customizations. 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.



11-48

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.



11-49

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.



11-50

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”>



11-51

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



11-52

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



11-53

Demonstration - Apply Site Map Customizations This demonstration illustrates how SiteMap is use to control the appearance of Microsoft Dynamics CRM.

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

1. From the Navigation Pane, click Settings, click Customization, and then click Export Customizations.

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.



11-54

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

1. From the Navigation Pane, click Settings, click Customization, and then click Import Customizations.

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.



11-55

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.



11-56

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.



11-57

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.



11-58

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 Microsoft Dynamics CRM.

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.



11-59

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?




11-60

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.



11-61


1.

2.

3.



11-62


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?

(•) Field OnChange Event ( ) Form OnSave Event ( ) Form OnChange Event ( ) Form OnLoad 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?

( ) Field OnChange Event (•) Form OnSave Event ( ) Form OnChange Event ( ) Form OnLoad event



11-63

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.



11-64


Appendix A: Permissions Required For Customization Tasks

A-1

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 Privileges

Comments

Access customization area Security roles: System Administrator 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

The Entity Read privilege controls access to the customization area.

Publish customizations Security roles: System Administrator System Customizer Privilege: Publish Customizations

Customizations that change the schema must be published. The Publish Customizations privilege is separate from other customization privileges because it allows user-interface elements to be customized by several people but published only by someone who has reviewed the customizations.

Customize entities Security roles: System Administrator System Customizer Privileges: Entity: Read Entity: Write

These privileges allow you to change the Display Name of the entity. Modification of the entity attributes, form, views, or messages require additional privileges.

Editing entity messages requires the privilege:

Form: Organization Write.

Create custom entities Security roles: System Administrator System Customizer Privileges: Entity: Read Entity: Create Entity: Write

These privileges allow you to create a custom entity. Modification of the entity attributes, form, views, or messages require additional privileges.



A-2


Comments

Set privileges for custom entities Example Privileges <Custom Entity>: Create <Custom Entity>: Read <Custom Entity>: Write <Custom Entity>: Delete <Custom Entity>: Append <Custom Entity>: Append To <Custom Entity>: Assign <Custom Entity>: Share Security roles: System Administrator System Customizer

When a custom entity is created, the

access level is set to None for all privileges in all security roles other than System Administrator and System Customizer. Change the access level as appropriate to enable other users to use custom entities.

The settings shown here are default privileges for core user-owned entities that store customer data. These settings represent a common pattern for user-owned entities.

Organization-owned custom entities do not have the Assign or Share privilege.

Export customizations Security roles: System Administrator System Customizer Privilege: Export Customizations

You are able to export only customizations and settings for which you have read privileges.

To export ISV.Config you must have the ISV Extensions privilege.

Import customizations Security roles: System Administrator System Customizer Privilege: Import Customizations

Some customizations must be published after they are imported before they are available to users.

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: System Administrator System Customizer Privileges: Entity: Read Attribute: Read Attribute: Write

These privileges allow for modification of existing entity attributes only. Creation of new attributes requires additional privileges.



A-3


Comments

Create entity attributes Security roles: System Administrator System Customizer Privileges: Entity: Read Attribute: Read Attribute: Write Attribute: Create

New entity attributes are not visible to users until they have been added to the entity form. Modifying the entity form requires the Form: Write privilege.

Edit entity relationships Security roles: System Administrator System Customizer Privileges: Entity: Read Relationship: Read Relationship: Write

These privileges allow for modification of existing entity relationships only. This includes the ability to create new mappings. Creation of new entity relationships requires additional privileges.

Create entity relationships Security roles: System Administrator System Customizer Privileges: Entity: Read Relationship: Read Relationship: Write Relationship: Create

New entity relationships cannot be used until the relationship attribute is added to the related entity form. Modifying the entity form requires the Form: Write privilege.

Use custom entity relationships Security roles: Depends on the entities participating in the relationship. Privileges: primary entity record: Read primary entity record: Append related entity record: Read related entity record: Write related entity record: Append To related entity record: Create

At a minimum, users must have User

level access to the records participating in the relationship.

Users with the Create privilege on the related entity record will be able to create new associated records from the primary entity.

Modify entity forms Security roles: System Administrator System Customizer Privileges: Entity: Read Form: Write

Form: Read privilege is set to

Organization and cannot be changed.



A-4


Comments

Modify system views Security roles: System Administrator System Customizer CEO-Business Manager Customer Service Manager Marketing Professional Marketing Manager Vice President of Marketing Sales Manager Vice President of Sales Privileges: Entity: Read View: Write

These privileges allow for modification of existing views only. Creation of new views requires additional privileges.

The View: Read privilege is set to


Create system views Security roles: System Administrator System Customizer CEO-Business Manager Customer Service Manager Marketing Professional Marketing Manager Vice President of Marketing Sales Manager Vice President of Sales Privileges: Entity: Read View: Write View: Create



Delete system views Security roles: System Administrator System Customizer CEO-Business Manager Customer Service Manager Marketing Manager Vice President of Marketing Sales Manager Vice President of Sales Privileges: Entity: Read View: Delete





A-5


Comments

View client extensions Security roles: System Administrator System Customizer CEO-Business Manager Customer Service Manager Marketing Manager Vice President of Marketing Sales Manager Vice President of Sales Privilege: ISV Extensions

This privilege grants users the ability to see client extensions configured using ISV.Config.

Edit entity messages Security roles: System Administrator System Customizer Privileges: Entity: Read Entity: Write Form: Write

Download Web Services Description Language files

Security roles: System Administrator System Customizer Privilege: Entity: Read

The entity Read privilege is necessary only to gain access to the URLs in the customization area. It is not necessary to download the Web Services Description Language files.



A-6


Index

Page i

INDEX

1-to-Many relationships.............................8-2, 8-3 Access levels ............................................2-4, 2-6 Active Directory................................................3-3 Add a business unit..........................................1-6 Add Users wizard.............................................3-7 Adding a custom attribute ................................7-3 Adding a single user ........................................3-6 Application event programming .....................11-2 Auto Numbering.............................................4-15 Base language...............................................4-22 Business Unit access.....................................2-10 Business units..................................................1-2 Cascading ........................................................8-8 Child business units .........................................1-5 Client extensions............................................11-2 Client-side code .............................................11-9 Configuration database..................................10-4 Copy an existing role .....................................2-22 Create a new role...........................................2-23 Create a new team.........................................3-19 Creating a custom entity ................................7-21 Customizing an existing view.........................6-35 Deployment Administrators..........................10-17 Deployment Manager.....................................10-1 Disabling a business unit .................................1-7 Enable the MUI pack......................................4-23 Enabling a disabled business ..........................1-8 Entity mapping ...............................................8-42 Exchange rates ..............................................4-34 Export customizations....................................5-21 Export/import..................................................5-19 Field events..................................................11-16 Filtered views...................................................5-9 Fiscal year settings ........................................4-16 Form customization..........................................6-3 Form events .................................................11-15 Form Preview.................................................6-15 Implementation methodology...........................5-2 Import Organization .......................................10-7 Importing customizations ...............................5-23 Intersect entity..................................................8-5 ISV.Config....................................................11-36 Manager...........................................................3-9

Managing users............................................... 3-2 Manual N :N relationship ................................. 8-4 Many-to-1 Relationship ................................... 8-3 Many-to-Many relationship .............................. 8-4 Microsoft Dynamics CRM architecture ............ 5-6 Microsoft Dynamics CRM security model........ 2-2 MUI language pack ....................................... 4-21 Multicurrency ................................................. 4-32 Multilingual User Interface (MUI)................... 4-21 Multi-tenancy ........................................ 10-1, 10-2 Native N :N relationship................................... 8-4 None access level ........................................... 2-8 Organization access...................................... 2-12 Parent:Child Business Unit access ............... 2-11 Parent Business Unit....................................... 1-5 Personal views .............................................. 6-31 Preview form ................................................. 6-15 Privileges.................................................. 2-3, 2-4 Public views................................................... 6-30 Publishing...................................................... 5-18 Relationship Behavior ..................................... 8-7 Renaming a customizable entity ..................... 9-1 Reorganizing a business unit .......................... 1-7 Role-based security model.............................. 2-2 Root business unit........................................... 1-2 Security role .................................................. 2-12 SiteMap ....................................................... 11-48 System Administrator role ............................. 2-16 System Settings .............................................. 4-2 System views ................................................ 6-30 Task-based privileges ..................................... 2-6 Teams ........................................................... 3-18 Types of customizations................................ 5-11 Types of entities .............................................. 7-2 Types of views............................................... 6-30 Unsupported relationships............................... 8-7 URL Addressable forms .............................. 11-33 User access..................................................... 2-9 User authentication ......................................... 3-3 User licenses................................................... 3-3 User maintenance ........................................... 3-4 Workflow........................................................ 11-2 System Customizer role ................................ 2-17



Page ii


8912-en customization and configuration student manual

Documents

security roles

dynamics gp software

business units

elements of training

written license agreement

intellectual property

subject matter

names of actual companies