MidstreamDocs
Reviewing changes

Sharing instances with your team

Who can open a scene in Midstream, how to bring reviewers and designers in, and how to handle instance links.

Scenes and instances live inside your workspace, and opening one means being a member of it. This article covers how to get the right people in, and how to treat the links once they are.

Sharing means adding a member

To open a scene in Midstream and get an instance of it, a person needs to be signed in and be a member of the workspace that owns the project. There is no separate audience: the reviewer, the designer, and the PM you want to hand a link to are all workspace members.

So the way to share a scene is to invite the person to the workspace. Invitations go out by email from the workspace's Members page, and only a workspace owner can send them — if you are not one, ask an owner.

The viewer role exists for exactly this. Someone with the viewer role can do everything reviewing asks for — browse scenes, open instances, click around in the app, start comment threads and resolve them, mark favorites — and nothing that changes how the workspace is set up. It is the right role for a designer, a PM, a support lead, or a founder who wants to see the change without owning it. The roles article covers the full capability table.

Share the scene, not the running instance

Send people the scene's page in Midstream rather than the address of a running instance. The scene page is the better link in every way:

  • It gives each person their own instance, so nobody is clicking around in someone else's session. See Opening an instance.
  • It carries the context — the screenshot, the description, the comment threads, which pull request the capture came from.
  • It keeps working. An instance can be destroyed and rebuilt; the scene stays put.

For a change under review, the pull request's view in Midstream is an even better link, because it names the scenes the change touches. See What Midstream puts on a pull request.

An instance is not a screenshot and not a static preview. It is your application, running, with the session that the test held at the captured moment already loaded into it.

So a link to one deserves the care you would give a link to a running copy of your app with a live session in it: fine in a team channel or a pull request your team can see; keep it out of public issues, customer-facing documents, conference slides, and screenshots posted outside the company.

Two habits make this easy to live with:

  • Point people at the scene. Then the link you circulate is a Midstream page, and the person opening it gets their own instance.
  • Do not capture what you would not share. A capture stores the session the test had, so mark scenes in tests that use test accounts and seeded data — never a test signed in against real production data. The security article covers what is stored and why this matters.