OnBase redaction workflow: bulk redaction for documents already in OnBase

County clerks, records offices and the integrators who support them share a simple problem. A public records request lands, and the responsive documents are in OnBase. They need release copies with the personal information removed. This guide covers the practical loop: get the PDFs out, run one redaction command on your own machine, check the result, and put the redacted copies back.

One thing first. KeptPDF has no OnBase integration, connector or plug-in. It is a command line tool that works on PDF files in folders. What connects it to OnBase is the export and import you already run.

Where redaction sits in an OnBase records workflow

There are two jobs here, and they need different machinery.

Before filing. Day-forward scanning. Paper comes in and gets captured. If the redaction happens in this lane, the sensitive text never gets filed in the first place.

Already in OnBase. The backfile: years of permits, property files, case records and council packets, filed long before anyone wrote a redaction rule. This lane produces the release copies for public records requests, and it is where the manual work piles up.

A tool that works at capture time does nothing for the second lane. That is the gap this loop fills.

What OnBase itself offers

Hyland documents Automated Redaction for OnBase as its own module: Automated Redaction and Advanced Capture. It is a separately licensed module, so it is not part of every OnBase deployment. Ask your OnBase administrator or your Hyland representative whether your organization has it, and what it covers on your version.

If you have it and it fits the documents, use it. The loop below is for the cases it does not reach: you do not own the module, the documents are already filed and you need a one-off release copy, or you want a redaction pass that runs outside OnBase and leaves a proof file next to every output.

What any pattern-based redaction leaves to a person

These points are true of any automated redaction, ours included.

• Anything without a shape. A Social Security number has a shape. A resident’s name does not, and neither does a street address written into a sentence, or a date of birth in a paragraph of narrative. Those need a careful reader and then a human check.
• Pages with no text. A scanned page is a picture. Text has to be recognized before it can be found and removed.
• The review call. Recognition is not perfect, and automated detection can miss something handwritten. Keep a person in the loop for anything that goes out the door.
• The copy that leaves. A release copy is a file that goes to a requester, with no access rules following it. What you want in that file is characters that are not there any more, not a box drawn over live text.

The loop: export, redact, verify, re-import

Four steps. OnBase keeps custody at both ends; the redaction happens on a machine you control.

1. Export. Get the responsive documents out of OnBase as PDFs into a local folder. Use whatever your organization already uses for that: your OnBase export or document retrieval step, a person pulling documents in the Unity Client, or a scheduled export to a network folder. What you can use depends on your configuration and permissions, so ask your OnBase administrator.
2. Redact. Run one command over the folder.
3. Verify. Check the report and the certificates, and have a person look at anything leaving the building.
4. Re-import. Bring the redacted files back through your normal import, as new documents or, where your system keeps revisions, as a new revision, with the certificates alongside.

Step two, on the export folder:

$ npm install -g keptpdf
$ keptpdf redact ./in -o ./out -r

  ✓ 41827-parcel-file.pdf      22 boxes   verified
  ✓ 41828-parcel-file.pdf      17 boxes   verified
  ✓ permit-packet-2004.pdf     31 boxes   verified (OCR'd first)

  318 redacted, 0 skipped, 0 failed

A page with no text layer is OCR’d first, on the same machine, then redacted like any other page. The characters are removed from the content stream and the area is painted, rather than a rectangle being drawn over live text. After writing, the output is re-opened and every string in it is checked against what was supposed to be gone. If anything survived, no file is written and the run reports a failure. Each output gets a .cert.txt and a .cert.json, plus a branded .cert.pdf on licensed runs: the counts by category, the SHA-256 of the input and of the output, and that verification result.

The documents do not leave the machine the CLI runs on. KeptPDF talks to no OnBase service at all. It reads the folder you give it and writes the folder you name.

Exemption codes and a log that travels with the production

A public records production usually wants each black bar to say why it is there.

$ keptpdf redact ./records -o ./produced --label "(b)(6)" --log production.csv

--label stamps the code inside the box, clipped to it, so the redaction never grows to fit the text. --labels <file> gives a different code per category. The log records one row per box: file, page, category, code, method, confidence, position and the certificate id. It carries no redacted text, on purpose: the log travels with the production, and listing what you hid would undo the work. KeptPDF ships no exemption preset. Which code applies is your legal call.

The review step, which you should keep

Automatic detection is a first pass. It can miss things, and we will not claim otherwise, so the tool can hand you a spreadsheet before anything burns:

$ keptpdf review ./in -o decisions.csv
# open decisions.csv, change any wrong "keep" to "redact" (or the reverse)
$ keptpdf redact ./in -o ./out --apply decisions.csv

One row per candidate, with the page, the category, the confidence and the detected text. Rows above the sensitivity threshold arrive marked redact, rows below it arrive keep. An untouched file applies exactly what a plain run would have done, so adopting the review step cannot quietly stop something being redacted. A code column sets the exemption code per box.

The review file holds the detected text, because a person has to read it to judge it. Keep it with the sources and never ship it with the production. What we do claim, and prove per file, is that whatever you decided to redact is genuinely gone from the output.

Bringing the results back

Import the redacted PDFs the way you import anything else. Keep each document’s .cert.txt or .cert.json with it, so the proof sits next to the deliverable. Keep the original in place too. The redacted copy is a release copy, not a replacement for the record, unless your retention rules say otherwise. That is a records decision for your office, not a tool setting.

The day-forward half: a watched folder

For scanning still arriving, you do not need the export at all. Point the scanner output at a watched folder and import from the other side:

$ keptpdf watch ./scan-drop -o ./ready-to-import

Every PDF dropped into that folder comes out redacted, with its certificate. The interactive menu (type keptpdf with no arguments) can save a watch setup and write a ready-to-install service file: a systemd unit on Linux, a Task Scheduler command on Windows, a launchd plist on macOS. It then runs from boot with nobody logged in, and your import step watches the output folder.

A backfile that arrives as one long scan needs splitting first: see that guide.

What it costs, and how to check it before you commit

Install with npm install -g keptpdf. It needs Node 18.17 or newer and runs on Windows, macOS and Linux, on Intel and ARM. The trial covers your first 100 files with no account and no card. That is 100 files in total on that machine, not per run, and there is no deadline. Trial output carries one small footer line naming it as trial output, so it is not fit to file or produce, but it is enough to judge the redaction on your own documents.

A license is $4,800 a year for one organization, unlimited files, on your own hardware. For a solution provider, the license names the client organization and every certificate prints that name, so one client’s key does not fit another client’s work. Partner terms are on the CLI page, which also has a form if you would rather talk to a person first.

Measured accuracy, the corpora it was measured on, and the misses are on the benchmarks page.

KeptPDF is not affiliated with, endorsed by or sponsored by Hyland. OnBase is a trademark of Hyland. The one statement above about OnBase, that Automated Redaction is a separately licensed module, comes from Hyland’s own published documentation. Check it, and anything about your export and import options, against the version and licenses you run.