Teams and organizations

An Altostrat organization is Studio’s primary trust and administration boundary. Organization context, members, teams, channels, integrations, policy, billing, and shared resources all live inside that scope. Use separate organizations when two populations must not share administration, inventory, context, integrations, or billing. Do not use a channel as a substitute for a true customer or regulatory boundary.

​

Choose an organization model

Switching organization re-scopes cloud and local organization data. Always verify the displayed organization after a switch and before approving a state-changing operation.

​

Organizations, teams, and channels

Use a team for “NOC” or “Security Engineering.” Use a channel for “Customer A,” “Core network incidents,” or “Q3 migration.”

​

Organization roles

Channel roles—owner, admin, and member—are separate from organization roles. They determine who can maintain that channel’s members, settings, context, and tool ceiling.

​

Visibility

Studio resources can be private, organization-shared, or shared with selected members where the surface supports it. The exact control appears on the resource or Share dialog. Keep drafts and personal investigations private. Share reviewed procedures, dashboards, hosts, diagrams, and work products when another operator should rely on them.

​

Credentials

Studio supports both personal and explicitly managed shared credential modes.

• Personal credentials live in the member’s private Key Chain and are appropriate for user-attributed external access.
• Shared credentials represent an organization service identity and require deliberate provisioning, ownership, rotation, and policy.

An admin may see whether a member is ready to use a required personal integration, but not the member’s secret. If an account is missing, the member completes the connect-your-accounts checklist in Settings → Profile. Never paste credentials into organization context, channel context, member context, memories, artifacts, or chats.

​

Context layers

Organization context defines stable shared rules. Member context describes a person’s role and preferences. Channel context narrows the operating stream. A conversation adds live history and explicit attachments. Keep each fact at the narrowest correct scope. A customer-only rule belongs in that customer’s channel, not organization context. A personal working preference belongs in member context, not the channel.

​

Presence and collaboration

Studio shows teammate presence and activity in the workspace and on shared surfaces. Shared terminal sessions, calls, guest links, chat board status, and Studio Remote support real-time handoff without changing the underlying organization boundary. Presence is an availability hint, not authorization. Use the explicit role, share, and approval controls for access.

​

Member lifecycle

When inviting a member:

1. Assign the minimum organization role.
2. Add only the necessary teams and shared channels.
3. Set or delegate member context.
4. Preload routine tools without widening policy.
5. Have the member connect required personal accounts.
6. Test effective access in the target channel.

When offboarding, transfer owned work, replace credential dependencies, reassign gates, remove membership, and rotate external shared secrets the person could access.

​

Related