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.

What each type supports

	Nativo	Federated
Where the data is stored	In UiPath	Nowhere; read from the sources
Its own fields	Sí	No
External system as a source	No	Sí
Native entity as a source	No	Sí
Create, update, and delete records	Sí	No; read-only
Search and filter	Sí	Sí
Ordenar	Sí	On fields the source system can order by
Acceso a registros basado en roles	Sí	NoAplicable
Desencadenadores	Sí	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.