Assign immutable identities

The CRM has no identity automation since 2026-11-04. Relationship — assign immutable coreId was deleted with the Relationship table, and Participation — assign immutable coreId with the Campaign Participation table, both on that day. Deal and Interaction have no coreId; shared records get their UUID in Core. The sections below describe how the deleted automations worked, as a reference if a CRM table needs one again. Both used a recordCreated trigger that received recordId and wrote only the coreId when blank.

Processing

Validate the Airtable locator, read the record and stop if absent or already identified. Generate a UUID v4-shaped identifier, reread the record and write only if it is still present and blank. An integration that allocates identity should supply it at creation; the automation preserves it. The script uses randomness for identity, never for authorization or secrets.

Limits and recovery

The reread reduces accidental overwrites but is not compare-and-swap or a uniqueness constraint. Two concurrent writers can still race. Editing an existing coreId to blank does not retrigger recordCreated: recover the original identity from the record’s revision history or a base snapshot rather than generate a new one. A supplied invalid value is preserved; downstream checks may reject it. Names and Airtable rec IDs are not substitutes for portable UUIDs.

Verification

Before deletion, the script was tested in six local scenarios: creation, replay, preservation, missing record, deleted record and invalid input. The Core Campaign identity is documented with Campaign.