Records

---
name: records
description: Use for Signalsurf CRM Objects, People or Company Records, Lists, audiences, identity-resolved data, qualification, selection, or membership.
---

# Signalsurf Records

Before every request using this Skill, follow [version check and automatic update](../signalsurf/references/freshness.md), then use the current guidance.

Read the [shared operating contract](../signalsurf/references/operating-contract.md) unless already loaded; a focused Skill uses the same context, actor, confirmation and result rules.

Use Records for durable CRM truth; use Sheets for flexible temporary operational rows.

1. Resolve the collection with `object_query` and the target with `record_query` or `list_query`. Never guess ids.
2. Use `object_manage` only for collection/schema work, `record_manage` for durable entity changes, and `list_manage` or `list_membership` for audience configuration/membership.
3. Read current state immediately before a consequential update. Preserve fields outside the requested change. For requested Record history or provenance, use `record_query` action `field_history` with the exact `objectId` and `recordId`. Filter stored changes by field, source, dates or literal text; continue `nextCursor` until null, even when a text-search page has no matches. `events` are stored rows; `changes` contains old/new field values. For a current Record and recent overall context, use `record_query` action `activity` with the exact IDs. Its `recordChanges` and `conversations` groups remain separate, and reply counts cover only the returned preview. For communications with that Record, use `conversations_query` action `search` with `record: { objectId, recordId }`, then `get` with a returned thread ID for full messages, call or meeting content. Paginate search results and narrow dates when its bounded search window is incomplete. Activity is an overview, not complete communication evidence. Company scope includes only its exact binding, not inferred employees. Sheet history uses its Item reader. Do not claim historical actors, edits or deleted Records that the stored history cannot establish.
4. Routine edits rely on Record history. Write to a Project Thread only when the result changes a hypothesis, creates reusable evidence/insight, or needs coordination.
5. Business Record mutations carry the selected work Project as top-level `projectId`, independently of Commons placement or Thread writeback. CRM schema administration follows its native action scope. Read [research and capture](../signalsurf/references/research-capture.md) when saving researched identities or Person + verified Company relations; email and Company-first are not generic Person prerequisites.

For requested lookup-based completion of supported existing fields, inspect the owning schema and saved bindings through `enrichment_query` action `list` before separate research and updates per Record. Records and Lists can use Enrich independently. For a Record request, retain its actual `objectId` and verified Record IDs; use `record_manage` action `select` for those IDs or an explicitly requested collection selection, without a `listId`. No List is required or created. For a List request, retain `listId` through binding discovery, configuration and execution. Read `list_query` for the actual `recordDatabaseId`, `entryDatabaseId` and selected active members. Shared Record fields use `recordDatabaseId` and canonical Record IDs; List-owned fields use `entryDatabaseId` and membership IDs. Native List Enrich checks the actor, exact active members and requested field, then updates shared canonical facts visible in other Lists. Shared Record Enrich is manual; never expand it to collection-wide scope. Generic Record edits and schema changes still require explicit Records access. Inspect the live capability schema; if shared fields with `listId` are unavailable, report the release gap instead of substituting independent Records access or research plus manual writes. Record bindings and List bindings are separate; reuse only the binding for that exact scope. For Records and Sheets, pass the returned selection token unchanged to `enrichment_run` action `run`; for Lists, pass the exact selected IDs described above. Run one exact field key at a time. `enrichment_manage` action `enable` is only for a missing binding or requested settings change. Honor approval and credit bounds, preserve unrelated/populated values, and read back actual results. Primary/protected and unsupported fields are not mandatory Enrich targets. Research-only requests create no Record or persistent binding; supplied facts and deterministic edits use ordinary Record updates.

To save a sourced Email for a known Record whose Email identity is empty, use `record_manage` action `update` on that exact Record. The server normalizes and claims it atomically with manual provenance; it remains unverified. Read the Record back. If the Email belongs to another Record or an existing identity differs, report the conflict and resolve the existing Records; do not create a duplicate to fill Email. Other declared identities, including a nonprimary LinkedIn identity, remain protected except for exact unchanged values.

For localized collection fields, use `object_manage` action `patch_schema`; for an Explicit List's process fields, use `list_manage` action `patch_entry_schema`. Read current schemas and revisions first. Name each field to add, update or explicitly delete. Omitted fields, options and relation metadata remain intact; supplied options replace that field's option list. Identity and system fields are protected. Full schema replacement is for an explicitly intended complete replacement and requires preserving everything outside the request.

Use `list_manage` actions `view_create`, `view_update` or `view_delete` for native List table views. Pass `listId`; `table_views` targets Sheets and cannot use a List ID. Read `list_query` action `get` for complete schemas, existing views and revisions. Filters use scoped column IDs such as `output.record:stage` or `output.list_entry:assignee`, with actual stored values/options. They narrow the List's membership without changing it. Preserve unrelated views and settings; explicitly send an empty filter list to clear filters. Update a dependent view before deleting its filtered field or removing a selected enum option. An attached List grants its own field operations, bounded Record reads, and native Enrich on its exact active members. It does not grant generic Record writes or collection-wide Records access.

For an explicitly requested whole-List deletion, discover `list_manage` action `delete`, inspect the exact List and revision, use a stable `operationId`, and verify deletion. Follow the shared operating contract for native member deletion, with no second conversational yes; existing confirmation resumes and internal Surfer/browser/autonomous confirmations remain unchanged. This removes the List rather than its backing Records. `view_delete` removes one View, and membership removal removes entries; neither deletes a List. Native member File lifecycle follows its declared Workspace authority and revision/dependency guards, independently of historical Project attachment. Do not create or enter an old Project or claim Working File ownership to satisfy deletion.