🗄️ Intelligence Storage & Retention

Keep your analytics data tidy — without ever touching your real business data.

TSync's intelligence features (forecasts, replacement-cost estimates, currency-sensitivity figures) produce derived data — numbers calculated from your invoices, stock and rates. Every time they recompute, they write a fresh result. Over months that adds up. The Intelligence Storage console lets you see how much space this derived data uses and keep it under control.

Where is it? Setup → Configuration Center → Intelligence Storage, or go straight to /admin/tsync_intelligence_storage.

Important: this page only ever affects derived analytics data (things the system can always recompute). It never deletes invoices, payments, stock, partners or any of your real records.

What you see

Table volume — one card per derived table, showing its size in MB (split into data and index) and the real, exact row count — current values vs older history. A card turns amber, then red, as a table grows past the warning and critical sizes you set.
Cleanup preview — how many rows a cleanup would remove right now, with a per-rule breakdown, so there are no surprises before you click anything.
Cron run log — the size of the background-job log and how fast it is growing (in the last 24 hours and 7 days). This log is now kept tidy automatically too (see the policy below).
Recent runs — the last calculations: which feature ran, when, how many rows it produced, and whether it succeeded.

Keeping only what you need (retention policy)

The Retention policy is a small form where you decide how long each kind of derived data is kept:

Detailed history (days) — how long to keep day-by-day historical results before thinning them out.
Cache (days) — short-lived computed values.
Demo / test (days) — any sample data created while trying things out.
Failed runs (days) — how long to keep records of calculations that didn't complete.
Cron success / failed log (days) — how long to keep the background-job run log. Successful runs are kept a short while; failed ones are kept much longer because they're useful when investigating a problem.
Max rows per run and Table warn / critical (MB) — the thresholds that colour the volume cards.

Set the numbers that fit your business and click Save policy. Every change is recorded in the audit trail.

The newest, current value for each item is always kept — retention only trims older history.

Cleaning up

Run cleanup now removes the rows the preview listed (expired history, old demo/cache, stale failed runs), in safe batches. You're asked to confirm first. It tells you how many rows it deleted.
Optimize tables reclaims the disk space on the server.

Why didn't the size shrink after cleanup? Deleting rows and freeing the disk are two separate steps. The database keeps the freed space allocated to the table until you optimize it — so right after a big cleanup the MB may barely move. That's normal. Click Optimize tables to actually reclaim the disk; the page then shows the size before → after, so you can see exactly how much was freed.

Both actions ask for confirmation, are recorded in the audit log, and touch only the derived analytics tables.

A daily background job also applies your retention policy automatically, so in normal use you rarely need to do anything by hand — the console is there for when you want to check or speed things up.

Exporting the numbers

Need the figures for a report or a colleague? The Health page (Setup → … → System health) has per-section Export chips — pick Intelligence storage and download the current sizes, retention settings and cleanup preview as JSON or CSV.