0.02_extended Crm Capabilities.docx

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

Risks and Mitigations

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.

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.

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.

A connection could be leveraged for relationships between individual records that are less formal and more flexible.

Data Access Security

There are two core data-access 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.

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

Operation Privileges and Security

As well as managing data-record access, the platform provides a number of capabilities, such as being able to send mail on behalf of another user or exporting data to Microsoft Office Excel.

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.

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

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.

Cloud Microsoft Dynamics CRM 2011 has Development been integrated with the Microsoft Windows Azure platform by coupling the Microsoft Dynamics CRM event

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 Operations

Certain entities have operations that 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.

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.

Location of Business Logic

Certain business logic can be built on the client (typically by using JScript on the entity form) or server (by using a plug-in or workflow).

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.

Dashboard, Inline Data Visualization, Reporting and Analysis

Dashboard, Inline data visualization, and reports are a standard element of the platform. XRM solutions may require additional richness.

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.

Provisioning of Multiple Applications

The xRM platform provides a great strategic capability for adding further applications to the deployment, either as extensions to an existing solution or as a new tenant on the existing hardware.

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.

Extensibility

The xRM platform has a rich set of extensibility points, including workflow, scripting, plug-ins, and process dialogs.

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.