Tables and Fields

Tables are the foundation of your Lotics workspace. Each table defines a schema with typed fields, stores records (rows of data), and supports multiple views: filtered, sorted, and grouped perspectives on the same underlying data. Everything updates in real time across all connected users.

Table Structure

A Lotics workspace contains tables, and each table has three layers:

• Fields define the schema — what data can be stored and in what format.
• Records hold the actual data — one row per entity.
• Views provide different perspectives on that data — which records to show, in what order, with which fields visible.

This separation means you define your data model once and create as many views as your team needs. Fields are typed and validated. When you add a Number field, only numeric values are accepted. When you add a Select field, values must come from the defined option list. This type safety prevents data quality issues at the source.

Tables can hold tens of thousands of records and remain performant. The query engine supports server-side filtering, sorting, and pagination, so views load quickly even on large datasets. Real-time updates via WebSocket ensure every team member sees the latest data without refreshing.

Field Types

Lotics supports 12 field types that cover the full range of operational data. Each type has specific configuration options and value formats. Choosing the right field type matters for downstream features: a Number field enables rollup aggregations, a Record Link field enables lookups and rollups across tables, and a Date field enables deadline-based workflow triggers.

Text

Stores string values. Three display formats:

• Plain text — default, unformatted text.
• URL/link — rendered as a clickable hyperlink.
• Rich text — supports formatted content (bold, lists, etc.).

Can enforce unique values across records, preventing duplicates.

Number

Stores numeric values with configurable display format:

• Number — standard numeric display.
• Currency — displays with a currency symbol. Requires an ISO 4217 currency code (e.g., USD, VND, EUR).
• Percentage — displays as a percentage value.

Date

Stores date and time values as ISO 8601 strings. Four formats:

• Date — date only, e.g., 2024-01-15.
• Datetime — date and time, e.g., 2024-01-15T14:30.
• Date range — start and end dates, e.g., 2024-01-15/2024-01-20.
• Datetime range — start and end datetimes, e.g., 2024-01-15T09:00/2024-01-20T17:00.

Supports timezone configuration using IANA timezone identifiers (e.g., Asia/Ho_Chi_Minh, America/New_York).

Boolean

True/false checkbox. Simple on/off toggle for binary states like approval flags, completion status, or active/inactive toggles.

Select

Dropdown selection from predefined options. Each option has:

• A key (opt_xxx) — stable identifier used in data storage.
• A name — the display label users see.
• A color — for visual distinction in the grid.

Two modes:

• Single select (default) — one option at a time.
• Multi-select (multi: true) — multiple options allowed.

Values are always stored as arrays of option keys, even for single select. A single-select value looks like ["opt_abc123"]. No selection is an empty array [].

Member

Assign workspace members to a record. Works like Select but draws from the workspace member list instead of predefined options.

• Single member (default) — assign one person.
• Multi-member (multi: true) — assign multiple people.

Values are arrays of workspace member IDs.

Record Link

Links to records in another table, forming a relational graph within your workspace. Key behaviors:

• Bidirectional — when you link Record A in Table X to Record B in Table Y, a paired field is automatically created in Table Y showing the reverse link.
• Display fields — configure which fields from the linked table are shown alongside the link.
• View filter — optionally restrict which records are available for linking based on a view.

Values are arrays of {id, display} objects, where display is auto-computed from the linked record's display fields.

Lookup

Read-only computed field that pulls values from records linked via a Record Link field. If your Shipments table links to a Customers table, a lookup field on Shipments can display the customer's email, phone number, or any other field — without duplicating data.

• Returns native arrays with one element per linked record.
• Each element preserves the source field's type: text lookups return ["Alice", "Bob"], number lookups return [100, 200].
• Updates automatically when the source data changes.

Rollup

Read-only computed field that aggregates values across linked records. If an Orders table links to Order Lines, a rollup on Orders can compute the total order value (sum), number of items (filled), or the largest line item (max).

Available operations by field type:

Rollups can filter linked records before aggregation. The filter uses the same condition system as view filters, so you can aggregate only line items in a specific status or date range.

Formula

Read-only computed field that evaluates expressions referencing other fields in the same record. Expression syntax uses field names in curly braces:

{Price} * {Quantity}

Supports arithmetic, string manipulation, date calculations, and conditional logic. Output types:

• Number — arithmetic results like {Revenue} - {Cost}.
• Text — string operations and concatenation.
• Date — date calculations.
• Boolean — conditional expressions.

The output type is inferred automatically from the expression and determines which rollup operations are available when the formula is used as a rollup source.

Errors produce diagnostic strings like #ERROR: Division by zero.

Files

Attach documents, images, PDFs, and other files. Multiple files per cell. Each file attachment stores the filename, MIME type, and a storage reference. Files are served via signed URLs generated by the backend.

Button

Triggers a workflow when clicked. Has a configurable label text displayed on the button. Button fields do not store data — they are action triggers that execute automations defined in the workflow engine.

Records

Records are individual data rows within a table. Each record's data is a key-value object where:

• Keys are field keys (e.g., fld_abc123) — stable identifiers that never change even if you rename the field.
• Values follow the rules of each field type.

Example record data:

Records also track created_at and updated_at timestamps, and may have locked_fields — field keys that cannot be edited by users (used for approval workflows and controlled updates).

Computed Fields

Three field types — Lookup, Rollup, and Formula — are computed automatically. They are read-only: you never enter values manually. Instead, they derive their values from linked records, aggregations, or expressions.

Dependency cascade: Computed fields form a dependency graph. When a source record changes, every computed field that depends on it recalculates. This cascade is automatic:

1. A change to an order line item's amount...
2. Updates the lookup field showing that amount on the parent order...
3. Updates the rollup field summing all line amounts...
4. Updates the formula field calculating profit margin...
5. All changes propagate to connected clients in real time.

Computed field values are persisted at write time (not calculated on read), so queries and filters on computed fields are fast.

Record Linking

Record Link fields connect data across tables, forming a relational graph within your workspace. A shipment record links to a customer record, which links to invoice records, which link to payment records.

Key behaviors:

• Bidirectional — linking Shipment A to Customer B automatically shows Shipment A in Customer B's linked records. A paired field is created in the target table to hold the reverse link.
• Foundation for computed fields — Lookup and Rollup fields traverse these links to pull and aggregate data. Without links, these computed fields have nothing to traverse.
• Cross-table workflow access — workflows triggered by a shipment status change can read the linked customer record for an email address, then read linked invoice records to attach a PDF.
• Display configuration — choose which fields from the linked table appear alongside the link, so users see meaningful context (e.g., customer name and email) instead of just an ID.

Views

Each table supports multiple views with independent configuration. All views share the same underlying data — changes in one view appear in all others.

View Configuration

How Different Teams Use Views

The operations manager sees all shipments sorted by deadline with overdue items highlighted in red. The sales team sees only their assigned deals grouped by stage. The finance team sees invoices filtered by unpaid status. Everyone works from the same source of truth, with each view tailored to their workflow.

Validations

Fields can have validation rules that enforce data quality at input time. Validations run when a user edits a cell and prevent saving values that violate the rules. This catches data quality issues before they propagate through computed fields, workflows, and reports.

Real-Time Collaboration

Multiple team members can edit the same table simultaneously. Changes propagate to all connected clients within milliseconds via WebSocket. There is no save button — edits are persisted and broadcast as they happen.

This applies to:

• Record value changes (cell edits, new records, deletions).
• Field schema changes (adding, renaming, reconfiguring fields).
• View configuration updates (filter, sort, field visibility changes).
• Computed field cascades (a change to a source value triggers recalculation through the entire dependency graph, with results pushed to all clients).

The real-time system is designed for operational teams where data changes frequently and decisions depend on current state. When a warehouse team marks a shipment as dispatched, the operations dashboard updates immediately. When a salesperson closes a deal, the revenue rollup on the team summary table reflects it without delay.

Frequently Asked Questions

How many fields can a table have?

There is no hard limit on the number of fields per table. In practice, tables work well with 100+ fields. If a table grows beyond that, consider splitting it into linked tables for better organization.

Can I change a field's type after it already has data?

Yes. Lotics supports field type conversion for compatible types — for example, converting a Text field to a Select, or a Number to a Currency. Data is preserved and converted where possible. Incompatible conversions will warn you before proceeding.

What happens to computed fields when I delete a linked record?

When a linked record is deleted, lookup fields that referenced it return empty values, and rollup fields recalculate excluding the deleted record. The link reference is removed automatically from both sides of the relationship. Formula fields that depend on lookups or rollups also recalculate.

Can different views have different filter permissions?

Views control which records are visible through filters, but they do not enforce access permissions. All workspace members with table access can see all records if they create an unfiltered view. For access control, use workspace-level roles and sharing settings.

How do computed fields handle circular dependencies?

Lotics prevents circular dependencies at configuration time. You cannot create a lookup, rollup, or formula that would form a cycle in the dependency graph. The system validates the dependency chain when you configure a computed field and rejects configurations that would create infinite loops.

What is the difference between Single Select and Multi-Select?

They are the same field type (select) with a configuration toggle. When multi is false (default), users pick one option. When multi is true, users can pick multiple options. In both cases, the stored value is always an array of option keys — single select just enforces that the array contains at most one key.

How do Record Link paired fields work?

When you create a Record Link field in Table A pointing to Table B, Lotics automatically creates a paired field in Table B pointing back to Table A. Linking a record in one direction automatically updates the other direction. Deleting the link from either side removes it from both. The paired field's key is stored in the paired_field_key property.

Can I filter which records are available for linking?

Yes. Record Link fields have an optional view_id property. When set, only records that match that view's filters are available as link targets. This is useful for restricting link options to active customers, open orders, or any other filtered subset.