Skip to content

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 clients exist.

Use it when you need to align:

  • plan limits;
  • help options;
  • hub addresses;
  • who creates the first hub;
  • how clients and permissions should be named;
  • whether default or separate skills should be used;
  • who can change runtime config.

Use this page when:

  • more than one person will create or review workspace items;
  • the team needs shared names for hubs, clients, and permissions;
  • plan limits, help ownership, or runtime changes need an owner;
  • the first setup should become the pattern for later setups.
Team questionFirst 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-client-permissions loop.
When should runtime change?Change runtime only when the hub purpose needs different defaults.
Team setup flow showing plan agreement, naming agreement, one first setup loop, and repeated setup ownership.
Team setup starts with ownership and names, then repeats only after the first setup loop is healthy.
  1. Review the workspace plan. Confirm hub limits, client limits, permission limits, addresses, skill access, and help options. Pro allows up to 10 owned hubs.
  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 clients 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 client 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, clients, and permissions.

A team setup is ready to repeat when:

  • the first hub, client, 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.