Microsoft CRM v1.2 Sales Professional 5user(s) CRM software

CRM v1.2 Sales Professional, FR, CD, Win32, 5 user license In general, there are three physical layers within the Microsoft CRM architectural "stack," as illustrated in the following figure. These are the client, application, and server layers. The server layer contains the Microsoft CRM platform code. Microsoft CRM relies on Active Directory®, the Microsoft Windows® operating system directory service, and two external Microsoft programs to perform additional processing. Active Directory identifies security principals, roles, and groups within the product. Microsoft Exchange 2000 Server and Microsoft Exchange Server 2003 send and receive e-mail messages. Microsoft SQL Server™ 2000 is the data storage mechanism.

Platform Overview

The platform is the heart of Microsoft CRM. When you use the Microsoft CRM SDK, you are building on top of this system. The Microsoft CRM platform supports smaller deployments and can scale for Application Server Providers (ASP) models as well. The focus of the security model is to provide protection of the platform from unauthorized access across the Web. The main platform components are:
- The database
- System services (workflow)
- The object model
- A query processor that supports the object model
- Secured spontaneous queries that use an Extensible Markup Language (XML) fetch statement to protect the physical database

When you develop an application using the Microsoft CRM platform, you use messages formatted as XML strings to communicate with the underlying platform layer. You use SOAP to communicate between an application and the platform.

The platform is responsible for creating domain-specific objects. In Microsoft CRM, 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, you can assume that the interaction between those objects within the domain implements 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 objects. 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. Think of the platform layer as providing all of the "hard" plumbing work necessary to implement a complete Microsoft CRM application. The platform layer provides for both inbound and outbound e-mail message processing through the CRM-Exchange E-mail Router. The platform also implements a replaceable pricing module for opportunities, quotes, orders, and sales invoices.

Data Tier

The data tier is the lowest level of the platform and consists of a database (loosely speaking) and a well-defined data access layer. The data management tier in Microsoft CRM supports Microsoft SQL Server 2000 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 uses an internal object-based data management layer to shield the platform code from the data access code. Just as it is not possible for an application developer to directly access the database; it is also not possible for a platform developer. The CRMQuery class, along with the Fetch query language, exposes the object-based data management construct to the application.

Access the Platform: An Example

The following steps illustrate how the system handles a sample request from an application:

1. A user submits a request to create a new account.
2. The request goes through the platform API that passes the user credentials.
3. The platform API calls the object model that verifies user authentication.
4. The object model then requests the logical properties of an object that is accessible by the caller.
5. Then, the query builder requests the building of a Transact-SQL query.
6. The query builder gets the request, uses the metadata to build a physical query, and then returns the Transact-SQL statement to the caller.
7. The query then passes to the data access layer, which returns a property bag to the caller.
8. Then, the data serializes to XML, back to the API, for consumption by the applicatio

Security Overview

The Microsoft CRM SDK provides you with a security model that protects data integrity and privacy, as well as supports efficient data access, teamwork, and collaboration. The design goals of the Microsoft CRM security model include the following:

- Support data sharing so that users can access objects for collaborative effort
- Prevent users from accessing objects that are not been shared with them
- Categorize types of users in order 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 the primary business objects, namely Leads, Opportunities, Contacts, Accounts, Competitors, Products, Sales Literature, Quotes, Orders, Invoices, Contracts, and Incidents (Cases), which form the core of a sales force automation and customer service solution.

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

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

The SDK also includes a set of predefined security roles, each of which is a set of security rights aggregated to make user security management easier. Each application deployment can also define its own roles to meet the needs of different users.

Business and Organization Structures

Microsoft CRM uses a very simple, but powerful, organizational structure for the construction of arbitrarily complex business hierarchies. Each installation can have multiple organizations. However, every action performed by a user is confined to the user's own organization. Organizations are lightweight entities that provide a common location from which to locate other business units. Business units are not strictly hierarchical in nature; however, they may be parented only by a single business unit.

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 the 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. The business unit structure determines and defines the concepts of Basic, Local, Deep, and Global access.

Database Overview

Microsoft CRM is a metadata-driven product. This means that the vast majority of its work focuses on abstracting itself away from the implementation details that so often cause problems with upgrades and extensibility. In essence, the metadata layer abstracts the underlying data storage details, such as schema and data access, from the higher-level constructs of domain-logic implementation and the user interface (UI). The word metadata literally means "descriptive information about the elements of a set of data." Think of the metadata 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 adding or removing columns), the platform code continues to operate without any performance or degradation. This means that you can significantly alter Microsoft CRM 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 to use a given attribute. For example, some attributes are write-once, such as order numbers; these attributes should not be changed after creation because changing them causes ripple effects throughout the business data. Other attributes are always read-only, which the platform itself supplies. The metadata captures all of these rules about context, but it also captures business-defined rules, such as business-recommended and business-required attributes.

The Object Model

The object model is your view to the objects used in Microsoft CRM. The object model leverages a set of metadata components that create SQL statements on the fly, providing you with the ability to support, create, retrieve, update, and delete methods with little coding. The object model sits below the APIs. It supports Microsoft CRM requirements for passing workflow and back-office events to other external systems.