First-run setup

The system arrives with content already in it: eight update types, one email template and one global checklist form. Day one is a pass over what shipped and a change to whatever does not suit the organisation — not building from nothing.

The order

#	Screen	What is decided there	Why at this point
1	Access management	Who may sign in, and who gets administrator rights	Every later step is done by people who need to get in
2	Integrations and connections · Support center	That the connections work and the inventory is being read	A setting that rests on an empty inventory looks correct and is not
3	General settings	System title, default calendar view, items per page, schedule cadence	The two cadence numbers decide the next due date of every host in the inventory
4	Update types and templates	The types themselves, what is picked in each, and the message template	The scheduling wizard opens on the type — before this there is no first schedule
5	Checklist forms · Task templates	What is filled in and done during an event	Derived from the types just settled
6	Configuration freeze	Periods in which changes are not to be scheduled	Decided once a year, and convenient to do here
7	Recipient groups → Scheduled reports → Alert rules	What leaves the system and to whom	Decide who receives before deciding what is sent
8	Custom fields	Fields the register needs and does not have	A field is easier to design once you have seen real records

Who gets in first

The first configuration is done by the administrator set at deployment time. This step is the move from that one administrator to access decided against the corporate directory.

The decision is recorded in AD group allowed to sign in, Admin AD group (optional) and Admins by id. Changes save immediately.

Before configuring anything that rests on the inventory

The support center shows a System information panel with the rows that matter on setup day: system version, server uptime, database, server inventory and the number of configured connections. When a source is unavailable the panel says so and states that the screen is showing demo data, rather than showing empty rows.

On the connections side, two actions prove a connection rather than a saved configuration: a connection test against the saved configuration and send a test email. Both are worth running before anyone schedules a first event that sends invitations.

Some connections are set at deployment time and others are configured on screen; either way their state is shown.

The settings decided once that affect everything

System title is what appears in the browser tab. An organisation that prefers its own wording sets it here once.

Schedule cadence is two numbers in months: B2B / T1 / T2 (default 3) and T3 / MGM (default 6). Both the cadence and the next due date of every host are derived from the same value, so the two cannot disagree.

External site access decides what happens when someone clicks an external support link. The three options are "Unknown — show the address first", "No access — show the address to copy" and "Access available — open directly in a new tab". On a disconnected network the second is the right one, and it saves the user a tab that hangs on an error.

Update types are the gate to first use

The scheduling wizard opens on the update type, and everything after it follows from that choice: what is picked in the next step (servers, equipment or databases), whether the pick is mandatory, and one template that serves the email, the calendar invitation and the ticket — so the three cannot say three different things.

The eight types that ship are a starting point. The name, colour, template and pick kind of each can be changed, and more can be added.

What can wait until tomorrow

• Checklist forms — one global form is already active. A form dedicated to a particular update type replaces it for that type.
• Configuration freeze — a freeze period is marked on the calendar and appears as a warning in the wizard. It does not block scheduling. Holidays appear on the calendar with no configuration and no network access.
• Custom fields — a field marked required applies from the next save onward, never retroactively to records that already exist.
• Access tokens — needed only if a script or another system calls this one. A token is shown once, when it is created.

The next step after setup is Supported browsers, which decides what users will open the system on, and Version upgrades when the next package arrives.