Source: https://manu-tests-all-orgs.docs-staging.pageloop.ai/product/assets-objects/custom-objects/attributes-vs-objects # Attributes vs. Custom Objects Every time you need to capture new information in Atomicwork, the question is the same: does this data belong as a field on something that already exists, or does it need to be its own thing? Getting this right keeps your data model clean. Getting it wrong means either data crammed into the wrong place, or unnecessary object types that nobody uses. --- ## Add a field to an existing record when... **It describes exactly one thing about that record — always.** If the information is a property of the record it belongs to, and there's one value per record, add a field. A user has one job title. An asset has one serial number. A ticket has one priority. These are fields. **It has no lifecycle of its own.** If the data doesn't go through states, doesn't get created and closed independently, and nobody needs to manage it in a list — it's a field, not a record type. > Adding a `cost_center` field to your user profiles is correct. Cost center is a single attribute of an employee — it doesn't have a status, it doesn't expire, and you don't manage cost centers as standalone records. If you later need a real Cost Center object that tracks budget, owners, and allocations, that's a separate decision. **It belongs on a record you already manage.** Service requests, users, and assets all have extensible field schemas. If you need to capture business unit, customer tier, or a risk classification on those records — add a field directly, rather than creating a custom object and linking back. --- ## Build a custom object type when... **One person, asset, or request can have multiple of this thing.** This is the clearest signal. Fields hold one value per record. If an employee can have three active contracts, you cannot put contract data in a field on their profile — you need a Contract object type with records that link back to the person. > An employee owns multiple contracts. A vendor has multiple contracts. A single contract has an owner, a vendor, a value, a status, and dates. None of this fits in a field — it needs its own record type. **The thing has a lifecycle and its own states.** If it gets created, changes status, expires, is renewed, or is cancelled independently of the record it's related to — it's an object, not a field. > A vendor relationship isn't a field on your procurement manager's profile. It's a Vendor record with its own status (Active, Under Review, Suspended), its own contacts, and its own contracts. It exists regardless of which employee is managing it. **Multiple records reference the same thing.** Fields belong to one record. If twenty employees reference the same vendor, and forty service requests reference the same project code — putting that data as a field means duplicating it everywhere and keeping it in sync manually. An object record gets referenced once, from many places. **You need to search it, filter it, or report on it independently.** Custom object types get their own directory — a searchable, filterable list of all records of that type. If your procurement team needs "show me all contracts expiring this quarter," or your finance team needs a vendor list sorted by contract value — you need a Vendor type and a Contract type with their own views, not data scattered across user profiles. **It needs workflow automation.** Custom objects support CREATE, UPDATE, and SCHEDULED triggers. If you need to send a renewal alert when a contract's expiry date is 30 days out, or notify the account team when a vendor's status changes — the record needs to be a custom object so it can be the subject of an automation. --- ## The borderline cases Some things genuinely could go either way. Here's how to decide: **"I want to track which team owns each vendor."** → A `team` field on the Vendor object type. It's a single value describing the vendor — not a separate Team record (unless you have other reasons to model teams as objects). **"I want to track multiple contacts at each vendor."** → A `contacts` multi-select or multi-relationship field if contacts are just names. A separate Contact object type if each contact has their own attributes (role, email, phone), history, or needs to be managed independently. **"I want to flag that an employee has signed an NDA."** → A `nda_signed` checkbox field on the user profile if you just need the flag. A separate NDA object type if you need to track NDA details (date, version, expiry, document link) per employee — since one employee can sign multiple NDAs over time. **"I want to add a renewal date to a vendor."** → A `renewal_date` field on the Vendor object. Single value, describes the vendor, no independent lifecycle. **"I want to track all past and upcoming renewals."** → A Renewal or Contract object type. Multiple per vendor, each with its own dates and status. --- ## Quick reference | Signal | Right choice | | ---------------------------------- | ------------------------ | | One value per record | Field on existing record | | Multiple per person / asset | Custom object type | | No lifecycle, no status | Field on existing record | | Gets created, changes, expires | Custom object type | | Only one record references it | Field on existing record | | Shared across many records | Custom object type | | Just need it visible in context | Field on existing record | | Needs search, filtering, list view | Custom object type | | No automation needed | Field on existing record | | Needs workflow triggers | Custom object type |