Dynamics CRM 101: Glossary of Terms and Concepts

Like other customer relationship management systems, Microsoft Dynamics CRM uses a specific terminology to refer to the various concepts and data entities in the system. I find that I often need a basic overview of terms & concepts, for example:

  • As an introduction to end-user training materials;
  • As a guide to requirements gathering;
  • As an introduction to customization concepts.

So, with only a little more ado, here’s a glossary of Dynamics CRM terms and concepts, presented in three sections:

Terminology Basics: What the Heck is an Entity?

In Dynamics CRM, things like leads, accounts, contacts and opportunities are often referred to as entities. You may also hear them referred to as record types. Generally, those two terms can be used interchangeably.

For example, when we refer to a specific type of entity/record type in Dynamics CRM, we might say, “The lead entity is used to store information about prospective customers.” On the other hand, sometimes it gets a little tedious always referring to this entity or that record type, so if we say, “Leads are used to store information about prospective customers,” we really mean the same thing.

As you get experience customizing Dynamics CRM, you begin to appreciate that an entity is much more than just a table, however: a Dynamics CRM entity stores much more than just rows and columns of data. For example, custom forms and views, entity relationships, field definitions, custom charts – these are all stored as metadata regarding the various entities making up your CRM.

System Record Types

One of the big advantages of the Dynamics CRM platform is how customizable it is. And one example of how many organizations customize it is to change the built-in terminology to match how they currently refer to concepts like customers, prospects, sales opportunities and so forth. That being said, it is useful to start our discussion with reference to an un-customized Dynamics CRM system, and that’s what I do here, with summaries of the most frequently used system record types (that is, available out of the box) in Dynamics CRM. We provide a brief description of each and some of the most common uses, and in some cases provide additional information, such as common sources of the data, and alternative terms frequently used in businesses to refer to the same concepts.

Leads: Potential

In Dynamics CRM, the lead record type is conventionally used to store information about prospective customers. A lead can contain information about a person, about a company, about a sales opportunity…or any combination of those three things. The primary distinguishing characteristic of leads is that they are not intended as a “permanent” record: leads generally go through a qualification process, at the end of which they are either qualified (and converted to “customer” records – covered in the next section), or disqualified.

  • Common sources of leads: import from spreadsheet, phone inquiries, purchased/rented lists, web form, scanned business cards, booth visitors from trade-show.
  • Frequently used alternative terms: suspect, prospect.

Accounts and Contacts: The Customer Records

The account and contact record types in Dynamics CRM can be referred to collectively as the “customer” record types. Unlike leads, account and contact records should usually be thought of as permanent fixtures of your CRM database.

While they are similar in that both are considered “customer” records, they are different in an obvious way: an account is an organization, and a contact is a person. An organization with a “B2B” sales model may sell only to accounts, a “B2C” organization may sell only to contacts…but many organizations might need to have sales transactions with both of these record types, and Dynamics CRM is designed to accommodate that.

Dynamics CRM is a relational database management system, with the “one-to-many” relationship between account and contact records being perhaps the most obvious example. Many organizations use this to model the relationship between an employer (the account record) and an employee (the contact), but this is not a requirement.

Also, while they are referred to as “customer” records, these records can certainly be used to store information about organizations and people in addition to those you sell to! For example, in addition to using accounts to store information about customers, many organizations also use account records to store information about vendors, suppliers, resellers, competitors, and so forth. Again, the Dynamics CRM platform is certainly flexible enough to accommodate requirements like this, and an important part of the design process is to specify the various relationships an organization will capture on important record types such as account and contact.

Account and contact records tend to be the most “static” records, in the sense that they remain in the same state (in Dynamics CRM terms, “Active”) longer than most other records.

  • Common sources of accounts and contacts: data migrated from other CRM applications (e.g., Salesforce, Act, Goldmine), converted from leads, contacts promoted to CRM from Outlook, scanned business cards.
  • Frequently used alternative terms: Company, client, customer, organization.

Opportunities: Potential Sales

Opportunity records are used to represent a potential sale. Questions such as when a lead should become an opportunity are often difficult to answer precisely, and part of the benefit of a well-planned CRM deployment is the creation of a shared terminology around important business processes and concepts like this one. A good practice is to define several criteria, specific to your business, regarding when an opportunity record should be created. For example:

  • A specific customer (account or contact) is identified and has expressed interest in purchasing your product or service.
  • You have enough information to make a reasonable estimate of the potential revenue.
  • You have enough information to make a reasonable estimate of the date the deal will close.

Unlike the account and contact record types, with which most organizations would like to have long active relationships, opportunity records generally have a desired end-state: a new opportunity starts out as open, you’d like to close it as won, but if you don’t win the deal, you close it as lost.

Many organizations use open opportunity records to represent their sales pipeline, in reports, charts and dashboards. One of the most common approaches to implement a sales process is to use a pick-list field such as Sales Stage to represent the current stage of the sales process for a specific opportunity.

And opportunities closed as won can be used to measure actual sales, or booked revenue. Several out of the box reports, charts and dashboards adopt this convention. For example, the “Won Opportunities” system view is specifically designed for use with the “Actual Revenue by Month” chart, while the “Open Opportunities” view is designed for use with the “Sales Pipeline” chart.

Opportunity records must be associated with at least one of the “customer” (account or contact) record types.

  • Frequently used alternative terms: deal, project, potential sale.

Cases: Customer Service Transactions

Cases are the core record type of the service management area of Dynamics CRM, and are used to track information about a customer issue, request, incident, or complaint. Just as you can think of an opportunity record as representing a sales transaction, you can think of a case as representing the primary service transaction. Besides the obvious differences in business functionality, cases and opportunities have several features in common:

  • Cases, like opportunities, must be associated with a customer (remember: either an account or a contact) record.
  • Cases, like opportunities, have a desired end-state: after being created and before it’s resolved, a case record has a status of active; the goal is to close it out with a status of resolved.
  • Cases, like opportunities, often have business processes designed to assist them in their journey to resolution.
  • Common sources of cases: converted from emails or phone calls, created manually from an account or contact record, created from information entered on a web form (self-service case creation).
  • Frequently used alternative terms: incident, ticket, issue, request, problem, complaint.

Activities

Activity record types include several of the most frequently used and important activities we perform in our daily interactions with customers: phone calls, e-mails, appointments, tasks, and the like. In fact, each of these is a specific record type; so we might refer to an appointment record type, a task, phone call or e-mail record, and the like. There are actually nine specific activity type records you can create in CRM, and they all have certain features in common:

  • They are generally intended for “point-in-time” actions, and all have several date and duration fields to record when they happened.
  • For organizations rolling out the Outlook client along with their Dynamics CRM, activity record types created in CRM can be synchronized to a user’s Outlook calendar, providing a valuable “all-up” version of a user’s schedule.
  • They all have a “Regarding” field, which is used to associate them with another record. The records they can be associated with include customer records (account and contact), opportunities, and cases (and most other record types, for that matter).
  • Common sources of activities: e-mails, appointments, and tasks created in Outlook and tracked in Dynamics CRM; migrated from other CRM.

Customizations

While many CRM applications can be customized, a common problem is that customizations make upgrading to a new version of the core CRM application difficult or impossible. For example, clients with the unfortunate experience of having gone through an upgrade of a highly customized SAP deployment are often initially wary of the topic of customizing. But the Dynamics CRM platform is explicitly designed as a platform for customization, and in particular is designed to allow for easy upgrading of customizations. In one sense, there are two kinds of customizations that can be performed on Dynamics CRM:

  • Supported customizations are explicitly documented and performed in a specified manner. Supported customizations are also supported by Microsoft, and supported for upgrade. So for example, if you make a supported customization and something breaks, Microsoft technical support will help you out. And if you make a supported customization and have trouble upgrading it to the next version, Microsoft technical support will help you out.
  • Non-supported customizations are different. These are things that are possible, but not supported by Microsoft.

Customizing Dynamics CRM is a Big topic, and I don’t mean to trivialize it with the following 1,361 word treatment. But this is Dynamics CRM 101, after all, so I’m going to keep this as short as possible. I’ll cover four main kinds of customizations, roughly in order of ascending complexity. All of the customizations discussed here are supported customizations.

 

Custom Fields

The most basic customization is probably the addition of a custom field to a record type such as lead, contact or opportunity. Just as we refer to the entities that Dynamics CRM comes with as system entities, we can make a distinction between system fields (all pre-existing fields) and custom fields (fields you add yourself). Neither system entities nor system fields can be deleted. (Custom fields can be, but that’s getting a little ahead of ourselves.)

To keep this treatment relatively brief, the following table shows several frequently encountered custom fields for various record types:

Record Type  Custom Field  Data Type  Uses, Examples 
Lead  Event  Lookup to custom record type  A firm using events to drive leads might use a field like this instead of, or in addition to, the built-in pick-list Lead Source field. 
Account  Facebook Page URL  Add it to the main account form to provide easy navigation to a client or business partner’s Facebook page:http://www.facebook.com/broadlook
Contact  Contact Type  Pick-list (“option set”)  A firm selling prosthetics might use a field like to indicate whether a contact is a patient, a doctor, an outside sales rep, or various other things.
Opportunity  Opportunity Type  Pick-list (“option set”)  Used by many organizations to categorize sales into a relatively small number of categories.
Appointment  Appointment Type  Pick-list (“option set”)  Might be used to flag what kind of appointment a record represents: In-person Sales Call, Internal Meeting, Project Meeting, Other 

 

There are many reasons you might want to add custom fields to a Dynamics CRM; some of the most common are:

  • To support custom reporting requirements.
  • To add the ability to segment customer and potential customer records, for marketing lists and the like.
  • To accommodate data imported from another application that does not have an appropriate corresponding system field in Dynamics CRM.

Custom Entities

Some organizations can successfully implement a Dynamics CRM by customizing the system record types, but sometimes new record types must be added. In Dynamics CRM terms, these are referred to as custom entities. When a custom entity is created, the system automatically adds several fields to it. These are examples of the system fields I referred to above, and all of the system entities have these fields as well. They have names like Owner, Created By, Created On, Modified On, Modified By, and so forth.

Also, you can extend custom entities with custom fields, just as you can extend system entities In fact, when you create a custom entity you will almost always add many custom fields to it. Otherwise, you probably didn’t need to create the custom entity in the first place!

Again, this can be a complex topic, so to keep the present treatment brief, here’s a table illustrating with several commonly encountered examples:

Custom Entity  Uses & Considerations  Commonly Added Fields 
Event 
  • Used to manage events
  • You might use the system-provided Appointment or Service Activity entities, but there are pros and cons of repurposing built-in entities for custom requirements
  • Event Date
  • Registration Fee
  • Event Type (pick-list)
  • Location (lookup)
Registration  Used to manage registrations for events 
  • Event (lookup to custom Event entity)
  • Contact (lookup to Contact entity)
  • Registration Status
  • Registration Fee
Project Dynamics CRM does not have a standard Project record type; many organizations will add a custom entity to track and manage projects 
  • Start Date
  • End Date
  • Project Sponsor (lookup to Contact)
  • Project Type
Work Item  If you want to keep track of the time spent on projects, a custom Work Item entity can be used
  • Date
  • Duration
  • Project (Lookup to Project)
  • Notes

 

In addition to adding custom fields, both system and custom entities can be extended in several important ways. I won’t cover these in detail here, but I at least wanted to acknowledge them as important entity customization methods.

  • Entity Relationships. System relationships can be customized (with some limitations) and custom relationships can be created.
  • Forms. Forms can be customized. Much more flexibility in customizing forms in CRM 2011 than in the previous version. Some of the most important improvements include:
    • Improved (drag & drop) form designer.
    • Multiple forms per entity.
    • In-place customization from grids & forms, in-place field creation from form designer.
    • Flat UI (tabs down the side, no longer across the top); no more limit of 8 tabs per form.
    • Customizable Sub-Grids can display both lists and charts.
  • Views. Custom views can be created and system views can be customized. Here again, much more flexibility than previously, including:
    • Public views (the ones you can select from a grid’s view menu) can be deactivated.
    • System views (e.g., Quick Find, Lookup) are more customizable than before, especially Lookup.

Custom Business Processes

Dynamics CRM 2011 has two distinct kinds of customizable business processes:

  • Workflows are automatic processes that run in the background, without any user interaction.
  • Dialogs must be run manually (i.e., started by a user) and present one or more pages containing prompts a user responds to.

This topic is big enough for a book. For example… But again…this being Dynamics CRM 101, I’ll keep it short, and simply include a few examples in the following table:

Business Process Type  Example 
Workflow 
  • Case-Routing
  • Runs automatically when a case record is created; routes case to one of several queues depending on values of various fields on case record
Workflow 
  • Solution Selling
  • Runs automatically when an opportunity record is created; automatically creates tasks, appointments and so forth appropriate to each stage of the solution selling process for an opportunity
Dialog 
  • Custom Lead Conversion
  • Prompts user in creation of contact record from selected lead. Checks to see if contact already exists; sends follow-up email, etc.
Dialog 
  • Opportunity Intake
  • Walks user through creation of opportunity record, based on responses to prompts: who is customer? What kind of opportunity is it? When is it expected to close? How much potential revenue?

 

Custom Code

The Dynamics CRM platform can also be extended by implementing custom business logic with code. In Dynamics CRM 4.0 we could generally contrast two main kinds of supported code: form script (JavaScript functions triggered by a form event such as OnLoad) and plug-ins (compiled .NET assemblies triggered by a platform event such as pre-delete). This distinction doesn’t quite do it anymore, because of the richer client-side programming model supported in Dynamics CRM 2011. Nowadays, this is a better way to classify the ways you can program Dynamics CRM in a supported manner:

  • Client-side programming with
    Web Resources. Web resources are “virtual files”: they’re stored in the Dynamics CRM database, but generally treated as if they were files. They provide a rich and powerful programming model, the main constraint being that all code is executed on the client. Some examples:
    • Jscript, triggered by form events, to create a dynamic form experience for users.
    • HTML pages can present a customized UI, can be combined with stylesheets, execute script, and so forth.
    • Silverlight web resources can be used to extend the UI in complex ways, such as custom grids and list views, controls like sliders and gauges, and pretty much anything you can think of doing with Silverlight.
  • Server-side programming with Plug-Ins and custom workflows. While form script is un-compiled Jscript and must always be triggered by an event on a form, plug-ins are compiled .NET assemblies, and can be triggered by any event supported by Dynamics CRM, not just form events. While plug-ins can be more “complex” than form script, the most important requirement for a plug-in is that something must happen when a record is created or modified outside of the form. For example, if custom logic needs to be applied when a record is created, form script won’t always work, because a record can be created in lots of ways other than interactively by a user entering information on a form, such as importing records, or automatically creating records through a workflow or dialog process. Here are a few commonly encountered examples:
    • “Geo-code” a record (update latitude and longitude) when it’s created or when certain address fields change.
    • Check or update an external system when a new record is created.
    • Run custom business logic to check for duplicate records and take appropriate action.


4 Comments »

  1. ismail tutumluer Said,

    October 19, 2011 @ 3:07 am

    Nice summary. Thanks.

  2. AdamV Said,

    October 24, 2011 @ 4:13 pm

    Brilliant as always. Keep it up!

    One thing I always try to impress upon people when training them is that activities are not just about recording things which have happened (which is great for management reports to track activity and work carried out), but for planning too (which has a benefit to the user themselves of helping to organise and prioritise their work).

    Obvious example with or without CRM is appointments which are usually arranged for the future, then take place, then are updated (maybe with some notes) and then marked as complete. Service activities amount to the same thing from the point of view of a person who is diarised to carry out the job.

    Tasks also lend themselves well to being self-evidently planned ahead as reminders to do something which is then closed when done as a record of who-what-when.

    Forward-scheduling an important phone call to remind yourself (or someone else) to make that call is also very useful (and even better if it is created by a workflow as the outcome of something else – calling to close an opportunity, or following up a closed case to make sure the customer is satisfied).

  3. Richard Knudson Said,

    November 3, 2011 @ 6:39 pm

    Hi Adam,

    Thanks for the compliment, and for the as-always thoughtful note. I agree with your emphasis and will start including it in my training sessions!

    Plus, I think you just taught be another British-ism I should thank you for: diarised. Nice. Right up there with bespoke.

    Cheers,

    Richard

  4. Richard Said,

    December 30, 2011 @ 4:41 pm

    i have been looking for a basic 101 lesson in CRM 2011 to understand the underlying concepts…

    finally!

    thanks… this helps me to solidify my own understanding about what comes out of the box and where i might go with the program.

    keep up the great work :)

Leave a Comment