Core CRM Objects

Contact and Account records are at the core of Microsoft CRM. They are related to every other area and represent the key link between all the other data. Both Sales and Service data roll up to Contacts and Accounts. Because Contacts and Accounts span all areas, we will discuss them in detail.

NOTE

Throughout the book the terms object and record are used almost interchangeably. Traditionally, the word record has been more widely used to discuss data because we were most often interacting directly with a database, and the term record historically refers to a single row in a single database table. However, because in this book we are interacting with a CRM platform, we are truly interacting with objects that may or may not equate back to a single row in a single database table.

A single instance of a CRM object might pull data from various database tables or other data sources. As users, we shouldn't have to worry about this and, in fact, the Microsoft CRM platform abstracts this detail away from even developers who may be writing API calls to retrieve CRM objects. In reality when we see a list of CRM Leads, we are seeing a list of Lead objects, not records.


Contacts

As we mentioned earlier, Contact records represent individuals. These records can be standalone or can be linked to one Account (company, organization, or entity) record. A Contact can be any type of individual whose information is worth maintaining in your database. This will normally include customers, customer employees, vendor employees, partner employees, and so on. One of the first things you will want to do is identify the different types of Contacts you will be tracking, so you can list them in one of the configurable drop-down fields. The field named role can be used for this, or you can create an additional field. Most of the fields on the Contact screen are fairly self-explanatory, so I won't detail them now. However, there are a few details worth mentioning.

NOTE

Throughout the book I will refer to fields on the various object/record screens. Keep in mind that Microsoft CRM can be customized so that your particular installation may or may not have the same fields as that of a vanilla (standard) implementation. For this book, we are using a slightly modified version of the Adventure Works Cycle sample database provided by Microsoft Business Solutions.


First, all phone numbers in Microsoft CRM get inserted into the database exactly as you've entered them on the screen. Although that might seem obvious, consider the example of a phone number typed in as (404) 867-5309. The entire string, including the parentheses, will be included in the field. If at some point you want to perform a search on all Contacts with business phone numbers in the 404 area code, you will most likely need to search for business phone numbers that begin with “404” and “(404”. The moral of the story is to promote consistency in data entry, while at the same time assuming that users will not be consistent.

Another detail worth mentioning is that the State/Province field is a free text (string) field and is not validated against a list of valid states or provinces based on the country selected. This is not a big issue, but again, you will want to promote consistency in how data is entered so that any searches you do will be as accurate as possible. Without standards, some users will enter the two-character state code (GA), whereas others might enter the full state name (Georgia).

Each Contact record can have multiple Addresses, Sales Opportunities, Service Cases, Activities, Notes, and Contracts. Contacts are associated with a single price list, which will become the default price list on any Sales Opportunities attached to that Account. Price Lists are discussed in Chapter 5, “Setting up Microsoft CRM.”

Figure 4.13. The General tab of the Contact screen.


Contact Status

All Microsoft CRM objects have an internal status, which can be viewed in the lower-left corner of the object screen. In the case of Contact, there are two possible values: Active and Inactive. By default Contact records are Active until a user or process deactivates them. Selecting Deactivate Contact from the Contact's Actions menu can deactivate contacts (and many other record types). Deactivated Contacts will be in the Inactive status and can be viewed by selecting the Inactive Contacts view in the upper-right corner of the Contacts list view. Views will be covered in more detail in Chapter 6, “Homepage, Workplace, and Navigation.” For more detail on object statuses, refer to Chapter 12, “Workflow.”

eResources

On the Contact screen, as well as on the Lead and Account screens, there is a menu titled eResources. This menu lists Web sites that can be launched from Microsoft CRM. However, instead of simply launching the Web sites, these links take data about the Contact in question and pass that data into the Universal Resource Locator's (URL) of the Web sites being called. Figure 4.14 depicts the eResources menu options on the Contact screen. The power of the eResources menu is tremendous, but the menu options are preset and cannot be changed using the Microsoft CRM configuration tools. For an example of how to create your own eResource type customization, refer to Chapter 14, “Customizing Microsoft CRM.”

Figure 4.14. How Microsoft CRM enables you to pass Contact data into a Web URL using the eResources link.


The eResource concept of, for example, taking a zip code from your CRM record and passing it into a weather Web site is interesting, but let's take this concept a step further. Suppose your company has an application that is used to track billing information on your Contacts. If that application has some sort of Web interface, you could create a custom field on the Contact screen to house the Contact's ID from that system and also create an eResources link to call the appropriate URL of that system and pass it the Contact's ID. It would be similar (yet less irritating) to shouting over your cube wall to the Billing department and asking for the billing history on Contact 12D45. Further, if the other system supports Windows integrated security, the Web page could launch and let the user access it without asking them for a password. This is very simple integration at the user interface level. Very little data must be synchronized between the two systems, yet they can work together as if they were one. By implementing this concept, your CRM has become a portal through which your users can access all other systems, which contain data about your Leads, Contacts, and Accounts.

Accounts

Accounts represent companies, organizations, or entities. They can be your customers, partners, vendors, and so on. As with Contacts, determining the various types of Accounts should be your first priority. The Relationship Type field can be used for this with the caveat that it only allows for a single value selection. You will want to add additional fields if Accounts can be classified as more than one type (for example, a partner that is also a customer). Figure 4.15 shows the Microsoft CRM Account screen.

Figure 4.15. The General tab of the Account screen.


Each Account record can have multiple Addresses, Sales Opportunities, Service Cases, Activities, Sub-Accounts (for unlimited Parent/Child linking), Contacts, Notes, and Contracts. Accounts can have only one Primary Contact and one Parent Account. Like Contacts, each Account is linked to a Price List, which becomes the default Price List on any Sales Opportunities that are attached to that Account.

Accounts, like Contacts, have an eResources menu and an Account Status field, which can be Active or Inactive.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.112.242