Skip to main content
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 Settings → Custom objects. Records appear on each account’s Records tab, and each one opens on its own page.
Settings → Custom objects: a table of custom objects with their fields, record counts and who can add records, and the New custom object button

Defining one

New custom object opens a builder: give it a name — Deal, Escalation — choose who can add records, then add fields. Each field has a label and a type: text, number, date, true/false, a dropdown, a URL, an email address, an account, or a file. A dropdown asks for its options in the builder, and those are what you pick from when adding a record. A dropdown with no options can’t be added — it would be a field nobody could fill in. Removing a field asks first, and says what happens: values already saved under it stay in the database but stop showing on records. Every custom object starts with an Account field already on it, listed as Built in. That’s the link between a record and the accounts it belongs to, so it’s always there and can’t be removed. An account-typed field is a different thing: a record pointing at some other account. A reseller on a contract, or the partner who opened an escalation. You pick it by name and it’s stored as a reference, so segments can ask about it and the account’s name stays right if it changes. A file field holds one uploaded file: the signed order form on a contract, the incident report on an escalation. When adding or editing a record, click Choose a file to upload one, or Replace to swap it. The file is uploaded as soon as you choose it, and the record keeps it once you save. Click the file’s name on a record to open it. File fields take the same file types and 10 MB limit as account files. They aren’t offered in segment conditions, because a file has no value to compare.
Account and file fields are for custom objects. Custom traits don’t offer either type. A trait already belongs to an account, so an account-valued trait would be a different feature.
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: 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 choose the Records tab. Each custom object gets its own group, listing the records attached to that account with their first few field values.
An account's Records tab, with a group for each custom object listing the account's records and their first few field values
Click a record to open it on its own page. It shows the record’s name, every field, and the accounts it’s attached to. If you’re allowed to add records of that object, you can Edit or Archive it there. A record filled by an integration shows a note saying it can’t be edited in Zudo.
A custom object record on its own page, with its name, every field, the accounts it's attached to, and Edit and Archive buttons
Records attach to accounts, and a parent account 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. Adding a record fills its Accounts in with the account you’re on, and you can add more before saving. The account you started from stays on the record. One contract covering two subsidiaries is a single record showing on both, rather than two records with nothing tying them together. Underneath, Referenced by lists records that live on other accounts and point at this one through an account field — the escalations where this account is the partner, the contracts where it’s the reseller. Each one names the account it belongs to, so you can go there. It only appears when there’s something to show, and you can’t edit those records from here: they belong to the other 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.
  • Archiving a record, from its own page, removes it from accounts and segments 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.

Defining one with the Assistant

An admin can ask the Assistant for a custom object in their own words, such as “track renewals per account: the date, the amount, and a stage of open, won or lost.” The review card lists the object, who can add records and each field with its type and choices. Applying it creates them as if you’d made them here. It can also rename an object or a field, change who adds records, switch an object off, add fields, or add choices to a dropdown. It won’t take away a choice that records have picked, and like this screen it can’t change a field’s type. It can’t delete anything.

Using records in a segment

Records are not only something to read on an account. Each custom object appears in the segment rule builder, so the rest of Zudo can act on it:
  • Number of records — “has an open escalation”, “has had more than three this quarter”
  • A field on the latest record — “their newest contract expires within 30 days”
Because flag rules and playbook triggers are built on segments, the same conditions work there: a risk flag on every account with an open escalation, or a playbook that fires when a contract is about to run out. Archived records are ignored. Latest means the record with the newest date on it, not the one entered most recently.

Over the API and MCP

Custom objects are readable and writable over the API and from MCP. 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. An account field takes an account id. A file field takes the id of a file already uploaded to Zudo by your organization, such as one attached to an account. The API can list an account’s files but can’t upload new ones, so upload the file in the app first. A file from another organization, or an id that doesn’t exist, refuses the whole request rather than saving the rest.

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.