Distribution Network

The distribution network is the partner layer on top of Licensing. A distributor is a workspace that sells Altovar products to its own customers and issues the license keys for them, inside the limits you set.

Access it from the sidebar: Licensing → Distributors.

The order that works

Each step depends on the one before it. Skipping one does not fail loudly — it fails later, on the partner’s side, when they try to sell something.

Step 1 — Create the distributor

New Distributor opens on two modes, because a partner reaches you in two different states. Pick the wrong one and nothing breaks — you just get an error that names the other one.

Link an existing workspace

The partner is already on Auris and becomes a distributor as well.

1. Go to Licensing → Distributors and click New Distributor, then Link an existing workspace
2. Tenant Realm — the realm of the workspace that becomes a distributor (for example acme-partner). It must already exist, otherwise you get No tenant with that realm
3. Name — leave empty to reuse the workspace name
4. Tier — free text for your own commercial segmentation (gold, reseller, …). It enforces nothing
5. Notes — internal. The partner never sees them
6. Click Create

Create a new workspace

The partner is new. Auris creates the whole space — Keycloak realm, workspace, owner user — registers it as a distributor and emails the first-access link to the contact.

1. New Distributor → Create a new workspace
2. Name — the partner’s company name
3. Realm slug — becomes the name of the workspace and cannot be changed later. Lowercase letters, numbers and hyphens; it must start with a letter
4. Contact email — the contact person. Unless you fill in the next field, this is also the owner user of the new workspace and the recipient of the invite
5. Sign-in address (if different) — optional. When you fill it in, this one becomes the identity: the Keycloak user, the workspace owner and the recipient of the invite. The contact address above then stays a contact only, stored on the distributor
6. Contact first name / last name, Tier, Notes — optional
7. Click Create workspace and distributor

One workspace can be a distributor only once: a second attempt answers That tenant is already a distributor. A slug already used by another workspace answers A tenant with this slug already exists, and a Keycloak realm left behind without its workspace answers A Keycloak realm with this name already exists without a matching tenant.

Contact vs. sign-in address

Two addresses, one identity. This is the distinction that decides where the invite goes.

An empty Contact means same as the sign-in address — not unknown. Changing the address a contact signs in with is an operation on the workspace user in Keycloak; it does not happen from the distributor page.

Resend invite

⋮ → Resend invite mints a new first-access link for the partner’s owner and tries to email it. Use it when the first invite did not arrive, or when you closed the panel without copying the link.

• It redoes nothing: realm, workspace, user and configuration already exist. It only mints a link
• The recipient is the active owner of that workspace, not something you choose. There is no field to type an address into, on purpose
• The link comes back whether or not the email went out, because delivering it by hand is exactly why this exists
• This workspace has no active owner (MEMBERSHIP_NOT_FOUND) or The contact does not exist as a user in the partner workspace (KEYCLOAK_USER_NOT_FOUND) mean the accounts have to be fixed first — the invite is not the problem

Contract reference

From the distributor page, ⋮ → Edit carries Contract reference and Signature date. They are a pointer to the signed contract in the ERP (CON-2026-0001), for people reading the page — no automation reads them.

Edit also carries three fields that are anything but decorative: Contact, Parent in the network and May create sub-distributors. See Sub-distribution below.

Step 2 — Grant the product lines

A grant answers one question: what may this partner sell, and within which ceiling? It is created per line, from the distributor page → Grants → Add Grant.

Modules — the trap

On the ERP line the grant carries the list of modules the partner may resell.

In practice:

• You want to restrict — tick exactly the modules the partner may sell. Anything they ask for outside that list is refused (MODULES_NOT_GRANTED), and if they ask for nothing, they get precisely your list, never a full key
• You want no restriction — leave every module unchecked

The other fields

• Max Customers — the customer ceiling for this line. Leave empty for no limit. See below for when it actually bites
• Discount % — the number the partner’s price list is computed from. In its portal, under Price list and margins, the partner sees the list price of every plan on this line, the same price with this discount applied (Your price) and the difference (Your margin). It does not produce an invoice and it does not change a key — but it is not a memo either, so do not park a negotiation figure here
• Active — deactivating a grant stops issuing on that line without deleting it. The partner stops seeing the line entirely: its portal only ever receives the active grants, so an unexplained deactivation reads as a line that vanished

Each line can hold only one grant, so lines that already have one are not offered again — edit the existing one instead.

Step 3 — Attribute the customers

This is deliberate. A key of type tenant with status active is exactly the shape the ERP gate accepts: without this rule, knowing the name of a workspace would be enough to license an Altovar direct customer and walk away with the row claiming it as your own.

From the distributor page → Customers → Add Customer:

1. Tenant Realm — the realm of the customer workspace. It must already exist
2. Product Line — only lines the partner holds a grant for are listed. If the partner has none, the dialog tells you to add a grant first
3. Notes — internal
4. Click Add

Attribution is per line

The same customer is attributed once per line. A customer that buys ERP and Cloud from the same partner is two attributions, one for each — and the distributor list still counts it as one customer.

The line decides one thing only: which quota that attribution consumes. It never decides access, so a wrong line costs a slot on the wrong grant and nothing else. Fix it by removing the row and adding it back on the right line.

The quota bites here

Max Customers is enforced when you attribute, not when the partner issues. Attributing one customer over the ceiling of that line is refused; the partner never sees the wall you just hit.

Re-attributing a customer that is already on the same line is idempotent — it does not eat a second slot.

There is one case where the partner meets the ceiling directly: extending an existing customer to a new line. A customer attributed on Cloud, licensed on ERP, becomes a new customer on the ERP quota, and the issuing call books it.

One customer, one channel

A workspace belongs to a single channel. Attributing a customer that already belongs to another distributor is refused with CUSTOMER_ATTRIBUTED_ELSEWHERE — the second channel does not silently win, and the customer does not end up shared.

Handing a customer over to another channel

⋮ → Transfer to another channel, on the customer row. The customer changes partner in one go: no key is revoked or reissued, active keys stay active and only change channel, and the end customer sees no interruption.

The customer moves as a whole, with every line it holds in that channel: the row you clicked is only the handle, there is no per-line transfer.

The destination has to pass the same questions as a fresh attribution — active, holding the line, upstream chain active, and with its customer quota counted as if the customer were joining now. On top of that, the modules of the keys it inherits must fit inside its own grant: they are not silently narrowed, the transfer is refused (MODULES_NOT_GRANTED).

Removing a customer

⋮ → Remove customer detaches the link. The workspace itself is untouched — it keeps its users, its data and, if you leave them, its keys.

The removal is refused while that customer still holds active or suspended keys in that channel, on any line (CUSTOMER_HAS_KEYS, with the count in the message). Revoke or let those keys expire first, otherwise the channel would keep licensing a customer that, on paper, is not its own.

Step 4 — Issue a key for the partner

You can issue in the partner’s place from the distributor page → Issue Key. The distributor field is pre-filled and locked: the key lands in that channel.

The rest of the form is the ordinary issuing form — policy, licensee, ERP tier, expiry, ERP modules.

The plan is not optional on a channel key

On the ERP line, a key attributed to a distributor has to state the plan being sold. It is not an informative field: that slug is where the two things the product actually reads come from.

Changing a channel customer’s plan

A customer moving from Starter to Business no longer needs a new key. The plan of a channel ERP key is rewritten in place: same key, same JWT, unchanged status, no interruption for the end customer. Until now the only road was revoke and reissue — an outage on the single most frequent event there is.

Everything that holds at issuing time holds here, measured now and not when the key was minted: partner active, upstream chain alive, line erp granted and active, modules inside the intersection of plan and grant. The customer attribution is untouched and no Max Customers slot is consumed: the customer was already there.

Sub-distribution

A partner can resell through another partner. The network is a tree: level 1 is a direct Altovar partner, level 2 its sub-distributor, level 3 the last one allowed.

The whole thing follows from one sentence: what a child may do is a subset of what its parent may do. Everything below is that sentence applied.

Who can create a sub-distributor

Nobody by default. The right is a switch on the partner — ⋮ → Edit → May create sub-distributors — and only you can raise it. Turn it on and the partner opens sub-distributors from its own portal, without asking you: it fills in name, identifier and the contact’s email, and Auris creates the child’s workspace and mints its first-access link, which the parent delivers.

You still decide the terms. The child is born with no grant at all and with its own sub-distribution right off, so until you grant it a line it can sell nothing. A parent that could write its own child’s grants would be deciding the discount Altovar earns.

Why three levels

The margin of a parent is the gap between its own discount and its child’s. Every level cuts a slice out of the same discount, on the same list price — and the ERP list starts at 9 EUR per month. A fourth level would have to sit under the third, that is, work at roughly zero margin. The chain stops at three (MAX_DEPTH_EXCEEDED), and the check runs both when a child is created and when you re-parent an existing partner — re-parenting a partner that already has children sinks them too, and that is counted.

What a child grant must respect

When you write a grant on a partner that has a parent, it is checked against the parent’s grant on that same line:

The same pact seen from the other side: you cannot narrow, deactivate or delete a parent grant while a child still sits outside the new shape (CHILD_GRANT_EXCEEDS). Nothing is silently pushed down onto the child — a third party signed those terms — so the refusal lists the children to fix first.

Suspension travels down the chain

No customer key is touched by any of this. The chain gates the commercial act, not the licence already delivered: the end customer bought a product, not a channel, and switching it off over a contract two levels above would punish it for something it knows nothing about.

At issuing time, the modules actually grantable are the intersection along the whole chain. When two restricted lists have nothing in common the line is refused with MODULES_NOT_GRANTED, rather than read as no restriction.

Removing a partner from a chain

Delete is refused while a partner has children (DISTRIBUTOR_HAS_CHILDREN): deleting the parent would promote every child to a direct Altovar partner, because the discount ceiling, the customer cap and the module subset all live on the parent’s row. The way out is Terminate.

Detaching a single partner is deliberate and explicit: ⋮ → Edit → Parent in the network → None. It promotes that partner to direct Altovar — no ceiling above it any more — and leaves an audit trail. Do it knowing that.

Operating licence

Two different rights, and the grants only express the first one:

• A grant says what the partner may sell to its customers. It unlocks nothing on the partner’s own screen
• The operating licence says what the partner may use to work. It is an ordinary ERP licence on the partner’s own workspace

From the distributor page, the Operating licence card grants it and revokes it. The module profile is fixed by the platform and is not chosen here: crm, documents, finance, projects, calendar, subscriptions, products, inventory, billing. Expiry is optional.

To change the profile there is no edit: revoke, then grant again. A second grant on top of a live one is refused (OPERATING_LICENSE_EXISTS) so that “the” operating licence stays identifiable.

Suspending, terminating, deleting

From the distributor page, the ⋮ menu:

Keys already issued are not touched by suspending or terminating: existing customers keep working. To cut a specific customer off, act on the key itself.

Delete is refused as soon as the channel holds any key (DISTRIBUTOR_HAS_KEYS), the partner has sub-distributors (DISTRIBUTOR_HAS_CHILDREN), or it still holds an operating licence (DISTRIBUTOR_HAS_OPERATING_LICENSE). The way out of a partnership is Terminate, not delete.

What the partner does alone

At partners.altovar.net the partner sees its agreement and its channel, and — on its own — adds customers (existing workspace or a new one), issues keys for them on granted lines, within the allowed modules, then suspends and reactivates them — and changes the plan of an ERP key it already issued, in place, without cutting the customer off. From a customer row it can generate a site in its own ERP (the operating licence is claimed automatically if it was still missing) or ask Altovar to produce it.

It also reads its price list — but only whoever holds manage:distribution in its space, not every member — and, only if you turned the right on, it creates its own sub-distributors from the My network page.

It cannot move a customer to another channel, change its own grants, raise its ceiling, revoke a key, grant itself the right to sub-distribute, write its children’s grants, re-mint an invite, or see the notes you take about it. Everything on that list comes back to you.

Send partners to the Partner Portal guide.

Permissions

Messages you may run into

The ERP plan of a channel key

Sub-distribution and operating licence

Related

• Licensing Console — policies, keys, seats, devices
• Partner Portal — the guide to hand to your partners
• Software Licensing — validating keys inside a product