Vision

Platform

Teammates

Invites, roles, per-project access levels, and reviews — how a whole team builds without stepping on production.

Vision is built for teams where everyone builds — and for the admins who need that to be safe. Three layers make it work: team roles, per-project access levels, and reviews.

Inviting teammates

Invite by email from Settings → Teams, picking a role and a trust level as you send it. Invitees get a link that works whether or not they already have a Vision account (invites expire after 7 days). On the Teams plan, seats are billed per member — see Plans.

Every member has a team role:

  • Admin — manages members, invites, billing, and project settings; implicitly full access everywhere.
  • Member — builds within the access level they’ve been given.

Members

[email protected] Invite
M Admin
K Developer
P Internal-only
S

[email protected]

Invite sent · expires in 7 days

Read-only
Paola requested review — "Refund button on the orders page" Review it

Waiting on you. Open it, look at the change, then Approve or Send back.

Roles plus trust levels: everyone builds, and work beyond someone's level becomes a review instead of a surprise.

Access levels

Per project, members work at a trust tier — visible as a badge next to their name in shared sessions:

  • Read-only — can explore and run read-only analysis. Can’t publish; scripts may not modify data.
  • Internal-only — can build and publish inside internal scopes (an /admin area, for example). No database migrations; changes outside their scope need approval.
  • Developer — full access to the entire codebase and database.

People can start read-only and earn more access over time — that’s the intended shape, not an afterthought.

Scoping a project

Access levels get their teeth from a permission scan: in Project settings → Permissions, an admin presses Scan for permissions and Vision maps the codebase into scopes and proposes sensible default grants. Tune the level-by-scope matrix from there, or flip the master switch off to make everyone full-access on that project.

Reviews

When a member’s work goes beyond their level, it doesn’t ship — it becomes a publish request. The Reviews page is the queue, and every row says whose move it is:

  • Review it — waiting on you: open it, look at the change, then Approve or Send back (the buttons sit right above the chat box).
  • Make changes — a reviewer sent your request back; update and resubmit.
  • Publish — your work was approved; press Publish to ship it.

So a marketer on Internal-only can build all day in the admin area, and the moment something touches beyond it, an admin gets a review instead of a surprise. Guardrail results ride along with each update, too — see Guardrails.

Building together

Sessions are shared on the Teams plan: teammates can open the same workspace, watch turns run, and prompt in the same thread — every message labeled with its author and their access badge. For parallel workstreams, see Building in parallel.