MidstreamDocs
Administering a workspace

Members and roles

Who can do what in a workspace, how invitations work, and what the audit log keeps.

A workspace is your team. It owns your projects, your scenes, your API keys, and your billing. This page covers who you can add to one, what each role can do, and what gets written to the audit log.

The three roles

Every member of a workspace holds exactly one role, and it applies to the whole workspace — there is no per-project role.

CapabilityOwnerMemberViewer
View scenes and capturesYesYesYes
Open an instanceYesYesYes
Comment on a scene, resolve a threadYesYesYes
Read the audit logYesYesYes
Create a project and connect a repositoryYesYesNo
Change a project's settingsYesYesNo
Create and revoke API keysYesYesNo
Create, edit, and delete webhook endpointsYesYesNo
Delete a projectYesNoNo
Rename the workspace or change its settingsYesNoNo
Invite, remove, and change the role of membersYesNoNo
Delete the workspaceYesNoNo

Two things follow from roles being workspace-wide:

  • Adding someone gives them every project. If a person should see one repository's scenes and not another's, put those repositories in separate workspaces.
  • Viewer is the role for people who should look but not change anything — reviewers, designers, product managers, anyone you want in the conversation without handing them the keys to your build configuration.

A workspace always has at least one owner. The last owner cannot be demoted or removed; promote someone else first.

Inviting someone

Owners invite by email address, from Members in the workspace.

Pick the role at the time of the invitation. You can change it afterwards.

What happens next:

  1. A pending invitation appears in the members list, showing the email, the role, who sent it, and when it expires.
  2. Midstream emails the invitee a link.
  3. They open the link, sign in, and land in the workspace.

Invitations expire after 7 days. After that the link stops working and the invitee sees a message telling them to ask an owner for a new one.

Three rules that trip people up:

  • The invited address is the one that has to accept. If the link is opened by someone signed in as a different address, Midstream says so and refuses. There is no way to hand an invitation to a colleague.
  • One pending invitation per address. Inviting the same person twice is an error while the first invitation is still pending. Use Resend instead.
  • Resending restarts the clock. It sends a fresh email and pushes the expiry out another 7 days.

Revoking a pending invitation deletes it. The link stops working straight away.

Changing a role or removing someone

Both are owner-only, both take effect immediately, and neither touches anything the person made. Their comments, the scenes captured by their pushes, and their entries in the audit log all stay.

Removing a member does not remove any API key they created. Keys belong to the workspace, not to a person — see API keys for how to retire one.

The audit log

Every workspace keeps an append-only log of the actions worth being able to prove later. You will find it in workspace settings, newest first, filterable by action and by who did it.

ActionRecorded when
member.addedSomeone joins the workspace
member.removedSomeone is removed from the workspace
member.role-changedA member's role changes
api-key.createdAn API key is issued
api-key.revokedAn API key is revoked
workspace.settings-updatedThe workspace name or URL changes

Each entry records who did it, what they did it to, and when. Settings changes also carry the before and after values, so you can see what the name actually was.

Two properties matter:

Entries are permanent. There is no edit and no delete — not for you, not for an owner, not through the API. The log only grows.

Entries survive the person. Each row snapshots the actor's name and email at the moment it was written. If that user is later deleted, the entry stays and still shows who did it. A log you can erase by deleting an account is not worth keeping, so we do not build one.