Skip to main content

Where your data lives

Decide where records belong: an AutessaDB table you own, or the data a feature already provisions — and never mirror user-facing data in a second place.

The decision: you have data to store — customer records, extracted fields, a log of what a workflow did. Where does it go?

The systems​

  • AutessaDB tables — your own structured tables, created and owned through autessa.autessadb.*. Rows are user-editable, secured by row/column rules (see the sharing-permissions guide), and can drive automation through triggers (see the automations guide). This is the home for any data your workflow produces or curates.
  • The data a feature already provisions — many features keep their own authoritative records: meeting recordings live under autessa.meetingRecorder.*, e-signature envelopes under autessa.eSignature.*, agent conversations under autessa.agents.*. You read from those surfaces; you do not re-store their contents.

Decision rules​

  1. New structured data you own → an AutessaDB table. Create it with autessa.autessadb.tables.create, then write rows with autessa.autessadb.query.insert and read them with autessa.autessadb.query.query.
  2. Data a feature already owns → leave it there; reference it. If a meeting recording already exists, read it via autessa.meetingRecorder.recordings.get — do not copy its transcript into a table "to be safe". Store a reference (its id) plus only the derived fields you actually add.
  3. Never mirror user-facing data. AutessaDB is the source of truth for the rows it holds. Do not keep a parallel "system of record" elsewhere; a second copy drifts and confuses the user who owns the row.
  4. Pick column types deliberately. AutessaDB has twelve creatable column types: SHORT_TEXT, LONG_TEXT, ULTRA_LONG_TEXT, FILE, AUDIO, IMAGE, VIDEO, INTEGER, FLOAT, BOOLEAN, SINGLE_SELECT, MULTI_SELECT. ULTRA_LONG_TEXT has no character limit — values past a threshold are stored in S3 and re-inflated on read — but it cannot be vectorized (no semantic search) or indexed, so reach for it only when the value may exceed LONG_TEXT's cap. There is no JSON column type — serialize structured blobs into a LONG_TEXT column. There is no DATETIME column for your own timestamps — store times as SHORT_TEXT holding a UTC ISO-8601 string (yyyy-MM-ddTHH:mm:ssZ) so they sort and compare correctly.

Worked examples​

A. Summaries of meetings into a table. Read each recording with autessa.meetingRecorder.recordings.list, then for the derived summary create a table once with autessa.autessadb.tables.create (a SHORT_TEXT recordingId, a LONG_TEXT summary, a SHORT_TEXT summarizedAt), and append rows with autessa.autessadb.query.insert. The transcript stays in the recorder; only your summary is new.

B. A structured blob with no native column. You have a JSON payload to keep alongside a row. Add a LONG_TEXT column and write the JSON string into it — AutessaDB has no JSON type, so LONG_TEXT is the intended home.

C. An event timestamp. Store 2026-07-16T09:30:00Z in a SHORT_TEXT column, not a DATETIME column (there isn't one), so string comparison gives correct chronological order.

See also​

  • automations — how a table's rows trigger downstream work.
  • sharing-permissions — who can read and edit the rows you create.