Entities and metadata in Common Data Service
Common Data Service is designed so that you can quickly and easily create a data model for your application. Normally, you shouldn't have to concern yourself with some of the details about metadata that this topic will introduce. But if you want to develop a deeper understanding about how apps that use Common Data Service work or you are evaluating what is possible, understanding the metadata used by Common Data Service may provide you insight.
Metadata means data about data. Common Data Service provides a flexible platform for you because it is relatively easy to edit the definitions of the data that the environment will use. In Common Data Service, the metadata is a collection of entities. Entities describe the kinds of data which is stored in the database. Each entity corresponds to a database table and each field (also known as attribute) within an entity represents a column in that table. Entity metadata is what controls the kinds of records you can create and what kind of actions can be performed on them. When you use the customization tools to create or edit entities, fields, and entity relationships, you are editing this metadata.
Different clients people use to interact with the data in your environment depend on the entity metadata and adapt as you customize the metadata. But these clients also depend on other data to control what visual elements to display, any custom logic to apply, and how to apply security. This system data is also stored within entities but the entities themselves are not available for customization.
You can learn about standard entities, attributes, and entity relationships included by default in Common Data Service by reviewing the Entity Reference.
The designers available to edit metadata cannot show all the details found in the metadata. You can install a model-driven app called the Metadata Browser which will allow you to view all the entities and metadata properties that are found in the system. More information: Browse the metadata for your environment.
Create new metadata or use existing metadata?
Common Data Service comes with a number of standard entities that support core business application capabilities. For example, data about your customers or potential customers is intended to be stored using the account or contact entities.
Each of these entities also contain a number of fields that represent common data that the system may need to store for the respective entity.
For most organizations it is to your advantage to use the standard entities and attributes for the purposes they were provided.
If you install a solution you can expect that the solution developer has leveraged the standard entities and attributes. Creating a new custom entity that replaces a system entity or attribute will mean that any solutions available may not work for your organization.
For these reasons, we recommend that you look for and use the provided standard entities, fields, and entity relationships when they make sense for your organization. If they don’t make sense and can’t be edited to match your need, you should evaluate if creating a new entity, field, or entity relationships is required.
Remember that you can change the display name of an entity so that it matches the nomenclature your organization uses. For example, it is very common for people to change the display name of the Account entity to Company or the name of the Contact entity to Individual. This can be done to entities or attributes without changing the behavior of the entity. For more information about renaming entities, see Change the name of an entity.
You can’t delete standard entities, fields, or entity relationships. They are considered part of the system solution and every organization is expected to have them. If you want to hide a standard entity, change the security role privileges for your organization to remove the read privilege for that entity. This will remove the entity from most parts of the application. If there is a system field that you don’t need, remove it from the form and any views that use it. Change the Searchable value in the field and entity relationship definitions so that they do not appear in advanced find.
Limitations on creating metadata items
There is a limit to the number of entities you can create. You can find information about the maximum number in the Settings > Administration > Resources In Use page. If you need more custom entities, contact technical support. This upper limit can be adjusted.
Within each entity there is an upper limit on the number of fields you can create. This limit is based on the technical limitations on the amount of data that can be stored in a row of a database table. It is difficult to provide a specific number because each type of field can use a different amount of space. The upper limit depends on the total space used by all the fields for the entity.
Most people do not create enough custom fields to reach the limit, but if you find yourself planning to add hundreds of custom fields to an entity, you should consider if this is the best design. Do all the fields you plan to add describe properties for a record for that entity? Do you really expect that people using your organization will be able to manage a form that includes such a high number of fields? The number of fields you add to a form increase the amount of data that has to be transferred each time a record is edited and will affect the performance of the system. Take these factors into consideration when you are adding custom fields to an entity.
Option set fields provide a set of options that will be displayed in a drop-down control on a form or in picklist control when using advanced find. Your environment can support thousands of options within an Option set, but you shouldn’t consider this as the upper limit. Usability studies have shown that people have trouble using a system where a drop-down control provides large numbers of options. Use option set field to define categories for data. Don’t use option set fields to select categories that actually represent separate items of data. For example, rather than maintain an option set field that stores each of hundreds of possible manufacturers of a type of equipment, consider creating an entity that stores references to each manufacturer and use a lookup field instead of an option set.