First Successful Setup

Use this tutorial when you want one guided, practical pass through Thalovant. It assumes no product knowledge beyond the first idea: a hub is the place to connect to, a client is what connects, and permissions decide what the client can do.

By the end, you should have one hub, one client, one permission set, and one health check that all agree.

Start Here If

Use this page when:

• you want one guided setup instead of a full product tour;
• you need to learn by creating one small loop;
• you are deciding between a public hub and an owned hub;
• you want a checklist before repeating the setup for a team.

Applies To

Reader	Use this page when
New setup builder	You want the first practical loop without learning every feature first.
Public hub explorer	You want to try one shared hub with one narrow client.
Workspace builder	You want one private or team-controlled setup before adding more.

What You Will Build

One destination

Choose or create the hub that the client will use.

One connection

Create one client and keep its connection file private.

One access rule

Give the client only the access it needs for this first setup.

One health check

Confirm Dashboard and Live Map match the setup you intended.

The first setup should stay small: choose one hub, create one client, set access, then verify Dashboard and Live Map.

Before You Start

You need:

• access to the workspace where the setup will live;
• a clear name for the hub or public hub you want to use;
• a clear name for the app, device, or experience that will connect;
• a few minutes to check Dashboard and Live Map after setup.

If a create button is locked, open Billing before changing the setup. Plan limits are different from setup problems.

Step 1: Choose the Hub

Start with the smallest choice that fits your goal.

Goal	Best first hub choice
Try Thalovant without owning a hub	Use Public hubs.
Build a private or team-controlled setup	Create one hub with Create a hub.
Learn the model before creating anything	Read How Thalovant Works.

Good hub names explain the purpose. support-frontdesk, demo-kiosk, and research-helper are clearer than test.

Step 2: Keep Skills Boring at First

Use the workspace default skills unless the hub needs something special immediately. Skills give a hub abilities. Runtime holds shared settings behind those skills, such as language, location, speech, and blocked skills.

Use Runtime later when:

• one hub needs different language or location;
• a skill needs to be blocked for a specific setup;
• a skill update should be tested before more hubs use it.

Step 3: Create One Client

Create one client for the app, device, or experience that will connect to the hub.

1. Name the client by purpose. Use a name like frontdesk-client, demo-tablet, or skill-sync.
2. Attach it to the chosen hub. Avoid creating extra clients until this one works.
3. Store the connection file privately. Treat it like a key for that client.
4. Do not reuse the file for another purpose. Create a separate client when the purpose changes.

Read Clients if the client is offline, not connected, paused, or missing its connection file.

Step 4: Add Narrow Permissions

Permissions should describe what the client is allowed to do on the hub.

Use a name that explains the purpose, such as:

• frontdesk-questions-only;
• demo-read-only;
• skill-status-read;
• temporary-review-window.

Then ask these questions:

1. Does the permission name match the client purpose?
2. Are allowed actions specific enough to review quickly?
3. Are wider controls blocked when they are not needed?
4. Would a teammate understand why this access exists?

Read Permissions before adding broader access.

Step 5: Check Dashboard

Open Dashboard and check the workspace summary.

The Dashboard should answer:

• did the expected hub count change?
• did the expected client count change?
• is there an attention item that names this setup?
• does the visible status match what you expected?

Do not continue adding more items until the Dashboard view makes sense.

Step 6: Check Live Map

Open Live Map when live status is available.

Look for:

• the hub you chose;
• the client you created;
• a connected, stale, missing, or warning state;
• a route from the visible symptom back to Clients, Permissions, Runtime, or Billing.

If the client is missing or stale, check Clients first. If the client exists but access is unexpected, check Permissions next.

Done When

The first setup is done when:

• the hub has a clear purpose;
• the client name explains what connects;
• the connection file is private;
• permissions are narrow and readable;
• Dashboard shows the expected counts or attention item;
• Live Map matches the real connection state when it is available.

Tip

Stop after the first successful loop. A second hub or client is much easier once the first one gives you a trusted pattern.

Next Step

Use the scenario playbook when you want named examples for common situations.

Open scenario playbook