Meetings, lists, and reusable filters

GTM Brain treats meetings and audience lists as tenant-scoped operational records. They use the same governed event stream and query projections as accounts, contacts, and opportunities; neither screen introduces a separate CRM database or a browser-only source of truth.

Meetings

Open GTM Brain → Meetings to inspect meetings booked through the campaign and reply loop. Each row is projected from an immutable GtmOutcomeRecorded event whose result is meeting. The event remains tied to the account, touch when available, actor, invocation, correlation, and delivery history.

The screen supports cursor paging, search, sorting, custom columns, and multi-condition filters. Opening a meeting’s account uses the shared account record panel, so the surrounding signals, contacts, replies, tasks, artifacts, and audit events remain available without duplicating them on the meeting record.

GTM Brain does not silently create an editable calendar object when an outcome is recorded. Configured calendar connectors instead submit provider snapshots through gtm.sync_calendar_event_v2; the meeting grid combines those immutable projections with booked outcomes. Tenant custom fields can enrich the projected meeting without replacing its provider identity, version, account, or source timestamps. See Email and calendar synchronization.

Governed lists

Open GTM Brain → Lists to create one of two versioned definitions:

• Dynamic list — current membership is evaluated from up to 30 conditions over the latest tenant projection. Conditions can match all or any.
• Static list — membership is an exact set of canonical record IDs. Unknown or retired records do not materialize, but the immutable list definition remains auditable.

Lists currently materialize accounts, contacts, opportunities, and meetings. A tenant administrator publishes each definition through gtm.save_list_definition; editing publishes the next immutable version. The canonical action validates the object, fields, filterability, administrator proof, tenant, command ID, and version before emitting GtmListDefinitionChanged.

Reusable filter builder

The same filter contract drives record pages, saved views, and dynamic lists. Supported operators are:

equals          not_equals       contains
starts_with     is_empty         is_not_empty
greater_than    less_than        in

The server—not the browser—validates that each field exists and is filterable, evaluates all/any semantics, binds the cursor to the exact query hash, and rejects a cursor reused with different conditions. Custom field value types are normalized before comparison. Select fields, including Source, present their supported values by name; choose is not → Lightfield → Apply filter to exclude Lightfield records without remembering a provider identifier. Apollo contact records are labelled Apollo throughout the interface.

API

GET  /gtm/meetings/records
GET  /gtm/lists/{listId}/records
GET  /gtm/record-model
POST /gtm/record-model/mutate

People and autonomous clients use the same protected endpoints. List creation and updates pass through staged Lakebase command storage, compact Temporal orchestration, Fabric Platform policy and action execution, durable host invocation state, and an immutable audit event. Agents do not receive a direct database or projection write path.

Appointment creation is not part of the current connector contract. For the complete handoff from reply to meeting evidence—and the requirements for a future scheduling adapter—see Agent-led GTM lifecycle.

Next: Configurable record model, Accounts, and Governance.