Architecture and ownership
Who writes Core records, which systems mirror them and what is known about each sync.
Core is the only writer of shared records. Every other base is a domain: it mirrors the Core tables it needs, links its own records to the mirrors and never edits the shared facts. When a mirror and Core disagree, Core is right. This rule is proposed, not yet adopted; its acceptance is an open Work Item.
Who may write to Core
| Writer | What it writes | Evidence |
|---|---|---|
| People maintaining Core | Any Core table, through Data views and grid intakes | Data views |
| CRM two-way mirrors | New People and Organizations created from the CRM People and Companies tables | CRM two-way exception (below); Core views named Base Fields - Two Way Sync |
| n8n Cal.com Booking Intake | New People rows with Status Proposed and the tag cal-lead-n8n | Cal.com booking |
| Airtable automation in Core | coreId on new Campaign rows | Automations |
The CRM is an exception to “Core is never two-way”, with two guardrails: rows born in a domain enter as Proposed and Core promotes them, and each row carries a visible duplicate key (e-mail for a Person, website or domain for an Organization). Nothing sets Proposed automatically: a row created from the CRM without Status stays blank until someone sets it. The exception is not yet written into the proposed Core rule. Confirm in the CRM sync settings that the two-way setting is active before relying on it.
Who reads Core
Mirrors are recognized by table name and field shape. A table name alone does not prove the source view, the included fields or the refresh behavior.
| System | Core tables mirrored | Local table names |
|---|---|---|
| KPIs & OKRs | People, Organizations, Membership, Positions, Department, Team, Cadence, Tags, Campaign | Person (mirror), Organization (mirror), Membership (mirror), Position (mirror), Department (mirror), Memebership, Cadence (mirror), op:tags, Sync - Campaign |
| CRM | People, Organizations, Membership, Organization Relationships, Classification Term, Team, Department, Positions, Tags, Campaign | People, Companies, Membership (mirror), BusinessRelationship (mirror), schema:DefinedTerm, Team, Positions, Department, bds:position, Tags, Campaign (mirror) |
| Tooling and Access | People, Organizations, Membership, Department, Team, Tags | Person (mirror), Organization (mirror), Membership (mirror), Department (mirror), Grid view, Tags (mirror) |
| Communication | People, Organizations, Membership, Department, Team, Classification Term, Tags | Person (mirror), Organization (mirror), Membership (mirror), Department (mirror), Team (mirror), Classification Term (mirror), Tags (mirror) |
| Systems Central | Organizations, Membership, Tags | Organization (mirror), Membership (mirror), Tags (mirror) |
| Products & Services | Organizations, Tags | Organization (mirror), Tags (mirror) |
Three local names hide a Team mirror: KPIs & OKRs Memebership, CRM Positions and Tooling and Access Grid view. Address, Cities, States, Countries and Branch have no consumer.
What is verified about each sync
| Contract | Direction | What is known |
|---|---|---|
| Campaign → CRM | One-way | Source view Sync - Campaign with 16 fields; deleted source rows are retained in the CRM. Verified 2026-10-21. |
| Tags → Tooling, Communication, Systems Central, Products | One-way | Name, Kind and notes only; removed source rows are retained. Verified in the Airtable UI on 2026-10-22. |
| People and Organizations → CRM | Two-way by rule | Not confirmed in the sync settings. Core has a Base Fields - Two Way Sync view on each table. |
| Every other mirror | Not verified | Source view, fields, filters and refresh are unknown. |
A Work Item asks for a written sync contract per domain: writer, freshness and conflict rule. Until it exists, treat a mirror value as possibly stale and check Core first.
Rules that follow from mirroring
- Links between mirrors survive only when both tables are mirrored together. That is why Person, Organization, Membership, Position, Department and Team travel as a set.
- Airtable record IDs are local to each base. Never paste a Core record ID into a consumer’s link field.
- A column a domain adds on a mirror, such as a local Tags link, belongs to that domain and never reaches Core.
- Each base can hold at most 20 synced tables on the current plan, so every new mirror spends a slot.
Diagram of the KPIs & OKRs consumer path only. It does not assert automatic synchronization.