Attio Custom Objects and Data Model Explained (2026)
•
Attio's data model has four components: objects, attributes, records, and lists. Objects are your tables, attributes are your columns, records are your rows, and lists are the process layer where your team actually works. Custom objects, available on Pro and Enterprise plans, extend that model to any entity your business runs on: subscriptions, invoices, events, partners.
Definitions only get you so far, though. The data model is the foundation of an Attio implementation, the layer every workflow, report, and AI agent you build later depends on. And the most common mistake I see is not a missing feature, it is an over-built model, with custom objects doing work a list would do better. This guide explains how every piece fits together, then shares the decision rule I use with clients on the question that trips everyone: custom object or list?
How Attio's data model works
A CRM data model is the set of tables your customer data lives in, plus the relationships between them. Most CRMs hard-code that model and make you rent an admin to bend it. Attio treats the model as something you design, which is why the same five concepts keep showing up across its docs, its API, and its AI features.
The fastest way to understand the four components is the spreadsheet analogy Attio itself uses:
Component | Spreadsheet equivalent | What it does |
|---|---|---|
Object | A table or tab | Defines an entity type, like Companies or Invoices |
Attribute | Column headers | Defines what you track about that entity |
Record | A row | One specific company, person, or invoice |
List | A filtered working copy | Layers a process on records without changing them |
One property of this model matters more in 2026 than it did before. Attio's AI attributes, workflows, agents, and MCP server all read and write the same objects and attributes you define here. A clean model means your automations and agents inherit clean context. A messy one means they inherit the mess. If you want the AI side of that story, see my guide to connecting Claude and AI agents to Attio. If you are still evaluating the platform itself, start with the complete Attio guide.
The five standard objects
Attio ships with five standard objects. People and Companies are enabled by default and populate automatically when you sync email and calendar. The other three you switch on when your motion needs them.
Object | What it tracks | Enabled by default |
|---|---|---|
People | Every person your team interacts with | Yes |
Companies | Every company, identified by domain | Yes |
Deals | Sales opportunities and pipeline | No, enable it |
Workspaces | Product accounts, for PLG teams | No, enable it |
Users | Individual users of your product | No, enable it |
Enable Deals as soon as you run a real pipeline. A sales list on companies works for a founder closing the first ten customers, but Deals gives each opportunity its own record, tasks, and notes, so company records stay clean when multiple teams touch them.
Workspaces and Users exist for product-led teams. They hold product accounts and the users inside them, synced from your product via Segment, a rETL tool like Polytomic, or the API. If that is your motion, I cover the full setup in Attio for product-led growth.
One detail worth flagging early: standard objects carry built-in system attributes plus automatic enrichment, and custom objects do not get enrichment. If your data fits a standard object, use the standard object. You are giving up free data if you rebuild People under another name.
Attributes: the fields on every record
Attributes are the columns of your model, and they are available on every plan. They come in two categories, and the distinction does a lot of quiet work in Attio.
Object attributes live on the record itself and appear everywhere that record does. A company's domain is a company attribute no matter which view or list you see it in. List attributes belong to a single list, and their values live on the list entry rather than the record. An Onboarding stage belongs on the onboarding list, not on the company record, because it describes the process, not the company.
For types, Attio gives you the standard toolkit: text, number, currency, date, timestamp, checkbox, rating, phone, and location for values; status, select, multi-select, and user for process and ownership; record and relationship types for connecting data. Text, select, and multi-select attributes also support AI Autofill, where Attio fills the value against a rubric you write, which replaces a surprising amount of manual data entry.
Two expert-level details most teams miss. Required attributes can only be created on custom objects, not on standard objects or lists. And unique attributes, which block duplicate values, work on custom objects plus Deals, Users, and Workspaces, but not on Companies or People. Both matter the moment you sync data from another system, as we will see below.
Does Attio have formulas?
Not as an attribute type. There is no formula field in the attribute picker today, so you cannot write a spreadsheet-style calculation directly on a column. Calculations run through Workflows instead: the Formula block handles math on number and currency attributes, an Aggregate values block computes sums, averages, minimums, and maximums across related records, and an update block writes the result back to a regular attribute. MRR times 12 into an ARR field is the canonical example. It is more setup than a formula column, but it also recalculates on triggers you control. I walk through the blocks in my Attio Workflows guide.
Relationship attributes: how objects connect
Relationship attributes are the connective tissue of the model, and the main reason a well-designed Attio workspace feels like a graph of your business rather than a stack of spreadsheets. A relationship is two entangled attributes, one on each object. Add a company to an invoice's Company attribute and the invoice appears under that company's Invoices attribute automatically. Every relationship is two-way, always in sync.
When you create one, you choose how many records can sit on each side:
Relationship type | Example |
|---|---|
One to one | A buyer links to exactly one company |
One to many | One company has many invoices |
Many to many | Users belong to many workspaces, workspaces have many users |
The underrated part is what relationships unlock in views. Once objects are linked, any view can display, filter, and sort by attributes of the linked record. Your deals view can show each deal's company employee count and last funding round without duplicating a single field. This is the feature that removes most of the copy-paste data hygiene work other CRMs generate.
Two constraints to plan around. Relationship attributes can only be created on objects, never on lists. And while the system relationships, like Company to Team or Deal to Associated company, ship on every plan, creating your own requires Pro or above.
Custom objects: extending the model to your business
A custom object is an object you define from scratch: its name, its attributes, its relationships to the rest of your data. Attio's docs use a B2B marketplace as the example, with Buyers, Sellers, and Transactions as custom objects alongside the standard People and Companies. For SaaS teams the usual suspects are Subscriptions, Invoices, and Projects.
The plan reality first, because third-party posts get this wrong constantly. Custom objects are available on Pro and Enterprise only. Pro runs $69 per user per month billed annually, or $86 monthly. Plan limits cap total objects, standard ones included: 3 on Free, 5 on Plus, 12 on Pro, unlimited on Enterprise. In practice, a Pro workspace with all five standard objects enabled has room for seven custom objects, and I have never had a client need more than four.
Every custom object arrives with five system attributes built in: Record ID, List entries, Next due task, Created at, and Created by. You add everything else. You also choose the record text, the attribute that names each record in views, and optionally a record image. For an Invoices object, setting record text to the invoice number is the difference between a readable pipeline and a wall of random IDs.
Custom objects have caught up with standard ones on the communication side too. Since a January 2026 update, emails appear on any record type, pulled in through linked company domains and the addresses of linked people, and a February update added file uploads on deals and custom objects. Earlier guides that call custom objects second-class citizens for email tracking are out of date.
How to create a custom object in Attio
The mechanics are the easy part. The design decisions behind them deserve most of your attention.
Click your workspace name, then Workspace settings, then Objects. You need admin rights.
Click + New custom object.
Enter the plural and singular nouns, like Invoices and Invoice.
Set the identifier, also called the slug. Choose carefully: it cannot be changed after creation.
Click Create object, then open the Attributes tab and add a field per data point you track.
Under the Appearance tab, set the record text so records display by name rather than ID.
Build your first view, table for structured data, kanban if the object moves through stages.
The step that pays for itself later is marking external identifiers as unique. If your invoices sync from Stripe or your billing system, a unique Invoice ID attribute lets Attio update existing records instead of creating duplicates on every sync. Pair it with required attributes, which custom objects alone support, and your data quality holds up without a cleanup ritual.
From there, records flow in however suits you: manual entry, CSV import, Attio workflows, Zapier, n8n or Make, native apps, or the API.
Custom object or list? The decision that matters
This is the fork where I see the most expensive mistakes, in both directions. Here is the rule I use with clients.
A custom object earns its place when two signals show up together. First, the entity needs several attributes that belong only to it. An invoice has a due date, an amount, and a payment status, and none of those belong on a company. Second, it needs two-way relationships to other records, because lists cannot hold relationship attributes. If a form submission must link to both a person and a company, that is a custom object talking.
If neither signal is strong, a list on an existing object nearly always wins. Lists carry their own attributes without touching the underlying records, the same record can appear in multiple lists for different teams, and non-technical teammates reason about them instantly. Lists also scale much further than their reputation suggests. Attio's own team ran customer onboarding from a list of workspace records until mid-2026, at a company of roughly 150 people. If a list carries onboarding at that scale, it will carry your pipeline reviews and outreach sprints.
Signal | Build |
|---|---|
Entity needs its own set of attributes | Custom object |
Needs two-way links to people, companies, or other objects | Custom object |
You will report on these records as their own category | Custom object |
It is a process on existing records, like onboarding or recruiting | List |
Only one team needs the extra fields | List |
Under 20 seats and unsure | List first, migrate later |
The reason "list first" is safe advice: nothing locks in. Export the list to CSV, re-import it into a custom object, rewire the workflows, done. Attio is built to be iterated on, and a model that starts small and grows with evidence beats a model that anticipates everything on day one.
Where custom objects earn their keep
Invoices and subscriptions are the cleanest case. No standard object models them, the schema is unmistakably their own, and they need relationships to companies, billing contacts, and workspaces. Add a unique ID synced from billing and Attio becomes the one place GTM sees revenue state.
Events are similar. Nothing in the standard model represents a dinner, a webinar, or a conference, and an Events object with a many-to-many relationship to People gives you attendance history on every contact record.
Partners work well as a custom object when partnerships are a real motion: partner organizations, their tiers, and relationships to the deals they source.
Deal types deserve more caution. If SMB and enterprise deals share mostly the same fields, keep one Deals object with a select attribute for the type. You keep one pipeline report and one set of workflows. Split into a separate object only when each type carries many attributes the other never uses, and accept that reporting across two objects means separate graphs.
Activities and interactions, logging every call, email, and LinkedIn touch as records, is a popular pattern for reporting, and it works. Just build it lean. Attio's native activity, call intelligence, and reporting surface more of this every quarter, and heavy machinery here risks being made redundant by the platform.
Inbound form submissions depend on volume. At high volume, a list of People with list attributes for the form fields keeps the model simple. At low volume, skip the staging area entirely and have a workflow create the person and deal directly. When the form captures a person and a company together, the custom object case gets strong, because the submission record can hold relationships to both.
How real teams model Attio
Granola, the AI notepad, runs every inbound lead through a custom Inbound Leads object. Tally form submissions pipe in through Zapier, the GTM team tiers each lead 1 to 3, and workflows promote high scorers into the Deals pipeline. Result, per Attio's published case study: lead triage 83% faster, with daily review down from 2 hours to 20 minutes.
Railway, the deployment platform, runs a usage-based motion on the standard Workspaces object, with product usage and spend data synced in, after concluding legacy CRMs could not model it. Union Square Ventures modeled funds, LPs, and commitments as custom objects and reached 90% team adoption in under three months. Different motions, same pattern: the model mirrors the business, and adoption follows.
Honest limitations
A few edges to design around. Automatic enrichment covers Companies and People only, so custom objects contain exactly what you put in them. Plan the data-in path, whether that is workflows, a rETL sync, or the API, before you build. Custom objects and custom relationship attributes require Pro, so Free and Plus teams model with standard objects and lists, which covers most early-stage setups fine. There is no formula attribute type, as covered above. And two creation-time choices are unforgiving: the identifier is permanent, and deleting a custom object permanently removes all its records and views.
None of these block a well-designed model. They reward deciding on paper before clicking, which is exactly the work that separates a workspace teams trust from one they quietly abandon. It is also most of what I do in the first week of a client engagement.
Frequently asked questions
What are objects in Attio?
Objects are data structures that define each entity type in Attio, the equivalent of tables in a spreadsheet. Attio ships five standard objects, People, Companies, Deals, Workspaces, and Users, and Pro plans can add custom objects for entities specific to your business, like invoices, events, or partners.
What are relationship attributes in Attio?
Relationship attributes link records across objects in both directions at once, like connecting an invoice to a company. Update one side and the other updates automatically. They support one-to-one, one-to-many, and many-to-many configurations, and once linked, views can display and filter by any attribute of the connected record.
What is the difference between objects and lists in Attio?
Objects define what a record is, lists define what you are doing with it. A list groups existing records for a process, like onboarding, and adds list-specific attributes without changing the underlying data. Model entities as objects, model processes as lists, and you will avoid most data model mistakes.
How many custom objects can you create in Attio?
Attio caps total objects by plan: 3 on Free, 5 on Plus, 12 on Pro, and unlimited on Enterprise, with standard objects counting toward the cap. Creating custom objects requires the Pro plan at $69 per user per month billed annually, which leaves room for seven custom objects.
Does Attio have formula attributes?
No, there is no formula attribute type yet. Calculations run through Workflows instead: a Formula block handles math on number and currency attributes, an Aggregate values block computes sums and averages across related records, and an update block writes results back to a standard attribute on the record.
What is Attio CRM?
Attio is an AI-native CRM built on the flexible data model this guide describes: objects, attributes, records, and lists. Teams like Granola and Railway run their GTM on it because the model adapts to their business. Its workflows, AI attributes, and agents operate directly on that same model.
Sparsh Gupta, Founder of Automation Jinn and an Official Attio Expert Partner, helps seed to Series B B2B teams design Attio data models, workflows, and AI agents that drive revenue. If you want your objects, relationships, and pipelines mapped right the first time, book a discovery call.
