Entities

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: You confirm, and the entity is created. You can also create entities directly: “Create an entity called referrals.”

​

Field types

Entities support the standard field types from the platform schema system. Common types:

​

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 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.