Skip main navigation

New offer! Get 30% off your first 2 months of Unlimited Monthly. Start your subscription for just £29.99 £19.99. New subscribers only. T&Cs apply

Find out more

Other Entity Options

In this module, we will look at additional entity options. Before creating or editing entities and PowerApps, you should understand that there are different types of entities. Once a custom entity is created, these types cannot be changed. The two major divisions are based on the entity ownership and whether the entities are activity entities. There are four different types of entity ownership. When you create a custom entity, the only options are user or team-owned or organisation-owned. But you should be aware that other entities have different ownership types. User or team-ownership will add a field that is named Owner. So the record for the entity can be assigned between user and teams, and have at least user-level read privilege to the entity.
Internally, the owning user or owning team are stored separately. And the business unit they belong to is also stored. So there are actually four lookup fields added that relate to the ownership. This use of ownership also means that you can see at any of the usual five access levels and security roles to control the record that the user can access, depending on where the user and the record are in the business unit hierarchy. Most entities that relate to business data are likely to use this level of ownership. Organisation ownership means that entity does not have an owner field or the other related look up fields, and cannot be assigned to a user or team.
Security roles control where the users have access to all records or no records. There is no separation by business unit. Entities that do not have many fields are used as lookups for categorising. Other records might be more likely to use Organisation-level ownership. These includes article, article template, competitor, currency, and web resources. When a custom entity is first created, it’s available only to users who have either a security role of system administrator or system customizer. Other security roles must be modified to let other users view and use the new entity.
These security roles can be included in the solution, together with the custom entity, so that when a solution is deployed to another system, the roles are ready to be assigned to users. If the role already exists in the targeting system and are being updated, the changes will occur as soon as a solution is imported. Other types of identity ownership– Business-owned– There are several business owned system entities. These include business unit, calendar, team security role, and user. The other one is a none. There are many system entities that don’t have an owner but most of these aren’t visible. These mostly consist of intersect entities, created to support many-to-many relationships, or where access to the record is controlled by a parent record.
For example, the Opportunity Product records must be accessed through a user or team-owned opportunity record. Activity entities– You can create custom entities that work together with the existing activities and CDS, by selecting to create the entity as an activity. This means the entity will appear in the UI and other locations that the activities are viewed by users. And this might make it easier for users to follow and use. All activity share many properties in common, such as planned start date and actual start date, planned end date and actual date, duration, subject, and description.
All activity entities are linked to the ActivityPointer entity that stores these common fields and lets users view lists of all activities together, instead of separate views for each type. There is no definite rule for when you should use an activity entity type. There are some example scenarios that can help guide your decision making. Number one– an entity that represents an activity that occurs on a specific date and time, especially if the activity is planned in advance and must have some additional information to describe what it is and who is responsible for the activity. A project milestone might fit this description and be suitable as an activity entity.
Number two– a record that is created to document when an activity has occurred. The record has a short life span between when it is created and when it is closed. The record of when an article is published or their release of a product or upload of a file to a server might include in this category. You could use an existing activity or an activity feed post record for these activities. However, if you want to report on these activities separately or trigger any automated process, storing these activities as a separate custom activity might be more suitable.
Number three– An entity that might have to be related to different records on different occasions, such as a record that relates to an external social media post might be best created as a custom activity. The regarding field can be used to link the activity to the record that the social media update is related to. And this might be an account product event, for example. Let’s look at some other entity options. There are two custom activity settings defined as an activity entity. If this checkbox is selected, the entity will be used as an activity and can be created in the same manner as letters, email messages, phone calls, and so on.
After the setting is saved, this option is unavailable and cannot be changed. Display an activity menu– If the entity is defined as an activity, this option can be enabled or disabled. In some cases, an Organisation might want activities to be created automatically by workflow processes, instead of manually, or only from a subgrid or parent record they’re related to. Therefore this option can be cleared so that the activity cannot be created from the navigation bar, command bar, or Activities view menu. You need to be aware of the following– When you look at the activity entity record, you will see the use of the dagger symbol, also known as obelisk, next to them.
Because once you set them, they cannot be changed at a later date. Let’s take a look at virtual entities. A virtual entity is a custom entity in CDS that has fields containing data from an external data source. Virtual entities appear you app to users as regular entity records that contain data that is sourced from an external database, such as Azure SQL database. Records based on virtual entities are available to all clients, including custom clients, developed using CDS web API. In the past to integrate the disparate data sources, you would need to create a connector to move data or deploy a custom plugin, either a client or server side.
However, with virtual entities, you can connect directly with the external data source at runtime so that specific data from the external data source is available in an environment without the need for the data replication. 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 common data services, which includes metadata that represents the schema of the connection parameters. Each virtual entity references a data source in the entity definition. Entity– icons You can upload three types of entity icons for each custom entity.
When you create a custom entity, it is automatically assigned a default icon. And all custom entities, by default, use the same icon. If your Organisation has several custom entities, it can be helpful to change the icon associated with one or more custom entities to help users differentiate them. It is best practise to use SVG icons. Please note, as the platform continues to change, some of these entity settings will change.

In the last activity, we looked at all aspects of Relationships. In this activity, we will look at Additional Entity Options.

Before creating or editing entities in PowerApps, you should understand that there are different types of entities.

In this video, Mark Smith takes you through the following:

  • Area that displays this entity

  • Process

  • Communication & Collaboration

  • Data Services

  • Auditing

  • Outlook and Mobile

  • Help

Join the discussion

Before creating or editing entities in PowerApps, you should understand that there are different types of entities. What do you think the use of ownership related to business means on an entity level?
Use the discussion area below to let us know your thoughts.
Try to respond to at least one other post and once you’re happy with your contribution, click the Mark as complete button to check the Step off, then you can move to the next step which is Other Field Details.
This article is from the free online

Dynamics 365: Using Power Platform Applications

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now