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.

Your role is the ceiling. Bucket and folder access, below, decides what you get inside it.

• •Admin — full control: deletes, credentials, roles, and billing. Bucket and folder permissions do not apply to admins; an admin can always reach every bucket in the workspace.
• •Member — day-to-day work: browse, download, upload, rename, move, run jobs. A member cannot delete anything shared — not objects, buckets, jobs or servers — and cannot manage credentials, API keys or roles. Ask an admin for those.
• •Read-only — can view everything they have been given access to, and change nothing. Every upload, edit and delete is refused, and so is connecting a computer with BucketPilot Drop.

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.

Each rule picks one of six levels — Read & write, Contribute, Read-only, Upload only, and the two blocks No changes and No access.

They are set out in full, with worked examples, on their own page: Access levels →.