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 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:
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 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 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.