One record, edited in place

Not everything is a list. A homepage has one record. So does an about page, a set of global site settings, or the block of contact details that appears in every footer. Modelling those as an ordinary collection leaves an editor staring at a list with a single row in it, and leaves you guessing at the object's id when you write the template. A singleton collection removes both problems.

Set singleton to true on the collection — in the admin's collection settings, or directly in its .meta.json file — and its behaviour changes. Clicking the collection in the collection view or in QuickNav opens its one object directly, with no one-row list in the way. The Add new button is hidden, because a singleton cannot gain a second object. An empty singleton opens the new-object form, and once that is saved the same object is reused on every visit.

The part that matters to a template author is the id. A singleton's object id is always forced to the collection id, so the record in a collection called seo-site is the object seo-site, and its edit URL is a clean /collections/{collection}/{collection}. There is nothing to look up and nothing to remember.

Converting an existing collection is non-destructive. Flip singleton on and, if the collection already holds more than one object, singleton behaviour stays dormant — the normal list is shown with a notice — until you delete it down to one. Nothing is removed for you. With exactly one object left, that object is adopted and re-keyed to the collection id.

A typical shape: a site-settings singleton holding the phone number, address, social links and default share image, next to a homepage singleton holding the hero headline and the featured post. Both sit in the sidebar beside the blog and gallery collections, both open straight into a form, and both read from a template by name. The client never has to work out which of the two records in a list is the live one, because there is only ever one.