Engineered Code is proud to announce the availability of ecLearn - the Learning Management System built on top of Microsoft Dataverse


Virtual Entities and Dynamics 365 Portals – Part 3 – Finally, the Part About Portals

So far in this series, I’ve provided an intro on virtual entities and a deeper dive into virtual entities and relationships. In this post, I’m finally going to talk about how they work with Microsoft Dynamics 365 Portals.

What Works

Once you’ve got the Virtual Entity entity created, the great news is that, for the most part, Dynamics 365 Portals support them (keeping in mind that any create or edit operations are NOT supported – Virtual Entities are, at least for now, read-only). We’ve verified the following the following functionality:

  • Liquid, including FetchXML
  • Entity Lists, including:
    • Search
    • Metadata Filters
    • Map View
    • Calendar View
    • OData Feed
  • Entity Forms
    • Standard Fields
    • Subgrids (including 1:N and N:N)
    • Notes (including making them editable)
    • Geolocation

    The “Add Attach File” functionality can’t be used with Virtual Entities. It doesn’t show up when the Mode is set to Read Only (which is the only mode you should be using with Virtual Entities). If you need to attach files, you can still use the Notes functionality, which does still work in Read Only mode.

  • Entity Permissions

    Entity Permissions are respected, however the inability to performs link-entity queries with virtual entities means more complex scenarios that would be supported with non-virtual entities won’t work with virtual entities. You’ll probably have to stick with either a Global Entity Permission to expose all records, or if you go through the effort to create a N:1 relationship with Contact or Account, you can create Entity Permissions scoped to those records. You probably won’t have much luck with more complex Parent/Child Entity Permissions.

    You’ll also need to setup Entity Permissions properly if you want to add Notes to a Virtual Entity.

What Doesn’t

I really only found one thing related to virtual entities that I believe can be resolved with a change to the Portals source code, and it has to do with the Entity Source Type on an Entity Form.

If you create an Entity Form for a virtual entity, and set the Entity Source Type to Record Associated to Current Portal User, you will get a Generic SQL error. By having a look at the source code that was released for the Portals, I believe the issue is that the code performs a query on the Contact record, and attempts to link the virtual entity as part of that query. As discussed in the first post in this series, that is not possible.

I don’t think it would be difficult to refactor that code to avoid this error; hopefully that’s something that could be addressed in the next release.


One thing that you will need to pay attention to is caching. Dynamics 365 itself doesn’t cache virtual entities – each time you ask to see virtual entities, it performs a query against the data source. However, Portals heavily relies on caching between the web server hosting the site and Dynamics 365, and leverages Change Tracking and Azure Event Hub to notify the Portal that data has been changed. You can’t enable change tracking for virtual entities, so the portal won’t know when data has been updated. Therefore, you’ll need to rely on the cache going stale, which can take days, or a manual cache clearing by an administrator. So if you data is super time sensitive, this might be a deal breaker.

Potential Uses

I think there are a lot of interesting ways that an organization could use virtual entities with portals.

The first one that immediately comes to mind is displaying invoices on the portal. If your accounting system has an OData v4 endpoint, you may be able to show invoicing details directly from your accounting system without writing a single line of code. If you can find a way to link Contact or Accounts with the corresponding records in your accounting system, then the rest should be straight-forward.

Another great example would be if you have a customer support portal, and your product list is stored in a different system. Virtual entities would allow you to show your up-to-date product list to users so they can indicate what they need help with, without needing to synchronize that data in Dynamics 365.

I’d love to hear how other people are using virtual entities with Dynamics 365 Portals – please share you experiences in the comments below!

Portals Functionality Wrap Up

Overall, I was impressed by how much Portals functionality worked with virtual entities. I don’t think much, if any, effort was put into adding support for virtual entities in Portals (at least, I didn’t see anything in the release notes) – really it’s a testament to how well virtual entities act like real entities in general. I think that the caching issue may be a deal breaker for some situations, as well as the limitations around permissions, but virtual entities are an excellent tool that you can use to provide business value without the need for a significant investment in custom code.

In the last part of this series, I’ll describe how I had set up a simple in-memory OData service that made it very easy to test the virtual entity capabilities of Dynamics 365.

One response to “Virtual Entities and Dynamics 365 Portals – Part 3 – Finally, the Part About Portals”

  1. Florian Krönert says:

    Hi Nicholas,

    Thanks for this post.
    We were using Virtual Entities in our Portals as well, by accessing them via OData Feed.

    All worked well, but since last week all of our virtual entities fail with HTTP 500 when trying to access them via OData feed.
    Does this happen to you as well?

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 & Power Platform. Led by a professional engineer, our team of technology experts are based in Regina, Saskatchewan, Canada.