> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usehasp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Entities

> Entities are shared data schemas used by multiple workflows and apps within a project.

An **entity** is a shared data schema — the project's equivalent of a database table. Multiple workflows and apps within the same project can read and write the same entity without duplicating definitions or managing cross-references manually.

## Creating entities

Entities are created through chat, usually as a natural consequence of describing what you want to build:

> *"I need to track patient records with name, date of birth, chief complaint, and risk level."*

The system infers that a `patient` entity is needed and proposes:

| Field             | Type      | Notes               |
| ----------------- | --------- | ------------------- |
| `name`            | Text      | Required            |
| `date_of_birth`   | Date      | Required            |
| `chief_complaint` | Multiline |                     |
| `risk_level`      | Enum      | low / medium / high |

You confirm, and the entity is created. You can also create entities directly: *"Create an entity called referrals."*

## Field types

Entities support the following field types:

| Type        | Description                        |
| ----------- | ---------------------------------- |
| `text`      | Short string                       |
| `multiline` | Multi-line string                  |
| `number`    | Numeric value (integer or decimal) |
| `boolean`   | True / false                       |
| `date`      | Calendar date                      |
| `enum`      | Enumerated options                 |
| `reference` | Reference to another entity record |
| `currency`  | Monetary amount                    |
| `phone`     | Telephone number                   |
| `email`     | Email address                      |
| `json`      | Arbitrary structured value         |

Each field also carries a `phi_flag` marking whether it holds protected health information, which drives PHI handling downstream. These are the entity field types used by AI Studio projects and the [schemas API](/ai-api/quickstart) — distinct from the [App Builder SDK field types](/app-builder/reference/field-types), which are a separate vocabulary for workflow apps.

## Schema changes

Schema changes (adding, renaming, or removing fields) are **explicit confirmation gates**. When a conversational turn would modify entity structure, the system surfaces the change as a separate confirmation distinct from the workflow or app change that prompted it.

This is intentional: schema changes have data-model consequences — existing records, migration strategies, downstream consumer impact. The system surfaces:

* What the change is
* How many existing records are affected
* The default value or handling strategy for existing records
* Whether any workflows or apps reference the affected field

Schema changes are part of the project's draft changeset and are included in the next release. Entity migrations execute atomically with the rest of the changeset.

## Shared entity access

Multiple workflows can reference the same entity — this is the design. Entity schemas avoid duplication and ensure that when one workflow updates a `patient` record, another workflow listening to data-change events on `patient` sees the correct current state.

When two workflows would benefit from sharing a schema that currently exists in only one, describe it in chat: *"Use the same patient entity the intake workflow uses."* The system resolves the reference and wires the dependency.

## Data-change events from entities

Every write to an entity record — from an app, a workflow, an agent, or an integration — can emit a **data-change event**. Other workflows in the same project can listen to these events as triggers.

Example: A clinician marks a patient record as `discharged` in the triage app. A discharge workflow fires, generates a discharge summary via AI, and sends it to the billing system. No polling, no manual trigger — the data-change event is the trigger.

See [Workflow authoring → Data-change triggers](/studio/workflows#data-change-triggers) for the full event schema.

## Reverse-dependency view

From the project overview or a resource view, you can see which workflows write to an entity, which read from it, which apps render it, and which data-change events it emits and who listens. This makes refactoring safe: before removing a field, you know every consumer.

## Entity limits

Entities respect the platform's schema limits. See the platform documentation for record counts, field limits per entity, and retention policy by tier.