Setup checklist

This is the order that works. It is arranged so that nothing later depends on a decision you have not made yet, and so the parts that need somebody else (a service account, a DNS record, an API token) get requested early while you carry on with the rest.

Most of the elapsed time is waiting on other teams. The work itself is a couple of afternoons.

Day one: make it yours

• Sign in as the first administrator. A fresh install has no accounts; you create the first one. See the first hour.
• Set the branding. Product name, logo, colours. Two minutes, and it changes how the rest of the setup feels because every screen is now recognisably yours. See branding.
• Turn off the modules you will not use. Every module you disable is a navigation item, a set of endpoints and a page of documentation you never have to think about again. See modules.
• Set the workflow to match how you already work. Statuses, priorities, repair types with their coverage, and the parts list with prices. Do this before anyone lodges a real submission, because changing a status after the fact means deciding what happens to submissions sitting in it. See workflow.

Day one, in parallel: ask other people for things

These have lead times. Send the requests now.

• An MDM API client. Jamf, Intune, Kandji, Mosyle or Chrome Enterprise. Each vendor’s exact steps are on its connector page.
• An SIS API key, if you run Synergetic, Sentral or Compass.
• SMTP credentials or a Google service account, for outbound email. Nothing emails anyone until this exists.
• A certificate, if self-hosting. An internal CA is fine. See HTTPS and certificates.
• A DNS record for the hostname staff will type. See your own domain or the managed equivalent.
• An OIDC application in Entra or Google, if you want single sign-on. See single sign-on.

Day two: connect the systems

Do these in order. Each one makes the next more useful.

• Email first. Configure SMTP or Google Workspace and send yourself a test. Everything downstream (tracking links, receipts, alerts, scheduled reports) is silent until email works.
• Then the directory or SIS, so people exist. Without people, a repair has nobody to belong to. See Synergetic, Sentral, Compass or LDAP.
• Then the MDM, so devices resolve. Now a serial number typed at the kiosk turns into a model and an owner.
• Then the rest, as you need them: warranty lookup, a ticketing system, SMS, printers, endpoint security.

Every connector has a demo mode. Turn it on to see the feature work before the real credentials arrive, then turn it off. Leaving demo mode on in production is the single most common configuration mistake, and the connectors page flags it.

Day three: people and access

• Create roles that match your team before you create users. Roles are sets of permissions; users get roles. Building the roles first means you never have to go back and fix twelve accounts. See roles and permissions.
• Invite your technicians. See users.
• Turn on single sign-on if you have it, and set a fallback password on at least one administrator account so an identity provider outage does not lock you out entirely.
• Turn on SCIM if your identity provider supports it, so a leaver loses access the moment HR disables them rather than the next time somebody remembers. See SCIM provisioning.
• Enable two-factor authentication on your own account, then require it. See your account.

Day four: the things people will actually see

• Review the email messages. Thirteen templates ship with wording that works; most schools change two or three. Check the ones that leave the school (tracking, ready for collection, purchase receipts, parent notifications). See email messages.
• Set up loan groups if you lend devices, and point one at an MDM smart group so the pool stays current without manual entry. See loan groups.
• Set SLA targets per priority, if you want overdue flagging. See service levels.
• Write three knowledge base articles. The three questions your desk answers most. Published articles appear on the public help centre. See knowledge base.
• Open the kiosk on the machine that will run it and walk through lodging a repair as a student would. See the service desk kiosk.

Before you go live

• Back up SECRETS_MASTER_KEY somewhere other than the server. If you do nothing else on this list, do this. A restored database without the key cannot decrypt its own connector credentials, which turns a recoverable outage into permanent loss.
• Run a backup and verify it. Then restore it somewhere and confirm you can sign in. A backup you have not restored is a hypothesis. See backups and restore.
• Check the licence is active and the plan matches what you bought. See licence and plan.
• Confirm HTTPS works from a machine that is not the server, including on a phone. A missing intermediate certificate often works on a desktop browser and fails everywhere else.
• Set up monitoring so you find out before your users do. See keeping an eye on it.
• Turn off any connector still in demo mode.
• Fill in the compliance page so the answers to your school’s privacy assessment come from the system rather than from memory. See compliance answers.

In the first month

• Watch the audit log for a week. It tells you who is actually using what, which is usually different from what you expected.
• Turn on satisfaction ratings once enough repairs are closing to make the numbers mean anything.
• Add automation rules for the triage you find yourself doing by hand.
• Schedule the report your head of ICT keeps asking for, so they stop asking.