---
title: Administration & governance tools
description: The TSync admin consoles: Health & Release Readiness, the audit log, Design Governance and Agent Security — what each one watches, and when you actually need to open it.
product: TSync Intelligence 11.3.6
language: en
canonical: https://docs.tsync.pro/admin-governance-tools/
source: https://docs.tsync.pro/llms.txt
---

# Administration & governance tools

Beyond the everyday features, TSync has a set of **admin consoles** that watch the health, history and safety
of the system. You don't use them daily, but it's good to know they exist and what they answer.

## Health & Release Readiness

**`/admin/tsync_health`** — a single dashboard that checks the system is correctly set up: are the modules in
a consistent state, are the finance/accounting chains wired, are migrations applied, are there configuration
gaps? It runs the same quality checks used when a release is built, but here in **read-only** advisory mode
(warnings and info, never blocking). Open it after an upgrade, or when something feels off, to get a fast
"is everything wired?" answer.

**The "Release Readiness" section loads a few seconds after the rest of the page.** That is deliberate:
producing it runs the full set of release checks over every file, which takes far longer than everything else
on the page put together. Rather than make you wait for the whole page, TSync shows you the rest immediately
and fills that section in when it is ready — you will see a short "running the release gate" note with a
placeholder while it works. If it cannot be produced, it says so instead of spinning forever.

### Files left over from older versions

An update **adds and replaces** files — it **never deletes**. So a file retired from the product three versions
ago stays on your server indefinitely. Nothing uses it any more, but it is still there.

That had an unexpected consequence: this page sometimes reported problems that **do not exist in the product**.
It happened exactly that way — a security alert pointed at a file that had been retired three months earlier. It
was searched for in the code and in the archives; it was in neither. It was only on that one server.

The section now lists the files that are on your server and **were not in the delivered archive**. A leftover
`.php` file shows as a warning; anything else, as information.

> **TSync deletes nothing.** It tells you what it found and where; you delete it on the server once you are
> satisfied. An upgrade that removes files on its own is precisely the kind of operation that cannot be undone.

Two things will never appear in the list, so it stays readable: the system's own working files (logs, caches,
your configuration with its passwords) and **separately installed modules** — a module you installed yourself is
not a leftover, and offering it up for deletion would be the worst mistake this could make.

### External integrations — which ones still answer

The same page carries an **External integrations** panel: one row per integration your installation can talk
to — ANAF, the Fisc, a bank, a CRM, a messaging provider — with the result of that integration's **last real
call**, when it happened and where it went.

The page **makes no outbound call of its own** while you look at it. Probing every provider on each page load
would be traffic caused by the act of looking, at services that limit how often you may call them; a health
page must not become the problem it reports.

Three states, and the third is the point:

| State | What it means |
|---|---|
| **works** | the last call answered |
| **does not answer** | the last call failed — the count beside it is how many failures in a row |
| **never checked** | nothing has ever called it from this install |

**"Never checked" is the one to read carefully.** If nobody presses the button, the absence of failures is not
evidence of health — that is exactly how a search endpoint that had gone dead at every client survived
unnoticed across an API change. A row that has answered but not for a long time is also marked as such.

The list is built from the integrations the product **declares**, not from what has been used, so an
integration nobody touches still appears. Nothing about the content of a call is stored — no addresses, no
request or response bodies; only a result, a short status token and the timestamps.

## Security console

**Configuration Center → Governance & audit → Security console** (also in the Setup menu). One screen that
gathers what the security mechanisms already in place are reporting: anti-scraping, active blocks,
authentication, sessions, permissions, public routes, data access, agent tool calls and the latest audit
entries.

**It refuses nothing.** The page is read-only — it does not block a user, cancel a session or stop a request.
It shows you what is happening so you can decide.

Each card says plainly which of four things is true:

| | |
|---|---|
| **reading** | there is a source, and this is what it says |
| **switched off** | the mechanism exists and is off — which is itself the answer |
| **nothing to report** | it is on and genuinely has nothing to show |
| **not built** | there is no source yet, and the card says what it would take |

That last one matters more than it looks. *"0 CSRF rejections"* and *"nobody counts CSRF rejections"* look
identical on a screen and mean opposite things — and the reassuring one is the false one. Two cards are
honestly marked **not built** today: CSRF rejections and file integrity.

The overall posture counts **switched off** and **not built** separately, because the first is your decision
and the second is ours.

**Who sees it:** administrators. For anyone else, grant *Security console → View* in permissions.

## Portal access

**Who can sign into the customer portal** — one list, kept current, with the actions to fix it. In the sidebar
under *Customers*.

Every contact appears with its customer, the economic partner behind it, and two things you cannot see from
the customer screen without opening it: **the state of its access** and **when it last signed in**.

### Three states, not "has access / doesn't"

- **Active** — the contact is active **and** has a password. It can really sign in.
- **Blocked** — it cannot sign in, whatever else is true.
- **No password** — it is active but has **no password**, so it still cannot get in.

That third state is why this screen exists. Allowing access for somebody with no password grants nothing —
so when you do it, the system tells you **who** it did not help, and offers the button that actually fixes it:
*Send set-password e-mail*.

### The actions

Tick rows, then choose. Each one asks first and tells you **how many contacts** it will touch, then reports
how many rows really changed.

- **Block access** — they cannot sign in again until you allow it.
- **Allow access** — with the warning above for contacts that have no password.
- **Sign out now** — see below.
- **Send set-password e-mail** — only to the selected contacts that have no password.
- **Remove the password** — the contact stays, with all its history; it simply cannot sign in until a new
  password is set.

### "Block" and "sign out" are not the same thing

Blocking stops the **next** sign-in. Somebody already signed in stays in until their session expires. **Sign
out now** ends the sessions open at this moment.

If you need somebody out immediately, use both.

On some installations sessions are stored in a way this screen cannot reach. It will say so plainly rather
than claim to have signed anybody out — blocking still works.

### Who sees it

Anybody with the **customers** permission: viewing shows the list, editing enables the actions. There is no
new permission to configure.

Everything any of these actions does is written to the audit log, with who did it and to how many contacts.


## Audit log

**`/admin/tsync_audit`** — an **append-only** record of important changes: who changed a setting, who posted
or reversed an accounting entry, who ran a repair, and so on, with the old and new values. It is the place to
answer "who changed this, and when?". Entries are never edited or deleted.

## Design Governance

**`/admin/tsync_design_governance`** — keeps the interface consistent. It measures UI "drift" against an
accepted baseline (stray inline styles, off-scale spacing, raw colours instead of brand tokens), shows it per
file, and lets an admin **set a new baseline** once cleanup is done. It's a maintenance tool for keeping the
look uniform — it doesn't affect your data.

## Agent Security (foundation)

**`/admin/tsync_agent_security`** — the groundwork for safe automation/AI. It holds a read-only **policy**, a
deny-by-default **tool gateway** (any automated action is logged and must be allowed), and a rule that all
external content — web pages, e-mails, uploaded files, bank statements — is treated as **untrusted data,
never as instructions**. It is **inert by default** (no automated actions run); it's there so that when
automation is enabled, it is governed from day one. See also the
[Intelligence Layer](modules/tsync-intelligence.md).

## Operational data quality

**`/admin/tsync_data_quality`** — what the product knows about the state of your own data: payment modes with
no financial account behind them, a metric that has stopped being refreshed, records that contradict each
other. Each finding carries a severity — **critical**, **warning** or **information** — and belongs to one of
four components: **Data integrity (DIS)**, **Operational consistency (OCS)**, **Source reliability (SRI)** and
**Missing data (MDI)**.

The page is in your language now, severity included. Until v11.2.1 the severity was printed raw, in English,
*inside the coloured pill* you read at a glance — which is exactly where there is no time to translate
anything. The component names lead with the name and keep the abbreviation in brackets, because an acronym
tells something only to a reader who already knows.

> A finding here is often the cause of a symptom you are chasing somewhere else. "Payment modes without a
> financial account" is, for example, why payments do not move treasury.

## Event Inspector

**`/admin/tsync_event_inspector`** — the log of cross-module events: what was raised, when, with what payload,
and which listeners answered. Use it when an automation did not run and you need to know whether the event
ever happened.

**Replaying an event now asks for a real confirmation and is a POST.** Replay re-raises the event on the bus
and runs **every** listener attached to it — it can create records, send messages and post entries. Until
v11.2.0 it was an ordinary link, so any page an administrator happened to open could trigger a replay with
their session, without a click and with nothing shown on screen. The confirmation now says what will happen
rather than asking whether you are sure.

## Failed jobs queue

**`/admin/tsync_dead_jobs`** — the background jobs that gave up after their last retry. This is the page you
open when something stopped happening in the background.

Two actions, and their confirmations now tell you what each does: **re-queue** ("they will be queued again and
run on the next cron pass") and **delete permanently** ("they will be deleted for good; this cannot be
undone"). The count reads *failed jobs: 1* rather than a sentence with a plural that only works in English.

## These consoles are in your language

Module Health, the Event Inspector, Operational data quality, Agent Security and the failed-jobs queue were
shipped in English inside a product that is otherwise used in Romanian and Russian. They are translated now,
including their status words: *green / amber / red* used to render raw, so the page expected an operator to
know that "amber" meant "needs attention" — as a colour name, in English, among otherwise translated labels.

> These consoles are for owners/administrators. Who can open each one is controlled by
> [permissions](staff-roles-permissions.md); in hub mode they're reached from the
> [Configuration Center](configuration-center.md).