> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zudo.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Custom objects

> Define record types of your own — deals, escalations, contracts — and attach records to accounts.

Zudo has fixed record types: requests, issues, meetings, tasks. A **custom object** is a record type you define for the things your business tracks that those don't cover — a deal, an escalation, a signed contract, a security review.

Define them under **Custom objects** in the sidebar. Records appear on each account, under **Records**.

## Defining one

Give it a name — *Deal*, *Escalation* — then add fields. Each field has a label and a type: text, number, date, true/false, a dropdown, a URL or an email address. They're the same types [custom traits](/settings/organization) use.

Field names are worked out from their labels, so **Deal Value** and **Deal-Value** are the same field. That's deliberate: two fields whose names differ only by punctuation would quietly overwrite each other.

## Who can add records

Each custom object decides this for itself:

| Setting                      | Who can add, change and remove records |
| ---------------------------- | -------------------------------------- |
| **Admins can add records**   | Admins and owners                      |
| **Anyone can add records**   | Everyone in your organization          |
| **Filled by an integration** | Nobody in Zudo                         |

The last one is for objects kept in step with another system. Editing those by hand would look like it worked and then be overwritten on the next sync, so it's not offered at all — not even to admins.

## Records on an account

Open any account and find **Records**. Each custom object gets its own group, showing the records attached to that account and their field values.

Records attach to accounts, and a [parent account](/accounts/parent-accounts) is just an account — so a contract covering a whole customer attaches to the parent, and one covering a single product attaches to that account.

## Changing a custom object after records exist

* **Removing a field** stops it showing. Values already saved under it are kept rather than erased — records that were right when they were made stay right.
* **Removing a record** archives it rather than deleting it, so something a colleague acted on doesn't disappear from the history.
* **Renaming** a custom object changes what you see. Its underlying name stays fixed, because that's what an integration syncs against.

## Over the API and MCP

Custom objects are readable and writable over the [API](https://zudo.so/api/v1/docs) and from MCP.

| Tool                          | What it does                                              |
| ----------------------------- | --------------------------------------------------------- |
| `list_custom_object_types`    | Your custom objects and their fields                      |
| `list_custom_object_records`  | Records of one object, filtered by account or external id |
| `get_custom_object_record`    | One record                                                |
| `create_custom_object_record` | Add a record, or update one a sync already wrote          |
| `update_custom_object_record` | Change a record, or archive and restore it                |

Read the fields first. A record's values are keyed by field name, and a value sent under a name matching no field is dropped rather than stored.

### Keeping an object in step with another system

A record can carry a **source** naming the system it came from and an **external id** — the id it has there. Sending both again updates that record instead of adding a second one, so a sync that re-runs over the same rows is harmless.

This is what **Filled by an integration** is for. That setting stops records being edited by hand in Zudo; it does not stop the API, because the API is how such an object gets filled at all.

Updates are partial. Fields you send change, fields you leave out stay as they were, and accounts you send replace the record's account links outright.

## What's not here yet

Built-in syncing from Salesforce, HubSpot, Jira or a data warehouse. Records reach Zudo through the app or the API for now.