There are four ways to let someone else see your work, from inviting a colleague into the workspace to publishing a public site. Each is a separate opt-in, and none is on by default.
Invite people to a workspace
Workspace settings → Members invites by email. Each member has a role:
- Owner — everything, including deleting the workspace, backup destinations and billing.
- Editor — create, edit and delete content; manage members and invites; rename the workspace.
- Viewer — read-only.
A workspace you create gets a readable address taken from its name — a workspace called “Family Recipes” lives at /w/family-recipes, and every page inside it sits under that. You can change the address under Workspace settings → Workspace URL. Renaming the workspace leaves its address alone, so links you have already sent keep working; changing the address itself breaks them. (The workspace your account starts with lives at the root and has no address to choose.)
Each workspace also has a color and a mark — a small abstract shape — so you can tell at a glance which one you are in. One is picked for you; change it under Workspace settings → Appearance. Once you belong to more than one workspace, the mark shows in the workspace switcher, and on a phone it sits in the title bar next to the workspace’s name — tap it to switch without opening the menu.
There is no cap on how many people you can invite, on any plan. Gating who can work with you behind a headcount is the kind of friction Simplist deliberately avoids — the Free plan limits content instead.
Moving something into a workspace you share
A workspace is what you share — everything in it, with everyone in it. So to start working with someone on something that already exists, move it into a workspace you share with them: open the model, then Model actions → Move to workspace…. The option appears once you own more than one workspace, and only the workspace’s owner sees it.
What moves is the model and everything connected to it — models it links to through relation fields (in either direction), and its child models — because a relation can’t point from one workspace into another. The dialog lists exactly what will travel before anything happens. Records keep their ids, so their history, share links and any API references carry on working. Files attached to the moving records go with them.
Some things stay, because they belong to the workspace rather than the model: feeds (they simply stop including what moved), webhooks and API keys. A connector that files into a moving model goes with it.
Two things will stop a move, and the dialog tells you which: a file that is also attached to a record that isn’t moving (a file lives in one workspace — detach it from one side first), and a media-library field that links files to the model (remove the field first).
People in the old workspace who aren’t members of the new one lose access to what moved. You can move it back the same way.
Share a single document
From a document you can either:
- mint a secret link — an unlisted URL that anyone holding it can read, without an account; or
- grant a specific Simplist user read access — they see it under Shared with me.
Both live in the document’s Share dialog, under Secret link and Share with a person, and both are revocable at any time from the same place.
Notifications
Sharing a document with a person tells them in two ways: an email with a link to it, and an entry under the bell in the app’s action row (next to Search). The bell shows a red count of unread notifications; open it to see who shared what, and click an entry to open the document and mark it read. Mark all read clears the count at once.
Notifications follow you across workspaces, because a share can come from a workspace you are not a member of. Sharing is the only thing that sends one today: secret links notify nobody, and edits to a shared document do not notify anyone either. There are no notification settings, so the share email always goes out.
If a share is revoked, or the document is deleted, the notification stays in the list but its link no longer opens the document.
Publish a model’s documents
Any model can be published as anonymous, read-only web pages: a paginated listing plus one page per document. Turn it on with the Public checkbox under Model actions → Edit model, then save; the dialog shows a copyable link.
Published pages need no JavaScript and no account. Two details worth knowing:
- Relations pointing at models that are not published are hidden, so publishing one model never leaks another.
- The address contains a short permanent id with a decorative slug, so renaming the model or a document never breaks an existing link.
What visitors see, what stays hidden and how to unpublish are covered in Public model pages.
Collect submissions with a public form
A model can also expose a public form whose submissions become documents — lead capture, signups, requests. Enable it with the Public form checkbox under Model actions → Edit model; this is a separate opt-in from publishing the model, so you can accept submissions without publishing anything.
The form renders one input per simple field — text, long text, URL, email, phone, number, date, select, checkbox and switch. File, relation, rich document and multi-select fields are skipped.
Submissions are attributed to the workspace owner and count against the workspace’s document limit, so a form stops accepting once you hit your plan’s cap. The endpoint is rate-limited to curb spam.
Publish a site
For something closer to a website, a workspace can publish a hierarchy of pages — nested pages, each built from content blocks. Manage them under Sites.
Two block types exist today:
- Rich text — the same editor as a Rich document field.
- Document list — embeds a feed, so the block shows a live, filtered, cross-model list of documents that stays current as records change.
Publishing is two switches, and both must be on for a page to be reachable: the site must be published, and the page must be published. That lets you finish and publish a page while the site as a whole stays in draft.
A document list block also re-checks that every model it draws from is itself published before rendering. A model you have not published is silently dropped from the block rather than leaked, and the block disappears entirely if none of its models are public.