Adding and managing records

Getting records into an object, keeping them current, and the question of what owns the data. Put an external id in the first import; later updates need it.

Getting records into an object, keeping them current, and the question of what owns the data. Put an external id in the first import; later updates need it.

Three ways in

• By hand, from the records page. Fine for a few dozen.
• Bulk import, from a file. The route for an existing list.
• Through the API, from the system that owns the data. The route for anything that changes.

Add one by hand

1. In Support, click Custom objects in the sidebar and select the object.
2. Add the record and fill in the fields.
3. Click Save.

Changing one afterwards works the same way: click the record's name, click Edit, change the values, Save. Deleting is on the same screen, and up to a hundred records can be selected with the checkboxes and removed together.

Import a list

1. In Admin Center, click Objects and rules and select Tools > Data importer. Click Import.
2. Under Import type, choose Create only, Update only or Create and update.
3. Pick the object under Target destination and upload the CSV under File upload.
4. Click Next, check the field mapping, Next again, and Start import.

The file has to be UTF-8, with a header row containing name. Put an external_id in it even on the first import: it is what a later update matches on, and without it every subsequent import creates duplicates rather than updating what is there.

The question that decides everything

What owns this data? If contracts live in your finance system, Zendesk holds a copy, and a copy goes stale unless something keeps it in step.

• Zendesk owns it: maintain it here, and make sure someone is responsible.
• Another system owns it: keep it in step automatically and treat the Zendesk copy as read-only for agents. Zendesk has a built-in data sync for this on Suite Growth and above, one-way with the other system as the source; at present it connects to Salesforce only, so for anything else the route is still the API.

The failure mode is the middle ground: a copy imported once, edited occasionally by agents, and diverging from the source. Everyone stops trusting it within a year.

Keeping it usable

Records for things that ended should be marked as such rather than deleted, so historical tickets still make sense. A status field on the object handles that, and it needs deciding at design time rather than after.

See also

• Bulk importing custom object records
• The custom object records page
• Creating a custom object