How do you design your Attio data model from scratch?

You answer three questions before you touch Attio: what are you tracking, how do those things relate to each other, and what do you need to measure? Every data model decision flows from those answers.

A clean Attio data model with custom objects and relationship attributes connecting the core entities.

Start with your objects

Attio gives you Companies and People out of the box. Those stay. The question is what else deserves its own object. The test I use with clients: if something has its own lifecycle, its own attributes, and you need to report on it independently, it's a custom object. Deals almost always qualify. So do Funds for VC firms, Projects for services companies, and Subscriptions for SaaS businesses.

The mistake I see most often is creating too many objects too early. Start with the minimum. You can always add a custom object later without reworking your existing data. You can't easily collapse two objects back into one.

Before you create anything, write out your objects on paper or in a simple diagram. For each one, list:

• What it represents (a deal, a project, a fund, etc.)
• What attributes it needs (name, value, status, dates, etc.)
• What it relates to (which other objects it connects to)
• How you'll report on it (pipeline value, conversion rate, count by stage, etc.)

If you can't fill in all four lines for a proposed object, it probably doesn't need to be its own object yet. It might work better as an attribute on an existing object or as a list-level attribute on a filtered view.

Connect everything with relationship attributes

Once your objects exist, relationship attributes are how you wire them together. Link Deals to Companies so every opportunity is tied to an account. Link People to Deals so you know who's involved. These connections are bidirectional in Attio, which means a Company record automatically shows all its related Deals without any extra configuration.

The pattern that works for most B2B SaaS teams: Companies, People, and Deals as objects, with relationship attributes connecting Deals to both Companies and People. Add a status attribute on Deals for your pipeline stages, a currency attribute for deal value, and you have a working GTM data model.

For VC firms, the pattern shifts. You'll want a Deals object for pipeline, plus a Funds object and potentially an LP Commitments object. Services firms typically need a Projects object linked to Companies and People. The shape varies, but the principle is the same: model the real relationships, don't flatten them.

A common question I get: "Should a Person belong to a Company, or should they be linked via a relationship attribute?" In Attio, People have a built-in Company association through the company attribute. But you can also create explicit relationship attributes between People and other objects like Deals or Projects. Use both. The built-in association handles employment, while relationship attributes handle involvement in specific deals, projects, or engagements.

The discovery process I use with clients

When I'm designing a data model for a new client, I don't start in Attio. I start with a 30-minute conversation structured around three questions:

What does your team do every day? This reveals the operational objects. If your team is "working deals," you need a Deals object. If they're "managing projects," you need Projects. If they're "tracking investor commitments," you need a Commitments object. Listen for the nouns your team uses repeatedly. Those are usually your objects.

What do you report to leadership? This reveals the attributes and the relationships between objects. If leadership wants "pipeline by stage and rep," your Deals object needs a status attribute for stages and a relationship or actor reference for the rep. If they want "revenue by account," you need a calculated attribute on Companies that rolls up Deal values. Work backwards from the reports.

What breaks in your current system? This reveals the gaps in the existing data model. "We can't see all the deals tied to one company" means you're missing a relationship attribute. "We have ten different ways to track source" means you need a single, controlled select attribute. "We don't know when things changed" means you need status attributes with Attio's built-in audit trail rather than manual date tracking.

These three questions give you 80% of your data model. The remaining 20% emerges as the team starts using the system, and that's fine. A good data model is designed to grow, not to be perfect on day one.

Choose where attributes live

The next decision is whether an attribute belongs on the object or on a list. Object-level attributes are global -- they appear on every record of that type. List-level attributes only show up in a specific list view. Industry on a Company record is object-level. "Priority" on a target account list is list-level. Getting this distinction right keeps your records clean and your lists focused.

Here's the decision framework I use:

• Does every record of this type need this attribute? If yes, it's object-level. Every Company has an Industry. Every Deal has a Value.
• Does only a specific subset of records need it? If yes, it's list-level. Only target accounts need a "Priority" rating. Only event attendees need a "Session Interest" select.
• Will you report on it across the entire object? If yes, it's object-level. You can't aggregate list-level attributes in reports that span multiple lists.
• Is it temporary or context-specific? If yes, it's list-level. Campaign-specific tags, outreach sequence status, and event-specific fields belong on lists, not on the permanent record.

I also recommend thinking about calculated attributes early. If you need "total deal value per company" or "days since last interaction," those are calculated attributes that Attio can derive automatically from your relationship and attribute data.

Naming conventions that scale

At five users, attribute naming doesn't matter much. At fifty users, inconsistent naming causes real problems. Establish conventions early:

• Use clear, descriptive names. "Deal Value" not "Amount." "Close Date" not "Date." "Lead Source" not "Source."
• Pick a format and stick with it. Title Case or sentence case, but not both. I prefer Title Case for attribute names because it distinguishes them from freeform text.
• Prefix team-specific attributes. If your marketing team and sales team both need a "Status" attribute on People, prefix them: "Marketing Status" and "Sales Status." Alternatively, use list-level attributes so they don't collide.
• Document select attribute options. If you have a "Lead Source" select with options like "Inbound," "Outbound," "Referral," and "Event," write down what each option means. "Inbound" to one rep might mean "filled out a form" while to another it means "responded to a cold email." Definitions prevent data quality issues.

Create a simple document (even a note in Attio itself) that lists every object, every attribute, and its purpose. Update it when you add new attributes. This becomes your workspace's source of truth and saves enormous amounts of time when onboarding new team members.

Data model patterns by company type

B2B SaaS

The standard SaaS data model in Attio:

• Companies (built-in): Your accounts. Add attributes for Industry, Employee Count, Plan/Tier, and ARR.
• People (built-in): Your contacts. Use the built-in company association plus relationship attributes to Deals.
• Deals (custom object): Your pipeline. Status attribute for stages, currency attribute for deal value, relationship attributes to Companies and People.
• Optional: Subscriptions or Contracts for renewal tracking if your renewal motion is complex enough to warrant a separate object.

For enrichment, connect Clay to keep Company and People data fresh automatically.

Venture Capital

The standard VC data model:

• Companies (built-in): Both portfolio and pipeline companies. Use a select or status attribute to distinguish.
• People (built-in): Founders, LPs, co-investors.
• Deals (custom object): Your investment pipeline. See setting up Attio for a VC fund.
• Funds (custom object): Your managed funds, each with vintage, target size, and deployment attributes.
• Optional: LP Commitments (custom object): If you're tracking capital commitments per LP per fund.

Services / Consulting

The standard services data model:

• Companies (built-in): Your clients and prospects.
• People (built-in): Contacts at each client.
• Projects (custom object): Active engagements. Status attribute for project phases, currency attribute for project value, date attributes for start and end dates.
• Optional: Proposals (custom object): If your sales cycle involves multiple proposals per client.

Common mistakes in data model design

Modeling your org chart instead of your workflow. Your CRM data model should reflect how work flows through your company, not how your departments are organized. A common antipattern is creating separate objects for "Marketing Leads" and "Sales Leads" when they should be the same People object with different list views and status attributes.

Overloading select attributes. A "Status" attribute with 20 options is a sign that you're trying to track too many things in one field. If a select attribute has more than 8-10 options, consider whether it should be split into two separate attributes or whether some options represent a different concept entirely.

Skipping relationship attributes. Teams that use text fields to reference other records ("Company: Acme Corp" as a text attribute on a Deal) lose all the power of Attio's relational model. You can't click through, you can't roll up, and you can't filter by related record. Use proper relationship attributes from the start.

Not planning for reporting. If you build your data model without thinking about what reports you'll need, you'll discover gaps the first time someone asks for a metric. Design for how you report, not how you input.

The principle behind all of this: design for how you report, not how you input. If your leadership team needs pipeline by stage, revenue by segment, and deal velocity by rep, your data model needs to support those views natively. Work backwards from the reports you want and the objects, attributes, and relationships will become obvious.

Evolving your data model over time

Your data model is not set in stone. It should evolve as your business changes. But evolution needs to be managed, not ad hoc. Here's how I approach it:

• Quarterly review. Every quarter, review your objects and attributes with your CRM admin. Are any attributes unused? Are any missing? Are select options still relevant?
• Change requests. New attributes or objects should go through one person (your RevOps lead or CRM admin). This prevents the attribute sprawl that makes workspaces unusable. At 50 users, ungoverned changes compound fast.
• Migration planning. If you're coming from HubSpot or Salesforce, resist the urge to replicate your old data model exactly. Use the migration as an opportunity to simplify. You'll be surprised how many attributes in your old CRM were never used.

A well-designed data model does not just store your data. It shapes how your team thinks about their work. Get it right and the CRM becomes a tool people actually want to use. Get it wrong and you'll hear "the CRM doesn't work for us" every quarter until someone fixes the foundation.