System & Health: every screen, column and action¶
These screens are how you tell whether the platform itself is working, and they are the first place to look when a symptom spans several modules.
Process Manager¶
Actions: Logs, Restart, Stop.
Background work — imports, report generation, synchronisation, outbound email — runs as processes here. Logs is where a failure explains itself; Restart brings back a worker that has died; Stop halts one that is misbehaving.
Restart is not free
A worker restarted mid-message leaves that job in IN PROGRESS with nothing consuming
it — the job neither completes nor retries. Prefer letting a job finish where you can,
and check what is running before restarting.
Import¶
Import Type, Import Status, Log, Created At, Summary, with a child-process view
of the same columns.
The child view matters for large imports: one import spawns several processes, and the parent completing does not mean every child did. An import reporting success with fewer rows than expected usually has a child that failed, visible only here.
Health Check¶
The widest diagnostic in the product, and the one that answers "did we lose anything on the way in":
| Column | What it holds |
|---|---|
| Baseline | What the source reported |
| Current | What NxSAM holds now |
| New | Present now, absent from the baseline |
| Fixed | In the baseline, resolved since |
| Repeated | Seen in both |
| Re-open | Closed previously, present again |
| Total | The reconciliation total |
| Type | What kind of assessment produced the row |
| Match Key | The field used to decide two findings are the same |
| Classification | How the comparison classified the row |
| Severity, Status, Sub Status, SLA Expiry | The finding's own values |
| Issues | The findings behind the number |
Match Key is the field to check when a comparison looks wrong
Everything on this screen depends on how two findings are decided to be the same one. If New and Fixed are both unexpectedly high while Repeated is near zero, the match key is not matching — findings are being seen as fixed and new rather than as the same finding twice.
That is a matching-configuration problem, not a data-loss one, and the numbers look alarming in exactly the way real data loss would.
Re-open distinguishes a finding that came back from one that never left. A high re-open count against a specific asset usually means a fix that does not survive a rebuild or a redeploy.
Beats — scheduled jobs¶
Module, Sub Module, Last Sync Status, Last Sync Type, Last Sync Initiated At,
Last Sync Processed At, and per-run Sync Sub Module, Sync Type, Sync Status,
Sync Initiated At.
These are the periodic jobs that keep derived data current — recalculating SLA states as dates pass, refreshing pre-computed statistics.
Initiated At against Processed At is the useful pair. A job initiated and never processed is stuck; one where the gap is growing run on run is falling behind, and the figures it maintains are increasingly stale.
Figures wrong by a fixed interval rather than randomly are almost always a beat that stopped. Nothing else in the product reports an error for it.
Active Directory¶
Sign-in can be delegated to Active Directory, and more than one directory can be configured. Each is held as a named account and the screen lists them as cards rather than as a single form.
Pick an account from Select Account, then Configure. An account with nothing configured shows an empty state rather than a blank form — which is the difference between "not set up" and "set up and broken".
| Field | What it holds |
|---|---|
| AD Type | Which directory product and protocol variant |
| Domain | The directory host |
| Port | 389 for LDAP, 636 for secure LDAP — the form states both defaults |
| User Name Prefix | The prefix prepended to a username when binding |
| Admin User Name | The service account used to search the directory |
| Users Base DN | Where in the tree user accounts are looked up |
| Certificate | The uploaded certificate — shown only on Secure LDAP directories |
Choosing Secure LDAP is what reveals the certificate upload on the form and the Certificate row on the card. A directory that is supposed to be encrypted and shows no Certificate row is configured as plain LDAP, and its bind traffic is in the clear.
Each card carries Edit; a directory that is not the last remaining one can also be deleted.
User field mapping¶
The lower half of the form maps directory attributes onto NxSAM's First Name, Last Name, Email, Mobile and Username.
The Username mapping must be the AD login name
The form says so, and it is the one mapping that cannot be corrected later without orphaning accounts. Map it to the attribute users actually sign in with, not to a display name that looks right in a directory browser.
Everything else is cosmetic and can be remapped. This one decides whether a returning user is recognised as themselves.
Test Connection¶
Test Connection reports Connection Tested Successfully or Connection Failed before you save. A directory that saves but does not bind produces sign-in failures for real users, and it surfaces at their next sign-in rather than at yours.
AD logs¶
The panel above the accounts shows the last 100 lines of directory activity, with Refresh and Load Logs. It is where a bind failure explains itself — wrong base DN, expired service-account password, an untrusted certificate — and the first place to look when authentication works for some users and not others.
SLA configuration¶
Severity, Asset Type, SLA Duration, Asset Properties.
SLA duration is set per severity and asset type, and can be narrowed further by asset property — so a Critical on an internet-facing production system can carry a shorter deadline than the same Critical internally.
Changing a duration re-derives expiry dates, which can make a batch of findings overdue with no data change at all.
Asset limits¶
Client, Web Limit, Mobile Limit, Network Limit, Image Limit, Think Client
Limit.
Licensed ceilings per asset type per client. Worth checking before a large onboarding — discovering the ceiling midway through a bulk import means a partial inventory and a reconciliation afterwards.
Risk score properties¶
Asset Type, Properties — which asset attributes feed the contextual risk score, per
asset type. An estate with these unset produces a risk score that is severity with extra
steps, and a "top risky assets" list that ranks nothing meaningfully.
Tags¶
Four tables, one per asset domain: Application, API, Network and Audit
tags. Each carries Tags Id, Tags Name, Created By; audit tags additionally carry
Clients.
Export Tags produces the list. Tags are shared within their domain, so renaming one renames it everywhere it is applied — there is no per-use copy.
System configuration¶
| Screen | Columns |
|---|---|
| Modules | ID, Module, Created By |
| Controllers | ID, Class, Method, Created By |
| Permissions | ID, Module, Permission, Code, Created By |
| Queries | ID, Query, Task, Status |
| Task info | Info Id, Info Name |
These define what the platform can do and who may do it. Permissions map a code to a module — roles grant those codes, so a permission missing here cannot be granted however the role is configured.
Queries are maintenance operations bound to tasks. They are administrative tooling rather than a working screen, and running one without knowing what it does is not recoverable through the interface.
System settings¶
The switches that change how the whole platform behaves. Most are described with the module they affect; one is easy to miss because it lives here and bites elsewhere:
Only 1 On-going VA Audit per Asset — when on, a network VA audit cannot be requested for an asset that already has one in progress. The request fails at the point of saving with a message naming the rule. It exists because two concurrent scans of one host produce two sets of findings for one state, and reconciling them afterwards is worse than waiting. Turn it off only where genuinely parallel assessments of one asset are intended.
AI configuration¶
Two screens. The first is a form; the second is the queue it feeds.
AI Configuration¶
| Section | What it holds |
|---|---|
| Provider & Credentials | The AI Provider and its API key. The key is stored encrypted and never shown again once saved |
| Evidence Analysis Model | Which model reads the evidence. Larger models read complex evidence better and cost more per run |
| Analysis Schedule Interval | How often queued evidence is analysed — every 15, 30 or 60 minutes |
| Per-Audit Cost Cap ($) | Spending limit per audit. Analysis pauses when spend hits this cap. Negative values are not allowed |
| Evidence Analysis for RLCM | The master switch: let the platform review uploaded audit evidence and suggest compliance findings |
| Apply to Modules | Which assessments it runs for — Compliance, TPRM, or both |
If the AI service is not reachable from this deployment the screen shows AI service not configured and a Retry; nothing below it can be saved until that clears, and the message says to contact the administrator of the deployment rather than of NxSAM.
Set the cost cap from the evidence, not from the budget. A cap is spent by reading files, so an audit with a large evidence pack exhausts a small cap early and its remaining controls stay pending indefinitely. An auditor reporting that "the AI stopped halfway through" has almost always met the cap.
AI Queue Details¶
Reached from the AI Queue Details button on the configuration screen, which opens it in a new browser tab so the configuration stays where it was.
| Column | What it holds |
|---|---|
| Queue Details | The queue's key and what kind of job it is |
| Status | Where the run is |
| Created At | When it was queued |
| Actions | Re-analyse this queue — runs it again |
Re-analysing is safe to repeat: it reads the same evidence again and replaces the previous evaluation. It also spends against the same cap, so a queue re-analysed to get past a cap will stop in the same place.
Analytics custom charts¶
Custom chart cards carry Refresh always, and Edit and Delete only on charts you own.
Charts on a shared profile are read-only to everyone but their owner
A dashboard profile shared with you shows its charts with Refresh alone. That is deliberate: a shared profile is one definition seen by many people, so an edit would change what every viewer sees, and a delete would remove it from all of them.
To change a shared chart, ask its owner — or take your own copy of the profile, where the charts become yours to edit.
Refresh re-runs that chart's query alone. Useful when one widget looks stale and the rest of the dashboard is current — which points at that chart's query rather than at the warehouse sync.