Known gaps

These gaps describe the CRM’s tables, fields, views and Airtable automations as they stood on 2026-10-28. They are not changes made to the CRM. Open work is tracked as Work Items in Systems Central; each item below gives the Work Item name and its status on that date.

Current inconsistencies

• Since 2026-11-04 a lead is a Deal at stage Lead. The Relationship table was deleted that day, after its rows were migrated to Deals, together with the 17 fields in other tables that pointed to it.
• Since 2026-11-04 the campaign is linked on the Deal in Campaign°, and Interaction.Campaign reads it through Deal°. The Campaign Participation table was deleted that day, with its Deal and Interaction fields and the Campaign Attribution Check. The same day the 412 Deals tagged Win the Storm were linked to the Win The Storm 2026 campaign. The Cal.com flow does not set Campaign°.
• Pending: the Deal and Interaction step views are being rebuilt; some still show old columns.
• Pending: the n8n Email Logging workflow (inactive) still has a Find Relationships step and must move to Deals before it is turned on.
• People/Companies descriptions promise two-way writes and automatic duplicate handling. Airtable sync is one-way and Core is the only writer of shared records (a rule still proposed, not yet adopted), so treat those descriptions as unconfirmed and check the sync settings; Cal.com writes new people in Core. Work Items: “Document the CRM two-way exception to Core ownership” and “Write the mirror sync contract per domain (writer, freshness, conflicts)”.
• Deal.Product* links Offer. The Positions table has Team-shaped fields while bds:position has Position-shaped fields. Do not migrate by label alone. Work Items: “Rename the remaining misnamed synced tables” and “Free CRM sync slots (duplicate Positions, BusinessRelationship mirror)”.
• CRM Record ID is a local RECORD_ID() formula despite a mixed UUID description. Membership # differs from Core’s current Membership ID label.
• The native next-contact copy automation was deleted with the Relationship table on 2026-11-04: the v1 scope keeps the next step as a manual update. Since 2026-11-04 that update is a task in Tasks. Work Item: “Decide how manual Interactions update the Relationship next step” (Waiting).
• Relationship.Task° and Due date* were migrated to Tasks on 2026-11-04, before the table was deleted. Tasks links straight to People, Companies and Deal. Interaction.Next Action° remains text for now. Work Item: “Decide whether Relationship Task° becomes a link to a structured Task” (Waiting).
• The Tags column added on 2026-10-22 carries a free sentence inside its definition: block, and 13 of the 14 columns it added to the Tags table have no description; two of them are named Team 2 and Department 2. Work Item: “Fix the malformed Tags column descriptions”.
• The participation-mismatch alert next to the ✅ of Health check no longer exists: Campaign Attribution Check was deleted on 2026-11-04. Work Item: “Show the participation-mismatch alert apart from the Health check tick” can be closed.
• View descriptions are incomplete. On 2026-10-28 the calendars SEO Companies, Trevor - Cal.com and Verena - Cal.com had no description. Work Items: “Review and fix the description of every CRM view” and “Triage the 349 CRM usability audit items by rule”.

Integration limits

Cal.com uses a first match for routing, person and open Deal, a one-page read for lists, JSON-serialized signature verification and best-effort UID deduplication. Missing email/UID/date are not all rejected. After waiting for a missing person mirror, it continues with repair notes. Separate PATCH/create operations can leave partial results; replay is not guaranteed to repair them. No campaign enrollment or attribution exists in that workflow.

On 2026-10-28 five Lead Source rules were marked active, one per seller calendar, and bookings created lead and Interaction rows that day. Since 2026-11-04 bookings create or advance a Deal. An active rule does not prove that every account works: check the n8n execution log for each seller calendar before relying on it. The two empty native automations, Automation 1 and Automation 2, remain in the base.

Work Item	Status
Test an unmapped Cal.com source end to end (pilot case P16)	Waiting
Automate Campaign attribution in the Cal.com n8n flow	To Do
Validate central calendar coverage and Amanda’s access	To Do
Decide event title format and two-way calendar sync scope	To Do
Validate Fireflies transcripts and identify clients by any participant	Waiting
Activate the Email Logging workflow (Gmail to Message and Interaction)	Waiting
Sync Message to consumer bases and link Relationship Messages	To Do
Finish Cal.com session config cleanup (percent format, empty automations)	To Do

Campaign scope

The current campaign can be Active while source facts remain incomplete; the available queue therefore excludes it. On 2026-10-28 Seo for Agents was Active while its Campaign Check reported missing objective, audience, organization, membership and start date. The five pilot Participation rows were deleted with the table on 2026-11-04. Campaign° on the Deal accepts more than one record; one campaign per Deal is a working rule, not a database constraint. Source hard deletion can leave retained mirror data. Campaign-specific offers/targets, sequences, automatic suppression and advanced metrics are deferred beyond v1.

The closed v1 scope uses manual attribution and requires portfolio, unattributed-record and outcome review. Won clients with active campaign work are reviewed through the Deals linked to the campaign. Last Contact Date aggregates Interaction dates and does not prove completion. Without dedicated fields, actual completion and closing facts, currency/value basis and contact restrictions must be explicit in existing notes and recoverable by another operator. Do not use Expected Close Date as the actual sale date or clear one campaign link to represent a general contact restriction. These are not implemented automated controls. Synthetic Deals #25 and #26 remain as evidence and must be excluded from real metrics; archiving their campaign does not automatically exclude them from aggregates.

A Tag classifies a record; Campaign° on the Deal records which campaign the lead came from. A tag named after a campaign does not link the Deal to it.

Work Item	Status
Complete the Seo for Agents campaign record in Core	Waiting
Exclude pilot records (Deals #25/#26, PILOT) from commercial reports	To Do
Explain Tag vs Campaign Participation and settle Campaign scope	Waiting
Set up campaign offers, targets and aggregations	To Do
Build connected e-mail and campaign sequences	To Do
Add structured commercial fields and indicators after the pilot	To Do
Add stage history, multitouch, Project Management and Interfaces	To Do

Pilot 01 and homologation

Pilot execution 01 ran on 2026-10-21 with fictitious organizations and two controlled bookings, both cancelled. Twelve of 17 cases passed in the technical sample. Five stay blocked for full acceptance: P01 needs a real campaign that is ready, P05 a controlled real meeting, P15 a second operator who identifies a general contact restriction, P16 an unmapped Cal.com source, and P17 a reconciliation reproduced by a second operator. No model change came out of the pilot. On 2026-10-28 the v1 homologation was still pending.

Work Item	Status
Sign off CRM v1 manual operation (homologation)	Waiting
Complete Pedro’s reviewer check of pilot 01 records	To Do
Run controlled attendance and second-operator review (P05/P15/P17)	Waiting
Test CRM entry and update as a seller (Amanda/Daniel)	Waiting

Access and record rules

Company-named views and calendar filters organize work; they do not isolate records between sellers. Uniqueness of people, companies and deals relies on search before creation, not on a database key.

Work Item	Status
Define record-level visibility policy and test it per seller role	Waiting
Define uniqueness keys, merge approval and critical-change history	To Do
Clean up data issues left from the Cal.com and CRM sessions	To Do
Settle who owns Deal: the domain model or the CRM	To Do
Add a direct Contact (Person) on Deal once Relationship has Contacts	To Do
Define partner participation and commission rules on Deals	Waiting

The Deal ownership item refers to the rule that a customer of a group company is recorded in the CRM, never as an Organization Relationship in Core. Since 2026-11-04 that customer is the client of a Won Deal.

Documentation boundaries

The CRM has 19 tables, 332 fields (as of 2026-11-04), 70 inventoried Data views and two empty Airtable automations. The operating scope is Data views and grid intakes. Airtable Interfaces and their forms are excluded from the guides. The guides describe filters only for the Deal and Task step views and three Interaction calendars; open any other view to confirm its filter. Screenshots show selected intake, check and reference views, not every company variant or failure state. Before relying on them, confirm in the systems themselves the sync mappings other than Campaign, base permissions, the current n8n configuration and execution retention, and any integration outside the CRM folder in n8n.