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.



Taking Blockchain Seriously

[et_pb_section bb_built=”1″ _builder_version=”3.10.2″][et_pb_row _builder_version=”3.10.2″ background_size=”contain”][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.10.2″]

One of the benefits of the crypto currency market decline in prices over the last few months is that we are less burdened and distracted by the kind of manic pronouncements one both sides of the table. You don’t hear quite as as much of the likes of high-profile nonagenarians proclaiming that bitcoin is like trading “freshly harvested baby brains!” Nor do you hear as many prognostications from swooning European bank analysts like “$100K per bitcoin by December 2018!!”

Bitcoin’s stall aside, the ICO phenomenon appears to be steaming ahead, with, as reported by Business Insider, more than $13 Billion raised in the first five months alone, which has essentially dwarfed all of 2017 – itself a banner year. So it appears that interest in the space has by no means waned. It has changed, however, with more massive deals (Telegram at $1.7 Billion, EOS at $4 Billion), and with less investment going to smaller projects, and (we can only hope), far less money going to outright scams, since ICO investors seem a bit more skeptical this year than last. And we do see slow and steady work on the Compliance front, with SEC actions against true criminals, and with the FINMA token classifications earlier this year, and other decisions leading toward what might be a somewhat brighter (and clearer?) future.

Earlier this year, a headline-grabbing report suggested that 80% of ICO’s in 2017 were “scams.” That headline is a bit of an oversimplification of the report itself, and the good news of that report was that 70% of the money raised in 2017 didn’t go to those questionable projects. Still, it’s disturbing that as much as $3 Billion could have been essentially stolen from naive investors. Then there’s the news that nearly all of the “ICO rating” sites are biased – perhaps something most of us instinctively knew – and one begins to wonder whether there could be a sector that is more rife with fraud and foolishness.

So between the Baby Brainers, the Mooners, and the Scammers, I’m sorry to say that I’m faintly embarrassed by all of this, because to someone who has not looked very carefully at the underlying technology – and those of us who count ourselves as passionate about this should remember that  this is STILL the vast majority of serious people on this planet – the steady stream of information around this entire vertical space seems like a freak show.  It’s just hard for common folk to take it seriously. And especially hard to take seriously by those that don’t really understand how blockchain works, and therefore can’t appreciate the potential. I understand where they are coming from … the technical aspects can be a little daunting, and we don’t have a LOT of voices out there standing between technology and business, attempting to translate concepts.

When I speak with non-blockchain people now, in September of 2018, about the technology, the ICO market, and various projects, I get a sense that from their perspective, the decline in price and media circus show has somehow invalidated the sector altogether. Many of them have moved on. Yes, we can say “…their loss …” but it’s nevertheless not a great thing.

So what is to be done? I believe that the best way for us to rectify this willful ignorance displayed by the many is for each of us –  those of us inside the sector — to make some small change in our approach. A small step to a more sober analysis, perhaps. I personally believe in tools. So for my part, I spent a decent part of this year taking a break from the podcast ICO 41 to create some software to to help me make better sense of the chaos that is the current state of affairs in blockchain and crypto currency. The software is called KryptoTrak, and it provides support for serious analysis of blockchain projects. With tools like this, where findings and conclusions can be converted into useful and quantifiable data points, we can form and document our own careful analyses, and keep track of our own conclusions, rather than relying on questionable third-parties. And my other small thing will be through the podcast. In my return to ICO 41, I intend to take a much more skeptical view to projects, and also to be a bit more discerning. In fact, I’ve decided to not cover an ICO until the project is actually underway and in development. No more coverage of “upcoming ICO’s” because I frankly don’t wish to be part of the marketing hype, and in the year of analysis I have done, it appears that many teams behave quite differently before they raise the millions than they do afterward. I’ve decided that I would rather speak to someone who is building now, than someone who is hoping to raise money to build something in the future. These are my small contributions to the concept of taking it all a little bit more seriously.

There are some great resources out there. A podcast that started in July of this year named Bitgenstein’s Table is an example. As we meet people who are not well-versed in the space, it’s our job to teach them the fundamentals and help prevent them from being distracted by the manic silliness that is endemic to blockchain and crypto currencies.  Maybe we should all keep such a “Blockchain Beginner’s Toolkit” that can be handed out easily and at will. This could take the shape of a sticky blog post or a page on a website, and it could feature a curated list of resources. (I may start on that today, now that I think of it … )

One of the toughest things to do is raise kids. Especially when they become teenagers. You SO WANT them to succeed, to be better than you were when you were a kind, and so you do every little thing you can, hoping that your small actions can have some overall affect over their evolution through life. It’s kind of the way I feel about blockchain.

What small or large thing will you do to help blockchain and crypto grow up?


The Bilingual Dilemma

[et_pb_section bb_built=”1″ _builder_version=”3.10.2″][et_pb_row][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.10.2″ text_font_size=”18px”]

We are, all of us, products of our environment. But as we develop, leave our familiar surroundings and go out into the world, we have an opportunity to learn new languages. And I don’t just mean the language of speech – I mean vernacular. There are many languages, even more dialects, but there are also cultural and meme-based languages as well. Take, for instance, “Tech Speak.”

There was a recent interview with some of the longtime residents of Venice Beach, CA about their reaction to Snap (the company that makes SnapChat) deciding to park their young millennial selves and company on the beach in Venice. The biggest complaint was that the kids, with security badges around their necks and fancy-looking spectacles coming in and out of the Snap building and sometimes stopping at the food stands and bars in the neighborhood has little time to talk to anyone who didn’t want to talk about technology.
Kids can be forgiven these kinds of self-centered attitudes, but what about grown adults involved in complicated technology projects? Based on what I’ve seen, the problem is the same. Both sides have a point. On the business side, they believe that it’s hardly worth their time to dive into database theory, and the tech folks building that database feel a little bit busy to be reading up on EBITA, thank you very much.

I get it. I will say, however, that no matter what you do for a living, your life will be only enriched by broadening the things you understand and can talk about. Also, projects go much, much smoother when everyone can speak a little bit of the other language in the room. This is not a rant on my part, by the way — far from it, since after all, I have made an excellent living for the past twenty years and probably will for another twenty merely by choosing a couple of languages that I didn’t come across in middle school.
If you are having the kind of project meltdown that happens when business can’t talk to tech and visa-versa, let me know. I can probably help. Better .. if you are contemplating a technology project, and you want it to go well – contact me – I’m quite sure I can help get your project on the right track.