[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. 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.
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.
Figure 2 – The Service Module by default in 2018 Marketing. The marketing module contains entities that are designed to support marketing operations. Below is a screen shot of what the module looks like when the Marketing tile is clicked.
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.
|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
 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.  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.  It’s useful to note that in many deployments of Microsoft Dynamics 365, entities are often re-named and/or re-purposed.