When capture can't tell whose file it is
Captured files that don't sit under a mapped client folder wait in Client Uploads until someone says who they belong to.
Capture files a document by the folder it arrived in. When the folder is mapped to a client, the document lands in that client's workspace and you never think about it again.
When it isn't, the document has nowhere to go — so it waits, and it waits where you will find it rather than failing quietly on the machine it came from.
Where to find it
Waiting captures sit under Couldn't match a client, below anything else needing attention.
Why something ends up here
There is one reason, and it is worth stating plainly because it explains every large queue: the file's folder is not mapped to a client.
Not the filename, not the file type, not how confident anything is. Capture resolves the client from the folder path. No mapped folder, no client, so the document parks.
That makes the size of this queue a direct measurement of how much of your watched folder tree is mapped. A source pointed at one client's folder stages nothing. A source pointed at a drive with two hundred unmapped folders under it stages everything that lands in any of them.
See Client folders and subfolder rules for the mapping pass.
What each row tells you
- The filename, and beneath it the path it came from on your own machine. The path is usually the fastest way to recognise a file — it's the folder you'd have looked in.
- Looks like (client) when capture managed a guess. It reads the document for a taxpayer identification number and matches that against your clients; when it finds one, it shows the client and the number it read.
- No suggestion line at all when it couldn't read one. That's common and not a fault — a scanned page with no SSN on it gives nothing to match against.
Clearing a row
Confirm accepts the suggestion. Use it when the Looks like line names the right client.
Assign client opens a picker for everything else. Choose the client and the document files to them.
Both do the same thing: the document is created in that client's workspace, gets its first version, and goes through the same reading and classification as anything else you upload. It behaves from then on like a document you filed by hand.
Dismiss removes the row from the queue. Use it for what genuinely isn't a client document — a working file, a duplicate, something your software wrote into the folder that was never meant to be captured.
The one way back is to map the folder. Once a folder belongs to a client, a file arriving from it is filed to that client directly and never consults this queue — so a previously dismissed file does come through.
Filing something here doesn't fix the cause
A row you clear is one document. The folder that produced it is still unmapped, so the next file from that folder waits here too.
When you find yourself assigning several files from the same path, stop and map that folder instead. One mapping ends the whole stream.
Notes and limits
- Every waiting capture is listed at once. There is no paging and no bulk action — no assign all, no dismiss all, no multi-select. A queue of a few dozen is a few minutes; a queue of a few thousand is not workable a row at a time, which is the strongest reason to fix the mapping instead.
- The same file captured twice is one row. Capture recognises identical content, so a folder re-scanned or a file saved again doesn't multiply. This is also why a dismissed file doesn't return: capture has already seen those exact contents and treats them as dealt with.
- Waiting captures belong to no client yet, so they appear nowhere on a client record, in no search, and to nobody on the portal. Until you file one it exists only on this screen.
- Confirming a suggestion is not a verification. The identification number was read off the page by machine. On anything consequential, open the document and check it names who you think it names before you file it.
- Filing or dismissing needs the Manage documents permission. Without it you can see the queue but not clear it.