Skip to content
Console

Team Workspace

Team workspace setup is for groups that need a shared path before creating many items.

For a goal-based route, start with What Should I Do?. For naming and permission examples, use the Scenario Playbook.

The main goal is agreement before scale. Decide naming, access review, runtime changes, and help ownership before many hubs and connections exist.

Use it when you need to align:

  • plan limits;
  • help options;
  • hub addresses;
  • who creates the first hub;
  • how connections and permissions should be named;
  • whether default or separate skills should be used;
  • who can change runtime config.
  • more than one person will create or review workspace items;
  • the team needs shared names for hubs, connections, and permissions;
  • plan limits, help ownership, or runtime changes need an owner;
  • the first setup should become the pattern for later setups.
Team question First decision
Who creates the first hub? Name one setup owner before creating shared items.
Who reviews access? Name the person or process that checks wider permissions.
What should be repeated? Repeat one healthy hub-connection-permissions loop.
When should runtime change? Change runtime only when the hub purpose needs different defaults.
  1. Review the workspace plan. Confirm hub limits, runtime slots, connection limits, policy limits, addresses, skill access, and help options in Billing.
  2. Confirm review and help options. Decide who handles account questions, plan questions, and hub or client questions.
  3. Prepare the first hub. Create the first hub only after the plan and help options are clear.
  4. Agree on runtime changes. Decide when to use workspace default skills and when a separate skill set should have its own runtime config.
  5. Create connections and permissions together. A client without permissions is harder to understand later.
  6. Use Dashboard and Live Map. Make health and connections visible as soon as clients begin connecting.

Use names that explain purpose, not just ownership:

  • support-frontdesk is clearer than client-1;
  • demo-public-general is clearer than test-hub;
  • frontdesk-questions-only is clearer than default-permissions.

Good names make search, filters, Live Map, and reviews easier to scan.

Before the team creates many items, create one complete loop:

  1. One hub with a clear purpose.
  2. One skill set choice with runtime defaults left simple unless there is a clear reason to change them.
  3. One connection with a clear purpose.
  4. One permission set with narrow allowed actions and clear safety rules.
  5. One Dashboard review.
  6. One Live Map review after the client is live.

That loop becomes the template for future hubs, connections, and permissions.

A team setup is ready to repeat when:

  • the first hub, connection, and permissions are easy to explain;
  • the team knows who reviews wider access;
  • runtime changes have a clear review path;
  • Dashboard and Live Map are part of the normal check;
  • names follow the same purpose-based pattern.