Using the Microsoft Dynamics 365 Opportunity Entity

The Microsoft Dynamics 365 Opportunity

The Opportunity entity, as well as related features such as pipeline charts, goals, and sales reports, is about Time and Money:

Time: When might the business close? (Estimated Close Date)

Money: How much might be realized?  (Estimated Revenue)

Who: Who is responsible for driving this business? (Owner)

The Opportunity form in Microsoft Dynamics 365 is designed to reflect this in a number of ways:

  • Important fields in the header:
    • Close Date
    • Revenue
    • Status
    • Owner
  • A Chevron-Based visual business process

Using the Business Process Flow

The Business Process Flow is designed to keep the sales staff on track through a given sales process. Since the process flow is entirely customizable, the flow can provide a way to standardize sales processes across the organization, or across business units.

The feature is designed as a series of stages and steps. Each chevron is a stage, and the fields presented within the stage can be considered “steps.” Users interact with the flow to report and also view various steps. Thus, below, the Opportunity is in the “Qualify” stage, but since all steps are completed, it may be time to advance the stage to the next by clicking the “Next State” icon in the upper right corner. See below for a screen shot.

Microsoft Dynamics 365 Business Process Flow

Figure 1 – The Microsoft Dynamics 365 Opportunity Business Process Flow

Clicking the “Next Sales Stage” reveals new steps below that stage which are initially incomplete.

Microsoft Dynamics 365 Opportunity Business Process Flow Stage 2

Figure 2 – Stage 2 of the Business Process Flow – note the new steps visible.

Best Practice ! A common customization to be made in Microsoft Dynamics 365 is to tie activities to the completion of steps in the Business Process flow AUTOMATICALLY. This is accomplished with workflows, and alleviates the users from needing to set these completion flags themselves. If the system can do it for them, they can focus on simply completing the activities – emails, phone calls, etc. In this way the flow becomes informational for all, and less of a burden on the sales team.

Product Catalog and Price List Items

Another important aspect of the Opportunity entity is the ability to use the Product Catalog to precisely define what the customer would potentially be buying. This is done by creating Products (“Product” is a loose term which can also include any type of service that generates revenue, such as professional services) with pricing, and attaching those “Price List Items” to the Opportunity. This supports a couple of powerful functions:

  1. Automatic Estimated Revenue, based on pricing and discounts.
  2. One-Click Quote generation from an Opportunity.

To set this up for use on the Opportunity, a user with permission must:

  1. Create and Publish Products
  2. Create at least one Price List
  3. Add Products to the Price List

Once at least one Product, Price List, and Price List Item is created in this way, it’s possible for users to add Line Items to Opportunities as shown below in figure 3 by clicking the small plus sign in the sub-grid for Product Line Items.

Microsoft Dynamics 365 Price List Item

Figure 3 – Price List Items added to an Opportunity (AKA “Product Line Items”)

When the user clicks the small plug sign as shown above in figure 28, they are prompted to use an existing product from the catalog, or “write-in” a product. If the “Revenue” field is set to “System Calculated,” the Est. Revenue field will reflect the sum total of the pricing of all Line Items as shown below in figure 4.

Best Practice ! Set up your Product Catalog before your sales users begin to use the system to ensure the least amount of frustration when creating complex Opportunities and Quotes with multiple line items.

Remember that products will not show up unless there are Price List Items in the Price List that is selected on the Opportunity form.

Calculated Opportunity with Price List Items

Figure 4 – Microsoft Dynamics 365 Opportunity Calculated with Price List Items

Note that the Est. Revenue is now calculated automatically (and the field is locked – which means it can only be changed by adding or removing price list items or providing discounts on those items). To support this entire feature set, the following must be in place:

  1. Price List created and set on the Opportunity
  2. Price List Items created in the selected Price List
  3. Products chosen on the Opportunity
  4. Revenue set to “System Calculated”

This post has been an introduction as to how to make use of the Opportunity entity in Microsoft Dynamics 365. We hope you have found it useful. For more hands-on experience with Microsoft Dynamics 365 feel free to sign up for our free weekly webinar by using the pop-up training form below.  Thanks!


Microsoft Dynamics 365 for Service Introduction

[et_pb_section bb_built=”1″][et_pb_row][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.18″]

Microsoft Dynamics 365 for Service Components

Microsoft Dynamics 365 for Service is a large, fully-functional module that has been present since the beginning of the Microsoft Dynamics platform, and which has evolved considerably over the years. The heart and soul of the current Service “app” remains the Case entity, but a large number of additional entities and features have been added. Figure 1 below provides a good way to understand the various functions provided by the Service app.  

Microsoft Dynamics 365 Service Features

Figure 1 – Microsoft Dynamics 365 Service Module Features Included

! Pitfall Some users have been confused by certain aspects of the evolving nature of the Service application. For instance, as of October 2018, there are two types of Knowledge components – the “Knowledge Article” and the “Article”, and two categorization capabilities – the “Subject Tree” and the “Category.”  The “Knowledge Article” and “Category” are used in the “Customer Service Hub”, which might be characterized as a more modern interface reminiscent of Microsoft Teams, whereas the “Article” and “Subject Tree” are used in the traditional interface of the Microsoft Dynamics 365 Service application.  This part of the application continues to evolve.


Figure 1 above provides a useful list of features that are present in the Service app, and their descriptions.  Before you get started with the Service module in Microsoft Dynamics 365, you should understand some key components in the list above.  Table 1 below is designed to help you understand whether or not your organization may wish to make use of the various features of this very robust module.


Use this Feature if your Organization Wishes To …


Track work items (like Cases) in a list that can be “picked” to work on by staff, where anyone can see who is working on what.  This is also necessary if you wish to “route” cases to a queue using routing rules.  Also, use queues to create aliases that don’t consume a Microsoft Dynamics 365 license, but which can send and receive emails.

Parent and Child Case Settings

Track cases that may spawn “child” cases and inherit the attributes of a “Parent” case. We see call centers using this frequently when an outage may be related to many tickets that are opened, and staff wish to group them under a “Master” case.

Routing Rule Sets

Automatically assign cases to a Queue, or to a User/Team based on values in the Case itself, or values in a record related to a Case, such as a Customer, Entitlement, Contract Line, or other related entities.

Automatic Record Creation and Update Rules

Automatically create a record from certain types of activities (for instance, create a Case from an Email under certain conditions). This feature can also be used to specific additional actions after the creation, such as sending an email. This is frequently used by support teams to create specific cases based on incoming emails to a support alias, along with notification. All of this can be accomplished using the Workflow engine (Processes) as well – but this feature provides a slightly easier interface


Assist support staff with information relevant to a given Case. This is a hierarchical tree of subjects, which is an important field on the Case entity. Subjects are also related to Articles, which facilitates a subject-based knowledge base that shows appropriate articles for the case in question to help support staff.

Service Level Agreements (SLA)

Establish and enforce (or at least inform status of) a set of standards for support tickets (cases). An example is that a response for a ticket must be recorded by the system (and what constitutes a “response” can be defined in the SLA) within, say, 4 hours. Warnings actions can be set, and then failure actions, such as email notifications and re-assignments can be configured.  (By the way, SLA’s can also be applied to Sales entities, such as Leads, Opportunities and Quotes.)


Define a number of support cases or minutes allocated for a customer, the balance of which is automatically calculated as support teams resolve cases. Use this when you would like multiple channels of support, with different allocations.  This feature also contains less moving parts than Contracts and Contract Lines.

Holiday Schedule

Apply holiday hours to SLA’s where the SLA might be different for holiday schedules.  This should also be configured if it applies and if you also plan to set a Customer Service Calendar (see below)

Customer Support Calendar

Set a schedule for when support is available and when a SLA should be enforced. This is an optional field on the SLA. If a Holiday Schedule is set, you can set the Customer Service schedule to honor the Holiday Schedule during holidays.

Service Configuration Settings

Control and manage certain SLA and Entitlement features. For instance, you can completely disable SLA’s with one click, or set manual overrides. You can also configure SLA Pauses based on the status of the case. You can also control the automatic calculation of customer entitlement balances.

Embedded Knowledge Search

Turn on Knowledge Base capability for entities.  In addition to this ability, the “Knowledge Source” setting allows either the use of Dynamics 365 or “Parature” for the source and management of knowledge articles.  However, it should be understood that Parature as source of these articles is now deprecated[i], so about the only utility left in this feature is the ability to turn on Knowledge Management for specific entities, which is something that can also be done in the Customization area of the application.  Incidentally, “turning on” this capability consists of creating a many-to-many relationship between the entity and the Article entity, which allows a sub-grid to be created to add articles to the entity in question.


Categorize Knowledge Articles found in the Customer Service Hub.

Entitlement Templates

Set up templates that form the basis for new Entitlements. The template simply allows for a set of parameters that can be individually changed on each new Entitlement, but it’s a time-saver to have the SLA, a name, terms, channels and potentially products all defined before the Entitlement is created.  Then each Entitlement can be tailored, if applicable, to a specific deal or customer. This is similar to a Contract Template.

Email Templates

Create templated communication that can be used on the fly when sending communication out regarding service requests, or knowledge components.

Article Templates

Create formatted templates for new Articles. For of these are provided by default, but new templates can be created as well. Sections, text and header sizes, languages and simple formatting can be pre-determined, and the user then chooses a template when creating a new Article.

Contract Templates

Create pre-determined templates for new service Contracts. Important choices here are Allotment Type (cases or minutes), billing frequency, contract service level, and the calendar of support hours. When a user creates a Contract record, they choose a template.  Contract Lines are then configured with allotments, and the closure of Cases under the Contract Line subtracts the allotment, depending on the Contract Template chosen for the Contract.

Business Closure

Set a single, upcoming calendar period where Service Activities cannot be scheduled. Creating this record will prohibit the scheduling of these types of activities unless resources with the “Do Not Observe” option checked are part of the activity. An example would be a day or days where all service vehicles are to undergo an emergency maintenance event.


Create specific resources that can be scheduled using Service Activities, and that would appear in the Service Calendar.


Create specific locations where resources can be located in specific time zones for scheduling purposes, and also to manage Resource Groups.


Define categorical types of services which require specific sets or resources and durations when scheduled Service Activities.

Resource Groups

Define the specific components of groups of facilities, equipment, people, and even other resource groups that are required to carry out a particular Service. Using Resource Groups allows the enforcement of “Selection Rules” so that the minimum resources required for a Service Activity are available when attempting to schedule.

[i] Microsoft (2018), “Use embedded knowledge search to set up knowledge management”,




Qualifying Leads in Microsoft Dynamics 365

Converting (Qualifying) Leads in Microsoft Dynamics 365

The concept of the “Lead”, as mentioned in other posts in this series, is for the organization using Microsoft Dynamics 365 to use the Lead entity to store low-value information, work the Lead in an effort to sell services or products, and eventually either “Qualify” or “Disqualify” the lead. This is performed simply by clicking on either of the two icons shown below on the Lead entity form.

Qualify a Lead in Microsoft Dynamics 365

Figure 1 – Qualify and Disqualify buttons on the Lead form in Microsoft Dynamics 365

  • Typically, if you click this icon, you are essentially saying the system “This is not worthy of creating an Opportunity, Account and/or Contact from this effort – make it disappear.” The concept is to remove it from the active lead lists so that the sales team does not expend any more effort on the sales effort – at least for now. (Leads can be re-activated and no data is lost.)
  • Typically, this icon is clicked if the efforts could prove to be fruitful.  What you are saying to the system in this case, is “This effort could go somewhere, and we should create more information to manage those efforts.” This “more information” consists of an Opportunity, a Contact and possibly an Account (if the Company field was filled out on the Lead form.)

To illustrate this important concept, we will provide a small graphic followed by the way the qualification/conversion is represented in the interface, as well as the populating of the Opportunity, Contact and Account entities.

Converting a Lead in Microsoft Dynamics 365

Figure 2 – The Qualification of a Lead can potentially create three new records – the Contact, Account and Opportunity

To understand how this is represented in the interface, see the figures below, which represent the Lead and the ensuing three entity forms showing information as well as important relationships between those newly created entity records.

Microsoft Dynamics 365 Lead Form Summary Tab

Figure 3 – The Lead form Summary Tab

Note in figure 3 above the important fields, such as Topic, Name and Company. There are other fields populated, such as job title, phone information, email, website, and address information. We also see an estimated budget.

The next step is to click QUALIFY at the top of the lead form.  Once this is done, the page refreshes and the newly create Opportunity form is presented for the Lead that was just converted. See below.

Microsoft Dynamics 365 Opportunity from Lead

Figure 4 – The Microsoft Dynamics 365 Opportunity that was created from converting a Lead

Note the highlighted fields, where the Contact and Account are lookups to records that were created in the qualification process, and the opportunity was named from the Topic of the lead.

Clicking on the Contact link in the Opportunity presents the contact form as shown below for the newly created contact record.

Microsoft Dynamics 365 from Converted Lead

Figure 5 – Microsoft Dynamics 365 Contact from a Converted Lead

Figure 5 above shows the form for the Contact record that was created during the Lead qualification process. Note that all of the relevant information that was present in the Lead was transferred over to the Contact– such as Job Title, Email, Phone, Address.  And the Account Name field is a lookup to the created Account record, which we will examine next. (Please note that the photo was not transferred – this must be uploaded on the Contact record.)

Clicking on the Account Name field presents the form for the Account record that was created during the qualification process. See below for a screen shot of this record.

Microsoft Dynamics 365 Account from a Lead

Figure 6 – The Account record that was created from the Conversion of a Microsoft Dynamics 365 Lead

Figure 6 above shows a rich set of information that was created when the Lead was qualified, such as the name of the organization, the main business phone, the address, the website, as well as the primary contact and their contact information.  In addition to the Primary Contact field populated with the contact that was created, the same contact record was added to the list of contacts that are associated with this newly formed company.  Also, the system posted information in the social pane that informed all users who look at this record who created these records and when.

Thus, with a rich set of data across three newly created entity records in Microsoft Dynamics 365, the Lead Qualification process represents a significant time-saver (one click on the Lead created all of this inter-related data), as well as lays the groundwork for a robust system of Customer management, where information about Companies, People, and Opportunities is stored in separate but related entities in the system. This is powerful for organizations of any size that seek to maintain their data in an organized and reportable fashion.



Microsoft Dynamics 365 Sales Vernacular

Terms used in Microsoft Dynamics 365 for Sales

The Microsoft Dynamics 365 for Sales application is designed to provide a robust system for the management of sales activities in your organization, although many deployments start with the sales application and customize it for whatever line of business they are servicing. This blog introduces the components of the sales application.

Understanding Leads, Opportunities, and Customers

It’s important to understand Microsoft’s interpretation of the core entities that make up the sales application.

  • Leads. The Lead entity in Microsoft Dynamics is designed to store information about potential but not-quite-qualified customers. Since customer information is stored using Contacts and Accounts, the concept is to store new information about people and organizations and your efforts to win business from those people and organizations. And if the efforts are successful, the lead is “Qualified”, and thus converted to a Contact and an Account, if applicable. The most common use-case for the Lead entity is to store large amounts of low-quality data – such as purchased lead list, or a downloaded large list of contact information for potential customers, a list of your followers from LinkedIn, or perhaps a stack of business cards you collected at a trade show or by some other means.  You will see information on a lead form related to three major parts of the sales process, which become signification in the conversion process:
    • The person you are communicating with
    • The organization you are communicating with
    • The topic of conversation
  • Opportunities. In Microsoft Dynamics 365, the Opportunity entity is designed to store information about qualified Leads[1]. In fact, the act of Qualifying a Lead record immediately creates an Opportunity. We are often asked the difference between the Lead and the Opportunity entities.  There are a number of important differences:
    • An Opportunity requires a Customer (either a Contact or an Account.) A Lead can stand alone.
    • The Opportunity contains information about Revenue and Time (estimated and actual revenue, and estimated and actual close date)
    • The Opportunity supports line items from the Product Catalog, and the value of the Opportunity can be automatically calculated from the values added from the catalog.
    • The Opportunity can be quickly converted to an Quote.
  • Customers. It’s slightly misleading, because there is actually no such entity as “Customer” in Microsoft Dynamics 365. In fact, the concept of “Customer” is a conditional descriptor of EITHER a Contact (a person) or an Account (an organization). This is represented in the Microsoft Dynamics 365 interface in a number of ways:
    • The “Customer” area in the Sales module navigation, where Contact and Account are listed as tiles to choose from.
    • The special field named “Customer” and “Potential Customer” on certain entity forms, such as Opportunity, Quote, Order and Invoice, which can be EITHER a Contact or an Account.
    • When an Opportunity is created from a Contact, the Contact is the Customer. When an Opportunity is created from an Account, the Account is the Customer.

[1] Some organizations that deploy Microsoft Dynamics 365 choose not to use the Lead entity, since the bulk of their sales are repeat sales from existing customers. In this case, the Opportunity is simply created under the existing Customer, instead of converting a Lead.


Microsoft Dynamics 365 Licensing and User Management

[et_pb_section bb_built=”1″][et_pb_row][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.18″]

User Management and Licensing for Microsoft Dynamics 365

The Microsoft Dynamics 365 subscription is managed in the Microsoft Office online portal (, which is the same place that an organization manages their Microsoft Office subscription. Once you subscribe to Microsoft Dynamics 365, you will see an icon similar to what is shown below.

Office 365 Portal App Management The list of icons in your Microsoft online subscription will determine what icons you see when you click on the 9-dot waffle icon in the upper left corner after you login to

Click on the Dynamics 365 icon to be presented with the “Dynamics 365 Home” screen that will list whatever Dynamics 365 applications you subscribe to. To manage users, click on the Admin icon as shown above.

User and License Management

When you first deploy Microsoft Dynamics 365, especially if you start with a trial, there will be only one licensed user for the application – generally, the global administrator of the “tenant” – which is the organization that is associated with the Microsoft 365 subscription. Clicking Admin will allow the management of the users in your company, provided you are an administrator with enough access to manage users. In the administration module for the Microsoft 365 Admin Center, you would expand the Users section and click Active Users as shown below.

Active Users in Office 365 Portal 

Figure 2 – Active Users in the Office 365 Admin Portal

In “Home > Users > Active Users” you will be able to add a user, delete a user, edit the contact information, roles, reset the password, and manage licensing. Get started with these tasks by clicking “More” and choosing what you wish to do as shown below.

Active Users in Office 365 Portal

Figure 3 – User-management actions available in the admin center

It’s important to understand that you can add users without incurring charges to any subscription you have with Microsoft because users and licenses are separately managed. The steps are to first create the user, and then apply whatever licenses you like to the user you just created.

License Management

Once you have created a user, you can assign one or more available licenses to that user. To assign or manage software licenses, you would click “Edit” on the user management screen as shown below.

Assign Office 365 Software Licenses

Figure 4 – Editing software licenses in Microsoft 365  

Assigning or revoking licenses is as simple as sliding the license status “On” or “Off” as shown below.

Office 365 Toggle LIcenses

Figure 18 – Assigning or revoking product licenses in Microsoft 365

Click Save when complete. Obtaining new licenses to products is performed in the “Billing” section, where you can manage your subscriptions, view your billing history, payment methods, licenses and view billing notifications.

It’s important to know that any subscriptions that are provided to your organization through a Microsoft Partner will not appear in this list of subscriptions. To manage those subscriptions, you must contact the partner that provided you with the services. It is possible to purchases licenses for subscriptions directly from Microsoft using your administration panel, although for continuity and to mitigate confusion it is recommended that you work through your partner to add licenses to those subscriptions that are managed in this way.

Purchasing Licenses from Microsoft

To purchase services directly from Microsoft, simply click Billing and “Purchase Services” as shown below.  

Purchase Licenses from Microsoft


Microsoft Dynamics 365 Service

Microsoft Dynamics 365 Accelerator for Non-Profit Donor Management

NonProfit Add-On Released by Microsoft

Microsoft recently released an “Accelerator” for Nonprofit companies that are currently using Microsoft Dynamics 365. For those that don’t know what is meant by the term Accelerator in this context, it’s essentially a solution that provides pre-configured entities that relate to the vertical market in question. In this case, it’s the Not-for-Profit sector, and Donor Management.

This is helpful, since Salesforce is often touted as the CRM of choice for Non-Profits, but we respectfully disagree. In fact, we believe that Dynamics 365 is a great choice, and we have even built a course for organizations who wish to build a custom solution.

But for those organizations who just want to get started quickly, the new accelerator should provide a nice starting point.

According to the AppSource,” … the Nonprofit Accelerator extends the Common Data Model (CDM) to include new entities to support a data schema for the nonprofit sector. With the Common Data Model organizations have a unified view of their data across sources which enables business apps to deliver new insights and drive intelligence-based experiences to users within the organization.”

You can test drive this application, even without having your own instance of Microsoft Dynamics 365, y visiting the AppSource listing here.

Custom areas and entities that come with this solution include:

Fundraising Management

  • Donor Commitments
  • Planned Giving
  • Transactions

Grant Management

  • Objectives
  • Programs
  • Grant Request
  • Grant Awards
  • Dockets

Program Management

  • Programs
  • Budgets
  • Benchmarks
  • Reviews

Volunteer Management

  • Volunteers
  • Applicants

Below is a screen shot that shows the navigation (sitemap) of the solution.

This is definitely worth a try and using the Test Drive feature mentioned above you can try it out without even purchasing Microsoft Dynamics 365!  An alternative is to download the solution and install it into a trial version of Microsoft Dynamics 365, but this is a bit more work, and requires knowledge how to install a solution.


Choosing a Version of Microsoft Dynamics 365

[et_pb_section bb_built=”1″][et_pb_row][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.18″]

Microsoft Dynamics 365 Versions

The focus of this blog is currently the Microsoft Dynamics 365 Sales and Customer Service applications. But for context, we supply the full, current list of business software applications that make up Microsoft Dynamics 365. It should be understood that with bundling, it’s possible to use most or all of these applications with a single price that is far lower than if they are chosen individually. Microsoft Dynamics 365 is a product in a constant state of evolution.  Thus, we can only report the available versions at the time of this post (early November 2018.)  We have no doubt that what we present below will change, but you can always check the latest version simply by visiting Microsoft’s site devoted to the family of products, which is currently or by simply typing “Microsoft Dynamics 365” in your favorite web browser and following the likely link. Currently, Microsoft Dynamics 365 consists of a wide range of business applications, some of which are very recently added, and some of which were present from the beginning and have gone through a great deal of refinement. Table 1 below shows the application, a quick tagline to explain it, and the approximate date of release.  

Application Release Quick Description
Sales Jan 2003 Leads, Opportunities, and Customer Management
Customer Service Jan 2003 Cases, KB Articles, Queues, and Contracts
Field Service Mar 2016 Work Orders, Dispatch and Service Scheduling
Talent Jul 2017 HR Management (Recruiting, Onboarding)
Finance and Operations 2016-2017 Formerly “AX” (rebranded twice) – a complete ERP solution. Finance, Operations, Supply Chain. Generally, for larger organizations.
Retail   Storefront Management, Payment, Merchandise Management
Project Service Automation Mar 2016 Project Planning, Costs, Sales, Resource Management, Delivery, and Billing
Marketing (Adobe Marketing Cloud) 2017-2018 Analytics, Prospect Tracking and Management. This requires an inquiry to Microsoft to get this set up.
Marketing (Dynamics 365) Apr 2018 Automated Marketing Campaigns, Landing Pages, Prospect Nurturing, Response Analytics
AI for Sales 2018 Artificial Intelligence add-on for Dynamics 365 for Sales
Ai for Service 2018 Artificial Intelligence add-on for Dynamics 365 for Service
Mixed Reality 2018 Virtual Reality devices used to remotely troubleshoot and collaborate
Business Central 2018 ERP for small business – all-in-one financial, operations, marketing, service, and sales (Originally “NAV”).

  Table 1 – List of Microsoft Dynamics 365 Business Applications (11/2018) Choosing the application or applications from the suite that is Microsoft Dynamics 365 can be a daunting task, although if you approach it systematically, it should not take an onerous amount of time. Here is how we would suggest you approach it:

  1. Identify high-level problems that your company has or needs that are not being fulfilled by your current processes. Keep this list high-level at first.
  2. Review the Overview and perhaps an introductory video of each of the applications that might assist in your quest for business software. Look for some use cases for the applications that interest you the most.
  3. After you have reviewed what is available, return to the list of high-level needs and add to them, since you may have uncovered possibilities that you didn’t know existed from the overviews, videos, and use cases.
  4. Create a matrix that uses the applications and columns and the rows as your needs. Place a checkmark in each cell for the need that could potentially be met by the respective software.

An abbreviated matrix is shown below so you get an idea.  

Category Need Sales Svc PSA Mark
Sales Lead Qualification X      
Sales Opportunity Management X      
Customer Svc Service Requests   X    
Customer Svc Contract Management   X    
Pro Services Software solution project management/delivery     X  
Pro Services Quote and Invoicing X      
Sales Reporting X      
Marketing Email campaigns, analytics tracking       X

  Table 2 – Need/Feature Matric Example The Sales and Service applications are broken up into two offerings levels:

  • Professional
  • Enterprise

At the time of this writing (November 2018), Microsoft just released a new licensing guide that indicates that the most significant difference between these two versions is a limit of 15 custom entities for the Professional version.  There is a limit of 1500 custom entities in the Enterprise version, which we would argue is no effective limit, since we can think of no use case where anywhere near that number of entities would be required. We can easily imagine, however, a scenario when fifteen custom entities may not be enough to create a robust custom solution for a line-of-business application.  Considering this limitation, if you are planning to deploy the Professional version (at the time of this writing, the Pro version of Sales and Service is $30/user/month less expensive than the Enterprise version), there are two strategies that will be covered in the Customization section of this book – Global Option Sets and re-purposing entities.



Navigating Microsoft Dynamics 365

[et_pb_section bb_built=”1″][et_pb_row][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.18″]

Microsoft Dynamics 365 Navigation

It’s important to understand how to navigate through the system. Now that you understand the definition of views and forms, you can better understand how to locate those important sets of data. As you shall see, there are two fundamental methods of navigating, and therefore using the system. These are not mutually exclusive by any means, and all users should be familiar with both approaches.

Menu Navigation

Microsoft Dynamics 365 features a top-bar, hierarchical style of navigation, as shown in figure 1 below.  This bar is accessed by clicking on the top bar, which reveals a set up “drop-down” tiles that represent various modules where information is contained in the system. Microsoft Dynamics Sales and Service Navigation Bar    

Figure 1 – Module Tiles in Microsoft Dynamics 365

What tiles show in this level of navigation depends on the versions and choices you have made in your trial or your purchase. The three modules above (Sales, Service, Marketing) are what are seen if you have a version that supports both the Sales and Service modules. (Marketing comes with Sales.) The next level of navigation is what you see when you click on any one of the tiles shown above. Figure 10 below is a set of tiles presented when the Sales module is clicked. Microsoft Dynamics 365 Sales Navigation Bar            

Figure 2 – The Sales module navigation

Clicking on any icon will display the default view of the entity that is represented by the icon – such as Accounts, Contacts, Leads, etc.


The presentation of tiles for modules and icons for entities is referred to and controlled by the “Sitemap” which, from a technical perspective, is an XML document, which is editable.  There are two methods by which the sitemap can be edited:

  1. Include the sitemap as a component in a solution, export the sitemap, edit the XML and import the sitemap.
  2. Use the Sitemap Designer, which is a PowerApp that Microsoft created to visually edit the sitemap using a drag and drop interface.

While it could be argued that a user has more ability to control the finer aspects of presentation when using the first method, we predict that most Administrators of Microsoft Dynamics 365, technical or otherwise, will elect to use the Sitemap Designer since it is quite simple and accomplishes the most common needs.  Figure 3 below is a screen shot of the designer itself. Microsoft Dynamics 365 Sitemap Designer Figure 3 – the new “Sitemap Designer” available in Microsoft Dynamics 365. This tool features drag and drop capability.

For those that are curious about what the Sitemap consists of, below is a snippet from a sitemap XML file that governs some of the tiles that are shown in this post. Please note that the colored text represented in this screen shot is available when using Notepad ++, a text editing tool popular with developers. Microsoft Dynamics 365 Sitemap XML Figure 4 – a snippet from the Microsoft Dynamics 365 sitemap XML file that is included in the default solution.

Please see other blog posts in this series for specific instructions how to use the PowerApp tool to edit the Sitemap.

View Navigation and Filtering

Once an entity icon is clicked and the default view appears, the user can further navigate in the following ways:

  • Change the view using the View Selector as described earlier
  • Filter the view in place using the “funnel” icon to set filters as shown belowFilter a View in Microsoft Dynamics 365   Figure 5 – Applying selectable filters to all columns in a view

Clicking on any of the small black triangles next to the column names will provide the ability to filter based on a specific type of data.  For instance, using the filter as shown above would allow a user to filter the list by “Specific Owner” by clicking on the selector next to the Owner column. At this point, the user will have found the record they wish to open and has used the menu navigation method to find that data. The last step is to simply click on the Name of the entity, if it is available in the view, or double-click between any column on a record row in the view.  This will open the form for the specific record in question.

Dashboard Navigation

Based on the number of steps shown above that the Microsoft Dynamics 365 user must execute to navigate to a record, and considering the sheer number of modules and entities represented, no one should be surprised that instead of using the menus and tiles to navigate to data in Dynamics 365, users often elect to create and use dashboards as a means of navigation. The advantages of using dashboards to find and navigate to important information are:

  • Up to six entities can be represented on a single page
  • Records can be presented using views or charts
  • Dashboard components can be drilled into to filter visually
  • Dashboards are entirely customizable, so that users can decide what information to see and how to see it

Since the user will most likely use a dashboard of their own design, much of the searching for specific types of data is saved, and the dashboard can be pre-filtered to show only the sets of data and visualizations that the user is most interested in. This saves time in navigation. Microsoft Dynamics 365 Dashboard                    

Figure 6 – A typical User-focused Dashboard

In figure 6 above, we see that a user has created a dashboard that presents their activities in the upper left, sorted by due dates. Opportunities and Leads assigned to this user is presented as well, with some graphical information to help the user focus on accounts and opportunities of importance. To navigate to the data behind a given dashboard component, the user can click the middle icon in the component as shown below. Snap out a Dashboard with Microsoft Dynamics 365                          

Figure 7 – Snapping out a dashboard component

Clicking on this icon will present the graphic from the component, along with the underlying data that makes up the graphic, in the form of a view. Microsoft Dynamics 365 Dashboard Chart and View Figure 8  – A dashboard component snapped out with the underlying view

The graphic can be used to filter the view. For instance, clicking on any element of the component, such as the blue part of the funnel above, would present only the opportunities that are in the stage “Qualify.” It’s important to understand that both the Chart Selector and the View Selector can be used to change the chart and view.  This provides a wide array of visualizations, all of which are filterable through interaction. Considering the fact that many different types of charts can be created against any number of views, and you can see that dashboard navigation can be far more efficient than hunting for a single record using common navigational features.  


Views and Forms in Microsoft Dynamics 365

[et_pb_section bb_built=”1″][et_pb_row][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.18″]

Creating Views and Forms in Microsoft Dynamics 365

One of the most important aspects of customizing the user experience in Microsoft Dynamics 365 is the construction of custom views and forms.  These components can be created on standard entities that come with the out-of-the-box version of the software, such as Leads, Opportunities, Accounts and Contacts, or they can be created for custom entities that are designed to solve specific problems and meet specific requirements for the organization deploying Microsoft Dynamics 365.

Microsoft Dynamics 365 Views

All entities in the system feature at least one view, which is a list of records of that entity, containing columns from the entity, and laid out much like an Excel spreadsheet. As an example, in terms of navigation, when a user clicks on the “Contacts” tile, they are presented with a default list of Contacts (the default view can be edited, changed to another view, or overridden by each individual user using the “pin” feature.)  Views are completely customizable. Figure 4 below illustrates a typical default view of Accounts, which results when a user navigates to the Accounts entity.

My Accounts View in Microsoft Dynamics 365

Figure 1 – A Default View of Accounts All views have columns and “filter properties,” also known as “criteria.” The filter properties form the basis of the query that filters the list of records.  Well-named views provide a clue as to the filter criteria used.  For instance, above we see “My Active Accounts.”  This is a well-named query, since the filter criteria of the view is:

  • All accounts where Status = Active
  • Owner equal current user

A view that is constructed in this way will ensure that whoever logs in will see “their” accounts and that those accounts will be in an “active” state.  

Skill ! An important skill in Microsoft Dynamics 365 is to fully understand the basis of any view. This is easily done by clicking the Advanced Find icon at the top of the screen after navigating to the view in question.  Continue reading these blogs for a step-by-step for this important skill.

Users of Microsoft Dynamics 365 can switch to different views easily, simply by clicking the small black arrow next to the view name knows as the “View Selector” as shown in figure 5 below.

Microsoft Dynamics 365 View Selector

Figure 2 – the View Selector allows users to choose a view The results of views can be exported to Microsoft Excel as shown below in figure 3.

Export to Excel in Microsoft Dynamics 365

 Figure 3 – The “EXPORT TO EXCEL” feature is available for all views

Microsoft Dynamics 365 Forms

Each entity in the system has one or more forms, which is a screen that contains various fields from the entity in question. To view an entity form, you can click on the name of any field presented in a view or double-click between fields on a view. This will “open” the record and present the form.  The form for any entity is presented as a number of tabs, sections, and fields.  Figure 7 is a screen shot of a typical form for a Contact record. Microsoft Dynamics 365 Contact Form                      


Figure 4 – The contact form for the record of Susan Burk

Figure 4 above shows the expanded “Summary” tab to reveal several sections (i.e. “CONTACT INFORMATION, POSTS, OPPORTUNITIES”) and within those sections are fields and “sub-grids” of related information. Using this robust method of presentation, Microsoft Dynamics 365 truly does present a “365 degree” view of information all in one place about a given record – in this case, a customer or potential customer named Susan Burk. The following information is readily available on the form or just one click away:

  • Contact Information
  • Company Details, such as Primary Contact Phone
  • Opportunities
  • Photo
  • Posts (news and related announcements)
  • Activities, Notes, and the Assistant (information fed automatically)

The Summary tab is only one tab on the Contact form.  Collapsing that tab and expanding the Details tab provides more information as shown below. Microsoft Dynamics 365 Contact Form Details Tab                    

Figure 5 – The Details tab on the Contact form – expanded to show information

As covered later in this blog series, forms are completely customizable, in terms of which tabs, sections, fields, and the layout thereof. Colors are also customizable using the Themes customization feature.  


Basic Architecture of Microsoft Dynamics 365

[et_pb_section bb_built=”1″][et_pb_row][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.18″]

Basic Architecture of Microsoft Dynamics 365

Microsoft Dynamics 365 is a web-based, database-driven application that is hosted by Microsoft, and is accessible through several means:

  • Directly, using a web browser
  • Through an integration with Microsoft Outlook
  • Through native mobile applications
  • Through certain, supported BI applications like “Power BI”
  • Through an API
It’s useful to know that there is also an “On-Premises” version of the software which can be purchased and run on the private servers of an organization. In this case, direct access and management of the SQL database is technically possible, although not “supported.”  It should be understood that as the online product evolves, the differences between the On-Premises version and the Online version hosted by Microsoft widen. The scope of this blog post is limited to the Online version.

The database that supplies the “back-end” of Microsoft Dynamics 365 is Microsoft SQL, although none of the methods of access above provide direct access or management of the underlying SQL database. The database is relational, which means that the “entities” (tables in the database) are related to each other in several ways. Examples of these relationships are below with their respective notations and definitions. “Many-to-One” (N:1) – in this relationship, the “Many” entity is related to one and only one of the “One” entity.  Example: Any number (Many) of Contacts are related to one and only one Account. “One-to-Many” (1:N) – this type of relationship is an inverse of the one mentioned above, where the One entity is related to “Any Number” of the Many relationship. Example: One Customer can have “Any Number” of Opportunities associated with them. “Many-to-Many” (N:N) – this type of relationship is actually a bit of a technical problem in a typical relational database system such as SQL, which is what Dynamics 365 is based upon. In this type of relationship, “Any Number” one entity might be related to “Any Number” of the other type of entity.


The following modules exist in the Microsoft Dynamics 365 for Sales and the Microsoft Dynamics Service Apps, which are the most common Microsoft Dynamics 365 versions deployed[1].  A few of important points should be understood about modules:

  • They are customizable – that is, what entities appear can be modified.
  • Because they can be changed, by default, they represent the perspective of an imaginary job role. For instance, the features in the Sales module are those that Microsoft originally imagines a salesperson would be interested in using.
  • The entities common to other modules are the SAME set of data. This is important to understand. Meaning – the Contacts that are seen in Service are the same Contacts that are seen in Sales.

Sales. This module contains entities that are designed to support all manner of sales processes.  Below is a screen shot of what the module looks like when the Sales tile is clicked on a default deployment of Microsoft Dynamics 365 Sales in 2018.

Microsoft Dynamics 365 Sales Module

Figure 1 – The Sales Module by default in 2018 Service. The service module contains entities that are designed to support customer service operations. Below is a screen shot of what the module looks like when the Service tiles is clicked.

Microsoft Dynamics 365 Service Module

Figure 2 – The Service Module by default in 2018 Marketing. The marketing module contains entities that are designed to support marketing operations[2]. Below is a screen shot of what the module looks like when the Marketing tile is clicked.

Microsoft Dynamics 365 Marketing Module

Figure 3 – The Marketing Module by default in 2018  


The term “entity” originates from the XML standard, and in the context of Microsoft Dynamics 365, you can think of it as a “type of information.”  For those a little more technical, you can think of an entity as a table in the SQL database that holds data that is specific to a business function. An example is the entity “Contact,” which represents a “contacts” table in the database and is generally used to store information about people. Another example might be “Account,” which is used to store information about organizations. It should be understood that in a default Microsoft Dynamics 365 instance of either Sales or Service, there are over 300 entities in the underlying database. However, a subset of these are what you may call “functional” or “user-based” entities, which would be used by the typical Dynamics 365 user, depending on their role in the organization. Many entities exist in the background to support the main set of functional entities that we are most familiar with. Table 1 below lists the most important of these entities, the module (Sales, Service Marketing, or All) they are mainly associated with, and the definition and usage of the entity by default[3].

Entity Name Associated Module Definition/Note
Account All An organization of any type. This can be a Customer, a Vendor, or any other type of organization that you wish to track.
Contact All A person of any type. This can be a Customer, a Vendor, or any other type of person that you wish to track.
Lead Sales and Marketing A potential customer, as yet “unqualified.”  The qualification process converts the lead to an Account, Contact and an Opportunity
Opportunity Sales The date-based (when?), revenue-based (how much?) representation of potential business from a Customer. This entity is often re-named and repurposed based on the requirements of a given organization.
Competitor Sales In this entity, you can identify organizations that compete for business with your organization, as well as specific Opportunities that you are competing with them for. A basic SWOT analysis is also available.
Quote Sales The quote entity provides tracking for specific quotes containing products or services, with pricing for specific customers, and, optionally, related to a specific Opportunity.
Order` Sales The order entity is designed to track orders, and can quickly be created through the Quote entity, by clicking “Create Order” from the quote itself.  Orders can also be created in a standalone fashion, without using a quote.
Invoice Sales The invoice entity allows the user to create, track and distribute (through export to PDF or print) an invoice that is based on an order by clicking “Create Invoice” from an order. Invoices can also be created in a standalone fashion, without using an order.
Product Sales and Marketing The product entity is part of the “Product Catalog” feature in the system.  Products store information about the product itself, but prices are stored in a separate entity.
Price List Sales Price lists allow the organization to maintain multiple price lists, which may or may not have different prices for the same products in the catalog.
Price List Item Sales The price list item is the junction between a product and a price list – and the price itself is stored on the price list item, as well as any discounts that may apply.
Sales Literature Sales and Marketing This entity allows for the management of sales literature assets, such as product sheets, marketing collateral, manuals, and other documentation that could be useful for sales. It’s possible to store various version of sales literature documents and associate them with both products and competitors.
Goal Sales The goal entity and feature support the ability to track precisely sales goals and present that information in a visual way to the user and management base. Using related entities and features such as Goal Metrics and Rollup Queries, it’s possible to maintain sales goals across a wide range of staff, including individual salespeople, teams, and management. If they are set up correctly, goals update automatically when Opportunities are won and lost.
Marketing List Marketing and Sales Marketing lists work with campaigns to track a list of Leads, Accounts or Contacts that are bundled together through various criteria and then marketed to using marketing campaigns. Marketing lists can be static, which means the membership is managed manually, or dynamic, which means the membership is managed through a query against the database.
Campaigns Marketing Campaigns allow the tracking of meta-data, such as expenses, budget, start and end dates, around a sales (or any type of) activity campaign against customers or potential customers. The campaign entity allows different channels that can contain different campaign activities. It also allows the ability to track one campaign against several different types of marketing list data – such as Leads, Contacts and Accounts.  It also allows you to track campaign activities of different types and channels.
Quick Campaign Marketing The quick campaign is a wizard-based campaign tracking feature that allows the generation and distribution of one channel of campaign activity, such as phone call or email activity. With a quick campaign, you can quickly collect customers or potential customers, and launch a quick campaign against that collection of data. The limits of the quick campaign are that it can only be used for one channel (one type of activity, such as phone call or email), and it can only be used for one type of marketing list, such as Leads, Accounts or Contacts.
Campaign Activity Marketing The Campaign Activity is a specialized type of entity that is specific to Marketing. It’s not a typical activity-type entity in that it does not appears in the activity menus – only under a Campaign. Also, it has a lot of rich functionality that is very specific to marketing, such as tracking of outsourced vendors, a choice of channels, an allocated budget and actual cost (which roll up to the overall budget of the campaign), as well as relationships with one or more marketing lists.  When the Campaign Activity is “Distributed,” activities for the chosen channel (such as phone calls or emails) are created and assigned appropriately.
Campaign Response Marketing The Campaign Response entity is an activity entity that is specialized in that it has a relationship to a “Related Campaign” and is designed to track the response to any type of campaign activity. This activity does appear in the general activity menu, but not entity-specific menus.
Case Service The case entity is designed to track requests for service, or trouble tickets for an organization that tracks customer service in this manner. Cases are organized around a hierarchical “Subject Tree” and can be related to knowledge-based articles. Cases are also closely related with Contracts and Entitlements.
Article Service This is the traditional (original) knowledge base article that was features in the application since the first version.  This is not to be confused with “Knowledge Article” below.  This entity provided templates for different types of articles and allows the user to associate them with Cases.  Approving the article automatically publishes it.  These articles do NOT show up in the Customer Service Hub.
Knowledge Article Service This is an updated version of the Article above, but the chief difference is that this entity appears in the “Customer Service Hub,” which is a somewhat modern interface for the Service module. The editor is more robust as well, since it features a WYSIWYG editor, and has the ability to modify the HTML of the article.  In this version, there is an approve and then a separate publish step. These articles do NOT show up in the native Dynamics 365 interface.
Service Service The Service entity provides the ability for the categorization of Service Activities. This entity features a fair amount of business logic, which allows for Resources, Resource Groups, and Selection Rules to assist in scheduling Service Activities using Resources and Users.
Service Activity Service The Service Activity can be used in conjunction with the Service Calendar to schedule Users and Resources for specific types service, at specific locations, on a specific date and time. The Service Calendar then provides a matrix-style view to see who and what is scheduled where and when. A typical use case would be the ability to schedule a driver, a second person and a truck as a “Resource Group” and enforce that type of configuration according to a schedule.
Queue Service Queues are the ability to manage work items such as Cases (although they can also be applied to Leads and just about any other entity in the system) and assign them to a list of open items to be “selected.” A typical use case is a help desk where emails arrive through a “support” alias (a unique property of the queue is that it can have an email address that receives mail into the system but doesn’t use a Dynamics 365 license), and are listed in a queue, which is then “picked” by support staff.  Various routing rules can be created to help automate queues and assignments of work.
Contract Service The Contract provides a robust system for tracking support contracts for customers by an organization that provides service through time-based contractual arrangements.  This system is mainly composed of the Contract and Contract Line entity.  However, when working with Contracts and Cases, if the contract provides a set amount of time, or of cases, the remaining cases or minutes available to the customer per the contract can be tracked automatically through Case management.
Contract Line Service The Contract Line in Dynamics 365 is used to specific one or more types of service under a given support contract.  The benefit of using contract lines is that 1) you can provide different types of services under different types of terms for one contract and 2) when the contract and contract line is set on a given case, and the case is resolved, the time spent or the case itself will be subtracted from the contract line details.
Entitlement Service The Entitlement in Dynamics 365 is a more powerful flexible option for tracking cases and time-based allotments, because it can be applied to the company as a whole. This means that any case, as long as the entitlement is selected, will subtract in the same fashion as the Contract Line above when resolved. The other reason why Entitlements are more powerful and flexible is because a SLA can be applied, as well as the ability to specific channels of support (Phone, Email, etc.) separately.
Social Profile  Service To use this entity, you must first have a valid Social Engagement instance, which is part of the Microsoft Dynamics 365 stack, as it were. Once you have such an instance, which is associated with the same “tenant” (organizations) that your Microsoft Dynamics 365 instance is in, you will be able to set up your Social Engagement configuration.  Once that is done, any Social Profiles you create in Social Engagement will be visible in Microsoft Dynamics 365.  Note that you can only create profiles in Social Engagement, not in Microsoft Dynamics 365.  However, you can make use of the data that flows into the system through this integration.
Activity – Phone Call N/A The Phone Call entity is a type of Activity entity, which means that it resides in the “Activity Menus”, which appear throughout the system, both in the navigation, and within entity forms that are enabled for Activities. The phone call entity is unique in that is has multiple “multi-party” fields, such as “From” and “To” where it’s possible to track who was on a conference call with multiple people. This activity can also synchronize with Microsoft Outlook, and when it does, it shows up in Outlook as a Task.
Activity – Task N/A The Task entity in Dynamics 365 resembles the task in Microsoft Outlook and is relatively simple compared to the Phone Call entity, since there are no multi-party fields.  There is one lookup field to “Regarding”, which can be any entity in the system that is enabled for Activities, and there is a due date, a subject, and an owner (the person assigned to the task.) Tasks in Dynamics 365 can be made to sync with Outlook.  Tasks are most often used as reminders.
Activity – Appointment N/A The Appointment entity in Dynamics 365 resembles the appointment in Microsoft Outlook and features two multi-party fields – “Required” and “Optional.”  In these fields, it’s possible to add Users, Contacts, Accounts, Entitlements, Facilities (used in the Service Calendar), KB Articles, Leads, and Queues. The Appointment activity can be made to synchronize with Microsoft Outlook.
Activity – Letter N/A Frankly, we rarely see this entity used much in deployments we have done outside of the Legal industry, but the Letter activity does have the potential to track details around letters that were sent from Accounts, Leads, Contacts, and Users to those same entities. It also has a “Regarding” field that allows association with any entity in the system that has activities enabled.  So, if you need the ability to keep careful track of letters sent or received, this is the entity to use.  This entity would be synced with Outlook as a task.
Activity – Fax N/A The Fax entity is very rarely used, and it’s essentially a clone of the Letter activity, except instead of “Address” there is a “Fax Number” field.  Everything else is identical.  This entity would also be synced with Outlook as a task.
Activity – Custom N/A One of the most powerful features of Microsoft Dynamics 365 is the ability to create a custom entity of type “Activity.”  This is a choice you can make when creating a custom entity, and if you choose this type, the entity will show up in Activity menus throughout the system.  Besides the menu location, custom activities also have typical characteristics of activities, such as a start and end date/time, a due date, are owned by (or assigned to) Users. Custom activities cannot synchronize with Microsoft Outlook directly, but we have seen strategies where workflows are created to create parallel instances of synced entities so that information from custom entities can flow into Microsoft Outlook.
Custom Entity N/A Customization of Microsoft Dynamics 365 takes several forms, but one of the most important is the ability to create a custom entity.  Performing this action creates a table in the database and can also modify the database schema when creating relationships between other custom entities or existing entities. Custom entities feature automatic creation of a several entity forms, views, and also a place in the navigation (sitemap.) While it’s an extremely useful feature, the use of custom entities should be carefully considered, especially if an existing system entity might be lightly modified to create the same functionality that a custom entity may.  The main reason for this careful consideration is that many system entities have a rich set of business functionality that is difficult to re-create through customization.


Table 1 – A comprehensive list of the most-used entities in Microsoft Dynamics 365

[1] Other “apps” in the Microsoft Dynamics 365 family include Project Service and Field Service. These are not included in this book but provide robust and specific functionality. [2] The marketing module that comes along with the Sales module in Microsoft Dynamics 365 is not to be confused with “Microsoft Dynamics 365 for Marketing” which is an add-on. More information is found here. [3] It’s useful to note that in many deployments of Microsoft Dynamics 365, entities are often re-named and/or re-purposed.