Setting up a tenant and the first login

A tenant is the self-contained data space of a company or a plant. It is not created in the application but in the Console — the operator surface under the path /console. It sits outside the customer login and does not belong on the same public address as the application.

What the Console may and may not do

The Console manages and observes. It shows name, state, creation date, the container and the history of the setup.

It has no path to a tenant’s business data: no records, no tags, no captures. That is not an agreement but built — the Console never sets the tenant context that would make such data readable in the first place.

Signing in to the Console

At first start the service creates one Console administrator, from two values:

CONSOLE_BOOTSTRAP_EMAIL
CONSOLE_BOOTSTRAP_PASSWORD

The step is repeatable: if the account already exists, nothing happens. If both values are empty, no account is created and nobody can sign in.

The Console login is local — e-mail and password, not the identity provider. It is the only password login in the whole system.

Creating a tenant

On the Tenants screen you create a tenant. The setup then runs on its own and does, in one go:

1. create an organisation at the identity provider,
2. set up a login client (OIDC client) there for this instance,
3. create a first tenant administrator with an initial password,
4. set up the tenant’s database roles,
5. start the instance.

While this runs the tenant carries one of four states: provisioning, active, failed, incomplete.

If it stops at failed or incomplete, repeat the setup with the same button. The procedure is built to run more than once: it carries on where it stopped instead of creating everything again.

The initial password

The initial password is shown exactly once, right after the setup. We do not store it — the identity provider keeps only its hash. Write it down before you close the window.

If it is lost, reset it in the tenant’s detail view. That invalidates the current password and shows you a new one, again exactly once.

If a tenant never finished its setup, there is no administrator to reset. The message says so explicitly; repeat the setup in that case instead of the reset.

The customer’s first login

The tenant administrator opens the address of their instance. The login goes to the identity provider, not to a TrakState form. There they sign in with e-mail and initial password and set a password of their own straight away.

After that they are in the application — with an empty data model. Next you decide which records exist and which fields they carry. That is the Data model chapter.

Detail view

For every tenant you see:

Item	What you need it for
State	Is the tenant running, or did the setup get stuck?
Address	Where the customer signs in.
Organisation and login client	For questions at the identity provider.
Container and its state	Is the instance running at all?
History of the setup	What happened last, and what it failed on.

From the same view you switch a tenant active or inactive. Inactive means the instance no longer runs. The data stays.