Scenario Playbook

Use this playbook when you understand the basic words and want realistic examples. Each scenario names the goal, the safe order, and the checks that prove the setup is healthy.

The examples are not scripts to copy exactly. Use the structure and choose names that fit your own workspace.

Start Here If

• you want examples with realistic hub, client, and permission names;
• the concept pages make sense but the setup order still feels abstract;
• you need a pattern for public hubs, owned hubs, access review, stale clients, or runtime changes;
• a teammate needs a short example before changing the workspace.

Each scenario uses the same small pattern: choose one hub, connect one client, set narrow access, then check health.

Scenario Index

Try a public hub

A first-time reader creates a narrow client for a listed hub.

Create a private support hub

A workspace creates one owned hub, one client, and narrow permissions.

Review team access

A reviewer splits broad access into readable permission sets.

Fix a stale client

A support contact traces Dashboard, Clients, Permissions, and Live Map.

Change runtime for one hub

A builder creates a separate skill set before changing shared defaults.

Scenario 1: Try a Public Hub

Goal: explore a public hub without creating an owned hub.

1. Open Public hubs and choose a listing with clear audience guidance.
2. Create one client named for the app, device, or experiment.
3. Use narrow permissions that match the first task.
4. Keep the connection file private and place it only where the client needs it.
5. Check Dashboard for the client count and any attention item.

Healthy result: one client exists for one public hub, and the permission name explains why access exists.

Scenario 2: Create a Private Support Hub

Goal: create a workspace-owned hub for a support front desk.

Item	Example name	Why it helps
Hub	support-frontdesk	Names the destination and purpose.
Client	frontdesk-client	Names what connects.
Permissions	frontdesk-questions-only	Shows narrow access before anyone opens the rule.
Runtime choice	workspace default	Keeps the first setup small.

Check Billing first if the hub, client, paid skill, or address action is locked. Then create the hub, create the client, add permissions, and verify Dashboard.

Healthy result: Dashboard shows the expected hub and client, and Live Map shows the client when live status is available.

Scenario 3: Review Team Access

Goal: make access readable before more clients are added.

Start by finding permission sets with vague names like default, full, or temporary. Then split them by purpose.

Instead of	Create
One broad default set	frontdesk-questions-only
One shared service set	skill-status-read
One temporary broad set	temporary-review-window with an end date in the notes

Healthy result: each permission set can be reviewed without opening unrelated clients.

Scenario 4: Fix a Stale Client

Goal: understand why frontdesk-client is stale in Live Map.

Check order

1. Open Dashboard and note the attention item.
2. Open Clients and confirm the client is active and attached to support-frontdesk.
3. Confirm the connection file is still private and placed with the connecting app.
4. Open Permissions and confirm the client is linked to the hub.
5. Open Live Map and compare stale, missing, warning, and connected states.

Likely cause

1. Missing from Clients usually means the client was not created or was removed.
2. Present but offline usually means the connection file or running app needs attention.
3. Present but blocked usually means Permissions need review.
4. Visible in Dashboard but stale in Live Map usually means the latest live update has not arrived.

Healthy result: the symptom points to one owner page instead of a guess.

Scenario 5: Change Runtime for One Hub

Goal: change language or location for one hub without changing every hub that uses the default skills.

1. Create or choose a separate skill set for the affected hub.
2. Assign only the intended hub to that skill set.
3. Open Runtime config for that skill set.
4. Change language, location, speech, or blocked skills only where needed.
5. Check Dashboard and Live Map before moving more hubs to the same skill set.

Healthy result: only the intended hub uses the changed runtime defaults.

Scenario 6: Explain a Locked Button

Goal: decide whether a locked action is a plan question or a setup question.

Start with Billing. Read the plan card, current usage, and the message beside the locked action. Common locked actions include creating another hub, adding another client, using a paid skill, setting a hub address, or using a help option that belongs to another plan. On Pro, creating another owned hub is locked once usage reaches 10 of 10.

Healthy result: the reader knows whether to change the plan, reduce usage, or return to the original page and continue setup.

Make Your Own Scenario

Use this pattern:

1. Name the goal. Keep it short and specific.
2. Name the hub. The hub name should explain the destination.
3. Name the client. The client name should explain what connects.
4. Name permissions by purpose. The name should make review faster.
5. Choose the first health check. Dashboard first, then Live Map when live state matters.

Build the first setup