CRM Architecture and CRM Framework Basics

CRM stands for Customer Relationship Management. It is a process or methodology used to learn more about customers' needs and behaviours in order to develop deeper stronger relationships with them leading to more business for you and better service for them. There are many technological components to CRM, but thinking about CRM in primarily technological terms would be a mistake. A more useful way to think about CRM is as a process that will help bring together lots of pieces of information about customers, sales, service issues, and responsiveness to their needs and market trends.

In essence therefore, CRM helps businesses use their technology and their people to gain insight into the behaviour of customers and the value of those customers.

Types of CRM Software

There are a range of CRM software products available but they generally fall into several identifiable categories:

Sales Force Automation Software

This comprises several key component sections and functions:

Contact management
Contact management software stores, tracks and manages contacts and relationships of an enterprise with its customers (and also suppliers).

Opportunity management
Sales Opportunity Management software enables an organization to manage, track and forecast sales leads. Also helps understand and improve conversion rates.

Campaign management
Campaign Management software enables an organization to generate, manage and track sales leads and opportunities from specific marketing campaigns or initiatives by selecting target clients (or prospects) and communicating with them in a specific way then monitoring uptake or conversion to sales.

Web based CRM (i.e. CRM delivered and managed over the web and which very often communicates directly with the client/target organizations)

Web based CRM is normally rented on a per user per month basis and is not installed on the client premises' systems but accessed via a web browser. The advantage of this is that there is no need to buy hardware or software or impact the existing IT systems of an organization.

Hosted CRM
Hosted CRM software enables web based customer interaction, tracking of contacts, call logs, campaign management and service management all online without the need to buy any hardware or software or install it on the organization's own premises. The system is "hosted" by a third party provider and the users pay a usage or connection fee, normally monthly.

Survey Management Software
Survey Management Software automates an enterprise's Electronic Surveys, Polls, Questionnaires and enables the organization to understand customer preferences.

Event Management Software
Event Management Software automates an enterprise's sign-up processes to events, either electronic events or those held in conventional premises.

Customer Service

Customer service software is focused primarily on the help desk concept which is generally a "post-sales" operation. Some products (such as iportinstant) have both customer service and sales force automation software in the one solution allowing a complete picture of customer relationships. It includes software to manage the following:

• Call Center Software
• Help Desk Software
• Project Management Software
• Document Management Software

Partner Relationship Management

This is software which is aimed at managing a channel i.e. not selling direct to end clients but through an intermediary of third-party agent.

• Contract and Project Management Software
• Distribution/Supply Chain Management Software

Advantages of CRM

Using CRM, businesses strive to:

• Provide better customer service
• Increase customer revenues
• Identify, acquire and retain new customers
• Cross sell/Up Sell products more effectively
• Help sales staff close deals faster
• Make call centres more efficient
• Simplify marketing and sales processes
• Share information between diverse groups securely
• Manage cross-discipline project teams more efficiently
• Centralize information
• Control workflow and documentation procedures

The types of data CRM projects collect

• Responses to campaigns
• Shipping and fulfillment dates
• Sales and purchase data
• Account information
• Web registration data
• Service and support records
• Demographic data
• Web sales data

Microsoft Dynamics CRM Architecture Overview

The platform is the heart of the Microsoft Dynamics CRM system. When you use the Microsoft Dynamics CRM SDK, you are building on top of this system. The Microsoft Dynamics CRM platform supports smaller deployments and can scale for application service provider models also. The security mode protects the platform from unauthorized access across the Web. The main platform components are as follows:

• Microsoft SQL Server database
• Web services
• System services (workflow, metadata, and integration)
• A query processor that supports the entity model
• Secured ad hoc queries that use an XML fetch statement to protect the physical database
• Plug-ins for business logic extensibility
• Reporting services

When you develop an application that uses the Microsoft Dynamics CRM server, you use Web services to communicate with the underlying platform layer.

The server platform is responsible for creating domain-specific objects. In Microsoft Dynamics CRM, these objects include contact, lead, opportunity, account, business unit, and more. The goal of the platform is to implement the service-specific rules by manipulating and combining the underlying domain objects.

The platform does not impose business-specific logic. This layer imposes only generic domain constraints. It contains the building blocks for an application, but by itself is nothing more than a collection of related objects. However, the interaction between those objects within the domain can be assumed to implement more extensible logic such as the quote-to-order-to-invoice processing and pricing logic.

The server platform also controls access to objects through security, controls access to the database, and raises events for workflow processes and custom business logic implementations. The platform layer provides for both incoming and outgoing e-mail processing through Microsoft Exchange.

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 users 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 data through available APIs using languages such as Transact-SQL. But the client/server architecture has many shortcomings and there is only so much that a database designed for general use can provide.

Microsoft Dynamics CRM's Multi-Tier Architecture

Microsoft Dynamics CRM is a web-based application that uses a multi-tier architecture. This structure provides many benefits that support scalability, flexibility, and extensibility that cannot be matched using client/server architecture.

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 parts of the picture marked with a cog indicate places where the Microsoft Dynamics CRM customizer can interact with the platform through code, the UI, custom reports etc. This course concentrates on the part labelled Extendable Application. The other parts will be described briefly, but detailed treatment is beyond the scope of this course.

The Microsoft Dynamics CRM platform removes the complexity that developers may 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 the Application platform, ultimately from the Microsoft Dynamics standard UI or from customization code.

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:

• Controlling access to objects through security
• 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 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 (or Extended CRM) application.

Database Access

The Microsoft Dynamics CRM platform has a Data Access layer to handle all interactions between the application and Microsoft SQL Server, which contains the Microsoft Dynamics CRM database.

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

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; or through the UI using Dialogs or event scripts on Forms.

• 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. The Workflows apply the business logic using built in steps or by allowing developers to add their own custom code to carry out a step.
• 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 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. 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 behaviour 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.

Extensibility Architecture

You can customize Microsoft Dynamics CRM in different areas as shown in the following diagram. These customization points are shown in the color orange in the diagram.

Customization Tools: Customize, add, and rename entities.

ISV Script/Form Customization: Customize forms by using the client-side scripting.

ISV Code: Add your own features to the application by using the application configuration file and the SDK.

Custom Reports: Use filtered views to create custom reports within Microsoft Dynamics CRM and directly in Microsoft Excel, Microsoft Access, and more.

Import/Export: Export your customization for installation into a production environment.

Plug-ins: Augment the Microsoft Dynamics CRM business logic with your own plug-ins, for both online and offline applications. These extensions can also be used for integration to external systems. In the previous version, this feature was known as callouts.

Workflow Custom Activities: Call out to external systems from your workflow rules. Create custom workflow activities that can be used by your workflow rules. In the previous version, this feature was known as workflow .NET assemblies.

In addition, the following capabilities are also available:

Microsoft Dynamics CRM for Microsoft Office Outlook Customization: Customize your offline client by using the configuration file and custom code that uses the SDK.

Features in Microsoft Dynamics CRM

Security

The Microsoft Dynamics CRM SDK provides a security model that provides improved data integrity and privacy, and also supports efficient data access, teamwork, and collaboration.

Microsoft Dynamics CRM provides you with a security model that protects data integrity and privacy and supports efficient data access and collaboration. The goals of the model are as follows:

• Support a licensing model for users.
• Provide users with access only to the appropriate levels of information that is required to do their jobs.
• Categorize types of users by role and restrict access based on those roles.
• Support data sharing so that users can be granted access to objects that they do not own for a specified collaborative effort.
• Prevent a user's access to objects the user does not own or share.

Role-based security in Microsoft Dynamics CRM focuses on grouping a set of privileges together that describe the responsibilities (or tasks that can be performed) for a user. Microsoft Dynamics CRM includes a set of predefined security roles, each of which is a set of user rights aggregated to make user security management easier. Each application deployment can also define its own roles to meet the needs of different users.

Object-based security in Microsoft Dynamics CRM focuses on access rights to entities.

 

Organization and Business Structures

There are three primary entities within the organization. These are users, teams, and business units. Users represent people who use the Microsoft Dynamics CRM application. Teams are arbitrary groups of users created and defined by a user in an organization. Business units are the structural units of an organization, as defined by a user in the organization. They are the primary container entity within the organizational hierarchy. It is the business unit structure that determines and defines the concepts of Basic, Local, Deep, and Global access. For more information, see Microsoft Dynamics CRM Security and Access Levels sections. The following diagram is an example of a Microsoft Dynamics CRM business unit structure for an organization.

 

 

The organization in the previous diagram contains six business units in a simple hierarchy. The business units directly underneath the organization are unrelated in any apparent structural way except that they all belong to the same organizational structure.

The two business units labeled Department A1 and Department A2 are child business units of Business A. These two business units have a special relationship with regard to users parented to Business A. They serve up business objects to users within Business A who have "Deep" access. Notice that you cannot construct matrix organizations within the Microsoft Dynamics CRM organizational structure.

Users within Microsoft Dynamics CRM must be "parented" to a business unit and cannot be parented to the organization object itself. In the previous diagram, this means that users can be located at any node except the top-level node labeled Organization.

Because of the multi-tenant architecture of Microsoft Dynamics CRM, multiple organizations can be hosted on a Microsoft Dynamics CRM server.

Entity Model

The entity model is your view to the objects that are used in Microsoft Dynamics CRM. It supports Microsoft Dynamics CRM requirements for each entity in the system. In Microsoft Dynamics CRM, the platform consists of several high-level areas: sales force automation, customer service and support, scheduling, and marketing automation.

This section covers the entity model for Microsoft Dynamics CRM. The entity model illustrates the developer's view of the business and service entities. Described herein are the entities used by all Microsoft Dynamics CRM developers, such as Contact, Account, Lead, and Opportunity. This includes the entity relationships and behavior. The entities are divided up to correspond to the areas shown in the Web application.

In This Section

General Information about Entities

Specifies general information about the entity model such as common actions that can be performed on most entities. Describes actions or operations that can be performed on entity instances, the ownership model for entity instances, describes the types of relationships that can be established between entities, Explains how operations cascade from entities to their related entities.

Organization Management

We can see entities that describe your organization: organization, sites, business units, users, and teams.

Customer Management

We can have entities used to describe your customers and the activities for a business: account, contact, queue, and all kinds of activities.

Sales Force Automation

We can have entities used to manage your sales processes: lead, opportunity, competitor, quote, order and invoice, product catalog, and sales literature.

Marketing Automation

We can have entities used to run marketing campaigns: campaign and list.

Customer Service Management

We can have entities used for customer service: contract, incident, subject, and the knowledge base.

Scheduling

We can have entities used for scheduling: calendar, equipment and facilities, schedule, appointment, and service appointment.

Queries, Notes and Attachments

Learn about entities that work with other entities:  user query, saved query, annotation, and attachments.

 

Database

Microsoft Dynamics CRM is a metadata-driven product. The metadata layer basically abstracts the underlying data storage details, such as schema and data access, from the higher level constructs of domain-logic implementation and user interface. The metadata can be thought of as a description of the underlying data structures that controls how the application (platform and user interface) operates and displays itself. This version contains new APIs that allow you to add or update the metadata. The platform uses the metadata to buffer itself from changes to the underlying database structures. If a table definition changes, for example, when columns are added or removed, the platform code continues to operate without any performance or degradation. This means that Microsoft Dynamics CRM can be altered significantly to meet a particular business or vertical definition and still operate without interruption.

The Microsoft Dynamics CRM platform is not the only consumer of the metadata. The application layer uses the rules in the metadata to present the exact user experience offered by vertical solutions and customizations. These rules include attribute type definitions, entity definitions, and attribute context rules. Attribute metadata describes the underlying type structure of a given attribute. This includes the fundamental data type (such as string, integer, or date) and the information that effectively limits the attribute's type definition (such as its size and range values). Attribute context rules describe when and how a given attribute can be used. For example, some attributes are writing-once, such as order numbers. Other attributes are always read-only and are supplied by the platform itself. The metadata captures all these rules about context. It also captures business-defined rules, such as business-recommended and business-required attributes.

Workflow

The workflow feature supports extending the functionality of the Microsoft Dynamics CRM system by enabling the user to create and execute custom business processes. The workflow feature is built on top of Windows Workflow Foundation, which provides the programming model, run-time engine, and tools for quickly building workflows.

Windows Workflow Foundation

The Microsoft Dynamics CRM Workflow infrastructure is based on Windows Workflow Foundation. The Windows Workflow Foundation provides a runtime engine, a framework, a base library of activities, and default implementations of the runtime services. The Windows Workflow Foundation runtime engine manages workflow execution, and supports workflows that can remain active for extended periods of time. It preserves the state of workflow execution during computer shutdown and restart.

Workflow Architecture

The workflow management system is a part of the Microsoft Dynamics CRM extensibility story that includes the Microsoft Dynamics CRM SDK, plug-ins, forms, and other components.

The following diagram illustrates the high-level system architecture for Microsoft Dynamics CRM and highlights parts of the system that are specific to workflow.

 

The internal Microsoft Dynamics CRM components that support the Microsoft Dynamics CRM workflow programming model include Web services, shared platform, and business logic.

The shared platform consists of common Microsoft Dynamics CRM components that provide registry, metadata cache, and data access services. Business logic contains the implementation of business logic for Microsoft Dynamics CRM business entities.

The external components are as follows:

• Windows Workflow Foundation object model, which contains a set of classes used to create and parse workflow definitions in XAML format.
• Windows Workflow Foundation execution, which contains a set of classes used to execute workflows.

The Microsoft Dynamics CRM Workflow infrastructure consists of the following components:

• Workflow Object Model, which contains a set of classes that use the Windows Workflow Foundation object model and expose Microsoft Dynamics CRM workflow activities.
• Workflow business logic, which implements business logic for workflow-specific entities.
• Workflow Execution, which provides workflow execution services such as workflow hosting and persistence.

The Microsoft Dynamics CRM workflow programming model is supported by the following data:

• Business data, which contains information associated with Microsoft Dynamics CRM entities.
• Workflow configuration data, which includes workflow definitions, compiled workflows, and workflow settings.
• Workflow runtime data, which is required to execute workflows and implement such workflow features as persistence and notifications.

Workflow and the Asynchronous Service

The asynchronous service enables you to execute, monitor, and manage various long-running operations, such as bulk import, bulk mail, and workflows. To improve performance, scalability, and reliability of Microsoft Dynamics CRM, these operations are run asynchronously. This means that a requested operation is not processed instantly, but added to a queue and processed by the system at an appropriate time.

When an event is raised in the Microsoft Dynamics CRM platform pipeline, all workflows that are associated with the event are executed by the asynchronous service. The workflow event handlers are added to the asynchronous queue and processed according to the event execution order.

Workflow and the Unified Event Model

Microsoft Dynamics CRM 4.0 and after versions introduces a unified event model that is used in both plug-ins (callouts) and in workflow. This event processing subsystem adds more flexibility to the execution of workflows and plug-ins by introducing the pipeline execution model.

Using this model, workflows and plug-ins are executed based on their registration, message type and a predefined set of configurable parameters. The core platform operations take part in the execution sequence to form a much more reliable and extensible execution model.

Workflow Life Cycle

The life cycle of a workflow describes the state transitions from creation through execution. A workflow can be in one of the following states: Ready, Suspended, Locked, and Completed. The workflow events that occur throughout the lifetime of the workflow cause a transition from one state to another.

During the activation of a workflow, the workflow subscribes to specific Microsoft Dynamics CRM events. When these events are fired in the platform, a snapshot of the workflow dependencies and input parameters are created and a new asynchronous operation is added to the asynchronous service queue manager. The asynchronous operation represents a workflow execution job and awaits execution in the queue in the Ready state.

When the asynchronous operation is processed, a workflow instance, associated with this operation, is created by the Windows Workflow Foundation run-time engine and the state of it is changed from Ready to Locked.

The asynchronous operation is updated with the workflow instance state status on each transition. When the asynchronous operation is blocked, the Windows Workflow Foundation run-time engine puts the workflow instance into the Suspended state and removes it from the memory. When the Suspended state conditions are satisfied, the workflow instance is loaded back into the memory.

The workflow execution resumes by putting the workflow instance into a Ready state and then into a Locked state. In the simple scenario, the workflow instance moves to a Completed state when all workflow activities have completed successfully.

The state of asynchronous operations can also be changed by the user. For example, an asynchronous operation that is in a Suspended state can explicitly be restarted by the user.

Avoiding a Workflow Infinite Loop

A poorly designed workflow can result in an infinite loop where the workflow runs indefinitely, using up available system resources like memory and disk space. For example, consider a workflow that creates an account that is registered to run when an account is created. When a user creates an account, the workflow runs and creates another account that causes the workflow to run again, and so on.

 

Microsoft Dynamics CRM 3.0 Workflow Backward Compatibility

Microsoft Dynamics CRM 4.0 and after versions provides complete backward compatibility for workflows created for Microsoft Dynamics CRM 3.0. It also offers an upgrade path for workflows and workflow assemblies developed for that version.

E.g. Microsoft Dynamics CRM 3.0 is supported by using Microsoft .NET Framework assemblies as an extension mechanism for workflows. Any previously registered .NET assemblies that you have developed for Microsoft Dynamics CRM 3.0 will continue to work after you upgrade the system to Microsoft Dynamics CRM 4.0. Upon upgrade, the configuration information for the Microsoft Dynamics CRM 3.0 workflow is added to the database but the supporting files remain on the server.

Although every effort is made to maintain backward compatibility with Microsoft Dynamics CRM 3.0 .NET Framework assemblies, this programming model is deprecated in Microsoft Dynamics CRM 4.0. If you must change a plug-in or workflow .NET assembly from an earlier version of Microsoft Dynamics CRM, you should upgrade the code to use the new Microsoft Dynamics CRM 4.0 event model to avoid issues with versioning. If you do not do this, you may have issues with plug-ins and workflows such as failure to run or registration failure.

The following workflow items are upgraded:

• Workflow Definitions
• Running Workflow Instances
• Workflow Log
• .NET Assemblies

The following workflow items are not upgraded:

• Microsoft Dynamics CRM 3.0 workflow entities and messages. Applications that use Microsoft Dynamics CRM 3.0 workflow entities and messages must be upgraded so that they use Microsoft Dynamics CRM 4.0 workflow entities and messages. For more information, see Deprecated Entities and Deprecated Messages.
• Workflows that include the Post URL action, which was deprecated in Microsoft Dynamics CRM 3.0.
• Order of execution of upgraded workflows.
• Workflows that include change stage or skip step.

 

Workflow Authoring Types

You can create custom workflow activities in Visual C# or Visual Basic .NET code by creating an assembly that contains a class derived from one of the Windows Workflow Foundation activities. This assembly is annotated with .NET attributes to provide the metadata that Microsoft Dynamics CRM uses at runtime to link your code to the workflow engine. After you have created an assembly that contains one or more workflow activities, you register this assembly with Microsoft Dynamics CRM. This process is the same as the process that is used to register a plug-in. The custom workflow activity can then be incorporated into a workflow by using the Workflow Designer found in the Microsoft Dynamics CRM Web application.

Workflow Object Model

The Microsoft Dynamics CRM workflow object model is a set of classes that uses the Windows Workflow Foundation object model and exposes Microsoft Dynamics CRM workflow activities. These classes are found in the Microsoft.Crm.Sdk assembly. Activities are the elemental units of a workflow. They are added to a workflow to form a hierarchical tree structure. When all activities in a given path are finished running, the workflow instance is completed.

Workflow Persistence and Shutdown

A workflow can be a long-running business operation that might take hours, weeks, or months to be completed. It can be effectively idle for long periods of time waiting for input from users or other systems.

To improve performance, scalability, and reliability of Microsoft Dynamics CRM, long-running operations such as workflows use the asynchronous service.

The asynchronous service, as the host of the Windows Workflow Foundation runtime engine, cannot always cache and keep active all objects that accumulate during continued workflow activity. When certain conditions, such as restart or shutdown, occur while a workflow is running, the workflow runtime engine uses a persistence service to save the state of the workflow instance onto the disk. The persistence service is also invoked when other conditions occur, such as when a workflow becomes idle and is waiting for some external event to occur. Persisting these idle workflow instances saves memory and greatly increases scalability. If a server that is running the asynchronous service is shut down or if the workflow crashes during execution, the workflow can be restarted from its last persisted point after the server restarts. When the workflow resumes its operations and is no longer idle, the state of the workflow instance is restored in memory to the state at the last persisted point.

Supported Entities for Workflow

Please find the list of entities supporting the workflow

Business Logic Extensions

Microsoft Dynamics CRM 4.0 provides an extension mechanism for implementing custom platform-based business logic. Developers are not limited to creating custom business logic through workflow processes alone. They can also construct business logic that is integrated with Microsoft Dynamics CRM and executes in response to a particular system event for a specific entity. Be aware that these business logic extensions are not supported in Microsoft Dynamics CRM Online.

This extension mechanism supports an event handler interface that is based on a simple pipeline execution model. The pipeline model allows for event handlers, also known as plug-ins, to be executed before or after the core operation of the system. The platform metadata stores information about each entity in the system. This information about entities can be used to track the list of event handlers, the class names, and whether a given handler is required for an action. For example, the account object can have several registered handlers. These handlers are stored in call order, which is determined by priority. When an action occurs caused by user interaction with the Web application or a Web service call, the platform checks the metadata for registered event handlers. If a handler is registered for notification, the platform executes a well-defined event handler method, passing it run-time information.

APIs

The platform APIs are your view to the logical Microsoft Dynamics CRM system. The APIs are somewhat flat and require knowledge of the Microsoft Dynamics CRM Entity Model.

Custom Workflow Activities

Required Assemblies

The following assemblies must be added to your project. They can be found in the SDK\Bin folder.

Microsoft.Crm.Sdk.dll

Microsoft.Crm.SdkTypeProxy.dll

Registering Custom Workflow Activities

After your custom workflow activity has been compiled, you have to register this assembly as a plug-in. Your workflow will then appear in the workflow form in the Microsoft Dynamics CRM Web application.

Workflow Object Model

The Microsoft Dynamics CRM workflow object model is a set of classes that uses the Windows Workflow Foundation object model and exposes Microsoft Dynamics CRM workflow activities. These classes are found in the Microsoft.Crm.Sdk assembly.

Activities are the elemental units of a workflow. They are added to a workflow to form a hierarchical tree structure. When all activities in a given path are finished running, the workflow instance is completed.

Plug-ins

A plug-in is custom business logic that you can integrate with Microsoft Dynamics to modify or augment the standard behavior of the platform. Another way to think about plug-ins is that they are extension points made available by the Microsoft Dynamics CRM platform. You can subscribe a plug-in to a published set of events to have your code run when the event occurs. As part of the subscription, you must specify an event handler. The event handler is a segment of code that runs in response to the platform event that is fired. Your event handler must implement the IPlugin interface.

The plug-in model supports both pre-events and post-events. Pre-event plug-ins are run before a core system operation occurs; post-event plug-ins are run after a core system operation has been completed. There can be any number of pre-event plug-ins or post-event plug-ins registered for a given entity.

Because of their very nature, plug-in assemblies must be readable by everyone in order to work correctly when registered in the Microsoft Dynamics CRM system. Therefore it is a security best practice not to develop plug-in code which contains any system logon information, confidential information, or company trade secrets.

 

 

Event Framework Overview

With Microsoft Dynamics CRM you have the ability to extend or customize the functionality of the Microsoft Dynamics CRM server through the integration of custom business logic. You can customize the product to support the way your company does business, and you can add new features to the product. The technology that enables your custom solutions to be developed and integrated into the Microsoft Dynamics CRM server is called the event framework.

The event framework enables you to create rich vertical and horizontal solutions on top of Microsoft Dynamics CRM by supporting the development and integration of custom business logic (computer code) with Microsoft Dynamics CRM in a reliable and portable way. After your custom business logic has been integrated into Microsoft Dynamics CRM, it can be executed synchronously as part of the main Microsoft Dynamics CRM execution path, or asynchronously from a managed queue. Business data can be passed to your custom code, which can then perform actions based on the nature of the information, or modify the information itself.

The Microsoft Dynamics CRM Event Framework provides the following key features:

• An improved event processing subsystem for Microsoft Dynamics CRM. This subsystem provides a unified method of executing both plug-ins and workflow activities, which results in improved reliability, an enhanced feature set, and plug-in portability.
• A unified event framework API for extending the Microsoft Dynamics CRM platform through the development of custom business logic in the form of plug-ins and workflow activities.
• An API for the deployment of plug-ins and workflow activities to the Microsoft Dynamics CRM database. Deployment of plug-ins and activities to the database instead of to a Microsoft Dynamics CRM server's hard disk enables automatic distribution throughout a server cluster in a datacenter.
• Backwards compatibility for Microsoft Dynamics CRM previous version callouts.
• Synchronous and asynchronous execution of plug-ins. Synchronous plug-ins are executed in a pre-defined order as part of the main Microsoft Dynamics CRM event processing. Asynchronous plug-ins are queued and executed independently.

Plug-in Entity Model

The Microsoft Dynamics CRM plug-in entity model is a set of classes that describe an assembly that contains one or more plug-ins or custom workflow activity types. In addition, it defines entities used for plug-in registration. These entity classes are found in the CrmService Web Services Description Language (WSDL).

The Plug-in Assembly entity describes an assembly that contains one or more plug-ins or custom workflow activities to the Microsoft Dynamics CRM system. The entity provides information about the assembly such as when it was created or modified, where it is located, and the actual bytes in the assembly.

The Plug-in Type entity describes an object type that a plug-in assembly contains. This type can be either a plug-in or a custom workflow activity. Plug-ins must implement the IPlugin interface.

The Plug-in Registration entities define an SDK message, the entities that support a particular SDK message, and the entities used to register a plug-in or custom workflow activity.

The SDK Message entity defines a message to the platform. The message represents the operation that the platform is to perform. This entity should be considered read-only. You cannot use this entity to create or update a message in the platform.

The SDK Message Filter defines what entity type supports a particular SDK message. It also identifies whether a custom plug-in can be registered for the message and executed when the message is processed by the event execution pipeline.

The SDK message processing entities are used when registering a plug-in or custom workflow activity in a stage of the event execution pipeline.

 

 

Programming Reference

Below are the list of reference documentation of the public Web services, schemas, and error codes that constitute the Microsoft Dynamics CRM

CrmDiscoveryService Web Service

Documents the Web service you use to discover the URL for your organization. The CrmDiscoveryService Web service provides a mechanism to find the organizations that a system user belongs to and obtain the Web service endpoints for those organizations. The CrmDiscoveryService Web service is also used to obtain policy and ticket information that is used for CrmService and CrmMetadataService Web service authentication.

CrmService Web Service

Documents the Web service you use to write custom code that accesses data. The CrmService Web service contains the classes and methods you need to write custom code for the Microsoft Dynamics CRM server.

To add a Web service to your Microsoft Visual Studio Project, in Solution Explorer, right-click References and click Add Web Reference. Enter the following string into the URL box, using the name of your Microsoft Dynamics CRM server.

http://<servername[:port]>/mscrmservices/2007/crmservice.asmx

 

 

MetadataService Web Service

Documents the Web service you use to write custom code that accesses the metadata. This Web service contains the methods you need to access and modify the definitions for all of the entities in a Microsoft Dynamics CRM installation. It can also be used to build a client-side cache.

To add a Web service to your Microsoft Visual Studio Project, in Solution Explorer, right-click References and then click Add Web Reference. Enter the following string into the URL box, using the name of your Microsoft Dynamics CRM server.

http://<servername[:port]>/mscrmservices/2007/metadataservice.asmx

 

Microsoft.Crm.Sdk Namespace

Documents the namespace needed for developing plug-ins and workflows. This namespace is part of the Microsoft.Crm.Sdk assembly. It contains classes, methods, interfaces and enumerations needed for developing plug-ins and workflows with this SDK.

Microsoft.Crm.Sdk.Metadata Namespace

Documents the namespace needed for accessing the metadata from plug-ins and workflows. This namespace provides the classes needed for accessing the metadata when writing code for plug-ins and custom workflow activities.

Microsoft.Crm.Sdk.Query Namespace

Documents the namespace needed for queries in plug-ins and workflows. Contains the query classes and enumerations needed for queries in plug-ins and workflows.

Microsoft.Crm.Workflow Namespace

Documents the namespace needed for developing workflows. This assembly is used when you develop custom workflows and workflow activities.

Microsoft.Crm.Workflow.Activities Namespace

Documents the namespace needed for developing workflow activities.

Microsoft.Crm.Workflow.Services Namespace

Documents the workflow services namespace needed for developing workflow activities. This namespace contains interfaces used to invoke business logic implemented in asynchronous workflow handler from Microsoft Dynamics CRM workflow activities.

Microsoft.Crm.SdkTypeProxy Namespace

Documents the namespace needed for developing plug-ins and workflows. This assembly contains helper classes that can be used when you develop plug-ins and workflows. Most of the classes and enumerations in this namespace are the same as those found in the CrmService Web service. Instead of duplicating the documentation, these topics are linked to the corresponding reference topics in the CrmService Web service.

Note Use the request and response classes together with the DynamicEntity class found in this assembly for creating plug-ins and custom workflow activities. Do not use the entity types such as account and lead, and those classes that depend on them such as TargetCreateAccount. These classes are deprecated in this assembly.

 

Microsoft.Crm.SdkTypeProxy.Metadata Namespace

Documents the namespace needed for accessing the metadata from plug-ins and workflows. This namespace contains types needed to access the metadata when developing plug-ins and workflows. Most of the classes and enumerations in this namespace are the same as those found in the MetadataService Web service. Instead of duplicating the documentation, these topics are linked to the corresponding reference topics in the MetadataService Web service.

Microsoft.Crm.Outlook.Sdk Namespace

Documents the namespace needed for customizing Microsoft Dynamics CRM for Microsoft Office Outlook. The Microsoft.Crm.Outlook.Sdk assembly supports programmatic interaction with Microsoft Dynamics CRM for Microsoft Office Outlook (formerly the desktop client) and Microsoft Dynamics CRM for Microsoft Office Outlook with Offline Access (formerly the laptop client).

Microsoft.Crm.Tools.Email.Providers Namespace

Documents the namespace needed for developing a custom E-mail Provider component for the E-mail Router. This namespace provides the classes needed to develop custom e-mail providers for the E-mail Router.

Microsoft.Crm.Tools.Email.Management Namespace

Contains the reference for the e-mail providers management namespace. This namespace provides the classes needed to develop custom e-mail providers for the E-mail Router.

Global Scripting Reference

Describes global methods and variables that can be used in forms and in code configured for ISV.Config.

The Microsoft Dynamics CRM application provides global functions and variables that can be accessed in scripts configured for form events or in the JavaScript attribute of custom buttons and menu items configured in ISV.Config. The functions and variables described here can be used in both areas. These functions and variables provide information about the context in which scriptable actions are being performed and enable you to include conditions to control the behavior of your scripts.

Form Programming Reference

Describes the properties and methods of forms and the properties and methods of fields within the forms that are the foundation of programming within forms. Microsoft Dynamics CRM supports scripting for form events. Scripts for form events are typically used to perform tasks that reference or change the current data in the form.

SiteMap XML Reference

Documents the valid XML elements used when configuring the SiteMap to customize application navigation.

The SiteMap element is the root node for this reference.

Element Name	Description
Area	Specifies the areas to show in the navigation pane.
Description	Contains a description in one language.
Descriptions	Contains a set of localized descriptions.
Group	Specifies a group of subareas.
Privilege	Controls whether a subarea is displayed for a given user.
SiteMap	Specifies the root node for the site map.
SubArea	Specifies the elements displayed in the left navigation pane for each area.
Title	Contains a title in one language.
Titles	Contains a set of localized titles for an area.

 

ISV.Config XML Reference

Documents the valid XML elements used when configuring the ISV.Config to add client extension controls such as menu items, buttons and entity navigation bar items.

Customization File Reference

Contains detailed reference information about the schema of the import/export customization file.

The customizations.xml is the product of exporting customizations from Microsoft Dynamics CRM. The customizations.xml file contains all or selected portions of the customizations and configurations for your system. These may include:

• Entity definitions and customizations
• Security Roles
• Workflows
• Templates
• Client extension controls (ISV.Config)
• Relationship Roles
• Application Navigation (SiteMap)
• Entity attribute mapping
• Entity Relationships
• Organization Settings
• Installed languages

The customizations.xml file is exported as a compressed customizations.zip file. The XML file must be extracted from the ZIP format before it can be edited or imported.

 

E-mail Router Configuration File Reference

Contains detailed reference information about the e-mail router configuration file. The E-mail Router service reads run-time configuration settings from an XML file that is named Microsoft.Crm.Tools.EmailAgent.xml. The file stores two kinds of configuration settings: system configuration settings and provider configuration settings. The XML file is located at [InstallDirectory]\Service. By default, the location is \Program Files\Microsoft CRM Email\Service, on the server where the E-mail Router is installed.

Schemas

Documents the entity schemas, the Fetch XML schema, and the ColumnSet schema.

Error Codes

Provides a complete listing of error codes.

 

Configure CRM for integration with Microsoft Azure

This topic explains configuring on-premises or Internet-facing deployments of Microsoft Dynamics CRM 2016 for posting the execution data context to the Microsoft Azure Service Bus. Perform the following tasks before continuing with this walkthrough:

1.       Obtain a certificate from an issuing authority.

2.       Install the certificate in the certificate store of the server running the Microsoft Dynamics CRM asynchronous service.

3.       Generate a public key file in Base64 format from the certificate. Get a public certificate.

4.       Verify that Windows PowerShell is installed on your Microsoft Dynamics CRM server.

Configure certificate read access

---

The system user account under which the Microsoft Dynamics CRM asynchronous service runs must have read access to your certificate in the certificate store. Either a user account that is identified by the deployment administrator during server setup or NetworkService is used. You can verify the account used by running the Services administrative tool. In the tool, look up the service named “Microsoft Dynamics CRM Asynchronous Processing Service” and see what account that service is running under.

You must grant read access by the above mentioned account to your certificate in the certificate store. You can do this by setting an ACL on the certificate by using the certificate snap-in of the mmc (Microsoft Management Console) or by typing the following command.

msdos

winhttpcertcfg -g -c <certLocation> -s <subjectStr> -a <accountName>

Substitute the correct values, described in the following table, for the <> parameters shown in the command.

 

<certLocation>	The location (path) of the certificate in the certificate store. Use the Certificate snap-in of mmc (Microsoft Management Console) to locate the certificate.
<subjectStr>	The certificate’s subject value. You can obtain this value by double-clicking the public certificate key file (.cer) file in Windows Explorer. In the Details tab of the Certificate dialog box, look for the value of the Subject field.
<accountName>	The name of the account to grant read access to. For a default Microsoft Dynamics CRM installation, the name of the account is “NetworkService”.

Configure the MSCRM_Config database

Follow these procedures to configure the Microsoft Dynamics CRM MSCRM_Config database.

Register the Microsoft Dynamics CRM PowerShell cmdlets

1.       Log on to the administrator account on your Microsoft Dynamics CRM server.

2.       In a Windows PowerShell command window, enter the following command.

Windows PowerShell

 

Add-PSSnapin Microsoft.Crm.PowerShell

This command adds the CRM Windows PowerShell snap-in to the current session. The snap-in is registered during installation and setup of the Microsoft Dynamics CRM server.

Set the Microsoft Dynamics CRM certificate

1.       Enter the following command in the Windows PowerShell window.

Windows PowerShell

 

Set-CrmCertificate –CertificateType AppFabricIssuer –Name <issuerName> -StoreName My –StoreLocation LocalMachine -StoreFindType FindBySubjectDistinguishedName –DataFile <certificateFilename>

In this command, the issuer name <issuerName> can be any name. However, you’ll be using this same issuer name when you configure Microsoft Azure Active Directory Access Control Service (ACS). The -DataFile parameter value is the file name or path of the public certificate file.

2.       List the installed certificates in the MSCRM_CONFIG database. You should see the certificate that you just added.

Windows PowerShell

 

Get-CrmCertificate

Configure Microsoft Azure ACS for integration with Microsoft Dynamics CRM

Above topic explains you through configuring the Microsoft Azure Active Directory Access Control Service (ACS) 2.0 issuer, scope, and rules to allow a listener application to read the Microsoft Dynamics CRM messages posted to the Microsoft Azure Service Bus. This walkthrough applies to integration with any deployment type of Microsoft Dynamics CRM.

Create a new service namespace

---

If you have an existing ACS version 2 service namespace that you want to use, continue with the next section named Create a service identity (issuer).

Use PowerShell commands to create a new service namespace

Download and install the Microsoft Azure PowerShell module.

From the Start menu, open the Microsoft Azure PowerShell program and enter the following commands.

Windows PowerShell

 

> Add-AzureAccount

> New-AzureSBNamespace –Name YOUR_NAMESPACE -Location "YOUR_LOCATION" -CreateACSNamespace $true

Version 0.8.9 or later of Azure PowerShell supports the –CreateACSNamespace parameter in the New-AzureSBNamespace command. If your installed version of Azure PowerShell doesn’t support the –CreateACSNamespace parameter, install the latest version. To see the version of Azure PowerShell that you’re using, enter the command Get-Module Azure. Newer versions of the command may support a –NamespaceType parameter. If so, use –NamespaceType Messaging.

After you enter Add-AzureAccount, you’ll be prompted to provide the sign-in credentials for your Azure subscription. Substitute an appropriate namespace name for YOUR_NAMESPACE and an approximate location for YOUR_LOCATION. The supported locations are: Central US, East US, East US 2, North Central US, South Central US, West US, North Europe, West Europe, East Asia, Southeast Asia, Brazil South, Japan East, and Japan West.

After you enter these commands, the namespace is created and you should see output that looks similar to the following text.

msdos

 

Name                  : mynamespace

Region                : Central US

DefaultKey            : 1eKDTIYEACFP7Geiy5QV/hqJnWHeroJyKk/PBzv42Rw=

Status                : Active

CreatedAt             : 8/25/2014 3:36:47 PM

AcsManagementEndpoint : https://mynamespace-sb.accesscontrol.windows.net/

ServiceBusEndpoint    : https://mynamespace.servicebus.windows.net/

ConnectionString      : Endpoint=sb://mynamespace.servicebus.windows.net/;SharedSecretIssuer=owner;SharedSecretValue=1

                        eKDTIYEACFP7Geiy5QV/hqJnWHeroJyKk/PBzv42Rw=

Create a service identity (issuer)

---

1.       If you haven’t already done so, go to the Microsoft Azure Management Portal and sign in.

2.       In the management portal, click Service Bus and then select your existing namespace in the list.

3.       Click Connection Information.

4.       At the bottom of the form, click Open ACS Management Portal.

5.       Under Service Settings, select Service identities, and then click Add.

6.       On the Add Service Identity page, enter a name for the issuer identity. This must be the same issuer name that Microsoft Dynamics CRM is configured with. You can find this issuer name in the CRM web application by choosing Settings > Customizations > Developer Resources.

7.       Select a credential type of X.509 Certificate.

8.       Browse to the location of the certificate on your local computer. Obtain the certificate by clicking the Download Certificate link on the Developer Resources page of the CRM web application.

9.       Click Save.

If you’re working with Microsoft Dynamics CRM Online and see an indication that the certificate you obtained from that server is expired, you can ignore that warning.

Create a rule group and a rule

---

Create a rule for the target scope that will allow Microsoft Dynamics CRM to send or “post” to the Microsoft Azure Service Bus. You do this by configuring ACS to map the input “Organization” claim from Microsoft Dynamics CRM to the output “Send” claim of the Microsoft Azure Service Bus.

First, create a rule group by following these steps.

1.       Below Trust relationships, select Rule groups.

2.       Click Add.

3.       Enter a name for the rule group and select Save.

Next, add a claim rule to the rule group.

1.       On the Edit Rule Group page, click Add.

2.       In the If section of the page, select Access Control Service.

3.       For the input claim type, select Enter type and then enter http://schemas.microsoft.com/xrm/2011/Claims/Organization.

4.       For the input claim value, select Enter value, and then enter the name of a Microsoft Dynamics CRM organization.

For an Internet-facing or on-premises deployment, enter the unique name of the desired organization in lowercase characters. You can find this name on the Developer Resources page of the CRM web application next to the Organization Unique Name label. To navigate to that page in CRM, click Settings > Customizations > Developer Resources.

For a Microsoft Dynamics CRM Online deployment, specify the complete hostname part of the Web service URL. For example, given a URL of https://myorg.crm.dynamics.com/main.aspx, the host name part is myorg.crm.dynamics.com.

5.       In the Then section, for the output claim type, click Select type and then select the http://docs.oasis-open.org/wsfed/authorization/200706/claims/action item from the drop-down list.

6.       For the output claim value, select Enter value, and enter a value of Send for the output claim.

7.       Add a description of the rule (optional). For example, you could type: “Allow the Contoso organization to send to the Microsoft Azure Service Bus.”

8.       Click Save.

Configure the scope

---

The following steps describe how to configure the Microsoft Azure Service Bus scope of ACS for a normal mode post by Microsoft Dynamics CRM. Defining a scope provides more restricted access to the service namespace.

1.       Below Trust relationships, select Relying party applications, and then click Add.

2.       On the Add Relying Party Application page, enter a display name for the relying party. For example, enter internal. This name is the scope name.

3.       Enter the realm URI of your Microsoft Azure service endpoint and append the scope name, for example, https://crmsdkdemo.servicebus.windows.net/internal.

4.       Enter the return URL, which can be the same value as the realm URI you just entered.

5.       Select a token format of SAML 2.0.

6.       You may optionally increase the token lifetime value.

7.       Make sure the Windows Live ID identity provider is selected.

8.       Select the name of the rule group you created previously. If the check box next to your rule appears ghosted, first clear the check box that is currently checked, and then select the check box for your rule.

9.       Click Save.

 

 

Microsoft Dynamics CRM Overview

Microsoft Dynamics CRM is built by using Microsoft .NET–connected technologies so that it is easy to deploy, customize, and use. Microsoft Dynamics CRM can be accessed from Microsoft Office Outlook; it integrates with other business applications, and it scales as your business grows. Microsoft Dynamics CRM consists of the following components:

• Microsoft Dynamics CRM Server
• Microsoft Dynamics CRM for Microsoft Office Outlook
• Microsoft Dynamics CRM 4.0 E-mail Router