What changed

Every content update is versioned. Select a version to compare it with the one before.

Version 1 → 2

Small fix

2 lessons updated

Small corrections such as typos or translation fixes. Learners are not notified.

Customer tenants are managed from the default tenant of your installation, at **System → Tenants**. The page exists only when the installation runs with `MONOPAM_TENANT_MANAGEMENT=true`, and only for a `monopam_superadmin`. Anyone else who types its address gets `Page not found.` ### New Tenant - **Title** and **Name**: the name is lowercase letters, digits and dashes, and is fixed after creation. - **Type** (`Standard` or `Trial`) and the expiry. - **Host Name**, **Port**, **HTTPS**: the first address of the tenant. Enter the bare name only, such as `a.pam.example.com`; the port goes in `Port`. The address must be unique across all tenants. - The database choice (see the architecture course). **Test Connection** tells you whether the server answers and whether the database can be created. - **Copy authentication, Monosign API and storage settings from the default tenant**: on by default. Turn it off to give the tenant its own Monosign connection. - **Sign-in Policy**: `Delegated only` when settings are copied, otherwise `Local and delegated`. - **Run the seed right after creation**: on by default. ### Following the seed The seed prepares the tenant in nine steps and runs in the background. The **Overview** tab shows each step with its state and error. A tenant created without seed waits in `Waiting for Seed`; **Run Seed** starts or repeats it. The steps keep existing data, so repeating is safe. The tenant is ready at `9 / 9 steps`, state `Ready for use`. ::diagram msp-open-customer-steps > Warning: A tenant created with copied settings is `Delegated only`. Nobody can sign in on its address until you grant provider access or change the policy. This is intended, not a fault.

Giving your staff access to a customer

Your people never get an account in the customer's tenant by hand. They get a **provider access**: a grant from your main tenant to one customer tenant. ### Grant Access Open **System → Tenants → the tenant → Provider Access → Grant Access**: - **Who**: one user of your main tenant, or a Monosign group of it. A group grant suits a team that rotates and also reaches people who join the group later. - **Role**: `Tenant Admin` administers the tenant, `Operator` connects and works like a standard user, `Auditor` only looks. - **Policies**: the customer tenant's own access policies the person becomes a member of. They decide which spaces, resources and vault items the person sees. - **Access ends** and **Reason**. An access without policies sees only what the tenant's own rules give, usually just the default space. The policies are created inside the tenant, for example by someone with a `Tenant Admin` access, and only chosen here. ### Entering The person opens **Open tenant** in the header of the main tenant and picks the customer. The tenant opens in a new tab without a second sign-in. The header badge shows `tenant · role`: it is the only visual sign that the tab is a customer tenant. A delegated session lasts at most 8 hours, or until `Access ends`. ### Asking instead of deciding Staff with the permission `monopam.federation.request` can ask for access. The grant waits as `Pending approval` until someone with `monopam.federation.full` approves or rejects it on **System → Provider Access**. Nobody is notified of a pending request, so approvers must look at that page. ::diagram msp-provider-access-path > Tip: **System → Provider Access** lists every grant across all customers on one page. Use it for your reviews.