22.1 Data Fabric (Data Service) Entities: Modeling Business Data

22.1 Data Fabric (Data Service) Entities: Modeling Business Data

Core Concept: Data Service is transitioning to the name Data Fabric, and you may see both names. It is UiPath's persistent, no-code data store for automations and apps. Data is modeled as entities with typed fields, and automations work with whole records instead of dozens of loose variables. The exam description lists Data Service entities under resource management.

---

Why Use Entities

• One version of the truth across attended and unattended processes, for example storing invoices once and passing only the record ID through queues.
• Long-running processes that move data across several jobs and human steps.
• Aggregation: one unattended process gathers data from several systems, and other processes read it from Data Fabric instead of every user needing access to every system.
• Cleaner workflows: model a Customer entity, import it in Studio, and work with one typed variable.

---

Creating an Entity

The entity type is also fixed once chosen.

---

Field Types

Records also carry system fields such as the record Id and who created or updated them and when.

---

Access Control

• Manage Access assigns roles to users and groups.
• Standard roles: Administrator, Designer, Data Writer, and Data Reader. Standard roles cannot be removed, and custom roles can be created.
• By default, organization users can read data through the Everyone group. To restrict data, adjust that access and assign roles deliberately.
• Folder-level entities are additionally limited to users of their Orchestrator folder.

---

Managing Data and Schemas

• Add, edit, and delete records in the Data Fabric interface, or import data from CSV. Import requires Read and Create permissions and does not support relationship, choice set, or auto-number fields, which must be non-required for import to work.
• Schema export and import moves entity and choice set definitions between tenants for development, test, and production.
• Advanced search filters records in the interface.

---

Using Entities in Studio

1. In Studio, import the entities you need. Each entity becomes a type in the project, for example Invoice.
2. Declare variables of that type, such as inv As Invoice, and set fields directly: inv.VendorName = "ACME".
3. Use the Data Fabric activities, such as Create Entity Record, Query Entity Records, and Update Entity Record, which the next section covers.
4. When the entity's schema changes, update the imported entities in Studio so the types match.

---

Designing Good Entities

• Model business objects, such as Invoice, Supplier, and Claim, not screens.
• Use relationships instead of copying data between entities, for example Invoice to Supplier.
• Use choice sets for statuses so values stay consistent across processes and apps.
• Choose the location deliberately: use Folder entities to keep departmental data separate.
• Keep large documents in File fields or storage buckets, and keep searchable data in typed fields.

---

Worked Example

An invoice solution uses:

• Supplier (Name, TaxId, Country as a choice set).
• Invoice (Number as Auto-number, Supplier as a relationship, Amount as Number, Status as a choice set, PDF as a File field).

The dispatcher creates Invoice records and adds only the record Id to the queue. The performer reads the record, processes it, and updates Status. An approval app shows the same record to reviewers, and a reporting process queries all invoices with Status "Exception".

---

Common Traps

• Picking Tenant location for departmental data and then trying to move it to a folder; the location cannot be changed.
• Expecting to write to a Federated entity; it is read-only.
• Leaving the default Everyone read access in place for sensitive entities.
• Making relationship or choice set fields required and then failing a CSV import.
• Changing the entity schema without updating the imported entities in Studio.