Configurable record model

The record model lets each organization adapt GTM Brain without forking the product. System objects provide the stable operational vocabulary—accounts, contacts, opportunities, tasks, notes, meetings, communications, artifacts, and agent runs—while tenant administrators create their own objects, fields, and relationships for records unique to their business.

Create a custom object

Open GTM Brain → Data model and select the plus control next to Objects. Provide a singular name, plural name, stable API key, description, and Fabric-family icon. The object becomes available to the field and relationship editors after its governed command completes.

The API key is immutable. Later changes publish a new object-definition version; they do not rename past events or invalidate saved projections. System objects cannot be replaced. A custom object cannot be retired while active fields, relationships, views, or lists still depend on it.

Manage fields

Open GTM Brain → Data model, choose an object, and select Add field. A field definition includes:

• a stable field key and immutable value type;
• a human label and description;
• optional guidance telling approved agents how the value should be interpreted;
• an explicit AI-fill policy: off, suggest for human confirmation, or governed automatic enrichment;
• privacy classification;
• search, sort, filter, required, and uniqueness intent;
• select options or a relationship target; and
• an active or retired lifecycle.

Selecting an existing tenant field opens the same editor. Saving publishes a new immutable version. The object, field key, and value type cannot silently change; retire a field and introduce a new definition when its meaning changes.

System fields are visible but cannot be replaced by tenant definitions.

Import a Lightfield schema

Organizations with a configured Lightfield integration can select Import from Lightfield on the Data model page. GTM Brain reads Lightfield's definitions with the tenant's sealed credential and shows a non-destructive preview before anything changes. You can inspect the current object or all supported core CRM objects: accounts, contacts, opportunities, tasks, notes, and meetings.

The preview separates new definitions, revisions, existing matches, conflicts, and unsupported definitions. Publishing creates or revises only compatible definitions. A system or tenant-owned field that already owns a key always wins; an incompatible field is reported as a conflict and is never silently replaced. When a compatible relationship points to a Lightfield object that does not yet exist in GTM Brain, the preview includes a deterministic tenant custom object. Publication creates that object before publishing the relationship, through the same governed action path. Lightfield's built-in relationship aliases—such as $account, $contact, $opportunity, $task, $note, $meeting, and $mail—resolve to the existing GTM system graph instead of creating duplicate tenant objects. Only genuinely absent record types are proposed as custom objects.

Lightfield scopes are evaluated per object. For example, a credential with accounts:read but without contacts:read can still preview and import Accounts; Contacts appears as unavailable with the missing scope. One restricted resource never turns the rest of the preview into a partial failure.

The credential remains inside tenant-bound encrypted storage. It is not included in the import command, Temporal history, Fabric Platform invocation, audit event, log, or adapter payload. Each compatible definition is published through gtm.save_object_definition, gtm.save_field_definition, or gtm.save_relationship_definition, so the imported schema has the same authorization, validation, durable recovery, immutable event, and tenant-isolation guarantees as a definition created manually.

These endpoints expose the same experience to administrators and approved automation:

GET  /gtm/record-model/imports/lightfield/preview
POST /gtm/record-model/imports/lightfield
GET  /gtm/connectors/lightfield/parity

Schema publication and record movement remain separate commands, so previewing definitions can never copy customer data. After the compatible schema is published, open Accounts, Contacts, Opportunities, or Meetings, then select Import / Export to preview the first bounded record batch for that object. The preview provides a destination control for every compatible source field. A destination must be an active field on the same object with the exact canonical value type; a source field can also be skipped. Two source fields cannot target the same field.

Lightfield system properties such as account industry, revenue range, headcount, funding type, website, LinkedIn URL, owner, and last interaction may be returned as top-level record attributes rather than inside the custom-field map. The normalization boundary handles both representations. Tenant select fields preserve provider option identifiers so imported values resolve through the exact versioned schema; canonical system fields such as account industry resolve those identifiers to labels before the governed snapshot is written. Lightfield's select-backed employee band is published as the tenant field headcount_range; it does not overwrite GTM's numeric account.headcount. The account grid prefers an exact numeric value when one is available and otherwise renders the imported range label.

Record review classifies every row as create, update, unchanged, or conflict. Creates and same-Lightfield-source updates are selectable. Unchanged rows remain no-ops. A native GTM identity or a record owned by another import source is a non-selectable conflict; operators use governed merge review rather than silently overwriting it. The canonical action repeats that ownership check, so API and agent callers cannot bypass the UI decision.

The preview binds the exact source page, mapping choices, mapped rows, and an immutable hash. Each Lightfield page is capped at the provider's supported 25-record maximum. Applying one preview re-reads Lightfield, rejects drift, stages the bodies in Lakebase, and sends only an opaque command identity through Temporal.

For a complete object, select Import full workspace. GTM Brain starts one idempotent Temporal job, reads bounded provider pages inside trusted activities, and applies every safe row through the same gtm.apply_record_import_batch action used by the preview. The job checkpoints the exact offset, source count, imported count, unchanged count, conflict count, and source total after every page. A worker restart reuses that checkpoint; it never repeats a completed page or silently overwrites a conflict. After 50 pages, the workflow continues as new so Temporal history remains bounded. Credentials and record bodies never enter workflow history, action parameters, events, or logs.

The transfer dialog shows running, completed, and failed jobs with live counts. Failed jobs retain a privacy-safe failure code and their last durable checkpoint for operator recovery. Starting the same logical import with the same idempotency key returns the existing job; using that key for different input fails closed.

The Certification tab supports two levels of evidence. Preview parity checks a bounded provider page and labels it as a sample. Run full certification starts a durable Temporal workflow that reads every Lightfield account, contact, opportunity, and meeting, then compares the exact normalized source hashes with the imported GTM projection. The report identifies changed and missing rows, duplicate provider IDs, orphaned imports, unresolved import conflicts, relationship counts, and stable source, projection, mapping, schema, and relationship hashes. Record bodies remain inside trusted activities; Temporal retains only the compact certification result.

Every certification start and terminal result is a Fabric Platform action and emits immutable GtmRecordCutoverReportStarted, GtmRecordCutoverReportCompleted, or GtmRecordCutoverReportFailed evidence. A report cannot be ready while any supported CRM resource is unreconciled. Lightfield files are a separate API resource and require the files:read scope plus an approved binary-retention destination. Until that additional migration is implemented, file and attachment bodies are explicitly not certified rather than silently omitted. Outbound Lightfield writes also remain uncertified.

An applied batch emits GtmRecordImportApplied. Imported records join the normal account projection and therefore inherit search, filters, saved views, relationships, and tenant isolation. A compensating gtm.reverse_record_import_batch action can restore the previous snapshots only while the imported rows still match that exact batch; later edits fail the reversal closed instead of being discarded.

Export is separately authorized with record.exporter. gtm.request_record_export records the tenant, principal, selected fields, format, and filter hash before the product renders a bounded CSV or JSONL payload. Authorization proofs and provider credentials never enter the downloaded data.

Edit record values

Open an account and select Edit fields in the Workspace fields section. GTM Brain renders controls from the active field definitions, validates the submitted values, and uses optimistic concurrency so one operator cannot unknowingly overwrite another operator or agent.

The browser does not write the account projection. It submits gtm.upsert_record_fields with a base version through the durable command API. Temporal carries the compact command identity, Fabric Platform evaluates policy and executes the action, and an immutable GtmRecordFieldsChanged event rebuilds the query projection.

API contract

People and autonomous clients use the same protected product API:

GET  /gtm/record-model
POST /gtm/record-model/mutate
GET  /gtm/records/imports/lightfield/preview
POST /gtm/records/imports/lightfield
GET  /gtm/records/imports/jobs
POST /gtm/records/imports/lightfield/jobs
GET  /gtm/records/cutover/reports
POST /gtm/records/cutover/lightfield/reports
POST /gtm/records/exports
GET  /gtm/accounts/records
GET  /gtm/contacts/records
GET  /gtm/opportunities/records
GET  /gtm/meetings/records
GET  /gtm/lists/{listId}/records

GET /gtm/accounts/records supports a query-bound cursor, bounded page size, server-side search, state filtering, and stable sorting. A cursor cannot be replayed against a different query. Responses include the current custom values and their optimistic-concurrency version.

Schema publication requires an administrator and a short-lived record_model.admin authorization proof bound to the tenant, actor, command, and capability. Personal saved views can be authored by their owner; workspace views, lists, object definitions, field definitions, and relationship definitions require the administrator proof. Schema-changing actions remain denied to agents by default.

Audit events

The record model emits one of these privacy-safe events for each successful action:

The signed authorization proof is verified by the canonical action and is never retained in the definition snapshot. Repeating the same command returns the existing result; changing logical input requires a new command and definition version.

Current scope

The production slice provides the tenant object registry, versioned custom fields, relationship and display configuration, previewed Lightfield schema import for compatible core objects, account value editing, configurable Account, Contact, Opportunity, and Meeting grids, query-bound cursors, search, reusable all/any multi-condition filters, personal saved views, governed static or dynamic Lists, ownership and lifecycle, relationship navigation, reversible duplicate review, previewed core-record migration, reversible bounded import batches with reusable mapping and conflict review, durable full-workspace import jobs, full-dataset reconciliation for four core CRM resources, and audited exports. File-body migration, generic custom-object grids, two-way connector cutover, and the general workflow builder remain subsequent roadmap gates, not implicit behavior in this release.

Next: Record relationships and merge review, Meetings and lists, Accounts and account memory, Agent team, and Governance.