You've built a relationship graph in Affinity. Accounts connect to contacts. Contacts tie to deals. Deals reference multiple stakeholders. Organizations nest beneath holding companies. Then you hit export, and the CSV lands in your inbox flat as a pancake—one row per contact, one row per deal, cardinality collapsed, parent-child links severed. This is not a Affinity bug. It's the structural cost of any flat-file export: relational databases have depth; CSVs have width. But "technical constraint" doesn't rebuild your deal velocity or recover the context your reps relied on. You need a map of what's actually lost, which fields you can rebuild, and which data is gone for good. Why Affinity's export format breaks your relationship graph Affinity stores relationships as a graph database. An Account can have many Contacts. A Contact can belong to many Accounts (matrix selling). A Deal can involve multiple decision-makers. An Interaction (call, email, LinkedIn note) ties back to a Contact, an Account, or both. These connections are edges; the entities are nodes. A CSV has no edges. It has rows and columns. One row = one record. Related records become separate rows. To bridge them, you need a foreign key—an ID in Row A that points to Row B. This works if: The relationship is 1-to-1 (Account → primary contact) The relationship is 1-to-many (Account → contacts list, written as semicolon-delimited IDs) The relationship is stored as a field, not a connector (Affinity's architecture does both) Affinity's export fails the third test. Relationships stored as graph connections don't survive the column-to-field translation. What you get instead: Contact rows with Account IDs, but no Account names or hierarchies Deal rows with a single primary Contact, but not the decision committee Interaction history fragmenting across Contact, Account, and Deal records Organization hierarchies flattening—parent/child relationships lost unless stored as a field Many-to-many relationships collapsing into single-primary or null Map what survives the export Before you panic: most of your core data does survive. It's usually legible. You just won't be able to rebuild the original graph structure without manual work or a data engineering sprint. Survives intact: Contact names, titles, email, phone, location Account names, domains, employee count, industry (custom fields) Deal names, amounts, stages, close dates Custom fields (any data you stored in discrete columns) Interaction dates, subjects, and notes (if exported separately) Notes and attachments (usually as blobs or file references) Survives but degrades: Primary relationships: Contact → Account link, Deal → Contact link usually survive as IDs or name fields, but hierarchy depth vanishes. You lose "Contact A reports to Contact B" unless that's a custom field. Interaction threads: Calls, emails, and meeting notes export, but they're tied to a single entity (Contact or Account). If an interaction involves both, you lose that connection. You'll see duplicates or orphaned records. Organization hierarchies: Affinity's multi-level Account support exports as flat rows. Parent company and subsidiary relations usually lost unless stored as a "Parent Account" field. Lost, not recoverable: Many-to-many deal ownership: If Contacts A, B, and C are all stakeholders in a Deal, the export picks the primary Contact and drops the others. You'll have to manually re-link or reconstruct from notes. Matrix relationships: A Contact at Company X who also sits on the board of Company Y? You lose the second connection. One row, one Account per Contact. Soft relationships: Mentions in notes ("call with Alice at Acme") are text. They don't export as edges. Recovery requires NLP parsing or manual audit. Interaction attribution: If a call involved 3 Contacts, Affinity might log it under Contact A only. You lose the trace to B and C. Graph traversal context: The "warmth" your team built (Contact A → knows Contact B → intro to Account C) vanishes. You're left with isolated nodes. Audit your actual cardinality loss Before committing to a rebuild timeline, run a data audit. The loss you see on screen is often smaller than it feels, and sometimes larger than it looks. Step 1: Export and count Pull your Affinity export. Open it in a spreadsheet or load it into a SQL tool. Count: Total Contacts Contacts linked to multiple Accounts (if that column exists; if not, assume zero) Deals with multiple decision-makers (check for delimited lists in a Contact field; if none, assume single primary) Interactions: total count, percentage attached to Contact vs. Account Custom fields: which ones store relationship data (parent Account, committee members, ecosystem partners)? Step 2: Identify key relationship types in your workflow Not all relationship loss is equal. Ask your team: Do we route deals by decision committee, or just the champion? (If committee: high loss. If champion: low loss.) Do we manage account hierarchies (parent/subsidi