# Scenario Playbook

> Follow a public hub scenario or explore named Thalovant scenarios with decisions, steps, and success checks.

Source: https://docs.thalovant.com/examples/scenarios/

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

## Scenario Index

  
    A first-time reader creates a narrow connection for a listed hub.
  
  
    A workspace creates one owned hub, one connection, and narrow access rules.
  
  
    A reviewer splits broad access into readable access-rule sets.
  
  
    A support contact traces Dashboard, Clients, Access rules, and Topology.
  
  
    A builder creates a separate skill set before changing shared defaults.
  
  
    A developer creates a runtime group and a hub with an API token instead of the dashboard.
  

## Scenario 1: Try a Public Hub

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

This public hub scenario is the shortest path to a first reply, because no owned hub is involved.

1. **Open Public hubs** and choose a listing with clear audience guidance.
2. **Create one connection** named for the app, device, or experiment.
3. **Use narrow access rules** that match the first task.
4. **Use the setup link** and keep setup material private.
5. **Check Dashboard** for the client count and any attention item.

Healthy result: one client exists for one public hub, and the access rule 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. |
| Access rules | `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, connection, paid Skill Store entry, or address action is locked. Then create the hub, create the connection, add access rules, and verify Dashboard.

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

## Scenario 3: Review Team Access

**Goal:** make access readable before more connections are added.

Start by finding access-rule 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 access-rule set can be reviewed without opening unrelated clients.

## Scenario 4: Fix a Stale Client

**Goal:** understand why `frontdesk-client` is stale in Topology.

  
    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 setup link or connection file is still private and placed with the connecting app.
    4. Open Access rules and confirm the client is linked to the hub.
    5. Open Topology and compare stale, missing, warning, and connected states.
  
  
    1. Missing from Clients usually means the client was not created or was removed.
    2. Present but offline usually means setup material or the running app needs attention.
    3. Present but blocked usually means Access rules need review.
    4. Visible in Dashboard but stale in Topology 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 Topology** 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](/workspace/billing-and-plans/). Read the plan card, current usage, and the message beside the locked action. Common locked actions include creating another hub, adding another connection, using a paid Skill Store entry, setting a hub address, or using a help option that belongs to another plan.

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

## Scenario 7: Provision a Hub From Code

**Goal:** create a runtime group and a hub from a script instead of the dashboard.

1. **Mint an API token** with the hub write scope on the [API Tokens page](/account/api-tokens/).
2. **Browse the skill catalog** first. Reading the catalog works on any plan, so you can decide what the hub should run before upgrading.
3. **Create the runtime group**, then create the hub attached to it.
4. **Install one skill** into the runtime group and release both onto a channel.
5. **Check Dashboard** for the new hub, then connect one client to it.

Healthy result: the hub appears in the dashboard exactly as a hub created by hand, and the script can repeat safely because hub creation accepts an idempotency key.

See [Provision Hubs](/developers/provisioning/) for the calls, the scope and plan rules, and the error table.

## 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 connection.** The connection name should explain what connects.
4. **Name access rules by purpose.** The name should make review faster.
5. **Choose the first health check.** Dashboard first, then Topology when live state matters.

Build the first setup