How collections power a site
Your site sees your collections through a permission grid you control: for each collection you decide whether the site may read, write, or delete. Nothing is granted by default. Beyond that, an entry's published status decides what is publicly visible — so the grid says which collections, and status says which entries.
Requirements: a role that can manage website connections.
A connected site does not get your business wholesale. It gets exactly what you grant it, collection by collection — and within those collections, only the entries you have published. Understanding those two layers is what makes running a public site on your live records safe rather than nerve-wracking.
Layer one: which collections, and what the site may do
Every collection in your business appears in a permission grid for the site, with three separate switches: read, write, and delete. They are independent, and they all start off. A typical catalog site ends up with something like this:
- Products — read only. The site shows them; it must never change them.
- Leads — write only. The contact form creates entries; the site has no business reading everyone else's leads back.
- Bookings — read and write. It needs to see availability and create a reservation.
- Everything else — nothing. Deals, internal notes, staff records: not granted, not reachable.
That write-only pattern for leads is worth copying. A form only needs to submit; granting read as well would let anyone who obtained the site's credentials pull your entire lead list. Grant the narrowest thing that works.
Layer two: which entries are public
Granting read on a collection does not expose everything in it. Each entry carries a status, and only published entries are meant for the public. So you can draft a product with its photos and copy, leave it unpublished, and the site simply does not show it — until you publish, at which point it appears without any deployment or rebuild on your side.
Put the two layers together and the model is: the grid decides which collections the site can touch, status decides which entries it can see.
Changing permissions logs the site out
One practical thing to know before you touch the grid: changing a site's permissions revokes its existing access. The site must authenticate again with its credentials before it can read or write anything. For most setups that reconnection is automatic and momentary, but it is not nothing — adjust permissions deliberately rather than experimenting on a live storefront at peak hours.
Notes and limitations
- Nothing is granted by default. A newly connected site can reach no collection until you switch something on.
- Read, write, and delete are separate — granting write does not grant read, and delete is its own decision. Think hard before granting delete to a public site at all.
- New collections are not granted automatically. Add a collection later and the site cannot see it until you grant it — a common cause of "my new section is empty".
- Changing permissions revokes existing access and forces the site to reconnect.
- Status gates entries, permissions gate collections — if something is missing from the site, check both.
Related
The wider picture of Sonta behind your own site is in using Sonta as your site's backend. If something published is still not appearing, work through my entry does not appear on the site.