How Virtual Entities Work

Dynamics 365 has the ability to display what are known as virtual entities within the interface. These entities allow for heavily simplified integrations with external systems, and sometimes even new abilities to query data within D365 as well.

What is a Virtual Entity?

Let's start with looking at what a virtual entity is in D365. For the most part, when looking at data within D365, the data is stored within your database and displayed to the end user when requested.

A virtual entity functions very differently, where the data is not necessarily stored in your D365 database and instead can be stored outside, but still look and feel as if it was stored within your D365 database. You can almost think of it as a portal that you can look through and view data in external systems without needing to actually store the data in your database.

Here is a side by side comparison of a record that is in your CRM database vs. one that is virtual. Try to spot the difference.

Standard Entity

Virtual Entity

If you were having trouble finding the difference, that's because there are no differences between the two images. This does not mean there are no differences, but you can see from the portion of the form in the images, they are exactly the same.

The huge difference that is not apparent from the screenshot, is that the standard entity is referencing data in the D365 database, while the virtual entity is pulling data from an external system, and your end users are not immediately aware of the difference. So now that we know what they and that they look and feel very similar, how do they work?

How is Data Retrieved from External Systems?

When needed (a user loads a view or opens the form for a record) D365 will make a call to your external system to pull only the data necessary and display it as if it existed in your D365 database. Let us examine a request using our Mailchimp integration with D365. When a user clicks on the list of Campaigns, the following events occur:

1. D365 recognizes the view being requested in a Virtual Entity. A request is made to the Cached Entity connector to retrieve the data.

2. The Cached Entity connector sends a secure message to the Cached Entity platform requesting the Mailchimp campaigns.

3. The Cached Entity platform authenticates the request and the user that made it, then proceeds to connect to the Mailchimp API to retrieve the appropriate data.

4. The Cached Entity platform then returns the data back to the Cached Entity connector.

5. The Cached Entity connector returns the properly formatted data back to D365 which displays the data to the end user.

This happens for each call that is made from within D365 for every list, view, lookup field and anywhere that a virtual entity is presented to a user. The data is never stored within your D365 database.

Why are Virtual Entities Better?

There are several pros for using virtual entities over standard entities when accessing data from external systems. Here are just a few highlights:

Data is Available Real-Time

Have you worked with integrations that synchronize once per day? Or perhaps there was an error in the synchronization the night before and the data you are looking at is now 2 days old. Or perhaps nobody is monitoring for integration failures and the data is 2 weeks old. Not with virtual entities. The data is retrieved from the source with each request. This means you are no longer looking at stale data in the system.

Mappings Easily Changed

With any integration, there is a long process of going through and mapping fields before any data can begin flowing. This is intentional to make sure all of the data is mapped correctly as it is difficult to make changes. Suppose you synchronize a million contacts from Mailchimp into D365, but you forget to pull the birthday field from Mailchimp. Well, in order to fix that mistake you must update all contacts again in D365, which is a very tedious and costly process. With virtual entities, you can update the mapping, and the data is immediately available as soon as the mappings are updated. This means you can even test some mappings, evaluate their usage, and then determine what to keep / remove.

Quicker Implementation Times

If you are not spending time migrating data, determining mappings (since they can be easily changed) your implementation times are drastically shorter. With our Mailchimp integration for example, you can turn it on and be running in minutes. That means all of your data is available in D365 within minutes, not waiting days / weeks for all the data to synchronize.

Validate Business Need

While there are still some use cases that warrant storing data in D365, using Virtual Entities allow you to test the water a little before making a large commitment. For example, if your sales team is telling you they need access to every email sent from Mailchimp in their D365 database, start with virtual entities. It is much faster to setup, and allows you to monitor usage before making the commitment of time and money to provide a feature that perhaps nobody will use. Our system allows you to monitor who is using the system, how often, and then make a decision on whether to invest in a synchronization for specific use cases. Or perhaps you quickly determine it is not useful and you save the time and money to focus on areas that will help your business grow.

Storage Costs

D365 storage is not cheap. With integrations like Mailchimp and other marketing platforms, synchronizing all of those emails as activities against your contacts and leads will quickly eat up your available storage and start costing you more money. With Virtual Entities, the data is never stored in your D365 database, so you do not incur any storage costs for it.

Are there Limitations?

Like with anything in IT, there are always pros and cons for going in a specific direction. Let's look at some of the cons when going with Virtual Entities.

Read Only Data

For the most part, the data is read-only within D365. This means you can see the information in D365, but you will not see New buttons to create new records or Save buttons to make updates. This is true of the Virtual Entity functionality but Cached Entity provides other alternatives to make updates where appropriate. For example, we can synchronize account, contact and lead updates directly to Mailchimp even though we use Virtual Entities to display the data.

Performance

Performance of Virtual Entities may sometimes display slightly slower than a typical entity. There are multiple factors that come into play here, but there is the possibility of it being slower. However, there is also the possibility of it being faster as well. For example, Mailchimp is specifically designed to handle large volumes of emails, and can quickly show recent information for a lead record via their API where D365 may take a while to return results for those queries.

Dashboards

As we are writing this article, Microsoft has some limitations on querying data using Virtual Entities and presenting data or charts on dashboards as well. There are no workarounds for this available just yet, but relying on reports from the source systems generally provide the reporting functionality that is necessary for most organizations.

If you are looking to implement Virtual Entities within your organization to connect to external sources and need some assistance in doing so, please let us know. Our team of software developers and analysts will be happy to assist in getting your teams up to speed on being successful implementing virtual entities.