A custom object is a record type your organization defines for itself, such as "Film", "Education History", or "License Registration". It has its own fields, and each entry you add becomes one row. Those rows appear in a table on another record, such as a contact's list of films.
Why Custom Objects Exist
Rhythm's built-in records, such as contacts, organizations, memberships, and registrations, already include standard fields. When you need to track one more fact on a record, add a custom field. A custom field stores one value per record, such as a contact's "chapter region" or a registration's "meal choice".
Some information works better as a list than as a single field. A contact may have several degrees, and each degree needs a school, degree name, and year. An event registration may include several guests, and each guest needs a name and meal choice. You could create fields like "School 1", "School 2", and "School 3", but that becomes hard to read and runs out quickly. A custom object gives you the structure once: define one row with school, degree, and year, then add as many rows as each record needs.
| Use this | When |
|---|---|
| A custom field | You need one fact per record, such as one date, choice, or number. |
| A custom object and a table field | You need a list of entries per record, and each entry has several facts of its own. |
When a record has several related entries that each need their own status, show that status as a column in the custom object's table. For example, if a contact can have more than one license, and each license can be active, expired, or pending, the status belongs on each license row instead of in one summary field on the contact.
Where the Rows Live
A custom object is the definition. It has a singular name, a plural name, fields, and settings for how rows appear and sort, but it does not store the rows itself.
Rows live inside the records that hold them. To place a custom object on a record type, add a custom field of the Table/List type to that record type, then choose the custom object as its template. The field's type description reads "A list of custom objects that users can add, edit, and remove." Each contact, or other parent record, then carries its own rows in that field. Rhythm reads and saves those rows together with their parent record.
flowchart LR
A["Custom object: Education History<br/>fields: School, Degree, Year"] -->|template for| B["Table/List custom field<br/>on contacts"]
B --> C["Each contact's own rows"]
This setup has a few practical effects:
- You see and edit a person's rows on that person's record, not in a separate list of all rows.
- If any table field still uses a custom object, you can't delete that object. Remove the table field, or point it to a different custom object first.
- When you delete a custom object, rows already saved on records remain, and the object's own field definitions remain too.
- The Table/List type appears in the field type list only when custom objects are switched on for your organization.
A field on a custom object can also be a Table/List field that names another custom object, so one row can include its own table.
How It Relates to Fields, Layouts, and Forms
You manage a custom object from its home page in the Console. Go to System & Security › Custom Objects, then select the object's name. That page has three tabs:
- Custom Fields: the object's fields, which act as the columns for each row. They are ordinary custom fields and offer the same field types as custom fields elsewhere.
- Layouts: page layouts decide how a single row looks when someone opens, adds, or edits it. You build a layout with the same designer as a web form, in a restricted mode. When setup is complete, one layout is the default.
- Calculated Fields: rules that fill in field values when a row is saved.
Two more settings control lists of rows:
- Table Fields pick which of the object's fields appear as columns, and what heading each column uses, when rows appear in a table. A table component on a page layout can name its own columns instead.
- Sorting keeps rows in a chosen order. Rhythm applies that order each time a parent record is saved, so rows saved before you turned sorting on stay in their old order until their parent record is saved again.
Portals can display a custom object's rows. Portal members can read the object's definition so the portal can display those rows, but they can't list, change, or delete custom objects.
Tip
If a field has a value but does not appear when you open a row, check that the field is on the object's default page layout. A row's page shows the fields placed on the layout, not every field that has a value.
If the window for adding a new row opens with nothing to fill in, even though editing an existing row still shows its fields, check that the object still has usable custom field definitions. A missing or incomplete field definition can leave the add-row window empty while editing an existing row keeps working.
Rules and Limits
- A custom object needs both a name and a plural name.
- Its identifier uses lower-case letters, digits, hyphens, and underscores, and you can't change the identifier after you save it.
- You can't deactivate a custom object. Every object in the list shows Active. To stop using one, remove the table fields that use it, then delete it.
- The object's page shows a warning when setup is incomplete: it has layouts but no default layout, or fields but no Table Fields. The warning does not stop you from saving or using an incomplete object; it only notes that page layouts need table fields to work correctly.
- Rhythm sets up new custom objects for you, so your Console does not offer a button to create one. Plan the fields you need and send them to Rhythm Support.
- Custom object fields are not available in the merge field generator used to build customization configuration emails.
What Turning On Querying Does
Because rows live inside their parent records, Rhythm normally reads them only as part of each parent. Without querying turned on, you can still see and edit an object's rows one record at a time, but you cannot pull them into a query or export them as a connected table.
Where querying for custom objects is available to your organization, the custom object form shows a Support for Querying switch described as "Allow this custom object to be queryable". Turning it on tells Rhythm to build a separate table that holds a copy of the object's rows so they can be queried. When a parent record with rows is saved, Rhythm copies its rows to that table.
Keep these points in mind:
- Once querying is on and saved, the table's name can't be changed.
- The object's home page shows Querying: as Enabled or Disabled. That status reflects the switch, not whether the table has finished building. Turning querying on starts setup behind the scenes that can take some time, so the object may not appear among the query options until that setup finishes. The same delay can happen after you turn querying off and back on again.
- Rows that reach a parent record outside the normal save path, such as through a data import, may not be copied into the queryable table until that parent record is saved again. If rows you can see on a record are missing from query results, contact Rhythm Support about backfilling them.
- A query on a queryable custom object can include fields from the object itself and from the parent record that owns it. A field becomes available to choose in the query only after at least one copied row has a value for it. Add fields a few at a time as a good habit, because selecting a large number of fields at once has occasionally produced an unexplained error. Earlier, selecting a field with no value yet, or certain parent-record fields, could fail the query with a database error; Rhythm now returns a blank value for it instead.
- Deleting a queryable custom object also removes its queryable table.
An Example
Your association wants to record each contact's employment history. A custom field does not work here because one person has several jobs, and each job has several facts.
To track that history, the association gets a custom object named "Employment", with the plural "Employment History". Its fields are Employer, Job Title, Start Date, and End Date. Employer, Job Title, and Start Date are its Table Fields. Sorting is on by Start Date, descending, and one page layout is the default. On contacts, a Table/List custom field named "Employment History" uses the Employment object as its template.
Each contact now has an Employment History table. Staff add rows, the table shows the three chosen columns with the most recent job first, and opening a row shows the default layout.
Related Articles
- Custom Objects: every setting on the custom object screens, and why a delete can be refused.
- Page Layouts Explained: how layouts arrange a row's fields.
- Custom Field Types: the field types, including Table/List.
- Data Dictionary and Record Relationships: how records relate to each other.