Source: https://atomicwork.docs.pageloop.ai/product/assets-objects/custom-objects/what-are-custom-objects

# Custom Objects

Custom objects let you model the data your organization actually works with. Instead of forcing business records into tickets or maintaining spreadsheets outside the system, you define a schema and manage those records directly inside Atomicwork — with relationships to your people and assets, workflow automation, and access for AI agents.

---

## How It Works

The model has two parts:

**Object types** are the blueprints — you define the fields, layout, and identity of a category of records. A "Contract" type, a "Vendor" type, a "Client" type. You build these once in Settings.

**Records** are the instances — every Contract, Vendor, or Client your team creates. Each record gets an auto-incremented display ID based on a prefix you set on the type (`CON-1`, `VEN-42`, `CLT-7`).

---

## What You Can Do With Them

- **Capture any structured data** — text, numbers, dates, dropdowns, attachments, and relationships to people, assets, and other custom objects
- **Link records together** — a Contract can reference its Vendor; a Project can reference its Client. Relationships are live, not copied text.
- **Automate on record events** — run workflows when a record is created, when a field changes, or on a recurring schedule
- **Give your team a directory** — searchable, filterable lists with saved views for different audiences (account managers, procurement, leadership)
- **Ask Atom** — once records exist, AI agents can query and surface custom object data in conversation
- **Find records anywhere** — custom object records are indexed and searchable through Global Spotlight search
- **Reference them from assets and requests** — add a custom object as a relationship field on an asset or a request form, for example linking an application asset to its Software Contract record

---

## Key Concepts

Every custom object includes a `display_name` field. This is the label that appears whenever a record is referenced elsewhere in the platform — in a request dropdown, a relationship field, or a search result.

**Display ID prefix** — a short code you set on the object type that prefixes every record's ID. Use something recognizable: `CON` for contracts, `VEN` for vendors, `CLT` for clients.

**Scope** — Global types are available across the whole organization. Workspace types appear only in the workspaces they're tagged to, and a type tagged to several workspaces shares its schema and records across them. You can extend a workspace type to more workspaces or promote it to organization scope later, depending on your admin rights.

**Sections** — fields on a record form can be organized into named groups. Useful once a type has more than 6–8 fields.

**Draft vs. Published** — object types start as drafts. Build out the schema, then publish. Once published, records can be created and automations can run.

---

## Common use cases

- **Approval delegations** — track when employees are on leave and automatically route their pending approvals to a designated manager.
- **Software license tracking** — monitor total purchased versus utilized licenses by connecting custom objects to third-party APIs through workflows.

## Where to Go Next

- [Creating Object Types](/product/assets-objects/custom-objects/build-the-model/creating-object-types)

  Set up the name, display ID, scope, and sections for a new object type.
- [Fields & Sections](/product/assets-objects/custom-objects/build-the-model/fields-sections)

  All field types, relationship configuration, and form layout.
- [Workflows & Automations](/product/assets-objects/custom-objects/build-the-model/workflows-automations)

  Trigger automations on record creation, field changes, or a schedule.
- [Attributes vs. Custom Objects](/product/assets-objects/custom-objects/attributes-vs-custom-objects)

  When to add a field to an existing record vs. building a new type.