Organization administration

The Studio administration console is the organization control plane. Owners and admins use it to define who belongs to the organization, what shared context grounds Copilot, which integrations and tools are available, and how access is narrowed for each member and channel. Open the organization menu and choose the administration action. The console is organization-scoped; verify the organization name before making a change.

​

Administration areas

Administrative access does not reveal every personal credential. Policy controls availability; credentials remain in their configured personal or shared scope.

​

Members and roles

The Members page lists active members and pending invitations. Owners and admins can invite by email, change roles, revoke invitations, open a member record, and remove access. Pending invitations do not have member context or preloaded-tool settings until the invite is accepted.

​

Member context

Member context describes a person’s role, scope, responsibilities, and working preferences to organization-scoped AI. An admin can set one of two policies:

• Self-edit — the member can update their context from Settings → Profile.
• Admin-managed — the member can see the context but only an admin can change it.

Use member context for durable operating information, not performance notes or secrets. For example:

Senior network engineer responsible for EMEA production. Prefer read-only evidence before a change plan. Escalate firewall policy decisions to the security team.

​

Preloaded tools

Preloading makes selected built-in domains, connectors, or MCP tools discoverable at the start of a member’s new conversations. It does not bypass organization or channel restrictions and does not provide a credential. Preload tools that a member uses routinely. Leave one-off or high-risk tools discoverable on demand so the initial context stays focused.

​

Effective access

The member detail view includes a read-only effective-policy preview. Use it to answer:

• Which built-in domains and tools can this member use?
• Which organization connectors and MCP tools remain available after member policy?
• Which credentials are ready, missing, personal, or shared?
• Which tools are merely preloaded versus actually permitted?

The active channel can narrow this result further. Test a real conversation in the intended channel before declaring a rollout complete.

​

Organization context

Organization context is shared grounding applied to organization AI work. The current editor supports up to 32,000 characters. Include stable rules and definitions:

• Trust boundaries, environment names, and customer terminology.
• Required approval and change-management practices.
• Default escalation contacts or team names.
• Evidence and reporting conventions.
• Organization-wide exclusions, such as systems Copilot must never mutate.

Keep volatile incident state in a channel, conversation, artifact, or memory instead. Never place credentials in context.

​

Teams and channels

Teams group members for organizational and sharing purposes. Channels are the active operating boundary for conversations, context, tool policy, and workers. Use teams to represent stable groups such as NOC, field engineering, or security. Use channels for a workstream such as a customer, service, incident queue, or project. See Channels and the chat board for channel roles and settings.

​

Integrations

The Integrations page is the organization catalog for connectors and MCP servers. An admin can create or edit definitions, inspect a published MCP tool catalog, set organization availability, and choose how credentials are supplied.

​

Definition and credential scope

Separate the shared definition from the credential used to call it: Use personal credentials when the external system must attribute actions to an individual. Use a shared credential for a service identity whose access and audit ownership are intentionally organization-wide. OAuth authorization-code credentials are stored as private per-member entries unless an explicitly supported shared-service flow is configured. Studio surfaces missing-account markers without exposing the token to an admin.

​

Tool availability

For MCP servers, Studio can publish the server’s tool catalog to the administration console. An admin can disable the entire integration or individual tools. Runtime enforcement uses the integration ID and tool name, so a hidden or disabled MCP tool is rejected even if an old conversation still references it. For connectors, document each endpoint’s side effects and keep write operations disabled until the request and approval are reviewable.

​

The connect-your-accounts checklist

Members see account tasks in Settings → Profile when an allowed integration requires a personal credential. The checklist can deep-link to the correct OAuth or Key Chain flow. Completion means the required private entry is present; it does not expose the secret to the organization admin. Use the member credential-status markers to identify readiness gaps, then ask the member to complete their own account connection.

​

Offboard a member

Before removal:

1. Transfer ownership of channels, procedures, dashboards, and work that must continue.
2. Review personal-credential dependencies and provision a replacement owner or service credential.
3. Reassign open conversations and worker human gates.
4. Remove the organization membership.
5. Confirm the member profile and organization access are cleared.
6. Rotate any external shared credentials the person could access outside Studio.

Removing a member is not a substitute for rotating a shared secret in the external system.

​

Policy rollout checklist

• Test with a non-admin member, not only an owner account.
• Test inside the actual target channel.
• Verify both tool discovery and runtime dispatch.
• Confirm personal-account tasks appear for members who need them.
• Confirm shared credentials work without revealing them in chat or admin views.
• Record the intended owner and review date for every shared integration.

​

Related