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