Extended CRM Capabilities

Microsoft Dynamics CRM

Prepared for
[Customer Name]

Project
[Project Name]

Prepared by
[Author Name]

Contributors
[Document contributors]

1
Sure Step

Table of Contents
Table of Contents ................................................................................................................................... 2

1 Overview ........................................................................................................................................ 3

2 Microsoft Dynamics CRM 2011 Application Framework Capabilities ................................................ 4

Sure Step

1 Overview
The Dynamics CRM application framework has a number of capabilities that can be used to help support an
xRM business solution. This document highlights key capabilities and some key topics in using these
capabilities successfully during the design process.

This document makes the assumption that the xRM selection decision has already been made, so it does
not provide material to directly support that decision.
Sure Step
2 Microsoft Dynamics CRM 2011 Application Framework Capabilities
Capability Scope
Core Configuration of the entity model is a
Configuration standard activity in all types of project
using the Microsoft Dynamics CRM
platform. In xRM projects, a rich set of
customizations may be needed to
create a solution that is specific to the
problem domain.
Relationships Entity relationships define the ways
that entity records can be associated
with records of other entities or the
same entity. Creating new entity
relationships creates new table
relationships in the database.
Data Access There are two core data-access
Security models: One driven by Business Units
and data ownership, the other
through explicit data sharing with
teams and individuals. Records can be
owned by either an individual owner
or a team.
Field-Level Security: It can be used to
restrict access to high-impact business
fields to specific users and teams.
Role-Based Forms and Views: Used for
displaying forms and views based on
the user’s role.
Operation As well as managing data-record
Privileges access, the platform provides a
and Security number of capabilities, such as being
able to send mail on behalf of another
user or exporting data to Microsoft
Office Excel.
Service The Microsoft Dynamics CRM platform
Oriented exposes a set of basic Create, Read,
Architecture Update, and Delete (CRUD) Web
Service operations for all standard and
custom entities. These operations can
be used to build rich composite
applications, along with providing read
data access by the platform-generated
“filtered views” (which maintain data
security).
Cloud Microsoft Dynamics CRM 2011 has
Development been integrated with the Microsoft
Windows Azure platform by coupling
the Microsoft Dynamics CRM event
Risks and Mitigations
In Microsoft Dynamics CRM 2011 the distinction
between standard entities (also known as system
entities) and custom entities has diminished. But
consideration should be given to repurposing a
standard entity that is not being used.
A connection could be leveraged for relationships
between individual records that are less formal and
more flexible.
Either model may be appropriate. But in an xRM
solution where security modelling is shared with
other applications, consideration should be given to
how access to any given record is granted or
prevented in alignment with views of equivalent data
in those other applications. For example, if there is a
Microsoft SharePoint document library, how is
document access correlated with data access within
Microsoft Dynamics? The security model should be
designed to avoid excessive sharing.
Field security can be only applied to custom fields
(might change in the future).
Ensure that the full range of platform capabilities
(typically identified at the bottom of the relevant
Security Role configuration page) is understood and
discussed. Ensure that the design indicates which
capabilities should be disabled.
The Web Service operations may not be able to easily
support high-volume transactions or query rates. This
issue can be mitigated by provisioning additional
servers in this role, or considering whether some
data can be handled offline and loaded into the
application “on demand” by using techniques such as
IFrames. Alternatively, the filtered views may
provide appropriate access.
Synchronous plug-ins are not supported.
ACS needs to recognize the Microsoft Dynamics CRM
deployment as a supported issuer.
Production AppFabric should be used.
Sure Step
execution pipeline to the Windows
Azure platform AppFabric Service Bus
in the Cloud. In essence, the Microsoft
Dynamics CRM pipeline connects to
the AppFabric Service Bus enabling the
data that has been processed as part
of the current Microsoft Dynamics
CRM operation to be posted to the
bus. AppFabric solutions that are
“CRM aware” can listen for and read
the data that is posted on the service
bus by Microsoft Dynamics CRM.
Built-in Certain entities have operations that
Operations are presented in the platform user
interface that may not be appropriate
for the xRM solution, especially if an
entity has been repurposed. For
example, User Interface elements such
as buttons or “more actions” elements
may expose “meta-operations,” such
as converting a Lead to a Customer.
Location of Certain business logic can be built on
Business the client (typically by using JScript on
Logic the entity form) or server (by using a
plug-in or workflow).
Dashboard, Dashboard, Inline data visualization,
Inline Data and reports are a standard element of
Visualization, the platform. XRM solutions may
Reporting require additional richness.
and Analysis
Provisioning The xRM platform provides a great
of Multiple strategic capability for adding further
Applications applications to the deployment, either
as extensions to an existing solution or
as a new tenant on the existing
hardware.
Extensibility The xRM platform has a rich set of
extensibility points, including
workflow, scripting, plug-ins, and
process dialogs.
When defining the analysis and design requirements,
check that the full functionality of a standard entity is
appropriate for the xRM solution and, if not, whether
a custom entity that requires functionality to be
developed is likely to give a closer match to the
actual requirements. Also, look for opportunities for
the built-in operations to add “unexpected” value to
the solution.
Ensure that it is understood when the business logic
should be executed. Client-side richness may be
good, but data that is presented via Web Services will
then bypass this logic. For server-side logic, consider
whether asynchronous execution (which may
increase scalability) is appropriate or not.
Where an xRM solution is integrating with other data
stores, it may become appropriate to use data
warehousing and analysis techniques to fully cover
the business-intelligence requirements. Ensure that
the richness of the requirement is sufficiently
understood to make the right design decision.
Consider whether feature sets should be built within
a single application and delivered to subsets of users
via role security, or whether they should be split into
multiple applications for different user communities
that may then share core data through integration
techniques.
As well as ensuring that business logic is correctly
positioned in the solution for business-process
execution, ensure that it reflects the likely evolution
of the solution. Business rules that need flexible
configurations are perhaps best built by using the
platform toolkits, while other features may lend
themselves to being built as Microsoft .NET
components that can be shared with other
components.
Performance and maintainability should be
considered when choosing the components required
to meet the business requirements.