Model the record types your business actually runs on.
Define your own object types — policies, applications, events, grants, whatever your business tracks — with typed fields, then get a full create/read/update/delete UI and API for free.
The built-in CRM entities (contacts, leads, opportunities, accounts, tasks) don't fit every business. Custom objects let a tenant define first-class record types of their own, each with a set of typed fields, and immediately get list, detail, create, edit and delete for records of that type — in the UI and over the API — without any code or schema migration. It's what lets an insurer model policies, a school model applications, or a church model events natively inside the same CRM.
Define an object type
A manager (or above) defines a type with a key, a singular and plural label, an optional icon, and a list of fields. Each field has a key, a label, a type, and whether it's required.
- Field types are validated server-side against a fixed set of supported types (text, number, date, select, and more)
- Select fields carry their own list of allowed options
- Type keys are normalized (lowercased, spaces to underscores) and must be unique per tenant
- Updating a type's fields is a manage-level action — the field list can evolve without losing existing records
Records, generated forms and tables
Once a type exists, its records page renders a create form and a data table generated directly from the type's field definitions — add a field to the type and it shows up as a column and a form input automatically, no front-end changes required.
- Records carry a name plus a flexible data payload keyed by field key
- Records can optionally link to a contact_id and/or account_id, tying custom data back to the core CRM graph
- Every record is owned by the user who created it
Full CRUD, front to back
Custom objects aren't a read-only add-on: types and records both support create, read, update and delete, each producing an audit-log entry (object_type.created/updated/deleted, object.<key>.created/updated/deleted) so changes are traceable per tenant.
Validated data, paginated records
Record payloads are validated against the type's field definitions on every write — required fields are enforced on create, and updates are merged against the existing payload rather than replacing it wholesale. Record listings are paginated (default 50, up to 200 per page) with total-count and has-more response headers.
- An insurance agency tracking Policies with premium, carrier, and renewal-date fields
- A school tracking Applications with program, decision status, and interview-date fields
- A nonprofit tracking Grants or Events distinct from its donor/contact records
- Any team that has outgrown a spreadsheet for a record type the core CRM doesn't model
Custom objects — common questions
No — defining a type (its label, icon and fields) is a manager-level action in the product, not a code change or database migration.
Text, number, date and select (with a defined option list) are supported today; the field type is validated against the platform's allowed set whenever a type is created or updated.
Yes — every record can optionally reference a contact_id and/or account_id, so custom data stays connected to the people and companies you already track.
Existing records keep their stored data payload; the UI's generated form and table reflect the current field list, and updates merge new values into each record's existing data.
It's part of the Pro and Enterprise plans. It's accessible through the same /v1/objects API used by the UI, so it's automatable and reportable alongside built-in entities.