Training › Module 05

Module 05 — The Administrator

IT and systems administrators — the people responsible for the tool itself, not for the information requests · 30 minutes (20 minutes content, 10 minutes hands-on exercise) · Prerequisites: Module 00 — Foundation (roles, the disclosure lifecycle at a glance)

In a hurry? Jump to the quick-reference card or the knowledge check — or print the all-roles reference.

Learning objectives

By the end of this module you will be able to:

1. State exactly what the Administrator can and cannot do — configuration only, no access to cases, documents, reports, or packages.
2. Describe the activation and first-user flow, and the purpose of the setup wizard.
3. Explain how users are invited (domain-restricted) and that SSO and SCIM provisioning exist.
4. Explain why the agency name must be set — external exports are blocked without it.
5. Explain that OCR and AI detection are optional cloud features, and what still works without them.
6. State that the regime is fixed at activation and cannot be changed in Settings.
7. Brief operational staff on what the Administrator’s configuration means for their day-to-day work.

1. The role in one sentence

The Administrator configures the system and keeps it running — and can see nothing of case content. No cases, no documents, no reports, no export packages. This is deliberate: system access and case access stay separate. If an Administrator also needs to work on requests, they use a separate account with a case role — each account holds exactly one role.

Two things worth knowing up front:

• The Lead shares nearly all system configuration (settings, branding, departments, user management). What stays unique to the Administrator is granting the Administrator role itself.
• The Administrator has no route into cases at all, so the export screen is unreachable for them. (Case roles that lack a package tier see that package’s card disabled with “Your role cannot emit this package type”.)

2. Activation and the first user

• Veil ships with a pre-generated activation code. The first user to log in enters this code at the activation screen and is promoted to Administrator.
• The new Administrator then completes the setup wizard — a 7-step initial configuration covering organisation details, departments, roles, AI configuration, and related settings.
• The regime (LGOIMA or OIA) is set at activation and cannot be changed in Settings. Choose correctly at deployment; a wrong regime is a redeployment conversation, not a settings toggle.

This module keeps setup at orientation level — the deployment guide covers the specifics of each wizard step and the environment configuration behind it.

3. Users, SSO, and SCIM

• Invitations — the Administrator invites users via email. Invitations are domain-restricted to the organisation’s configured email domain.
• Single sign-on — Microsoft (Azure AD / Entra ID) SSO is the primary sign-in method in production, with a credentials fallback for development.
• SCIM provisioning — Azure AD can push user and group changes to Veil automatically, supporting automated onboarding and offboarding.
• Visibility is never self-served. The Administrator (or the Lead) sets each user’s role, department, and visibility. Only an Administrator can grant the Administrator role.

Configuration details (app registration, SCIM tokens, and so on) are in the deployment guide.

4. Organisation identity and branding

The Administrator sets the organisation’s identity — the agency name and branding that appear on generated documents.

The agency name is not cosmetic. Generating an external package (Requester or Ombudsman) requires the agency name to be set; if it is missing, the export is blocked with an explanatory message. Set it before operational staff reach their first release, not after.

5. AI and cloud services — optional, with known consequences

AI detection and OCR are cloud features the Administrator configures. The review, redaction, export, and audit workflow for already-processed documents always works. When a service is absent, the consequences are predictable:

• Without OCR — no upload can be processed. Every document format (including DOCX, XLSX, TXT, EML, and MSG) is converted to a canonical PDF and read through the OCR service, so all uploads go to “Error” until the service is available.
• Without AI detection — pattern detection of NZ personal identifiers still runs on every document; documents complete with pattern detection only, and reviewers lose the contextual AI layer (legal privilege, free-and-frank, commercial sensitivity suggestions).
• Audio and video are never screened — transcription exists in the code but is not enabled in any standard deployment. Media files upload but are not transcribed, detected, or redacted.
• Microsoft 365 / SharePoint — the “Import from SharePoint” tab is always visible on “Document Ingestion” and is enabled when the instance is connected (a one-off administrator task covered by the deployment guide). In-app import and export-back are coming soon; connected instances currently see a “SharePoint import — coming soon” panel.

6. Custom detection rules

“Custom Rules” — agency-specific keywords, patterns, and entities mapped to withholding grounds, running alongside the AI — belongs to the Lead and the Senior Reviewer; the Administrator does not have access to this screen on the current release. They are detection rules, not redaction rules: a match becomes an ordinary detection for a reviewer to accept or reject, and only Active rules run (Draft rules never match documents). The full walkthrough is in Module 01, section 8.

Worth knowing even so: rules detect, they never redact, and their matches surface inside cases — so feedback on rule quality comes from the Lead and reviewers, and questions about rule behaviour should go to them.

7. What to tell operational staff

Because the Administrator cannot see cases, staff will come to you with questions you can only answer from configuration. Brief them proactively on:

• Whether OCR is configured — if it has never been configured, uploads fail with a processing error naming the missing Document Intelligence credentials; if it is configured but the service is down, they fail with “OCR service temporarily unavailable…” and retry when it recovers. Neither is a document fault — staff should not raise it as one.
• Whether AI detection is configured — if not, reviewers see pattern detections only.
• Whether Microsoft 365 is connected — if the “Import from SharePoint” tab is greyed out with a “Not configured” chip, the integration is not enabled; staff should use direct upload.
• That the agency name is set — so external exports are not blocked at the worst moment.
• That you cannot unblock case-level problems — a blocked export, a frozen document, or a review question goes to the Lead or a Final Approver, not to the Administrator.

Hands-on exercise

Work on the demo instance with an Administrator account.

1. Confirm the wall. Check your left navigation: confirm you have no route into cases, “My Queue”, or “Reports”. Note what you can see.
2. Review organisation identity. Open Settings and locate the organisation identity/branding configuration. Confirm the agency name is set, and note where a missing name would surface (blocked external exports).
3. Check the regime. Confirm the instance’s regime is displayed but not editable in Settings.
4. Invite a user. Start (do not complete) an email invitation and observe the domain restriction on the address field.
5. Confirm the rules boundary. Check that “Custom Rules” does not appear in your navigation — rule authoring belongs to the Lead and the Senior Reviewer. Note where you would direct a staff member who asks for a new detection rule.

Quick-reference card