Seats and access: who can do what, and what they can see

Admin

Admins run the workspace. They are the only people who can create events, load the sample events, invite and remove people, and rename the workspace. The person who creates the workspace is its first admin.

Editor

Editors build the show. They edit event details, build and rearrange the run of show, manage speakers, shape the guest agenda, and generate and apply FlowGenius drafts. The one thing they can’t do is create a new event. An admin sets the event up and editors take it from there.

Viewer

Viewer is read only. Viewers open the events they’ve been given, read the full run of show, and download the crew PDF. They can’t change a block, edit a detail, or run FlowGenius.

Speaker, and AV / production

These are the two seats named for people who don’t work for you, and here is the honest state of both: today each one is a Viewer seat with a label on it. The focused speaker view and the focused production view are being built during the beta. Until they land, somebody on a Speaker or AV seat sees exactly what a Viewer sees. The label is there so those views know who to show themselves to when they ship.

One thing that catches people out: the Speaker seat is a login for a person, and the speaker roster on an event is the list of who is on stage. They are separate. Adding somebody to your roster does not give them an account, and giving somebody a Speaker seat does not put them on the roster.

Which events they can open

The default is one event. You pick which one on the invite form, and that event is the only thing they can open. Everything else in the workspace stays shut: your other events, their run of shows, their exports, and the team list with everyone’s email in it. That is the setting for an AV vendor or a speaker who is here for one show, and it is what happens if you don’t think about it.

You can also give someone every event in the workspace, which keeps applying to events you create later. That is a deliberate second choice on the same form. Admins are the exception and there is no control for it: an admin always sees every event, because a workspace you can only partly see is not a workspace you can administer.

Both answers are changeable afterward from Settings, and that is also where you give one person several specific events rather than one or all of them. The invite form itself grants exactly one.

What a read-only seat can still see

Read-only is about editing, not about secrecy, and the difference matters when the person is a contractor. For any event they have been given, a Viewer, Speaker, or AV seat can download the crew PDF, and the crew PDF is the internal document. It carries every block including the crew-only ones, your notes to the booth, energy levels, and VIP flags. If that is more than you want a vendor holding, the control you want is access rather than seat: give them the one event they are working, not the workspace.

Two things stay closed to them. Private speaker information is the first: energy ratings and crew notes are visible to admins and editors only, and speakers never see their own ratings either. The team list is the second: someone whose access is limited to specific events does not get your roster, so they never see the names and email addresses of everyone else in the workspace.

Worth knowing rather than discovering: a speaker’s walk-up song is not private. Anyone who can open the event can read it.

Sending the invite

Go to Settings, fill in their email, pick the seat, pick what they can see, and you get a link back. We can’t send email on your behalf yet, so nothing is sent and the link is yours to pass on however you normally reach that person.

Copy it when it appears. We store a hash of the link rather than the link itself, so that screen is the only place it can ever be shown. If you lose it, revoke the invite and make a new one. The link works once, it only works for whoever signs in with the address you invited, and it stops working after two weeks.

They don’t need an account first. The invite page signs them up in place, with the invited address locked in so it can’t drift. They do have to confirm that address by clicking the link in the confirmation email before they can join, which is deliberate: it is the thing that proves the person who opened your link is the person you meant to invite.

Nothing is billed or limited by any of this. Settings shows a seat count including pending invites, and today it is there to be informative and nothing else.

Changing or ending someone’s access

Admins change a seat or reshape what somebody can see from the same team list in Settings, and removing somebody takes effect immediately. Removing them also retires any live invite link addressed to them, so nobody walks back in through a link you forgot about.

Only admins can do any of this. Editors build shows, they don’t hand out access, and anyone who isn’t an admin sees the team card as a read-only note telling them who to ask.

Letting yourself out

You never need an admin’s permission to stop having access to a workspace. Open Settings, find “Your access” at the foot of the team card, and choose “Leave this workspace.” It asks once more and names the workspace before it does anything.

Leaving ends your access to every event, run of show, and export in that workspace immediately. Nothing you built is deleted, it stays with the workspace. Your Planet Events account is untouched, so if you’re in another workspace you land back in that one. Coming back needs a fresh invite from an admin.

This is the control an outside speaker or an AV vendor is most likely to want, and it’s there for every seat, not just admins. The one case it won’t let you through is being the only admin in the workspace, because a workspace can’t be left without one. Make somebody else an admin first and then it’s available.

The limit worth knowing before you need it

Granting Admin is hard to take back. There is no owner seat sitting above admin, so every admin is equal, and that means any admin can remove or demote any other admin, including you and including the person who created the workspace. The only thing the product refuses outright is leaving a workspace with no admin in it at all.

Treat granting Admin as a decision about trust rather than a convenience, because the person you grant it to can make the same decision about you.