Skip to content
English
  • There are no suggestions because the search field is empty.

12.06 Reviewing and Repairing Data Integrity Issues

SimpleRisk scans for corrupted text and mismatched file content on a weekly schedule, then surfaces what it finds on a dedicated review page reachable from the Settings Hub, the Health Check page, and an admin notification. This article covers what the scan looks for, how to repair what it finds, and why there's no way to dismiss an issue.

Why this matters

Corrupted data doesn't usually announce itself. A risk imported from a spreadsheet years ago can carry a handful of stray, invalid bytes in a text field — left over from a character-encoding mismatch during that import — and sit there unnoticed until something downstream trips over it. A single bad byte in a risk or asset description can be enough to break an entire list view elsewhere in SimpleRisk, so the record that's actually broken often isn't the one an admin is looking at when things start going wrong.

SimpleRisk runs a background scan that looks for exactly this class of problem: invalid text encoding left behind by old imports, and files whose stored content no longer matches their recorded size. Both are surfaced on one review page where you can see what's broken, apply a suggested fix, or go find and re-upload the file. Nothing here requires you to go looking — the scan runs on its own schedule and puts what it finds in front of you.

Before you start

Have these in hand:

  • Admin permission. The Data Integrity page, its Settings Hub tile, and the underlying repair API all require it.
  • A sense of how the affected record was created. Most text-encoding issues trace back to a CSV or Excel import through the Import-Export Extra, where the source file was saved in a legacy encoding rather than UTF-8. Knowing that helps you sanity-check a suggested fix before applying it — you're not guessing at what the text was supposed to say, you're confirming an automated cleanup got it right.

What the scan looks for

The scan checks two kinds of problems, run weekly in the background and available on demand from the review page:

  • Text encoding. Free-text fields on risks, assets, asset groups, template groups, and control tests are checked for invalid character encoding and stray control characters — the signature left behind by a spreadsheet import that wasn't saved as UTF-8.
  • File content mismatch. Uploaded files (compliance evidence, risk attachments, questionnaire attachments) are checked against the byte count SimpleRisk recorded when they were stored. A mismatch means the stored content is no longer what it should be — a corrupted upload, most often.

You don't have to wait for the weekly run. The review page has a Scan Now button that triggers the same scan immediately; if a scan is already running, a repeat click just tells you one's already in progress rather than queueing a second.

Getting to the review page

The Data Integrity tile only shows up in the Settings Hub (Settings cog, top-right of any page) when there's something to review — a clean instance won't show it at all. The moment the scan finds an open issue, the tile appears and is added to every administrator's favorites, so it sits in the Favorites row with a count of how many issues are open. It's an ordinary favorite: you can unstar it, though the next scan that still finds open issues adds it back. You'll also get a one-time notification the first time a scan turns up something to review, and it clears itself automatically for every admin once the queue is empty again.

Click the tile (or navigate to it directly if you've bookmarked it) to open the review page, which is split into two tabs: Text Encoding and File Encoding. Each tab's label carries its own open-issue count, and only tabs with something open are worth checking — an empty tab still displays, it's just empty.

Step-by-step

  1. Open the Text Encoding tab first. Each row shows the record's Location (table, column, and record number), the Broken Value as it's currently stored, and a Suggested Fix — a pre-computed correction you can edit before applying. The suggestion is usually right; it's worth a quick read against the broken value rather than a blind click, especially on anything that looks like it might have been more than punctuation.

  2. Repair one record at a time, or several at once. Click Repair on a single row to apply its suggested fix immediately — there's no confirmation step, so double-check the Suggested Fix field first if you've edited it. To handle several records together, check the box on each row you want (or use the header checkbox to select every row currently listed), then use Repair Selected from the bulk bar that replaces the toolbar once you've selected anything. Bulk repair applies whatever's currently sitting in each row's Suggested Fix field, edited or not.

  3. Switch to the File Encoding tab for corrupted file uploads. There's no suggested fix here — SimpleRisk can't reconstruct corrupted binary content, so each row just tells you where the affected record lives: a Record: line naming the table and record ID. Take that information to wherever that record's file lives in the normal SimpleRisk UI (a compliance evidence upload, a risk attachment, a questionnaire response) and re-upload the file. The next scan picks up the fix on its own — once the byte count matches again, the issue clears itself from the list.

  4. Confirm the tile clears. Once every open issue is resolved, the Settings Hub tile disappears again, the outstanding notification resolves for every admin, and the Health Check row that was failing turns green.

Why there's no dismiss button

You'll notice there's no way to ignore, snooze, or dismiss an issue on this page — not on a single row, not in the bulk bar. That's deliberate. These aren't warnings about something that might be a problem; they're records SimpleRisk has confirmed are broken. Letting an admin wave one away would mean a corrupted risk description or a dead file link sits there indefinitely, silently, until it breaks something else downstream. The only way a text-encoding issue leaves the list is a repair; the only way a file-content issue leaves is a working re-upload. If the scan runs again and finds the same problem, it's back on the list — which is also why re-checking after a repair is worth doing rather than assuming it stuck.

Health Check integration

The Data Integrity scan also feeds the Health Check page (Settings Hub → Health Check → Simplerisk tab, under Configurations). When there are open issues, that row fails and reports how many records need repair, and it's one of the checks rolled into the overall SimpleRisk Core summary on the Health Check page's Summary tab — so a data integrity backlog is visible from your regular health-check pass even if you never open the Data Integrity page directly.

Common pitfalls

  • Applying a bulk repair without spot-checking a few rows first. The suggested fixes are computed from the same recovery logic that prevents new corruption on import, and they're usually correct, but "usually" isn't "always" on a field that held something unusual before it broke. Read a handful of Broken Value / Suggested Fix pairs before you select fifty rows and click once.

  • Expecting the File Encoding tab to link you to the record. It doesn't — there's no viewer page yet that a bare record ID can point to, so the tab hands you a table name and record ID as plain text rather than a clickable link. You'll need to know your way around where that record type's files live, or search for it by ID through the relevant SimpleRisk section.

  • Assuming the tile's absence means the scan hasn't run. The tile is hidden by design whenever there's nothing open — that's the normal, healthy state, not a sign the background job is broken. Check the Health Check page or the SimpleRisk Core summary if you want positive confirmation the scan is running on schedule.

  • Not re-uploading through the actual record. A file-content issue only resolves when the real record's stored file is replaced. Uploading a replacement file somewhere else in SimpleRisk, or under a different record, won't clear the issue — the next scan is still comparing the original record's stored size to its content.

Related