The following diagram illustrates the Microsoft CRM architecture.

Microsoft CRM Server

The platform is the heart of the Microsoft CRM system. When you use the Microsoft CRM Server Programming Guide, you are building on top of this system. The Microsoft CRM platform supports smaller deployments and can scale for application service provider (ASP) models as well. The focus of the security model is protection of the platform from unauthorized access across the Web. The main platform components are:

• 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 Extensible Markup Language (XML) fetch statement to protect the physical database
• Callouts for business logic extensibility
• Reporting services

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

The server platform is responsible for creating domain-specific objects. In the Microsoft CRM space, these objects include contact, lead, opportunity, account, and business unit, among others. 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 platform does more than just contain the Microsoft CRM business entities. It is responsible for controlling access to objects through security, for controlling access to the database, and for raising events for workflow processes and custom business logic implementations. The platform layer provides for both inbound and outbound e-mail processing through Microsoft Exchange.

Data Management

The data management tier is the lowest level of the platform and consists of a data storage area and a well-defined data access layer. The data storage area uses Microsoft SQL Server as the primary data store. The data access layer provides a consistent programming interface for the service developer, which abstracts platform business logic from the underlying data source. The platform tier is the only direct consumer of this layer.

The data store hides the data access mechanism and exposes a common interface, in this case the Transact-SQL programming language. Microsoft CRM internally uses an object-based data management layer to shield the platform code from the data access code. You can only access the database by using the QueryExpression, QueryByAttribute and the FetchXML query language. For more information, see Building Queries.

Security

The Microsoft CRM SDK provides you with a security model that protects data integrity and privacy, and also supports efficient data access, teamwork, and collaboration. The Microsoft CRM security model was designed with the following goals:

• Support data sharing, so that users can access objects for collaborative effort.
• Prevent users from accessing objects for which they do not have access or that have not been shared with them.
• Categorize types of users to define roles and restrict access based on those roles.

The first two goals relate to object security; the last goal relates to role-based security.

The object security model focuses on access rights to the entities in the system.

The role-based security model provides a means to group a set of privileges together to describe the responsibilities for a user.

The Microsoft CRM security model is both robust and flexible. As a result, the SDK offers different security privileges that you can combine together to define the overall security rights users have within your custom Microsoft CRM application.

For an in-depth explanation of the security model, refer to Microsoft CRM Security.

Business and Organization Structures

Microsoft CRM uses a very simple, but powerful, organizational structure for the construction of arbitrarily complex business hierarchies. Organization is an entity that provides a common location for business units.

There are three primary entities within the organizational structure, not including the organization itself. These are users, teams, and business units. Users represent real people who are members of an Active Directory domain; these are the people who use the Microsoft 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, which will be covered in the sections Microsoft CRM Security and Access Levels. The following diagram is an example of a Microsoft CRM business unit structure for an organization.

The organization contains six business units in a simple hierarchy. The business units directly below the organization are unrelated in any apparent structural way except for the fact 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. Note that it is not possible to construct matrix organizations within the Microsoft CRM organizational structure.

Within this structure, users can be created from the users who are members of the Active Directory domains. Users within Microsoft 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.

Entity Model

The entity model is your view to the objects used in Microsoft CRM. It supports Microsoft CRM requirements for each entity in the system. In Microsoft CRM, the platform consists of several high-level areas.

Sales force automation

This provides salespeople with access to critical customer information and tools that enhance their ability to sell products and services and manage their time effectively. Sales force automation encompasses the following:

• Opportunity and lead management, for finding and managing leads and opportunities.
• Contact management, for creating and keeping customers by tracking personal information.
• Account management, for creating and keeping customers by tracking information about the customers' business.
• Sales processes, for converting a lead to an opportunity and then to a closed sale.
• Competitor and referral libraries, for tracking where leads come from and who competes for the customer.
• Sales force management, for managing sales quotas and commissions.
• Quote generation, for enabling the salesperson to get the right price to the customer quickly.
• Sales order and invoice generation, for managing quotes, orders, and invoices.
• Activity management, for handling e-mail, phone calls, fax transmittals, letters, tasks, and appointments.
• Product catalog management, which allows business units to manage a full-featured product catalog, including support for complex pricing models.

Customer service and support

This enables the enterprise to effectively and efficiently address customer questions, problems, or issues. Although customer satisfaction is the primary goal, many organizations are seeking to increase revenues and also provide customer service through cross-selling to existing customers. Customer service and support encompasses the following:

• Knowledge Base, which helps customers find answers to their questions.
• Customer care, which manages pre-sale and post-sale customer interactions.
• Case Management, which handles customer interactions.
• Contract Management, which manages contracts with customers.
• Queue Management, which handles work queues dealing with customer issues.

Scheduling

Microsoft CRM 3.0 introduces appointment-based service scheduling. Using these tools, you can define the services offered by your business, their resources and work schedules, and their service locations. A sophisticated scheduling engine manages booked appointments and service availability, and can be tuned to optimize scheduling to reduce costs and required resources. Reporting help service managers spot trends and adjust service offerings and resources to meet market demands. This powerful management across service resources includes:

• A Service scheduling engine
• A Global appointment book for resource and workforce planning

Marketing Automation

Marketing automation allows you to leverage the valuable data within Microsoft CRM in a completely new and powerful way helping a Marketing team to plan, create, and tightly coordinate the execution of marketing initiatives with their field sales force. This includes:

• Marketing list management
• Campaign templates
• Campaign management

For detailed information, refer to Microsoft CRM Entity Model.

Database

Microsoft CRM is a metadata-driven product. This means that the vast majority of its work is focused on abstracting itself away from the implementation details that so often cause problems with upgrades and extensibility. The metadata layer in essence 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.

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 CRM can be altered significantly to meet a particular business or vertical definition and still operate without interruption.

The Microsoft CRM platform is not the only consumer of the metadata. The application layer uses the rules inherent 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, including 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 write-once, such as order numbers. Other attributes are always read-only and are supplied by the platform itself. The metadata captures all of these rules about context, but it also captures business-defined rules, such as business-recommended and business-required attributes.

Workflow

The workflow subsystem's goal is to process system events and run processes.

The workflow system consists of:

• The Workflow Manager tool that provides a graphical user interface for creating processes.
• The Workflow Monitor tool that provides a graphical user interface for viewing process instances.
• The Workflow Service (a Microsoft Windows service) that responds to events, schedules events, and runs processes. The Workflow Service is available in the Services utility in Windows Administrative Tools. This service is installed during Microsoft CRM Server installation and is configured to be started automatically.
• A set of messages for accessing instances workflow rules. For more information, see the RetrieveByObjectWFProcess and ExecuteWFProcessInstance messages.
• .NET Workflow Assemblies which allow you to write modules that provide interaction between Workflow rules and external systems.

For more information about the workflow tools, please see the online help provided in each tool.

Business Logic Extensions

Microsoft CRM exposes a very simple extension mechanism for implementing custom platform-based business logic. With this model, application developers are not limited to creating custom business logic only in the application or through workflow processes; they can also construct business logic that runs in the context of a call, but in response to a particular event.

This extension mechanism exposes a callout interface that is based on a simple pipeline model. The pipeline model allows for both "pre" and "post" interceptions for basic data persistence operations. The platform metadata stores information about each entity. This information about entities can be used to track the list of callout 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, the platform checks the metadata for registered event handlers. This information is specified in a callout configuration file. If a handler is registered for notification, the platform creates the handler object and calls the correct handler method, passing the original XML document. See Business Logic Extensions (Callouts).

Application Programming Interfaces

The platform application programming interfaces (APIs) are your view to the logical Microsoft CRM system. The APIs are relatively flat and require knowledge of the Microsoft CRM entity model.

For a complete listing of APIs, refer to the Programming Reference section.