# Entity types

> Native and Federated entity types in Data Fabric / Data Service, what each one supports, and how existing entities are classified.

Every entity in Data Fabric / Data Service is either **Native** or **Federated**. The type is chosen when the entity is created, and it determines where the entity's data lives, which sources the entity can draw from, and which operations it supports.

The type of each entity is displayed in the **Type** column of the **Entities** page, and the list can be filtered by it. The type of an entity cannot be changed after the entity is created.

## Native entities

A **Native** entity stores its data in UiPath. It holds only its own fields, and it supports the full set of data operations: create, read, update, and delete, from Studio activities, Apps, Maestro, and the APIs.

A Native entity is the right choice when UiPath is the system of record for the data, such as application state, review queues, or reference data that has no authoritative home in another system.

A Native entity cannot reference an external system. In its **Add object** panel, only **Local fields** is offered.

## Federated entities

A **Federated** entity stores nothing of its own. It is a read-only view whose fields all come from its sources, read each time the entity is queried, so a read returns what the source systems currently hold.

A Federated entity draws its fields from:

* an external system, such as Salesforce, ServiceNow, Snowflake, or a database reached through Database Hub;
* a native Data Fabric / Data Service entity in the same tenant, through the **Native source** option.

A Federated entity is the right choice when the data belongs to one or more systems of record and it needs to be read in an automation or an application without being copied.

A Federated entity cannot hold fields of its own. In its **Add object** panel, **Local fields** is not offered.

For how sources are added and joined, refer to [Creating an entity](creating-an-entity.md).

## What each type supports

| | Native | Federated |
|---|---|---|
| Where the data is stored | In UiPath | Nowhere; read from the sources |
| Its own fields | Yes | No |
| External system as a source | No | Yes |
| Native entity as a source | No | Yes |
| Create, update, and delete records | Yes | No; read-only |
| Search and filter | Yes | Yes |
| Sort | Yes | On fields the source system can order by |
| Role-based record access | Yes | Not applicable |
| Triggers | Yes | No |

## Entities that hold both local and external fields

A single entity can no longer hold both locally stored fields and external fields. The **Add object** panel enforces this: **External source** is not offered on a Native entity, and **Local fields** is not offered on a Federated entity.

To combine data stored in UiPath with data from a system of record, the locally stored data is held in a Native entity, and the Federated entity references it through **Native source**. The Native entity then takes part in the view as one of its sources.

Entities created before entity types were introduced can hold both. They continue to work without disruption, can still be consumed in Apps, automations, Maestro, and the APIs, and their locally stored fields remain editable. Their external fields are read-only, as they have always been.

## How existing entities were classified

Entities created before entity types were introduced were classified automatically, and need no migration:

* an entity with no external fields is Native;
* an entity whose fields all come from external systems is Federated;
* an entity holding both continues to behave as described in the preceding section.