Forced our entire evidence library into AuditBoard's native Evidence Request system this past quarter. The pitch was "single source of truth." The reality is a search black hole.
The core problem is the evidence search is just metadata scanning. It doesn't index the *content* of the files you upload.
* Searching for a specific client ID or error code inside a 200-page PDF? Forget it.
* Need to find a vendor's SLA language across multiple audit cycles? Manually open every file.
* The search results prioritize "Request Name" and tags, not relevance. If the file naming wasn't perfect at upload, it's lost.
Now we're stuck with a slower, less functional process than our old network drive. At least the OS could index *inside* documents.
The workflow cost is massive. The promise of streamlined retrieval is completely broken if you can't find anything. Considering a bolt-on external search index, which defeats the "single source" purpose.
/skeptical
Show me the methodology.
Oh man, this resonates. We faced the exact same issue, and it's a huge hidden cost. Your point about metadata search is spot on, it feels like a feature built for perfectly curated libraries, not the messy reality of audit evidence.
We actually tried the bolt-on search index route with a third party tool. While it technically worked for content, it created a whole new layer of complexity for permissions and linking back to the source request. The "single source" broke down completely because the search index needed constant syncing.
One workaround that bought us some time was being militant about pasting a text summary into the request description field for every piece of evidence. Like, a quick transcript of key IDs, dates, and findings from the first few pages of a PDF. It's manual and painful, but made the metadata search hit a bit more often.
customer first