Settings & Administration Guide

Settings is where the building blocks behind the other guides get defined: the fields that make up your forms, the types that decide which fields a catalog item carries, the templates a lab request is built from, your company's own details, your team, and the laboratories and examinations you work with.

In one sentence: everything here shapes what a form asks, who can fill it in, and where a request ends up — set it up once, and the rest of the platform follows it.

Platform vs. Company

Almost everything in this guide comes in two flavours, and the same rule applies to all of them:

A Platform badge marks something you can see and use but not change — it's shared infrastructure the platform maintains so you don't have to build it yourself (a common field, a standard template, a default examination). Anything without that badge is yours: created by your company, editable only by your company's owners.

Platform admins have their own equivalent pages under a separate Platform Admin section of the menu, where the same forms create Platform-owned records instead.

Field Definitions

The individual inputs — a single question — that get attached to a subject type or a request template. Reach them from Settings & Administration → Field Definitions (Field library, subtitled "Every input that can be attached to a subject type or a request template. Fields marked Platform come with QC and are managed by admins; the rest are yours to define."). Platform admins have the matching Platform fields page.

Create one (New field): each field has —

Default values understand a small set of expressions, not just plain text: @today, @today+7d (a date offset — the unit letter is required: d/w/m/y), @company.name, @subject.name, @lot.number, @lot.supplierName, @lot.expiryDate, and similar. These resolve automatically wherever the field is used — a request raised from a lot, for instance, arrives with its lot number already filled in.

Width isn't set here. How much of a row a field takes up is set separately, by hovering the field where it's actually used — on a subject type's Preview pane, or a request template's Preview pane (see below) — and choosing Full, Half, One third or One quarter width. A company user sees a note that an always-included platform field's width is set by platform admins, not by them.

The list shows each field's type, scope, owner (Platform/Company badge), whether it's mandatory, when it was added, and its order. Deleting a field that's in use warns you first, since removing it also removes any recorded values against it.

Adding a field from elsewhere in the app. Wherever you're attaching fields to a type or a template, the same picker opens — From library (pick an existing field) or Create new (define one on the spot and attach it in the same step), filterable to All fields or Yours.

Subject Types

A type decides which fields a catalog item of that category carries — see Types in the Catalog Guide for how this looks from the catalog side. Reach them from Settings & Administration → Subject Types (New type).

Create one: Name, Category (Product / Raw material / Packaging / Environmental), Description, an auto-derived Slug, an Active checkbox, and — platform admins only, at creation — a System type checkbox: "Platform-wide: visible to every company, and only admins can edit it."

A type's dossier has two sections:

• General — the record's own fields.
• Item — fields recorded per lot or delivery. This section also lists a fixed, non-editable set of built-in item fields every raw material and packaging type gets automatically: Supplier lot number, Supplier, Quantity received, Unit, Received date, Expiry date.

Each section has its own Add field (opening the field-library picker above) and its own Fields / Preview toggle — Preview is where you hover a field to set its width, exactly as described under Field Definitions. Making a field on an in-use type required warns you first, since existing records may not yet have a value for it.

The list shows each type's category, scope (Platform/Company), how many fields and subjects it defines, when it was added, and whether it's active. Deleting a type still in use is refused with a count of what's using it.

Request Templates

A template decides which fields appear on a lab request's Prepare form — see the Lab Requests Guide for how a template is filled in. Reach them from Settings & Administration → Request Templates (Templates for your company, Platform templates for admins — "Request templates every company can use. Companies still create their own; these supplement them, and a company cannot change one.").

Create one (New template): Name, Description, and optionally Copy fields from an existing template to start from instead of a blank form.

A platform template shown on your company's list is View-only ("Open read-only — platform templates are composed by admins.") with a Copy action beside it — "Create a template of your own, starting from this one's fields" — the way to adapt a platform starting point without being able to change the original for everyone else.

A template's dossier covers:

• Applies to — which subject type (and, optionally, one specific subject) this template is used for. This is the chain request creation resolves against automatically.
• Request fields — the fields this template asks for, each with a Required toggle, a Customise option, and drag-to-reorder. Platform mandatory fields show in their own Always included strip, since they can't be removed from any template.
• Preview — the same Fields/Preview toggle as a subject type, for setting each field's width on this specific form.

Customise lets a template reword or re-default a field without touching the field itself — "This changes the field on this template only. The field itself, its type and its choices stay as they are — every other template using it is untouched." You can set a label override, a default-value override (same expressions as above), and which section it falls under on this form. A customised field shows an amber Customized badge, with the field's own values visible in its tooltip. Leaving an override blank resets it back to inheriting from the field.

An inactive template stays on any request already using it but can't be picked for new ones — useful for retiring a template without disturbing history.

Company Settings

Your organisation's own details — reached from the company-name menu in the sidebar (Company settings), not from a dedicated nav item.

• Company — name, contact person, email, phone.
• Tax & billing — Tax ID, bank account, a "Registered for VAT" checkbox.
• Address.
• Tracking numbers — the auto-format new requests' tracking numbers get, e.g. {dd}{mm}{yy}-{seq_day:4}. Available tokens: {dd} {mm} {yy} {yyyy} {seq_month} {seq_day}, and any of them can be zero-padded with :width ({seq_day:4} → 0007). Saved independently of the rest of the page.

List Configuration

Which columns your list pages show, in what order, and what each is called — reached from the same company-name menu (List columns). Currently covers the Requests list.

Two panes: Shown in this list (drag to reorder, edit the header text, set alignment, toggle sorting — greyed out with a tooltip where a column genuinely can't be sorted — and remove), and Available columns (search, filter by tag — Request / Platform field / Your field — and add). Reset to default discards your company's own arrangement entirely, so the list goes back to following whatever the platform ships from then on, rather than freezing today's default in place.

Team

Who in your company can sign in and work with lab requests — reached from Team (an owner-only page; there's no platform-wide user list, since every account belongs to exactly one company).

Shows Name, Username, Email, Role (Owner or Member), and Joined date. Add member creates an account directly, rather than sending an email invite: First name, Last name, Email, Username, and an Initial password (at least 8 characters) you share with them yourself so they can sign in the first time. Every member added this way is a plain Member — there's no role picker here, and no edit/remove actions on an existing member yet.

Laboratories

The labs you send samples to — reached from Laboratories (Platform laboratories for admins). The company list explains the split plainly: "The labs you send samples to. Ones marked Platform come with QC and are managed by admins; add your own for anything you work with directly."

Register one (Add laboratory): Name (required), Address, City, Country, Phone, Email, Website — the same short form used everywhere a laboratory is created, including inline from a request's laboratory picker.

A laboratory's dossier carries its contact details, plus a Portal access panel:

• An Enable / Disable toggle. Disabling asks for confirmation but keeps the portal link and any password saved, so re-enabling doesn't mean starting over.
• A read-only portal URL, with Copy and Regenerate.
• An optional password — Set password / Change password, and Clear password (confirmed, since clearing it means the link alone gets in).
• Open portal, to see exactly what the laboratory sees.

The Laboratory Portal

A laboratory doesn't need an account in SmartQC to work a request — the portal link gets them in on its own, optionally behind the password above. It's a bare, branded page showing only the requests assigned to that laboratory: a list, and from there the same request detail a request's Laboratory stage shows on your side — status and the same progress buttons, request details (read-only), examinations, samples, documents, and comments. This is how a lab that has no reason to log into the platform proper still moves a request from Accepted through to Done.

A laboratory whose own systems can call SmartQC directly — a LIMS, for instance — can skip the portal page entirely and use an API access token from that same dossier instead; see the API & Access Guide.

Examinations

The individual tests that can be asked for on a lab request — reached from Examinations (Platform examinations for admins). Deliberately minimal: just a name. There's no code, unit, method, price or turnaround field — an examination here is simply what's being asked for, not a full lab-service catalogue entry.

Create one (New examination): a single required Examination name. The same one-field form appears inline wherever a request's test picker doesn't find what you typed — see Tests in the Lab Requests Guide — so you're never sent away from the request to define one.

Platform examinations show on your company's list as Platform default, with no edit or delete controls, next to your own, which you can freely manage.

PDF Templates

The document a lab request prints as — your letterhead, the sample table, your terms — reached from PDF Templates (Platform templates for admins, used as the fallback when a company hasn't set one up of its own). This is what generates when someone clicks Preview PDF on a request dossier.

A template can apply to one specific request template, or to General (all requests) as a catch-all. The editor is two panes: a multi-page rich-text document on the left, and an Available tags sidebar on the right — click a tag to insert it at the cursor.

Merge tags pull live data into the document when it prints:

Layout tools: margin controls, a one/two/three-column choice per page, ready-made two- and three-column section inserts, and Add page for a multi-page document. Preview renders true-to-size pages using a real request's data, and flags any tag that couldn't be resolved so you catch a typo before it reaches a printed document.

A Platform template on your company's list is read-only — the editor is locked, with a banner explaining that making changes means creating a template of your own rather than editing the shared one.

Who can change what

See Who manages what in the documentation overview for the same table in context with the rest of the platform.