Workspaces and members

A video belongs to the workspace it was made in. Your name is on it as the author; the workspace is what decides who can see it.

Everybody has a personal workspace, created the first time they write something rather than at sign-up. It is private because you are its only member, and nobody can remove you from it — which is why your own videos survive being removed from a team.

Making a shared workspace

Create one from the workspace switcher, invite people by email, and everything made in it is visible to every member. There is no per-video permission toggle and there will not be one: a Demofy job is a demo of a URL — work product, not a personal screen recording — so the model is a shared drive rather than a personal library with sharing bolted on.

Privacy is therefore one concept: which workspace you are in when you press the button. The switcher is where you choose, and you choose before you create rather than afterwards.

Guests cannot create a shared workspace. A workspace others join cannot hang off an account whose only credential is one browser cookie — that is a durability rule, not a feature wall.

Invitations

An invitation is addressed, not bearer. It names an email address, and only a session on that address can redeem it — so the link is safe to paste into a shared channel, because it names an invitation without carrying the authority to accept it.

The invite page always ends in something you can do:

If email is configured for the deployment, an invitation is also mailed. The copyable link is the guaranteed delivery either way, and the panel's wording follows what is actually configured rather than promising mail it cannot send.

Roles

The line is drawn between organising and spending or restyling. A project changes where a colleague's video is found; a brand colour changes what every colleague's video looks like, and a subscription is a spending decision. A member who cannot buy is never a dead end: they are told who to ask, and offered their own personal workspace, where they are the owner by construction.

Access is membership, at read time

There is no standing exemption for the person who made a video. If the author kept access to work in a workspace they had been removed from, "remove member" would revoke nothing — which is the entire point of the button.

The corollary matters for how you plan a team: being in the workspace today is what decides what you see today, and it is checked when you look rather than when your session was issued. Somebody removed this morning loses access this morning, whatever their browser still has stored.

Derived videos follow the source

A re-render, a refresh or an edit lands in the source's workspace, not in whichever one you are currently looking at. A re-shoot appearing in your personal workspace while the demo it replaces sits in the team's is the failure that rule prevents.

Two consequences follow, and both are intended:

• A member of a Pro team can re-render the team's Ultra demo though they never paid personally.
• A personally-Pro member cannot re-shoot a free workspace's demo at Ultra by switching workspaces first.

Projects

Inside a workspace, videos are filed on projects — named shelves with an optional logo. Up to 50 per workspace.

A project is a label and nothing in the pipeline reads it: filing a video changes where it is found, never what it is. Any member may organise at any role, deleting a project never deletes videos (everything on the shelf becomes unfiled), and a derived job inherits the shelf.