---
title: First Steps
id: "en:tpm:firststeps:firststeps.adoc"
site: en
component: tpm
module: firststeps
version: 3.0
lang: en
url: "https://help.rtlscloud.io/en/tpm/3.0/firststeps/firststeps.html"
source_repo: "https://github.com/iot-invent/rtlscloud-tpm.git@3.0.x"
source_path: docs/en/modules/firststeps/pages/firststeps.adoc
---

# First Steps

At the end of this guide a third-party system receives the positions of a tag.

Every step is an **assignment**, not device commissioning. The device itself reports on its own as soon as it has power and cellular coverage — you do not create it, register it or configure it.

The sequence:

1.  The tag appears on its own

2.  Create a group

3.  Assign tenant and group

4.  Create a credential for the third-party system

5.  Check the events

6.  Add custom positions if needed

The order is not arbitrary: the group has to exist before the tag and the credential can reference it.

## 1. The Tag Appears

As soon as the device reports over the cellular network for the first time, its record comes into existence automatically — in the default tenant, because the message says nothing about which customer the device belongs to.

You can find it in [Tags (Administration)](../admin/tags.md). Filter by the device’s IMEI or by **Created at** to find a new shipment.

> **NOTE:** If the tag does not appear, its messages are not reaching the server. That is then not a problem of this application but one of reachability: check the endpoints, the port forwarding, and the server address configured in the device.

## 2. Create a Group

Switch to the tenant’s work area and create a group under [Tag Groups](../tag_groups.md).

| Field | Description | Example |
| --- | --- | --- |
| Name | Display name of the group | `North Hall` |
| Notes | What the group is for | `Load carriers, North site` |

Why first: groups are the unit by which credentials are authorized. Without a group you can neither assign the tag meaningfully nor grant the credential anything later.

One group is enough to start. Several make sense when different third-party systems are meant to see different subsets of tags.

## 3. Assign Tenant and Group

Two steps, in two different areas.

**Tenant** — in [Tags (Administration)](../admin/tags.md), select the tag and use **Assign new Tenant** from the context menu to assign it to the target tenant.

**Group** — then, in that tenant’s work area, under [Tags](../tags.md), select the tag and use **Assign new Group** from the context menu to assign it to the group from step 2.

While you are there, give it a meaningful name. Without one the list shows the MAC address, which becomes hard to read once there are several devices.

> **IMPORTANT:** After assigning the tenant, the tag is not yet assigned to any group. Its events are processed and recorded but do not reach any third-party system. The group step is therefore not optional.

## 4. Create a Credential

Under [Clients](../clients.md), create a credential for the receiving system.

| Field | Description | Example |
| --- | --- | --- |
| Name | The system that uses this credential | `WMS Production` |
| Groups | The groups whose events it may receive | `North Hall` |
| Client Secret | The credential’s password | a long, random password |
| Notes | Contact, purpose | `Warehouse management integration` |

> **IMPORTANT:** The client ID is generated when you save. The client secret cannot be viewed again afterwards — store both in the target system immediately. If the secret is lost, set a new one.

Without an assigned group, the credential connects successfully and receives nothing. This is the most common cause of "connected, but no data".

## 5. Check the Events

Two checks, in this order:

**Are positions arriving?** — In [Decision events](../decision_events.md), set the period to the last few hours and filter by the tag. For every event, the detail dialog shows whether a position resulted and where it came from.

**Is the third-party system connected?** — In [Clients](../clients.md), the **Status** column for the credential must show `Connected`. If it shows `Disconnected`, the issue is with the target system or its credentials, not with the assignment.

If both checks show what is expected, the setup is complete.

## 6. Add Custom Positions

Optional, but in practice the step with the largest effect.

Look in [Decision events](../decision_events.md) to see where positions are coming from:

-   If an online service is always shown even though the device is always at the same places, use **Customize WiFi** from the context menu on one of the reported access points to create a position of your own. Future events from that environment then need no request at all.

-   If positions jump between distant places, a mobile hotspot is usually involved. Set the access point in question to **Ignored** — see [Custom Locations](../custom_locations.md).

-   If an area needs to be located precisely, mount a beacon there and register it as **Gateway**. Every device in range then receives its position.

How the application consults its sources is described in [How a Position is Determined](../positioning.md).

## Next

| Topic | Page |
| --- | --- |
| What was decided on what basis | [Decision events](../decision_events.md) |
| The order of the position sources | [How a Position is Determined](../positioning.md) |
| Maintaining custom positions | [Custom Locations](../custom_locations.md) |
| Maintaining the shared position cache | [Geo Cache](../admin/geo_cache.md) |