Onboarding
Onboarding is vendor-initiated and customer-confirmed. We know the hosting model and the region by the time the deal is agreed, so you are not asked questions we already know the answer to. You confirm what we prepared, and confirming is what triggers the deployment.
1. Pre-build
Section titled “1. Pre-build”Us, in the control plane. We create the customer record, set the hosting model and region, pick the initial hostname, and issue the licence.
Nothing is deployed yet. This produces a pending deployment holding the
generated secrets, the .env and the licence key, all sealed until provisioning.
2. Invite
Section titled “2. Invite”Automatic. The panel emails you a single-use, expiring link.
No account is needed to open it. The token in the link is the credential, which is why it expires and why it only works once.
If the email does not arrive, we can send you the link by hand. It is the same link.
3. Confirm
Section titled “3. Confirm”Yours. A short review page, not an interrogation.
You see what we prepared, and you can adjust the parts that are cosmetic:
- Your organisation’s display name
- Your address, either
yourschool.plugboard.appor your own domain - The first administrator’s name and email
- Time zone and locale
All of these are editable in the product afterwards. They are on this page so that the first sign-in already looks right, not because the deployment depends on them.
Region and hosting model are shown as confirmation, not choice, with the data residency note for the region. They follow from the agreement. If you want either changed, reply to a human. It is rare enough not to automate.
4. Deploy
Section titled “4. Deploy”Pressing confirm provisions for real. The stack comes up on the region’s host, DNS and the tunnel are created, migrations run, and the first administrator is invited.
The page stays open and shows progress, because provisioning takes minutes and a spinner with no detail invites a support ticket.
5. Walk through
Section titled “5. Walk through”After deployment you get the guide matching the model we selected, so nobody reads instructions for a deployment they do not have.
Managed customers get: their URL, first sign-in, inviting staff, connecting their identity provider, pointing their own domain at it, where backups go, and how to ask for a restore.
Self-hosted customers get: the deployment method with their real values
already filled in, their pre-generated .env and licence key, TLS options, the
backup and update commands, and the installers themselves. The invitation
link authorises those downloads, so nobody has to go and get a separate
download centre link mid-setup; the centre is for
afterwards.
That guide puts the emphasis on the two things only you can do: keeping
SECRETS_MASTER_KEY backed up somewhere other than the server, and running the
update when a release lands.
Your first week
Section titled “Your first week”Once you are in, follow the setup checklist. It is written in the order that works, and it front-loads the requests that have lead times.
The short version:
- Branding, so it looks like yours.
- Turn off modules you will not use.
- Set the workflow before anyone lodges a real submission.
- Connect email first, then the directory or SIS, then the MDM.
- Build roles, then invite technicians.
- Turn on SSO and, if you can, SCIM.
Connecting systems on your network
Section titled “Connecting systems on your network”A managed deployment cannot reach Active Directory, a Synergetic database, PaperCut, or a printer answering SNMP, because those are inside your network and we are not.
Install a connector agent. It dials out, collects queued work, and returns results. There is no inbound firewall rule to request, which is usually the difference between a two week change request and an afternoon.
The agent registers itself as a monitor at the same time, so an agent that is installed and then dies gets noticed by the alerting rather than by somebody wondering why the roster stopped syncing.
What we need from you
Section titled “What we need from you”| Thing | When | Why |
|---|---|---|
| Confirmation of the onboarding page | To start | It is what triggers provisioning |
| A DNS record | Whenever you want your own domain | See your own domain |
| An OIDC application in your identity provider | Before SSO works | We cannot create it in your tenant |
| A connector agent installed | Before private systems connect | See above |
| Credentials for each connector you want | As you enable them | We never hold them; you paste them in |
Changing your mind later
Section titled “Changing your mind later”Moving between self-hosted and managed, or between regions, is an export, a provision, an import and a DNS change. It is a documented path rather than something to discover under pressure. See support, restores and exits.