CRM

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

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

implementation methodology as you develop customizations.
• Identify how the Microsoft Dynamics® CRM architecture can
influence how and where Microsoft Dynamics CRM can be
customized.
• Review the types of customizations that can be made based on the
default Microsoft Dynamics CRM security roles.
• Discuss some of the ways that Microsoft Dynamics CRM can be
customized.
• Identify which customizations require publishing and the various
ways to publish your customizations.
• Explain the use of Solutions.
• Discover how customizations can be re-used by exporting Solutions
that are made in one deployment and importing them into another.
• Create a new Solution.
• Identify the components of Solutions.
• Identify the differences between Managed and Unmanaged
Solutions.
• Configure properties of Managed Solution Components.
Introduction
The Microsoft Dynamics CRM application design provides a platform upon
which businesses can customize and configure the system to meet their own
particular business needs. When changes occur within an organization or to its
business processes, this architecture allows the organization to adapt to these
changes effortlessly and affordably within the application.
3-1
Microsoft Official Training Materials for Microsoft Dynamics®
Your use of this content is subject to your current services agreement
Microsoft Dynamics® CRM 2011 Customization and Configuration
Customization Methodology
Successfully customizing Microsoft Dynamics CRM requires more than just
familiarity with its customization features. The key to successful
implementations comes from the following:
• Understanding the application architecture and the types of

supported customizations.
• Understanding the organization's needs and expectations.
• Having and using a strong implementation methodology.
• Maintaining a perspective on the implementation's long term success.
A strong implementation methodology helps create a plan that does the

following:
• 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 Customer Relationship Management strategy frequently

represents a strong commitment to a fundamental change in the way an
organization does business. The change is supported, and sometimes driven, by
the implementation of software; but this change does not stop at the end of the
initial implementation. The capability of the Microsoft Dynamics CRM
implementation to continue to respond to change is affected by decisions and
processes that are made during the initial implementation.
Extended CRM (xRM)

Relationship Management is a business strategy that is supported by software.
Out of the box, Microsoft Dynamics CRM is configured to supply the
fundamental Customer Relationship Management requirements of an
organization and a small amount of customization may be all that is required to
meet the specific requirements of the business processes. More wide-ranging
changes allow Microsoft Dynamics CRM to manage any sort of relationship,
such as Member relationships, Investor relationships, Donor relationships, or
Subscriber relationships. Such systems are often known as xRM applications.
In either case, to successfully implement the software you must understand the
organization's Relationship Management strategy. If an organization does not
have a clear strategy, they may need help in defining it.
The Microsoft Dynamics CRM platform is customizable at many levels. Simple

changes may be made safely through the User Interface (UI) by any user. More
complex changes may be made by more highly qualified or experienced users
(power users), again through the UI. In both cases, the Microsoft Dynamics CRM
platform will ensure these changes are persisted and protected within the system.
3-2
However, some changes go beyond the scope of those that can be performed by
selecting options through the UI. For example, to make the system process data
in forms in a way that is specific to a particular implementation, it might require
the use of code in a scripting language (Jscript). Still, other changes might
require a developer to produce compiled code and interface it with the Microsoft
Dynamics CRM platform (Plug-Ins). The more complex and deep the changes,
the more the system can be molded to manage relationships beyond the classic
Sales-Customer or Marketing-Customer relationships. Such systems can be
produced in-house or through external consultants for a specific company, or
they can be produced and sold by ISVs.
Microsoft Dynamics CRM is built on the .NET Framework and makes use of
several core Microsoft Platform technologies, such as Windows Workflow
Foundation (WF), SQL Server, and Windows Communication Foundation
(WCF). Independent Software Vendors (ISVs) and other developers can use
these technologies to extend the Microsoft Dynamics CRM framework,
producing solutions that are tailored to vertical or horizontal markets.
NOTE: The Microsoft Dynamics Marketplace is a site that is maintained by

Microsoft as a place for ISVs to make their Solutions available to the Microsoft
Dynamics CRM community.
The Microsoft Dynamics CRM framework simplifies this development work,

making it fast and efficient in meeting just about any xRM requirement. The
framework also provides a robust method of deployment and management to
other Microsoft Dynamics CRM installations.
Microsoft Dynamics CRM Architecture

To effectively customize Microsoft Dynamics CRM, you must have a good
understanding of the application's architecture. The core architectural component
is referred to as the Microsoft Dynamics CRM platform layer. The Microsoft
Dynamics CRM platform can be contrasted with the client/server (two-tier)
architecture that has been around for more than two decades.
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 could go unappreciated now that users have become accustomed to
them. However, consider the difficulty that developers might 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 manage,
and it provides him or her with the means to interact with the data through
available APIs by using languages such as Transact-SQL. But the client/server
architecture has many shortcomings, and there is only so much that a database
that is designed for general use can provide.
3-3
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 by only using client/server
architecture.
FIGURE 3.1 MICROSOFT DYNAMICS CRM CUSTOMIZATION

ARCHITECTURE
In the multi-tier design that is shown in the “Microsoft Dynamics CRM

Customization Architecture” figure, the Microsoft Dynamics CRM platform
serves as an intermediary between the software developer and the database. The
database provides important services in the client/server architecture. Moreover,
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 parts of the graphic that are marked with a cog indicate places where the
Microsoft Dynamics CRM customizer can interact with the platform through
code, the UI, custom reports, and so on. This training concentrates on the part
that is labeled Extensible Application. The other parts will be described briefly,
but detailed treatment is beyond the scope of this training.
3-4
The Microsoft Dynamics CRM platform removes the complexity that developers
might otherwise have to deal with and provides a rich environment for
customizing the application. Because it is designed specifically for use as a
Relationship Management platform, it can provide more specific features that
programmers can use when they build applications that use it.
The Business Entity Components part of the 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. These objects are created in response to instructions from applications such
as the Microsoft Dynamics CRM web application or custom-built applications.
NOTE: A record is an instance of an entity. When you create an Account record

in Microsoft Dynamics CRM, you create an instance of the Account entity. Users
generally refer to this as a "record" and developers generally use the term
"object." These terms are used somewhat interchangeably in this training.
The goal of the Microsoft Dynamics CRM platform is to implement the service
rules by manipulating and combining the underlying domain-specific objects.
The platform accomplishes this by performing the following tasks:
• Managing access to objects by requesting security checks from the

database.
The database manages security, but the platform sends a call to the
database to check if the authenticated user has the rights to perform
the requested task.
• Controlling access to the database through the data access layer.
• Raising events for workflow processes and custom business logic
implementations.
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 that are created by ISVs. For
instance, 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 does not impose business-specific logic; it imposes only generic
domain constraints. It contains the components for an application, but 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.
3-5
You can apply business logic at the platform through workflow processes and
plug-ins, or through the UI using Dialog box or event scripts on Forms.
• Workflow processes: Microsoft Dynamics CRM Workflow enables

you to create automated business processes at the platform layer.
Workflow processes perform actions based on rules that are 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. The Workflows apply the business logic by using
built-in steps or by allowing developers to add their own custom
code to carry out a step.
• Plug-ins: These refer to the ability to create business logic
extensions by using pre- and post-plug-ins that are available in the
platform. Plug-ins are extension points that are made available by the
Microsoft Dynamics CRM platform.
There is a published set of events that a Plug-In 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 to the
system event.
NOTE: Creating plug-ins requires development expertise and is beyond the

scope of this training. Refer to the Microsoft Dynamics CRM SDK, and the
Extending Microsoft Dynamics CRM 2011 training offering.
Certain parts of the Microsoft Dynamics CRM application 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 that is
stored in the Lead object. The platform creates the Lead, but the built-in business
logic that is performed by the application converts the Lead to a Contact,
Account, and Opportunity.
Database Access
The data access layer of the 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. The only supported interaction with
the database is the querying of Filtered Views, which is covered in the "Filtered
Views - Exception to the Rule" topic.
3-6
Developers must not directly access or update the Microsoft Dynamics 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 function incorrectly.
• The Microsoft Dynamics CRM database structure might change
without notice in a future release.
• It is unsupported and in violation of Microsoft Dynamics CRM
support agreements.
NOTE: Because all data transactions go through the Microsoft Dynamics CRM
platform, the structure of Microsoft Dynamics CRM's actual SQL Server
database is technically irrelevant to even the deepest level customizations.
Filtered Views - Exception to the Rule

The only time that it is supported to directly query the SQL Server database is to
use a set of views to retrieve data for Microsoft Dynamics CRM reports. These
views have names beginning with "Filtered" and are known collectively as
Filtered Views. Filtered views only return records that a user is allowed to read.
The views accomplish this by applying Microsoft Dynamics CRM security to the
entities that the views represent.
Filtered Views have the following characteristics:
• Any application that can access views in a SQL Server can

potentially report against the data that is stored in Microsoft
Dynamics CRM, provided they do so through ODBC, OLEDB, or
the SQL Native client.
Such applications include Microsoft SQL Reporting Services and
Microsoft Office applications such as Excel, Word, and Access.
• Third-party reporting tools can be used to query the Microsoft
Dynamics CRM system.
3-7
• A filtered view for a custom entity is created automatically during

the creation of the entity.
• New attributes that are added to an entity are automatically added to
the filtered views.
FIGURE 3.2 FILTERED VIEWS
Filtered Views and Database Security Checking

The SQL Server retrieves the data for filtered views at run time whenever they
are queried. When the platform constructs a filtered view definition, 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 (at the
time the view is queried).
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 the returned dataset can bypass the Microsoft
Dynamics CRM platform but continue to honor security settings.
Filtered Views and IFDs

Users of an Internet-Facing Deployment of Microsoft Dynamics CRM do not
have direct access to filtered views. Therefore, if customizations are being
designed for deployment in both On-Premise and IFD installations, direct access
to filtered views should be avoided. Since it is uncertain whether a customer will
move from On-Premise to IFD sometime in the future, it is probably best to
avoid locking them into one deployment type through the customization design.
NOTE: Microsoft Dynamics CRM makes use of a relatively new standard for
data access called the Open Data protocol, or oData. This makes use of the
concept of a RESTful (REpresentational State Transfer) endpoint to allow
applications to access data held in the system. This applies to both On-Premise
and IFD systems, and removes the need for access to Filtered Views. Detailed
discussion of oData is beyond the scope of this training.
3-8
Customizing Microsoft Dynamics CRM

Each configurable area of Microsoft Dynamics CRM requires specific privileges
that authorize a user to customize the area. The default security roles provide
varying levels of rights to customize the application. The default roles that
provide maximum customization rights are the System Customizer and System
Administrator roles.
System Customizers
System customizers can customize the Microsoft Dynamics CRM schema,
including adding, modifying, renaming, and deleting entities and fields. System
customizers can create Solutions and most (but not all) of the components of
Solutions; they can also export and import configurations. However, System
Customizers have limited privileges to configure the sort of business entities that
come under Templates, as shown in the previous “Microsoft Dynamics CRM
Customization Architecture” figure. Users who are assigned the System
Customizer role are generally limited to working with records that they own.
In some organizations, the System Customizer role is assigned to a "power" user

who is also assigned a normal user role.
EXAMPLE: Contoso is a small electronics distributor that does not have a

formal IT staff. However, because the company's Sales Manager has a technical
background, she is usually the first person that users contact when they
experience hardware and software issues. Contoso assigns her the System
Customizer role (or a modified version of it) so that she can perform basic form,
option set, and view customizations.
System Administrators
System administrators can perform all customization and configuration tasks in
Microsoft Dynamics CRM, and they can work with all records. As a best
practice, an organization should strictly limit the number of people that are
assigned the System Administrator role, and it should never remove this role.
3-9
Permissions Needed for Customizing

Only the System Administrator and System Customizer roles have the privileges
to create, modify, import, and export customizations. Both of these roles have the
privileges necessary to perform the basic application and platform customizations
that are provided in the application's customization tools. These privileges are set
in the Customization tab of the Security Role.
FIGURE 3.3 CUSTOMIZATION TAB IN SYSTEM ADMINISTRATOR SECURITY

ROLE
The Customization tab includes permissions that allow or prohibit the user from
customizing each component of a Solution. However, the relationship between a
Customizer’s general role and the options on the Security Role’s Customization
tab is not entirely complete. Some Manager roles have privileges on the
Customization tab, such as Dialog Session, Process, and System Chart. This
reflects the fact that these components are connected with business processes.
3-10
Most of the customization-related privileges are limited to the following two

access levels:
• Organization: allows the user to customize an entity component.

• None: prohibits the user from customizing an entity component.
Other privileges also allow User, Business Unit, and Parent:Child Business Unit
levels.
Types of Customizations
Customizations to Microsoft Dynamics CRM can be classified into one of the
following groups:
• Customizing forms, views and charts.

• Customizing the Microsoft Dynamics CRM schema.
• Extending the application using application event programming.
• Extending the application using .NET, including the use of
Silverlight solutions.
• Using client extensions to modify the User Interface (Site Map and
Application and Entity Ribbons.
• Automating business processes using Microsoft Dynamics CRM
Workflows and Dialog box.
• Customizing Reports and Dashboards including creating Web
Resources.
This training examines in detail the first two types of customizations; that is,
customizing forms, views, and charts, and customizing the schema. In both cases,
customizations are performed using the Web application.
The remaining customization types are outside the scope of this training. These
tasks are typically performed by resources that are different from the
implementer/customizer that configures and customizes the application and
platform.
Customizing the Application - Forms

Customizing the application's user interface includes customizing forms, views,
and charts to satisfy a company's business requirements. 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.

• Rearranging the tabs, sections, and fields on a form to simplify the
way that users view and enter data.
• Removing entities.
3-11
• Modifying field properties such as labels and layout options.

• Assigning security roles to forms.
FIGURE 3.4 FORM CUSTOMIZATION
Customizing the Application - Views

The following characteristics apply to Microsoft Dynamics CRM views:
• Views are a type of saved query; they return lists of records for a
given entity that meet certain criteria.
• Views display only a subset of data for each record.
• The views for a given entity can display fields from related entities;
for example, each Account record in an Account view can display
fields from its primary Contact.
• Views provide a way for users to locate the data that they need and
can be used for reporting.
• The data that is displayed in a view can be exported to Microsoft
Office Excel spreadsheets.
3-12
• Administrators can create public views for the entire organization to

use.
• Users can create their own personal views with Advanced Find.
Each view includes the following elements:
• Filter criteria: filters are rules or conditions that specify the records
to show in a view.
• Columns: each view displays specific columns of data from records;
users can choose by which column the list of records should be
sorted.
FIGURE 3.5 VIEW DEFINITION
Customizing the Schema

System customizers can modify the Microsoft Dynamics CRM schema by
adding, modifying, renaming, and deleting entities and attributes. An entity is a
definition for the type of record that is used to store information in Microsoft
Dynamics CRM. Microsoft Dynamics CRM includes a default set of entities such
as Account, Contact, Opportunity, and Case.
Customizing the Microsoft Dynamics CRM schema by using the application's

built-in customization tools includes the following tasks:
• Adding new entities to Microsoft Dynamics CRM

• Adding or removing attributes from existing entities
• Creating relationships between entities
• Creating mappings between entities
3-13
Programming skills are not required to make schema modifications because

changes are made using the Microsoft Dynamics CRM application. The
application will request that the platform make the appropriate changes. In turn,
the platform makes the necessary changes to the Microsoft Dynamics CRM
databases.
Application Event Programming

Microsoft Dynamics CRM provides application events that developers can use to
further customize the application. Application event programming requires a
good understanding of the use of JScript (which is Microsoft's implementation of
JavaScript) and the Document Object Model (DOM). Microsoft Dynamics CRM
2011 provides libraries so that JScript code can be re-used across entities.
NOTE: Discussion of application event programming is outside the scope of this

training.
Client Extensions
Microsoft Dynamics CRM can be integrated with other applications by using
custom buttons and menu items in the web application and Microsoft Dynamics
CRM for Outlook.
For example, the following customizations can link Microsoft Dynamics CRM
with other applications:
• Create buttons and menu items that are configured to point to the
URL of another application, and optionally pass parameters to the
application regarding a Microsoft Dynamics CRM record. This
enables the other application to query Microsoft Dynamics CRM for
a specific record’s details.
• Use URL addressable forms to display Microsoft Dynamics CRM
forms within other applications.
• Use URL addressable forms to let users create a new Microsoft
Dynamics CRM record within another application.
NOTE: Discussion of client extensions is outside the scope of this training.
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 simplifies their
ability to create solutions that interact with Microsoft Dynamics CRM.
3-14
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 training offering.
Process Customization
Microsoft Dynamics CRM supports two types of processes, Workflow and
Dialog.
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 perform the following tasks:
• Specify actions to take when specified conditions are met.

• Automate tasks to achieve consistency and efficiency.
FIGURE 3.6 WORKFLOW ILLUSTRATION
Microsoft Dynamics CRM uses Microsoft Windows Workflow Foundation (WF)

to create workflow rules. 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.
• Developers can further enrich workflow rules by additionally calling
web services and .NET assemblies.
Dialog boxes allow interaction with a Microsoft Dynamics CRM user. A dialog
can present questions, receive and store answers, perform actions on data, and
implement conditional steps based on input. A dialog could be used to present a
sales user with a customer sales script, which prompts questions that the user can
ask, stores the responses, and then delivers different prompts depending on the
answers.
3-15
NOTE: Discussion of Microsoft Dynamics CRM workflows and dialog box is

outside the scope of this training. Refer to the Workflow in Microsoft Dynamics
CRM 2011 training offering for more information on these topics.
Reporting
SQL Server 2008 R2 Reporting Services is the default reporting solution that
Microsoft Dynamics CRM uses. A default set of Reporting Services reports is
included with the application. Report designer tools 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. For more information, refer to the
Microsoft Official Curriculum course titled "Implementing and Maintaining
Microsoft SQL Server 2008 Reporting Services for more information."
Users can export data from views, including Advanced Find. The data can be
exported into dynamic Microsoft Excel worksheets and pivot tables that can be
automatically refreshed when they are opened.
Microsoft Dynamics CRM also includes a Report Wizard, where users can create
simple Reporting Services reports from within the application. Reports can also
be generated by exporting data into Microsoft Office Excel and using Excel's
reporting functionality. The following is an example of a graph that was
generated using Excel's reporting tools.
FIGURE 3.7 GRAPH OF MICROSOFT DYNAMICS CRM DATA GENERATED

BY MICROSOFT OFFICE EXCEL
3-16
NOTE: Creating reports using the Report Wizard and by exporting data into
Microsoft Office Excel is covered in the Reporting in Microsoft Dynamics CRM
2011 training offering.
Using Solutions to Manage Customizations

A Solution is a container for components that make up a particular customization
project. By keeping track of all the components of a single Solution, Microsoft
Dynamics CRM can ensure that the following criteria is met:
• When a Solution is exported or imported, all components are

transferred.
• Version control is maintained.
• Security specific to the Solution is applied to the correct entities.
The components of a Solution can be just about anything that can be customized
or be part of the customization process. The components are displayed in
the"Solution Components" figure.
FIGURE 3.8 SOLUTION COMPONENTS
3-17
Default Solution
When an Organization is created, a corresponding Solution is created that
contains all the components in the system is created also. This is called the
Default Solution, which is essentially Microsoft Dynamics CRM at its basis. The
standard components can be customized in the Default Solution, and new entities
and other components can be added to it. The Default Solution can be exported
from the application and then imported into another Microsoft Dynamics CRM
organization.
Managed and Unmanaged Solutions

A Solution can exist in one of two states: Managed and Unmanaged. When a
solution is first created, it has no components and exists in an unmanaged state.
Unmanaged solutions are containers that hold references to components in the
organization. As you add existing components into a solution, a new reference to
that component is created in the solution.
Unmanaged solutions contain references to entities and other components; this

means that all unmanaged solutions in an organization are just views of the
concrete components. All unmanaged solutions can "see" the components, and
users can add references, if desired.
If a solution must be isolated from others in the organization, then it can be

loaded in a managed state. Unmanaged solutions are converted to a managed
state by exporting them as Managed and then importing them to the target
organization. A managed solution's components are kept isolated from the rest of
the organization, though they can be referenced from unmanaged solutions.
When a managed solution is imported, the Managed Properties that are

configured on its components become active. The managed properties allow you
to restrict or allow further customizations to the components. For example, an
entity’s attribute might allow a change of display name but not of requirement
level.
More than one managed solution may be imported into an organization.

Therefore, the final view of customizations is built from:
• The Default Solution, which is modified by all unmanaged solutions

• The first managed solution, the second managed solution, and so on
Two separate managed solutions can contain customizations to the same entity.
Microsoft Dynamics CRM 2011 has a conflict resolution strategy that supports
the idea of "merging and co-existence". Elements that support this, such as the
Ribbon and Forms, can exist in different states on multiple solutions yet, they can
be displayed in a consistent way in the organization.
3-18
The rules by which the merging and co-existence is implemented are complex.
The rules are explained in full in the Microsoft Dynamics 2011 SDK. However,
not all elements can co-exist in different forms of customization. For example, a
problem will occur if one solution renames Cases as "Incidents" and another
solution renames them as "Issues."
If a managed solution allows users to further customize its components, then it is

questionable whether these customizations will survive the installation of an
updated version of the solution. In Microsoft Dynamics CRM 2011 (unlike
previous versions), new customizations are kept isolated from those of the
original solution. When a new version of the solution is imported, users will be
given the option of keeping their own customizations or overwriting them.
When a new solution is created, it is always created in an Unmanaged state.

Because a solution is just a container, user have relatively few choices to make
on creation. One piece of information that will be required is the name of a
publisher.
Managed Properties
When a managed Solution is imported, some properties of the components

become active. These are known as the Managed Properties. The actual
properties depend on the type of component, but include the following:
• Is Customizable
• Can change Display name
• Can change requirement level
Some components, such as Site Map, have no managed properties. The Managed
Properties button allows you to set the component's properties, provided that
component is in an unmanaged state.
Creating Solutions
Perform the following steps to create a new Solution:
1. From the Navigation pane, click Settings > Solutions.

2. Click New on the toolbar.
3. Fill in a Display Name for the Solution. When you move from this
field, the form will create a Name field entry from the display name.
4. Accept or modify the Name.
5. Click the list tool next to Publisher. Select a publisher from the list.
6. A Configuration Page can be added if one is set up as a web
resource.
7. Decide on a version number, which should be of the form
major.minor.build.revision (for example 1.1.1.0).
8. Enter a description of the Solution in the Description field.
9. Click Save or Save and Close.
3-19
Once you have created the Solution, the various components will be available in
the Navigation pane under Components. No components will be available for a
newly-created Solution. Creating certain Solution components is covered later in
this training offering. The purpose of this lesson is to provide a general overview
of the options for managing components.
Adding an Existing Component to a Solution
If a component already exists on the system, a reference to it can be added to the

Solution. This works similar to creating a new component - either select the type
of component to add from the option in the Components view, or navigate to the
specific component in the Navigation pane and select Add Existing. Operations
that can be performed on components include:
• Delete: removes the component from the system and any references
to the component in unmanaged Solutions. You may might not be
allowed to do this if the component is part of managed Solutions.
• Remove: removes the reference to the component from the Solution.
• Publish: changes to some components may might need to be
published before they take effect; this does not apply to all changes.
WARNING: The Delete option removes the component itself, not just the
reference to the component in the Solution.
Two specific components can be added for which there is no New option: Site
Map and Application Ribbon. These components allow modifications to
navigation areas and ribbons (application and/or entity) for a solution.
Customizing these components is beyond the scope of this training.
Showing Dependencies
Components can depend on other components. For example, relationships

depend on the entities to which they relate, charts depend on data from entities,
and so on. For a given component X, Show Dependencies displays a window
that shows the components that depend on X, and the components upon which X
depends. It is beneficial to verify this before you delete a component (it cannot be
deleted if other components depend on it).
Adding Required Components to a Solution
Because of dependencies between components, other components may need to be

included in a Solution to make the existing component function. When an
existing component is added, the system prompts the user whether he or she
wants to include the components upon which the existing component depends (if
any).
3-20
The Add Required Component button checks the current component and adds
to the Solution any other components upon which it depends. This frequently
happens when existing standard entities are added to a Solution, because they
tend to have many inter-dependencies. The Add Required Components button
does not check for dependencies that arise through custom code.
Publishers
The Publisher identifies the body that develops the solution (whether an in-house
development team, an individual, or an ISV). You can create Publishers from the
Customizations area or from the Find Publisher dialog when creating the
Solution. The Publisher information is organized into three tabs: General,
Contact Details, and Marketplace.
General Tab
The following information can be entered in the General Tab:
• Display Name: the display name for the publisher.

• Name: internal name for the publisher. This is based on the Display
Name with all disallowed characters removed (including spaces) and
all letters converted to lower case. The internal name can be
modified.
• Description: long text description of the publisher. This will be
visible to consumers of the Solution.
• Prefix: the prefix text (followed by an underscore) is used to prefix
the names of entities created in the Solution.
The prefix must start with a letter, be at least two characters long and
contain only alphanumeric characters. It cannot be "mscrm" (which
is used internally). The prefix cannot be more than eight characters
long, and any uppercase characters are converted to lower case. The
Name Preview field gives an example of what the prefix will look
like in entity names.
• Option Value Prefix: a set of digits that will precede four zeros to
make the first number that is used to identify individual options in
option sets (refer to the "Option Sets" topic for more information.
The Prefix value is generated from the characters that are used for
the Prefix to form a unique value.
Contact Details Tab
Use the fields on the Contact Details tab to provide contact information that
your Solution consumers can use.
Marketplace Tab
If a profile exists on the Microsoft Dynamics Solution Marketplace, details of the

profile will appear in the Marketplace tab.
3-21
Lab 3.1 - Creating a Solution

The objectives of this lab include:
• Create a new Solution

• Add a Publisher to a Solution
Scenario
In this lab, you will create a new Solution for use in subsequent labs. You will
create a Publisher to attach to the new solution, though the solution itself will
have no components at this stage.
Goal Description
To distribute a managed solution you should create a Publisher with the
following properties:
• Display Name: ADVWorks Publisher

• Name: ADVWorks Publisher
• Prefix: ADV
Solution Properties:
• Display Name: CRM2011 Part 1

• Publisher: ADVWorks Publisher
• Version: 1.0.0.1
Challenge Yourself!
Perform the following steps to complete this lab:
1. Create a new Publisher with the properties defined in the Goal

Description.
2. Create a new Solution using this Publisher with the properties set out
in the Goal Description.
3. Export the Solution as an unmanaged solution and store the exported
file on the Desktop.
Need a Little Help?
1. If necessary, log on to the CRM2011APP-NYC-DC1 virtual image

as the crmadmin and open Microsoft Dynamics CRM.
2. From the Navigation pane, navigate to Solutions in the Settings
area.
3. Create a new Solution called CRM2011 Part1.
3-22
4. Look up the Publisher field, but use the Look Up Record dialog
box to create a new publisher called ADVWorks Publisher, and
assign it a prefix of ADV.
5. Enter 1.0.0.1 in the Version field.
6. Save the Solution.
7. Export the solution as an Unmanaged solution. Save the exported zip
file on the desktop.
Step by Step
1. If necessary, log on to the CRM2011APP-NYC-DC1 virtual image

as the crmadmin and open Microsoft Dynamics CRM.
2. In the Navigation pane, click Settings > Customization > Solutions.
3. Select New to create a new Solution. Enter CRM2011 Part1 in the
Display Name field.
4. In the Publisher field, click the lookup icon.
5. In the Look Up Record dialog box, select the New button at the
bottom of the dialog page.
6. In the New Publisher form, enter ADVWorks Publisher in the
Display Name field, click in the Name field to automatically fill the
value from the Display Name, and enter ADV in the Prefix field.
Click Save and Close.
7. On the Look Up Record dialog box, the ADVWorks Publisher
record is selected. Click OK.
8. On the New Solution form, this selected publisher is displayed in the
Publisher field. Enter 1.0.0.1 in the Version field.
9. Click Save and Close.
10. From the Solutions view, select the CRM2011 Part1 Solution and
then click Export on the toolbar.
11. In the Export Solutions wizard, on the Publish Customizations
page, click Next.
12. On the Export System Settings (Advanced) page, click Next (do
not select any settings).
13. On the Package Type page, select Unmanaged and then click
Export.
14. 11. In the File Download dialog box (this can take a minute or two
to appear), click Save.
15. In the Save As dialog box, do not change the suggested file name,
click the Desktop as the location of the zip file, and then click Save
to store the solution.
16. Click Close once the download is complete.
3-23
Summary
Microsoft Dynamics CRM's enhanced, built-in customization tools can help
organizations customize the application's user interface and platform quickly and
efficiently, providing flexibility to an organization’s ability to meet their business
needs.
The product's multi-tier architecture provides 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.
3-24
Test Your Knowledge

1. What is the purpose of a Solution in Microsoft Dynamics CRM?
2. Which of the following features does the Microsoft Dynamics CRM platform
apply through workflow processes and plug-ins, or through the UI using
Dialog box or event scripts on Forms?
( ) Row-based security checking
( ) Business logic
( ) Direct database access
( ) Open Data protocol
3. How does an unmanaged Solution become managed?

( ) Export the Solution, and then import it as managed.
( ) Export the Solution as managed, and then import it.
( ) Export the solution, and Import it on a different Organization, the
switch to managed is automatic.
( ) Solutions cannot transition between these states, they are set as
managed or unmanaged when they are created.
4. What happens if more than one Solution on a system contains customizations

to the same component?
( ) The situation is not supported.
( ) The second Solution to be created or imported will have the
component deactivated.
( ) Microsoft Dynamics CRM will employ “merging and co-existence” to
allow the two Solutions to exist together.
( ) One of the Solutions will be disabled. You will be warned of this.
3-25
5. Which development methods allow you to create custom entities with

Microsoft Dynamics CRM?
( ) An external .NET assembly
( ) Site Map
( ) The Microsoft Dynamics CRM customization tools
( ) Web Resources
6. What is the difference between Delete and Remove when applied to a custom
component in an unmanaged Solution?
( ) Delete will delete the component from the system and all references to
it from all unmanaged Solutions. Remove simply removes the
reference to the component.
( ) Delete simply deletes the reference to the component from the current
Solution. Remove will remove the component from the system and
all references to it.
( ) Delete will delete the component from the Solution unless the
component has dependencies. Remove will delete the component
regardless of any dependencies.
( ) Delete applies only to Client Extensions, Plug-in Assemblies, SDK
Message Processing Steps and Service Endpoints and allows them to
be removed from Solutions.
7. Three of the most important factors in the success of a CRM implementation

include which of the following?
( ) A deep understanding of every Customization feature
( ) Understanding the organization's needs and expectations
( ) Maintaining a perspective on the implementation's long term success
( ) Having a strong implementation method and using it
8. What type of file(s) is/are created when a Solution is exported?

( ) A file with the extension .CRMSln, which contains the binary
definitions of the Solution components
( ) A file with the .dat extension that contains the Solution data and file
with the .cnf extension that includes the Solution configuration
options and metadata
( ) An XML file that contains the component structures and Solution
definition objects
( ) One .mdb file for each component that contains the SQL data tables
for the component and a .bat file that includes the SQL import
command
3-26
Quick Interaction: Lessons Learned

Take a moment and write down three key points you have learned from this
chapter
1.
2.
3.
3-27
Solutions
Test Your Knowledge
1. What is the purpose of a Solution in Microsoft Dynamics CRM?
MODEL ANSWER:
A Solution acts as a container for all the components that form part of a
customized system. A Solution provides a means of tracking and isolating
the components of different solutions. A Solution allows solutions to exist in
managed or unmanaged states.
2. Which of the following features does the Microsoft Dynamics CRM platform
apply through workflow processes and plug-ins, or through the UI using
Dialog box or event scripts on Forms?
( ) Row-based security checking
(•) Business logic
( ) Direct database access
( ) Open Data protocol
3. How does an unmanaged Solution become managed?

( ) Export the Solution, and then import it as managed.
(•) Export the Solution as managed, and then import it.
( ) Export the solution, and Import it on a different Organization, the
switch to managed is automatic.
( ) Solutions cannot transition between these states, they are set as
managed or unmanaged when they are created.
4. What happens if more than one Solution on a system contains customizations

to the same component?
( ) The situation is not supported.
( ) The second Solution to be created or imported will have the
component deactivated.
(•) Microsoft Dynamics CRM will employ “merging and co-existence”
to allow the two Solutions to exist together.
( ) One of the Solutions will be disabled. You will be warned of this.
5. Which development methods allow you to create custom entities with

Microsoft Dynamics CRM?
( ) An external .NET assembly
( ) Site Map
(•) The Microsoft Dynamics CRM customization tools
( ) Web Resources
3-28
6. What is the difference between Delete and Remove when applied to a custom
component in an unmanaged Solution?
(•) Delete will delete the component from the system and all references
to it from all unmanaged Solutions. Remove simply removes the
reference to the component.
( ) Delete simply deletes the reference to the component from the current
Solution. Remove will remove the component from the system and
all references to it.
( ) Delete will delete the component from the Solution unless the
component has dependencies. Remove will delete the component
regardless of any dependencies.
( ) Delete applies only to Client Extensions, Plug-in Assemblies, SDK
Message Processing Steps and Service Endpoints and allows them to
be removed from Solutions.
7. Three of the most important factors in the success of a CRM implementation

include which of the following?
( ) A deep understanding of every Customization feature
(√) Understanding the organization's needs and expectations
(√) Maintaining a perspective on the implementation's long term success
(√) Having a strong implementation method and using it
8. What type of file(s) is/are created when a Solution is exported?

( ) A file with the extension .CRMSln, which contains the binary
definitions of the Solution components
( ) A file with the .dat extension that contains the Solution data and file
with the .cnf extension that includes the Solution configuration
options and metadata
(•) An XML file that contains the component structures and Solution
definition objects
( ) One .mdb file for each component that contains the SQL data tables
for the component and a .bat file that includes the SQL import
command
3-29
3-30

CRM

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CRM

Hochgeladen von

Copyright:

Verfügbare Formate

Chapter 3: Customizing Microsoft Dynamics CRM Overview

CHAPTER 3: CUSTOMIZING MICROSOFT

• Explain the importance of defining and using an effective

• Understanding the application architecture and the types of

A strong implementation methodology helps create a plan that does the

• Sets the organization's expectations.

The adoption of a Customer Relationship Management strategy frequently

Extended CRM (xRM)

The Microsoft Dynamics CRM platform is customizable at many levels. Simple

NOTE: The Microsoft Dynamics Marketplace is a site that is maintained by

The Microsoft Dynamics CRM framework simplifies this development work,

Microsoft Dynamics CRM Architecture

In client/server architecture, most of the application logic is found in the client.

Microsoft Dynamics CRM's Multi-Tier Architecture

FIGURE 3.1 MICROSOFT DYNAMICS CRM CUSTOMIZATION

In the multi-tier design that is shown in the “Microsoft Dynamics CRM

NOTE: A record is an instance of an entity. When you create an Account record

• Managing access to objects by requesting security checks from the

Domain and Business Logic

• Workflow processes: Microsoft Dynamics CRM Workflow enables

Workflow processes are triggered by events within Microsoft

There is a published set of events that a Plug-In can subscribe to. As

NOTE: Creating plug-ins requires development expertise and is beyond the

• It introduces the opportunity for invalid or corrupt data to be added

Filtered Views - Exception to the Rule

Filtered Views have the following characteristics:

• Any application that can access views in a SQL Server can

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

FIGURE 3.2 FILTERED VIEWS

Filtered Views and Database Security Checking

Filtered Views and IFDs

Customizing Microsoft Dynamics CRM

In some organizations, the System Customizer role is assigned to a "power" user

EXAMPLE: Contoso is a small electronics distributor that does not have a

Permissions Needed for Customizing

FIGURE 3.3 CUSTOMIZATION TAB IN SYSTEM ADMINISTRATOR SECURITY

Most of the customization-related privileges are limited to the following two

• Organization: allows the user to customize an entity component.

• Customizing forms, views and charts.

Customizing the Application - Forms

• Modifying an existing form to add new tabs, sections, and fields.

• Modifying field properties such as labels and layout options.

FIGURE 3.4 FORM CUSTOMIZATION

Customizing the Application - Views

• Administrators can create public views for the entire organization to

Each view includes the following elements:

FIGURE 3.5 VIEW DEFINITION

Customizing the Schema

Customizing the Microsoft Dynamics CRM schema by using the application's

• Adding new entities to Microsoft Dynamics CRM

Programming skills are not required to make schema modifications because

Application Event Programming

NOTE: Discussion of application event programming is outside the scope of this

NOTE: Discussion of client extensions is outside the scope of this training.

Extending the Application Using .NET

Workflow is a powerful type of platform customization in Microsoft Dynamics

• Specify actions to take when specified conditions are met.

FIGURE 3.6 WORKFLOW ILLUSTRATION

Microsoft Dynamics CRM uses Microsoft Windows Workflow Foundation (WF)

• End-users can design simple workflow rules that apply basic

NOTE: Discussion of Microsoft Dynamics CRM workflows and dialog box is

FIGURE 3.7 GRAPH OF MICROSOFT DYNAMICS CRM DATA GENERATED

Using Solutions to Manage Customizations