Teams & workspaces

Business plans can create an organization — a shared workspace with unlimited members. Data is fully isolated per workspace: your personal account and each organization are separate, and nothing moves between them automatically.

Team features are active for everyone in an org only while the org owner has Business access. Admins send invitations by email from the Team page.

Members can opt in to the organization's Monday digest email from Settings → Email Notifications ("Team digest", off by default) — it sends only while the organization is on Business.

• •Admin — full control, including deletes and credentials.
• •Member — day-to-day work; no deletes of shared credentials, no role management.
• •Read-only — can view everything, change nothing.

On top of roles, access is granted per bucket and per folder, to a person or to a group, as an allow or a deny — and a deny always wins.

A bucket is open to the whole workspace by default; marking it restricted means only the people and groups you name can see it at all. Inside a bucket, a folder grant narrows that further: read on reports/, write on reports/incoming/, and nothing anywhere else.

Grants apply to folders, not to individual files — deliberately. A folder is a key prefix, which is the only grouping S3 actually has, and one grant covers everything under it however much that grows. A grant naming a single object would stop applying the moment the object is re-uploaded under a new name, renamed or moved, and a permission that silently stops applying is worse than one that was never made. If a file needs its own rule, put it in a folder of its own and grant that — the rule then survives every later change to the file.

Naming a file where a folder is expected is refused rather than quietly accepted, because a grant that matches nothing looks exactly like one that works.