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.