Teams and Sharing
There are three ways to let someone else near a document, and they are different sizes.
| What it is | Who it suits | |
|---|---|---|
| A team | A shared account with its own subdomain and its own document library | People you work with regularly |
| A share link | A URL that opens one document, to view or to edit | Anyone, including people with no account |
| Sharing with a person | One named person gets read access to one document | Someone outside your team who needs to see one thing |
Teams
A team is an account of its own. It has its own address, acme.hyperclay.com, its own documents, its
own folders and its own trash. Nobody logs in “as” the team. You sign in as yourself and act on the
team’s account, and every save is attributed to you.
Creating a team needs an active Maker plan. Use create a team in the profile menu at the top right
of the dashboard, or go to /_/teams/new. You choose two things:
- A team name, which is what people see. You can change it whenever you like.
- A team address, which becomes the subdomain and the folder your documents live in.
The team address works like a username: changing it later breaks every existing link to the team’s documents. Pick it as carefully as you picked your own.
Team names share one namespace with usernames and claimed subdomains, so a name already in use anywhere on Hyperclay is refused.
Joining a team changes nothing about your own account. Your plan, your personal documents and your own subdomain are untouched, and you keep them if you leave.
Roles
Every member holds one of three roles.
| Owner | Editor | Viewer | |
|---|---|---|---|
| Open and download documents | yes | yes | yes |
| View version history and restore a version | yes | yes | no |
| Save changes to a document | yes | yes | no |
| Create documents and folders, upload files | yes | yes | no |
| Rename, move and trash | yes | yes | no |
| See the trash page and restore from it | yes | yes | no |
| Delete permanently and empty the trash | yes | no | no |
| Edit code | yes, if their own account is on a paid plan | yes, same condition | no |
| Team settings: privacy, signups, subdomains, custom domains, share links | yes | no | no |
| Invite people, change a role, remove a member | yes | no | no |
| Leave the team | no, transfer or delete it first | yes | yes |
Two things about that table are worth stating on their own.
Code editing follows the person, not the role. An editor on a free account can create, save, rename, move and trash a team’s documents, and gets no code editor. An editor on a paid plan gets one. The role decides what you may do to the team’s documents; your own plan decides whether the code tools are available to you at all.
Billing is never a team thing. Checkout, billing management, upgrades and changing a username all act on your own personal account. There is no team card and no per-seat charge.
What an editor is trusted with
An editor can save anything into a team document, including scripts. Every team document is served from one subdomain, which means one browser origin, so a script one editor saves runs with the same access as everything else on that subdomain.
The code editor being hidden from a free account is a convenience, not a boundary. Ordinary saving accepts a whole HTML document, so anyone who can save can change the code, whether or not the code editor is available to them in the interface.
So: invite people as editors when you trust them with the team’s documents the way you trust yourself. Invite them as viewers when you do not. There is no in-between role, on purpose.
The shared allowance
A team has no allowance of its own. It draws on the plan of the member who owns it, and that is a single pool covering the owner’s personal account and every team they own. Creating a team adds no capacity.
A teammate’s upload counts against the owner’s allowance. On the Maker plan that is 2 GB in total and 100 MB per file, shared.
The owner sees the plan on Team settings. Other members see only that it is a team; whose card is charged is not shown to them.
The one exception is when the plan lapses. Then every member is told who can fix it, because they need to know: the team becomes read-only until the owner renews, and everyone can still open and download everything.
Share links
Each document can have two links, and they are different.
- A view link opens the document, downloads it, reads its JSON, and opens its version history. On a collection dashboard it also reads the collection’s records.
- An edit link does everything a view link does, and can save.
Both work on a private document. Both are just a URL with a token in it, so anyone you send it to can use it, with no account and no sign-in.
Neither link reaches the owner’s side of the document. No settings, no privacy, no subdomains, no custom domains, no uploads, no code editor, no template reset, no managing the links themselves, and no deleting a collection record. A link grants exactly what its mode says.
An edit link lets someone change the document’s code. Saving accepts the whole HTML file, so an edit link is not limited to text and CMS fields. Send it to people you trust with the document.
Revoking a link is permanent. The link stops working straight away, any live connection it was holding is closed, and creating a link again gives you a new URL and a new QR code. The old one never comes back.
A share URL contains the document’s current address, so renaming the document, or moving it, or renaming your account invalidates the link. Create a new one after any of those.
What a link does not protect
Files stay public at their own URLs. An image or a PDF embedded in a document is served from its own address, and that address works for anyone who has it, whether or not they hold a link to the document. A private document does not make the files inside it private.
A link to a collection dashboard includes the collection’s records. Someone holding a view link can list the records and read one. They cannot delete one.
Sharing one document with a person
Enter someone’s email address on a document and they get read access to that one document. They can open it even when it is private, and view its version history. They cannot edit it.
What happens next depends on them:
- They already have a confirmed account. They get access immediately and an email with a link straight to the document.
- They have an account but have not confirmed their address. They confirm it first, then land on the document.
- They have no account. They get an invitation, good for 14 days, that creates a free account when they accept it.
An invitation can only be accepted by the address it was sent to. Signing in as somebody else and opening the link does not work.
Accepting a document share changes nothing about an existing account. It does not confirm an address, it does not alter a plan, and it grants nothing beyond that one document.
There is no editor version of this. Someone outside your team who needs to change a document either joins the team or holds an edit link.
Shared with me
Documents other people have shared with you by name appear in a Shared with me section on your personal dashboard, under your own documents. Each row shows the document, who owns it, and buttons to Open or to Leave.
The section is not shown at all when nobody has shared anything with you, and it does not appear on a team dashboard or inside a folder.
A share on a document inside somebody’s folder does not reveal the folder. You see the document and nothing around it.
Who else is on the document
When more than one person has the same document open you see them, as a small stack of initials in the corner. Hovering shows a name. Solid means they can edit, hollow means they are reading.
Names are shown to people who can already see the document. Someone reading a public page with no access of their own sees a count and no names. A view link holder can see the document, so they do see names, and they appear to everyone else as “Guest 1”, “Guest 2” and so on. A save made through an edit link shows as “Edit link”.
The count of anonymous readers counts connections, not people. One person with three tabs open is three connections.
You also get a one-line notice when somebody else changes the part of the page you were working in. Dismiss it and carry on.
This is not simultaneous editing. There are no live cursors and no selections. Two people editing different parts of a page merge cleanly, as they always have; two people editing the same paragraph is still last save wins. Presence makes that visible instead of leaving it hidden.
Version history
Version history says “Recorded by”, not “Saved by”, and the difference is real.
Some versions capture what the document looked like before an action, and the name on them is whoever caused the version to be taken, not whoever wrote those bytes. A first-save safety backup and a restore backup are both like this.
Saves made through the desktop app do not create a version at all, so there is no “API” or “Desktop” label to look for.
The name shown is the person’s current display name, so renaming yourself renames you throughout the history.
Moving a document into a team
Moving a folder carries everything under it: the documents, the folder structure, the files uploaded into it, and anything in the trash below it.
Moving a single document carries only the document and its versions. Files it uses stay on your personal account and keep working at the URLs they already have.
Because a file’s URL contains the account it belongs to, moving a folder changes the address of every file inside it. Hyperclay rewrites those addresses inside the documents it moved, and records the rewrite as a version with a note saying how many links it updated.
Before the move it shows you what it cannot fix: any document outside the folder that used one of those files, and will therefore break. It names the ones you are allowed to see and says generically that others may be affected.
Three kinds of reference cannot be found by any scan, and the move does not claim otherwise:
- a URL the page’s own JavaScript builds at run time
- a reference inside an uploaded stylesheet
- a reference that exists only in an older version of a document
Some documents cannot move at all until you clear the thing holding them: a claimed subdomain, or signups. Remove those first.
Moving needs the settings permission on the source and the create permission on the destination, so a team editor cannot move a team’s folder out into their personal account.
When a plan ends
Nothing is deleted and nothing is hidden. Every file, folder, upload, version, custom domain, share link and team membership stays exactly where it was.
What a free account can still do:
- open and download every document it owns, private ones included
- save changes to a document
- upload files, up to 100 MB in total and 10 MB per file
- duplicate a document
- rename and delete a document
- rename, serve and delete an upload
- use the trash: restore, purge, empty
- list, view and restore versions
- manage the records in a collection it already has
- keep every custom domain resolving
- see billing history and upgrade
What comes with a subscription:
- creating a blank document
- creating, renaming, moving and deleting folders
- the code editor, Add CMS and Make Malleable
- applying a template
- signups, collection mode, discoverability, making a document private, claimed subdomains
- creating share links
- configuring a custom domain
- changing your username
- generating a desktop sync key
- creating and owning a team
Tidying up is always allowed. A free account can remove a custom domain, revoke a share link, turn signups off, make a document private, make one public again, move things around, and delete a folder. You are never locked out of cleaning up after yourself.
A refusal that a subscription would lift says so, and paying reopens it immediately.
On a team, and in the desktop app
A team whose owner’s plan lapses becomes read-only. Everyone can open and download everything; nobody can save, create or upload until the owner renews.
The desktop app tells you. When a plan has ended, syncing a change says so plainly rather than retrying. Reading, exporting and deleting keep working.
When an account or a team is deleted
Deleting stops access straight away: from the moment you confirm, every address that resolves the account refuses. Moving the files off the live tree takes a few seconds more.
One thing can still be served during those seconds: a stylesheet that had already been generated and written to disk. Nothing else.
A deleted team keeps counting against the owner’s allowance for the whole restore window. The space comes back at the end of it, not before.
Some smaller changes worth knowing
- A share link’s cookie is named after the document now, rather than after its name. Two documents with the same name on one subdomain used to share a single slot; they no longer do. An existing link keeps working and upgrades itself the first time you open it.
- Some actions that used to work as a plain link now need a form submission, including creating a folder, the privacy and signup toggles, claiming a subdomain, getting or revoking a share link, adding a domain and changing a username. A bookmark or a script that fetched one of those URLs gets a 405 rather than quietly changing something.
- A version’s link now carries the document it belongs to, so a version URL is unambiguous about which document it came from.
- A document’s JSON no longer includes its share URL. A link’s token is handed out only where the owner asked for it.