Virtual Entities and Dynamics 365 Portals – Part 1

One of the great new features available in Dynamics 365 v9 is Virtual Entities, which allow you to represent data from external system as entities without copying or synchronizing data, and often times without any custom code. In this series of posts, I’ll dive into this new feature, with a focus on what it means for Dynamics 365 Portals, and how we can leverage them to create no-code integrations between your Dynamics 365 Portal and other systems.

What Are Virtual Entities?

Virtual Entities allow you to represent data from external systems natively in Dynamics 365 without the data actually residing in the database. There are three main components to setting up a Virtual Entity: the data provider, the data source, and the Virtual Entity definition.

The data provider is the code that performs the queries against a specific data source. As part of the first version of Virtual Entities, Microsoft includes an OData v4 data provider. This means that if your data source has an OData v4 endpoint, you can use it with Virtual Entities without writing a line of code! You also have the option to build your own custom data provider if you data source does not have an OData v4 endpoint, however I’ve heard mixed results from people who’ve tried this. It may be a while before all the kinks associated with a custom data provider are worked out.

The data source is used to point your Dynamics 365 instance to where the data is actually located. When configuring a data source, you select a data provider, and enter the configuration data needed to access that data source, such as the URL of the OData feed.

Finally, the Virtual Entity definition allows you to create the entity in Dynamics 365 in almost the exact same way you’d create a normal (i.e. non-virtual) entity. Within your solution, simply create a new entity and check the Virtual Entity checkbox. You’ll then be able to select your data provider and the corresponding entity/table within the external data source that map to the Virtual Entity.

There are a number of great articles already available that step you through the process of setting up a Virtual Entity – instead of repeating those steps I’ll provide the links below for your reference.

What Are The Limitations?

The following limitations of Virtual Entities have been well documented:

  • Data is read-only. This means you can’t use any editable Entity Forms or Web Forms and expect them to update external data.
  • The virtual entity is organization-owned, so no out-of-the-box permissions on a per-user basis (although I did read this interesting article on using a plugin on the RetriveMultiple message to perform security trimming).
  • The primary key for the entity in the external data source must be a GUID.
  • You can only map over fields whose types match a type in Dynamics 365 (such as text, numbers, option sets, dates, and lookups).

However, there is one other limitation I ran into when playing with these, and it has an impact on what we can do with portals: the inability to perform joins across Virtual Entities within a single query (in FetchXML language, if you’re fetching a non-virtual entity, you can’t use a virtual entity in a link-entity node, and if you’re fetching a virtual entity, you can’t include a link-entity at all). Now this limitation makes sense; it is not really feasible to perform joins across data that resides in different locations – it’s a complex thing to do, and performance could be a nightmare. However, it’s something you need to keep in mind if you intend on using Virtual Entities.

It seems like Microsoft has prevented users from creating these bad queries in some places, but there are still a few gaps. For example, if you create a N:1 relationship between Contact and a Virtual Entity, you’ll get a lookup to the Virtual Entity on the Contact record. When editing views for the Contact entity, you can add the Virtual Entity lookup field as a column; this will work fine. This is because underneath the hood, the FetchXML query simply returns the GUID of the related record; the UI is responsible to actually determining the name to display, which it does by making a single query to the OData source for all of the names that appear on that particular page. But, if you instead choose the Virtual Entity from the Record Type drop down when adding a column, and add the Name column (or any other column, for that matter), you’ll be able to successfully save the View, but you’ll get an error when you try to open that View and see the records.

One other thing to note: your OData v4 service may be case sensitive. This means that any searches will also be case sensitive, including Quick Finds. This may be counter-intuitive for users since generally Quick Finds in Dynamics 365 are not case sensitive.

In my next post, I’ll get into a bit more detail on what is, and isn’t, possible when it comes to creating relationships involving virtual entities.

3 responses to “Virtual Entities and Dynamics 365 Portals – Part 1”

  1. […] post Virtual Entities and Dynamics 365 Portals – Part 1 appeared first on Engineered […]

  2. […] my first post in this series I discussed how virtual entities and the link-entity node in FetchXML don’t mix well. In this […]

  3. […] my first post in this series I discussed how virtual entities and the link-entity node in FetchXML don’t mix well. In this […]

Leave a Reply

Your email address will not be published. Required fields are marked *


Engineered Code is a web application development firm and Microsoft Partner specializing in web portals backed by Dynamics 365. Led by a professional engineer, our team of technology experts are based in Regina, Saskatchewan, Canada.