Custom Objects

Define structured record types for any business data and manage them natively inside Atomicwork.

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

Key Concepts

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 are scoped to one team's service desk. Set at creation time; can't be changed.

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.

Where to Go Next

Creating Object Types

Set up the name, display ID, scope, and sections for a new object type.

Fields & Sections

All field types, relationship configuration, and form layout.

Workflows & Automations

Trigger automations on record creation, field changes, or a schedule.

Attributes vs. Custom Objects

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

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.

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

Key Concepts

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 are scoped to one team's service desk. Set at creation time; can't be changed.

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.