docs(guide): add processes.customer-provisioning — wizard runbook + handoff gotchas
CD - Develop (guide → bcos.dev) / build-and-deploy (push) Successful in 1m4s
CD - Develop (guide → bcos.dev) / build-and-deploy (push) Successful in 1m4s
Documents the mgmt portal 5-step New Customer + Institution wizard shipped to production in hiveops-mgmt#43: the five steps, atomic-submit semantics, the MSP_ADMIN agent-onboarding handoff message, and the gotchas (uppercased institution key, unrecallable handoff, skipping step 4 skips the handoff, MESSAGING_SERVICE_URL required).
This commit is contained in:
@@ -0,0 +1,107 @@
|
||||
---
|
||||
module: processes.customer-provisioning
|
||||
title: Customer & Institution Provisioning Wizard
|
||||
tab: Overview
|
||||
order: 10
|
||||
audience: bcos
|
||||
---
|
||||
|
||||
How to provision a new **institution** (customer + license + modules + MSP allocation) and hand
|
||||
agent onboarding off to an MSP admin — in one pass, from the mgmt portal.
|
||||
|
||||
**Where:** `https://mgmt.bcos.cloud/portal/customers/wizard` (also `portal.bcos.cloud`).
|
||||
**Who:** requires the `ADMIN` role in the **mgmt portal** (a separate account from your
|
||||
`bcos.cloud` SSO login — see [[technical.mgmt]]).
|
||||
|
||||
> There is no "institution" entity. An institution **is** a `Customer` of type `BANK` carrying a
|
||||
> unique `institutionKey`. The wizard is orchestration over existing services.
|
||||
|
||||
## The five steps
|
||||
|
||||
| # | Step | What it does | Required? |
|
||||
|---|------|--------------|-----------|
|
||||
| 1 | **Institution details** | Creates the BANK customer | Name, Email, Company Domain, Institution Key |
|
||||
| 2 | **License** | Issues a license key | Tier (BASIC / PRO / ENTERPRISE) |
|
||||
| 3 | **Modules** | Grants modules to the institution | Optional |
|
||||
| 4 | **MSP allocation** | Gives an MSP access to this institution | **Skippable** |
|
||||
| 5 | **Review & handoff** | Confirms, then messages MSP admins | Optional |
|
||||
|
||||
### 1 — Institution details
|
||||
`Name`, `Email`, `Company Domain`, and `Institution Key` are required; company, phone, address and
|
||||
notes are free-form.
|
||||
|
||||
**The institution key is normalised to UPPERCASE** on save (`first-national` → `FIRST-NATIONAL`).
|
||||
Whatever casing you type, the stored key is the uppercase form — that is the value the ATM agent
|
||||
must use for `incident.institution.key`.
|
||||
|
||||
### 2 — License
|
||||
Pick a tier. `Max activations` defaults to **3**. `Expires at` may be left blank for a perpetual
|
||||
license. Tick `Trial` for an evaluation licence.
|
||||
|
||||
**The license key is never shown in the wizard and is never sent in the handoff message.** Retrieve
|
||||
it afterwards from the customer detail page you land on (`/portal/customers/{id}`).
|
||||
|
||||
### 3 — Modules
|
||||
Only **enabled, non-default, non-core** modules are offered — defaults and core modules are granted
|
||||
automatically and don't need allocating. Selection is a **full replace** of the institution's module
|
||||
set, not an add.
|
||||
|
||||
### 4 — MSP allocation *(skippable)*
|
||||
Choose the MSP that will service this institution (e.g. *Quality Data Systems*). This writes a
|
||||
`customer_institution_access` row so the MSP's users can see the institution.
|
||||
|
||||
**Skipping this step also removes the handoff step**, because recipients in step 5 are drawn from
|
||||
the selected MSP. Skip it only for an institution BCOS services directly.
|
||||
|
||||
### 5 — Review & handoff
|
||||
The review pane summarises everything before you commit. Below it, tick the **MSP admins** who
|
||||
should receive the agent-onboarding handoff.
|
||||
|
||||
Recipients are the enabled `MSP_ADMIN` users whose **email domain matches the MSP's
|
||||
`Company Domain`** — e.g. selecting *Quality Data Systems* (`qualitydatasystems.com`) offers
|
||||
`jethridge@qualitydatasystems.com` and colleagues. An MSP with no matching admins shows an empty
|
||||
list.
|
||||
|
||||
## What happens on Submit
|
||||
|
||||
Steps 1–4 commit in a **single database transaction**. If any part fails, **nothing** is
|
||||
persisted — no orphaned customer, no dangling license. The wizard redisplays with the error.
|
||||
|
||||
Then, for each ticked recipient, an in-app **DIRECT inbox message** is sent (mgmt → `hiveops-messaging`).
|
||||
The success banner reports how many admins were notified.
|
||||
|
||||
## The handoff message
|
||||
|
||||
Subject: `Action needed: onboard agent for <Institution> (<KEY>)`
|
||||
|
||||
The body is a **runbook, not a credential drop** — it deliberately contains **no license key and no
|
||||
agent token**. It asks the MSP admin to:
|
||||
|
||||
1. Set the agent properties on the institution's ATMs:
|
||||
- `agent.endpoint = https://api.bcos.cloud/agent`
|
||||
- `incident.institution.key = <INSTITUTION_KEY>`
|
||||
2. Generate a token in the **Devices app → Agent Tokens → Generate** for that institution
|
||||
(`https://devices.bcos.cloud`).
|
||||
3. Paste it into the agent properties as `agent.auth.token`.
|
||||
|
||||
The MSP admin does the work; BCOS never handles their token. `MSP_ADMIN` already has permission to
|
||||
mint agent tokens, so no extra grant is needed.
|
||||
|
||||
## Gotchas
|
||||
|
||||
- **The handoff message cannot be recalled.** It lands in a real person's HiveOps inbox the moment
|
||||
you press Submit. There is no dry-run and no preview-send. For a first run, provision a throwaway
|
||||
institution with **no recipients ticked**, verify, then delete it.
|
||||
- **No recipients ticked ⇒ no message.** Provisioning still succeeds silently. If the MSP is
|
||||
expecting a handoff, check the success banner said "sent to N MSP admins".
|
||||
- **Skipping step 4 skips the handoff.** See above.
|
||||
- **Disabled MSP_ADMIN users never appear** as recipients.
|
||||
- Deployment requires `MESSAGING_SERVICE_URL` on the mgmt container. Without it the wizard
|
||||
provisions fine and the handoff **silently fails to send** (it defaults to `localhost:8086`).
|
||||
See [[technical.mgmt]].
|
||||
|
||||
## Related
|
||||
|
||||
- [[technical.mgmt]] — mgmt service, licensing, agent tokens, portal roles
|
||||
- [[technical.messaging]] — how the DIRECT inbox message is delivered
|
||||
- [[msp.institution-keys]] — institution keys and MSP access
|
||||
Reference in New Issue
Block a user