ObjectTypes and fields

Open Definitions & Relationships → ObjectTypes → Configure to edit a record type's schema.

Supported DynamicField kinds are short text, long text, number, checkbox, date, date/time, single select, multiselect, and Calculated Text. Fields can have labels, help text, required state, defaults, select options, and basic text/numeric validation.

Dependencies

Open the Dependencies tab beside Fields & Schema to review current definitions that use the ObjectType. The searchable table includes fields, incoming and outgoing relationships, member profile UserTypes, saved queries, legacy and contextual groups, Views, navigation, and data permissions. It follows indirect references, such as ObjectType → Query → Group → View, and explains each connection. A definition may have multiple rows when several definitions reference it. Configure links open the relevant editor or configuration list.

The overview refreshes when the tab opens; Refresh reloads changes made elsewhere. Retired definitions and audit history are excluded. Owners also see active/total record counts, active relationship connections, active member bindings, and whether the record schema is frozen. Record values are never returned. Delegated ObjectType managers see restricted names and no configuration links for areas they cannot manage; record and member counts require Owner mode.

The overview is read-only and does not change deletion guards or historical storage. Only actual field references in queries, groups, Views, actions, calculations, and option mappings block field retirement; unrelated saved queries do not. An overview exceeding 5,000 definitions, 10,000 displayed connections, or 64 levels reports a limit error instead of presenting partial results.

Keys and schema changes

Keys are generated from labels and remain fixed after creation, as do field types. Labels and help text may be renamed safely.

Use single-row selection and Delete selected field to retire a field. Choose Keep values and delete field, or, in Owner mode, Choose a destination and migrate. Retirement removes a field from normal forms, record reads, and validation while preserving its values in active and deleted records. Normal edits preserve these stored values, and new records omit retired fields. Retired keys remain reserved. You can reuse the visible label; the field editor automatically chooses a distinct key for the replacement field.

Optional fields can be added after records exist, so a destination can be created whenever needed. Existing field types and validation remain protected, and new required fields still need a separate backfill workflow. Referenced fields must be unlinked from query outputs/filters, group bindings, and option mappings before retirement.

Field Migrations

In Owner mode, open Field Migrations to see retired fields and how many non-null values remain, including values on deleted records. Select a retired field in the table or choose a source in the form. Choose an allowed destination. The picker and server use the same one-way rules:

Source	Allowed destinations
Short text	Short text, long text, or object selections
Long text	Long text or object selections
Number	Number, short text, or long text
Checkbox	Checkbox, short text, or long text
Single select	Single select, short text, or long text
Multiple select	Multiple select
Date	Date, short text, or long text
Date and time	Date and time, short text, or long text
Object connections	Empty single/multiple select replacement only

Existing-destination conversions never narrow long text to short text, and text is never parsed into numbers, dates, or checkbox values. Any source can instead create an empty single/multiple select replacement as described below. Numbers and checkbox values are formatted as text (including 0 and false). Dates retain their saved text representation. Other same-type migrations copy values. Every result must satisfy destination validation and the record size limit; live query option fields cannot receive migrated values.

For text → object selections, first configure an Object Relationship connected to this ObjectType, then choose it as the destination. Select the actual replacement record(s) for each distinct text entry. Names are never matched automatically; duplicate names have identifying suffixes. Multiple selections are available only when the relationship allows them. Migrations check the complete resulting connections against both sides’ cardinality limits, including conflicts between records in the same migration. Both relationship directions are supported. Existing connections are kept by default; explicit replacement retires superseded pairs and reactivates existing retired pairs with revision checks.

Object migration skips deleted source records and preserves their text. It never creates connections to deleted or foreign records. Original source text remains saved after migration. Connection or chosen-object revision changes invalidate the preview, as do source record or definition changes. The picker supports 200 distinct text entries, 500 active destination records, and up to 50 selected records per entry. Relationship migration plans support 20,000 existing/resulting connections.

Preview migration reports values to copy, occupied destinations, skipped records, invalid values, and values on deleted records. Zero, false, empty strings and empty lists count as values. Missing and null source values are left alone. By default, non-null destination values are kept, including zero, false, empty strings and empty lists. Choose Replace existing values explicitly to overwrite them. Invalid eligible values block the entire apply step.

Choose Delete the source field after migration when migrating during deletion. Original source values are always preserved, even after a successful copy. Skipped source values remain available for a later migration. If no destination exists, choose Create a replacement with the same name, or add an optional field under Fields & Schema and refresh.

Previews expire after 15 minutes and cannot be reused after applying. Record changes or field revision changes require a fresh preview. Each preview covers up to 10,000 non-null source values; the overview supports up to 1,000 retained field definitions. Recent migration summaries show the latest 50 attempts with migrated/skipped record counts, conflict policy, and whether source deletion was requested. They contain no previous record values and do not implement undo, schema version history, or backups.

Migration and retirement use the organization mutation lock. Copying updates record revisions, actor/time metadata and the existing bounded audit events. On standalone MongoDB, a database failure can interrupt a multi-record copy; the attempt is recorded and completed copies retain their source values. Review counts and create a fresh preview before retrying. For interrupted object replacements, some connections may already have changed; use a replacement preview to review the desired final connections before retrying.

Create a same-name replacement

In Field Migrations, choose the source, then set Destination choice → Create a replacement with the same name. Choose a new field type and configure any text length, number range, or select choices. For single/multiple select, choose manual choices or a Dynamic Query with projected label/value fields, just as in Fields & Schema. The new field inherits the source’s visible name and help text and receives its own permanent key/ID. It is optional, so unsupported values can remain empty.

For replacements other than single/multiple select, Carry over supported values; leave the rest empty copies only values allowed by the one-way conversion rules that also satisfy the new field’s validation. For example, short text can carry into long text, while short text → number creates an empty number field without parsing the original text. Even when a conversion is allowed, a value that fails the chosen validation remains saved only on the old field. Start empty for every record creates an empty replacement regardless of compatibility.

Preview reports carried-over and empty counts; it creates no field or record values. Applying creates the replacement, carries eligible values over when supported, retires an active field source, and makes the new field available to normal forms and tables. An already-retired field can also be replaced. Original values remain in their original records, including deleted records. Source permissions and query/group references are not transferred automatically; references that prevent retirement must be removed first.

Single and multiple select replacements always start empty, from every source type. No old values, names, arrays, record IDs, or existing selections are copied or matched—even if they exactly match a choice. Dynamic Queries only configure the new choices; migration does not execute them or look for corresponding results. The existing-values control is fixed to Start empty for every record.

Object relationships are available under Source field or object relationship, including incoming and retired relationships belonging to this ObjectType. Choosing an object source limits the new field to single/multiple select. The new field keeps the relationship’s name, but the original relationship definition and all active/retired connections remain unchanged. This operation does not retire or unlink the relationship, alter record access, or update existing Views/Groups automatically. It creates a separate empty field; update your presentation/access configuration when ready to use it.

Queries and projected label/value fields must be active and belong to the organization. Query/configuration changes invalidate the preview. Relationship definition, connection, and source-record revision changes also invalidate object-source previews. Object sources support up to 20,000 preserved connections. Existing query-backed field runtime behavior is unchanged by this migration/setup feature.

Existing-destination migrations retain their strict rules: unsupported conversions are blocked and validation failures prevent applying. Creating a replacement uses a distinct empty field instead of forcing a forbidden conversion into existing data. Recent migrations show both field types and a Left empty count.

Replacement previews check field versions, record data/revisions, key availability, and schema limits. The replacement is hidden while copies run and appears only when the operation completes. Failed copies retain their old values and any partially copied replacement values are kept in a retired definition for review. This is not a multi-document transaction or a record-history/undo feature.

Options sources

Manual options use one entry per line: value | display label. Query options reference a saved reusable query and map projected fields to option labels/values. Query-backed defaults and live options are not enabled yet.

Rich text, relationship references, attachments, calculated fields, and record rendering remain separate features.

Calculated Text

Add a field with Type → Calculated Text. Use Add Field to add a template part, then choose its Content type: Object field to select a stored field on this ObjectType or follow a relationship to a single related record, or Text for separators and other fixed wording. Changing a part’s content type resets its inputs. Parts are joined in the order shown; Move up changes that order. Save the field, then select it among the output fields in your DynamicQuery.

For an Enrollment label such as Jane — Mathematics — Fall 2026, build these parts:

1. Field: Enrollment → Student → Name.
2. Text: —.
3. Field: Enrollment → Section → Course → Name.
4. Text: —.
5. Field: Enrollment → Section → Name.

Use your actual relationship names and directions. If Section's name already includes the course, the Student and Section names may be enough. Existing Enrollment connections supply the values; no IDs or stored Name backfill are needed.

Calculated fields are visible as read-only columns in Records and configured DynamicGroups. To show the calculated value in a View table, add it as a read-only binding in its Group and grant the relevant UserType read access. The member also needs read access to every contributing record and field. A missing connection displays [Missing] for that field part. To customize it, check Custom fallback when no object is connected on the related field part and enter text such as Course not assigned. This also covers a missing connection anywhere along a multi-step path. Empty stored values, inaccessible values and ambiguous connections still leave the entire calculation blank. It does not change record names, record IDs, pickers or connection labels.

Templates allow 20 parts and up to four relationships per field part. Each step must lead to at most one record. This version combines stored scalar values; it does not run arbitrary code, arithmetic, nested calculated fields, aggregations, query filtering/sorting or automatic actions. Values are calculated when read, so changes to a connected name appear on the next load. They cannot be edited, required, given defaults or granted write permission. Templates can change after records exist without modifying stored data or record revisions. Remove dependent templates before retiring source fields or relationships.

A shared formula system and event-triggered DynamicConditions are planned future features. The planned events include CRUD in a particular View/Group, individual field edits, View loads, and relationship connection changes/deletions. Definitions will separate the trigger, condition and authorized DynamicAction. No automatic events are enabled today.