Teams and organizations

Studio is organization-scoped. Once you sign in, your hosts, diagrams, procedures, memories, and conversations are scoped to one organization at a time. Everything you create lives inside that organization’s boundary, and everything your teammates create inside the same organization is available to you according to its visibility. You can belong to more than one organization — a customer’s org alongside your own consultancy, for example, or separate orgs for different business units. Switching between them is a one-click operation that re-signs you into the chosen organization and re-scopes the entire workspace, so there’s no need to sign out and back in. Team features in Studio are built around two ideas: visibility (is this item mine alone, or shared with the organization?) and role (what am I allowed to do inside this organization?). The rest of the page covers both.

​

Choosing an organization model

Keep organizations aligned with real trust boundaries. Use one organization for a team that can safely share inventory, memories, procedures, and session context. Use separate organizations when customers, business units, labs, or regulated environments should not see each other’s work.

​

The organization switcher

The organization switcher sits in the lower-left of the activity bar. Clicking it lists every organization you belong to along with a shortcut to create a new one. Picking an organization re-signs you in against it and re-scopes everything in the workspace — your host tree, your chats, your procedures, your memories, and your dashboards all refresh to the new organization’s content. If you’re working with a customer and your own team in the same week, it’s normal to flip between organizations several times a day. Studio keeps your layout and unsaved work where it is; only the scoped data changes. Before running a procedure or changing inventory, glance at the organization name in the shell. It is the fastest way to catch “right host, wrong customer” mistakes.

​

Visibility: private versus team

Every item you create in Studio is either private to you or shared with everyone in the organization. The toggle lives on the item itself. Team items sync across everyone in the organization — if a teammate adds a host, you see it; if you edit a shared procedure, they see the edit. Private items stay on your devices and don’t appear to anyone else. Keychain credentials are always private, even when the host or connector they’re used with is shared. Use private visibility for drafts, personal scratch work, and one-off investigations. Use team visibility for hosts, diagrams, procedures, and memories that another operator should rely on. If the item encodes operational truth, it probably belongs to the team once reviewed.

​

Roles

Each member of an organization holds one role. The role determines what they can change. Most engineers are members. Admins handle user management and curate the shared body of team items. Owners typically also handle billing and the organization lifecycle.

​

Team hygiene

• Keep shared host names and folder names consistent; search quality depends on the names people remember.
• Review shared procedures before marking them active.
• Use memories for durable operational facts, not personal notes.
• Keep credentials in each user’s Keychain instead of sharing raw secrets in chats or memories.
• Remove inactive members from the dashboard when they no longer need access.

​

Inviting and removing members

Invites and user management happen in the Altostrat dashboard, linked from the organization switcher. An admin or owner can invite a teammate by email, set their role, and remove them when they leave. Because Studio re-scopes on sign-in, a newly invited teammate sees the organization’s team items the first time they pick it from the switcher.

​

Presence and collaboration

When teammates are signed into the same organization, Studio surfaces their presence on shared surfaces — you can see who is viewing a shared terminal, who is joined to a call, and who is active in a session. For real-time work like pair troubleshooting, handoff, and voice or video in the middle of a session, see shared-sessions.

​

Related