Wed, 04/29/2020 - 10:25 By Stéphan Drouard Contributor Lloyd Sebag
Virtual Entities


What is a Virtual Entity?

A Virtual entity is a custom entity in dynamics 365 Customer Engagement that have fields containing data from an external datasource. For the user, the virtual entity is displayed in your app like a regular entity but contains data that is sources from an external database.

In the past, you would have need to create a connector to move data or develop a custom plugin, client or server side. But you would have replicated the data to use them. Now thanks to the virtual entities, you can connect directly to an external datasource at runtime. So you will have data available in an environment without the need of data replication. The data will so always be up to date.


Virtual entities are made up of three main components, a data provider, a data source record, and a virtual entity. The data provider consists of plug-ins and a data source entity. The data source is an entity record in Dynamics 365, which includes metadata that represents the schema of the connection parameters. Each virtual entity references a data source in the entity definition.

Dynamics 365 includes an OData Data Provider that you can use to connect with an OData v4 web service that accesses the external data.

Alternatively, developers can build their own data providers. Data providers are installed in an environment as a solution.




  • Developers can implement plugins to read external data using the Dynamics 365 Customer Engagement Web Services and Customer Engagement Plug-in Registration tool.
  • System customizers use Dynamics 365 to configure the data source record and create virtual entities that are used to access external data without writing any code.
  • End users work with the records created by the virtual entity to view the data in fields, grids, search results, and Fetch XML-based reports and dashboards.


Create a Virtual Entities

OData v4 Data Provider

The service

We’re going to create a virtual entity from an OData V4 service. 

Let’s have a look at the service: 


You can see all collection available in the service. In our case, we are going to create a virtual entity with Advertisement. 

You can have a more details view of the entity by browsing$metadata


One important thing is that the entity must have a unique identifier with the type as Edm.Guid.

The creation

First, we’re going to the create the “connection” to the webservice. Go to Settings -> Administration. 


Select Virtual Entity Data Sources -> New



Name: Name of your datasource

URL: Url of the service definition. It should look like 

Timeout: Enter the number of seconds to wait for a response from the web service before a data request time-out

Pagination mode: Select whether to use client-side or server-side paging to control how query results are paged. The default value is client-side paging. With server-side paging, the server controls how results are paged by using the $skiptoken parameter, which is added to the query string. –lequel est le plus performant

Return inline count: Returns the total number records in the result set. This setting is used to enable next page functionality when you return data to a grid. Use a value of false if your OData endpoint doesn't support the OData $inclinecount parameter. The default value is false.


Save and close. Congratulation! Your datasource is ready.

Now we’re going to create the virtual entity linked to this datasource.

Go to Settings -> Customizations -> Customize the System.

Create a new entity


On the top right of the form, check the checkbox “Virtual Entity” and select the Data Source as the one just created. Two new important fields will appear:

  • External Name
  • External Collection Name

These two fields must contain the name of the entity you want to display. It must have the same name than the one displayed in the service metadata.


Click on Save. Once the entity, we will have to map the fields to the external datasource.

The system automatically creates two fields, one for the id and one for the name.


Open the new_advertisementid field in order to fill in the “External Name” field. 


It must be filled with the property name of the service. Beware, it is case sensitive.


Let’s do the same with the name field.


You also can add the other fields of the entity definition. In our case, there is a DateTime field named AirDate. Create a new field and fill the form like below:


The Field Requirement MUST be as “Business Required”!

Save and close then publish customization.

Our virtual entity is now created. You should be able to do an advanced search on it.


You can go back to the entity customization to create a new view and form with the new created fields.



Virtual entities have these restrictions.

  • All virtual entitites are read-only.
  • Existing entities cannot be converted to virtual entities.
  • By default, virtual entities contain only a Name and Id field. No other system managed fields, such as Status or Created On/Modified On are supported.
  • Virtual entities don't support custom fields with the Currency, Image, or Customer data types.
  • Virtual entities don't support auditing.
  • Virtual entity fields can't be used in rollups or calculated fields.
  • A virtual entity can't be an activity type of entity.
  • Many features that affect entity table rows cannot be enabled with virtual entities. Examples include queues, knowledge management, SLAs, duplicate detection, change tracking, mobile offline capability, field security, Relevance Search and N:N relationships between virtual entities.
  • Virtual entities are organization owned and don't support the row-level Common Data Service for Apps security concepts. We recommend that you implement your own security model for the external data source.
  • We recommend that you target a single data source when you use virtual entities in Advanced Finds. For example, creating an Advanced Find that ultimately creates a join between the Common Data Service native data and the virtual entity external data isn't supported.
  • Field metadata properties that validate on update don’t apply to virtual entities. For example, a Whole Number field on a virtual entity field may be set to have a minimum value of zero. However, since the value is coming from an external data source, a query will return values less than zero when retrieved from a virtual entity. The minimum value property is not implied in the query. You would still need to filter the values to be greater than 0 if that’s what is desired.
  • Virtual entities don't support change tracking and cannot be synchronized by using a Customer Engagement feature, such as the Data Export Service.






Add new comment

Enter the characters shown in the image.