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.


Determining A Return on Investment from a CRM

How to Determine a ROI on your CRM Investment

It’s possible to quantify, or at least theoretically quantify the return on investment for the use of a Customer Relationship Management system. There are two essential steps:

  1. Examine and Record the potential efficiencies of your organization. Based on some of the benefits we listed above, it may be possible to select specific tasks from your existing business process. Examples include:
    • Automated Communication (How much time do staff use each week/month to perform communication that could be automated?)
    • Consolidated Information (How much time do staff spend looking up information as they go about their daily tasks?)
    • Process Design/Support/Enforcement. (How much time might be saved from either Business Process Re-Engineering and the subsequent CRM enforcement thereof, or how much time might be saved if existing processes were better supported/enforced?)
  2. Perform a Calculation. This can be a simple ROI calculation and can be supported by something as simple as the following spreadsheet:
ROI Calc for CRM
Simple ROI Calculation

The figure above represents the extremely simple calculation of ROI based on two common tasks:

  1. Writing a simple thank-you email each time a sale is made.
  2. Finding an important email[1].

To use this concept, create a spreadsheet like the one above and use the formulas below.  You can add as many Process/Tasks as you like. Naturally, your numbers will differ entirely from the examples above.  You will need to discover and enter the following cells A2(+) à F2(+).

Here is the very simple set of formulas for the remaining cells that allow you to achieve a result, whether it be positive or negative:

  • Hours Savings: =(D2*B2*E2)-(D2*B2*F2)
  • TimeFrame Savings: =H2 * G2
  • License Cost (please contact your Microsoft Partner for the best price[2])
  • ROI: =i2-j2
Please note that we average the ROI when there are more than one tasks listed.

This simple ROI calculation can, of course, be modified to suit the special circumstances of your organization, and different formulas may be used to reflect the special circumstances surrounding the various tasks.

!  Pitfall ! Depending on the size of your deployment, license costs may not be the only cost to consider. In the Deployment Strategy section of this blog, we walk through the steps of discovering and then quantifying the potential costs of customization and configuration of Microsoft Dynamics 365.  This may or may not apply to your deployment. If it does, then adjust the formula above by adding those costs (and potentially amortizing them across time) accordingly.

[1] In this case, the presumption is that email tracking is enabled per Contact / Organization / Opportunity / Lead, etc of your Microsoft Dynamics 365 deployment.

[2] Your Partner will know which license is appropriate for the users in question.  Depending on which entities the user is using, pricing can vary widely!  Contact us with questions.  As always, we are happy to help.

Understanding Customer Relationship Management

Understanding the Benefits of CRM

What is Customer Relationship Management?

The concept of Customer Relationship Management became a “thing” relatively recently, when you consider the fact that buying and selling and therefore “Customers” has been with us humans for about 150,000 years[i].

Thus, it was at the far end of our commercial history, when, in the 1970’s the idea of obtaining feedback directly from customers began the earliest glimmers of “Relationship Management.”  It was, however, the development of the database used widely in business that allowed the idea of tracking and managing the relationship with the customer as an ongoing process to help sell and upsell to them to truly take flight. The first widely used system for small business was developed in the mid-eighties[ii] and featured the basic concepts that remain foundational for any Customer Relationship Management system:

  • Tracking Information around people and organizations
  • Tracking activity history between the CRM user and people and organizations
  • Tracking opportunities for the CRM user
Because modern CRM systems are used by almost ANY type of organization to track almost ANY type of information, you will notice throughout this blog that we avoid the assumption that you will be using your instance of Dynamics 365 to track only Leads and Opportunities for selling. In fact, Microsoft Dynamics is used by thousands of organizations that don’t sell anything directly, but need to track very specialized sets of data.

Since this was over 30 years ago, you may suspect that these basic features must have evolved and widely expanded.  You would be right about that.  In fact, the concept of Customer Relationship Management was originally applied to organizations that sell goods and services to people and other organizations, but CRM systems have evolved to the point at which almost EVERY organization of almost EVERY type can benefit from tracking a wide variety of information about those that they interact with.

How Does my Organization Benefit from CRM?

One of the most important things to understand is that in recent years it has emerged that “data” – that is, information ABOUT people and organizations, has intrinsic value.  When we discuss the benefits of Customer Relationship Management, it’s important to understand that there are two major classifications of benefits:

  • Operational Benefits
  • Executive Benefits

As you will see later in the document when you consider the tactical strategies of deployment, it’s sometimes tricky to balance these two sets of benefits to ensure a successful deployment.  For now, however, definitions are in order.

Operational Benefits

Modern Customer Relationship Management systems are designed in a way to improve operational efficiency. That is, whatever business process is in place, or whatever business process needs to be designed, or re-designed, a good Customer Relationship Management system will support, and perhaps even help enforce an efficient operational process. If the process, whether it be sales, service, marketing, or another completely different type of process is supported by a well-designed CRM, you can expect to realize the following benefits:

  • Universal Access to Useful Information. With a centrally-managed, relational database that is presented properly, and accessible from anywhere, staff from throughout the organization can be apprised of historical and current information about the people and organizations they are dealing with.
  • Automation of Process. Repetitive and mundane tasks can often weigh an organization down. A fully-featured Customer Relationship Management system like Microsoft Dynamics 365 supports the ability to automate steps during any process, so that when data changes in one area of the process, data is created, changed, or transformed in another area of the process.  The simplest example of this is an automatic task/reminder to follow-up with a person or organization is created under a certain set of conditions.
  • Enforcement and Support of Process. Efficiency is often achieved through a disciplined approach. This is true for sales, but also service – for instance, what is done by staff when a service request or trouble ticket is received?  Or what are the steps to onboard a new customer? If those steps are accessible by everyone in the system that is designed to track their activities in the first place, then operational efficiency is achieved when the steps are supported by the software system.  The most obvious example of this is the chevron-based business process flows that ship with Microsoft Dynamics 365 by default for the Lead and Case entities.
  • Structured Communication. One of the most time-consuming tasks that burden the modern worker, whether it be sales or service, is communication. This is especially true if the same email needs to be sent under the same conditions, time after time. A good CRM will automate these communications and give back those minutes and hours back to the staff member.


Executive Benefits

While it is true that operational benefits will “roll up” to the Executive level, we present here some benefits that directly impact the Executive branch of the organization with the use of a well-designed and implemented CRM.

  • Improved Reporting. One of the great benefits of a CRM is the ability for the Executive staff to immediately gain answers to questions about their business, without having to ask anyone. For instance, one of the traditional tasks of the Sales Manager in many organizations is to prepare a weekly, monthly, or quarterly “sales report,” for those that they manage. This is presented to the Executive staff. With a CRM that is used properly by all staff, and with well-designed dashboards and reports, the answers can be had immediately and without taking time away from the sales management team. This, of course, is true for any type of organization, sales-driven or otherwise.
  • Forecasting. With good data comes good forecasting. This is especially true now, with the advent of Machine Learning algorithms, a number of which are represented as add-on applications that can be installed on top of your instance of Microsoft Dynamics 365.
  • Staff Visibility. For the Executive staff, it’s important to understand the activities of the employees across the organization. If staff are widely using a centralized system to track activity, this visibility is instantaneous and ongoing.
  • Holistic View. With a well-designed system of dashboards that answer specific questions under specific criteria, an Executive benefit is the holistic view of the entire operation, or output, of the organization.
  • Data. It could be argued that with recent developments in Europe (GDPR), that this benefit may be slightly rolled backward, but the fact remains and is likely to remain that information about people and organizations, and their historical behavior and other criteria is intrinsically valuable. So much so that fortunes have been made by mergers and acquisitions based on little else but the value of the database held by the target of the acquisition[i]. Thus, it should not be discounted that the aggressive use of a well-designed Customer Relationship Management system could potentially increase the value of the organization.

[i] HuffPost (2017), Capitalizing on Data-Driven Acquisitions in 2017,

[i] Watson, Peter (2005). Ideas: A History of Thought and Invention from Fire to Freud. New York: HarperCollins Publishers. ISBN 978-0-06-621064-3

[ii] Wikipedia, ACT! Software History


Microsoft Dynamics 365 Glossary

[et_pb_section bb_built=”1″][et_pb_row _builder_version=”3.18″ custom_css_main_element=”.et_pb_post a img {|| height: auto;|| float: left;|| width: 600px;|| left: 0;|| margin-right: 14px;|| margin-bottom: 10px;||}”][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.18″]

The Microsoft Dynamics 365 Basic Glossary

As a way to bridge the gap between the business and technical side of things, we offer this glossary of terms for the organizations that will be working to deploy Microsoft Dynamics 365. It’s important to have a common set of understood terms when working with an in-house technical team, or a Microsoft Dynamics 365 consultant to deploy your custom solution.

Why?  Because confusion can arise when one person’s “entity” is another’s “table” in a database – as one simple example. If you have any suggestions of important terms we missed that would be useful in this context, please feel free to add to the comments section of this post!

  • Module – a module in this system is a grouping of functionality and is visually expressed as a tile in the navigation. For instance, the “Sales” module consists of a number of “entities,” that support Sales functionality, such as the Lead, Opportunity, Quote and Order entities.
  • Entity – an entity in this system is a type of data and can also be thought of as a table in the database, for the more technical. Examples of entities are Lead, Contact, Account, Opportunity, Case – and many others.  Generally, entities are provided with a tile in the navigation, and clicking on the tile provides a default “view” of records.
  • View – a view is a list of records, with columns, of a certain type (an entity). Each entity in the system has a default view, but there can be many views, including personal, custom views. Since views are lists of data the definition of the view is the filtering criteria. Example of views:
    • “My Contacts” – all of the contacts in the system that are active and owned by the current user
    • “Active Leads” – all leads in the system that where Status = Active
    • “Inactive Accounts” – all accounts in the system where Status = Inactive
  • Record – a record is a single instance of an entity. For example, if you have a person in your database named Phil Collins, the “record” of Phil Collins would be found by clicking on Contacts, and then selecting the row in the view with the name Phil Collins.  All of the information in the all of the fields on the Phil Collins record make up that record.
  • Field – a field is a single piece of information about an entity. Fields have “types”, such a “text”, “whole number”, and “date” to name just a few. A typical field is “First Name” for a person. It’s important to understand types of fields, since data integrity and reporting rely heavily on correct types of fields.
  • Form – a form is the screen of a single entity record. When you click on the name of a record, or anywhere in the light blue row of a record in a view, the screen changes to show the form of the record, which contains all of the fields on the form. It should be understood that fields can exist in the database and can be searched on, but not appear on a form.
  • Advanced Find – the ad-hoc query system in Microsoft Dynamics 365 is known as “Advanced Find” and allows the user to find data based on criteria directly on an entity as well as related to an entity. The results of the query can be saved as a view and can also be easily exported to Excel. It’s also possible to add columns from related entities to the output of the view, providing the relationship to the entity is “N:1”
  • Report – there are several reporting options in Microsoft Dynamics 365 – there is the Report Wizard, which allows users to create summarizing and grouping reports, there is an API which allows SQL Service Reporting Services reports to be created using FetchXML, and there are Power BI reports and dashboards that can be created. In addition, it’s possible to use modern versions of Excel which support Power Query and Power Pivot, along with “OData” authentication to visualize data from Microsoft Dynamics 365.
  • Workflow – in Microsoft Dynamics 365, there is a Process feature which allows for the use of a “workflow” engine to automate processes in the system, generally based on changing data. Workflows are used in this way to create automatic notifications based on created or changing data, as well as the updating and creation of entity records to streamline operations.
  • Business Process – with the Process feature, there is also the ability to create visual, chevron-based “Business Process Flows” at the top of entities. The default state of the application provides one at the top of the Lead and Case entities. These business process flows can be created and edited freely to support specific data-driven business processes.
  • Activities – in Microsoft Dynamics 365, activities refer to a specific type of entity which generally features a start date/time, end date/time, and which appear in special Activity Menus throughout the system. The most common Activity type entities are Task, Phone Call, Appointment, Email, and Service Activity, although there are more, and it’s also possible to create completely custom Activity type entities.
  • Specific Entity Definitions – there are a few entities that are key to the system, but which have names that may not work across all industries. The good news is that you can change the name of almost all entities if you need to, as well as specific messages in the system that refer to them. Here are the most common entities as they are named by default:
    • Contact – used to track a Person.
    • Account – used to track an Organization.
    • Lead – used to track a potential Customer (Contact or Account)
    • Opportunity – a time-based (when?), revenue based (how much?) representation of potential business with a Customer.
    • Case – a service request, ticket for a Customer.
    • Quote, Order, Invoice – three separate entities that represent the stages in the sales process, and which contain revenue numbers.
    • Product/Price List Item – an item or service for sale, with a price.