You have built the setup. This chapter is about getting answers out of it — which is mostly about decisions you already made, two chapters ago, without knowing it.
Before this chapter
The Dashboard has its own chapter — see The Dashboard. This one is about the other half of finding things: the list, its filters, and the two switches that decide whether a search finds anything at all.
The dossier list
Dossiers in the left menu. Two views:
- List — a table, sortable, with columns for state, priority, confidentiality, SLA, assignee, owner and progress.
- Kanban — the same cases as cards in columns by stage. Better for a standup, worse for finding one specific case.
Switch between them with the toggle at the top right. The choice is per person, not per organisation.
Filters
Down the side: state, stage, process, area, priority, assignee, and the fields you marked filterable.
That last one is the point of this chapter.
Addenda
Addenda are in the same list as the Dossiers, each shown after its matrix's number: 123/620. In the search panel's Scope section, Dossier type narrows the list to Base dossiers only or Addenda only; the default is All. Searching 123 finds the Dossier and its addenda; 620 or 123/620 finds the addendum. Chapter Working a Dossier explains what an addendum is.
People, files, and the third view
Two sections of the search panel are about who and what, not about the process:
- People — the reporter (who created the dossier), the responsible (who it is assigned to) and the employee a per-employee document is about. Pick one or several of each; the dossier must match all of them.
- Attachments — the review outcome of a file (to review, approved, rejected) and its reviewer. For a file already decided, the reviewer is the person who decided it. For a file still to be reviewed, the reviewer is whoever is expected to decide it: the dossier's approvers. So "reviewer Isabella, to review" lists what is waiting for her.
Neither needs a process chosen first, and both survive changing the process.
Then the third button next to List and Kanban: Attachments. It answers the same search one level down — one row per file instead of one per dossier — with the file, its document, its dossier number, the employee it concerns, the reporter and responsible, and the review outcome with the reason when it was rejected. Every row opens its dossier.
Use it for the question the dossier list cannot answer directly: "the rejected files reported by Thassia for the timesheet process between February and May, for Alan". The dossier list would tell you which dossiers contain such a file and leave you to open each one; the attachment view lists the files.
Two things to know about it:
- The filter is the same. Whatever you set above — dates, process, fields, people — applies. The view only changes what a row is. When the filter names a document, only that document's files are rows; when it names an employee, only that employee's files are.
- Access is the same. A file is listed only if you could open its dossier. There is no combination of conditions that shows a file you could not otherwise reach.
The two switches that decide whether you can find anything
Back in chapter 3, each field had these:
| Switch | What it gives you |
|---|---|
| Is searchable | The value can be found by typing it in the search box |
| Is filterable | The value appears as a filter on the dossier list |
Neither is on by default, and neither can be applied retroactively to the way people think. If Policy number is not searchable, somebody with a policy number in their hand cannot find the case. They will find it eventually, by opening cases until one matches, and they will conclude the system is slow.
Go back through your nine processes and ask, for every field: would somebody arrive holding this value? Policy number, claim reference, supplier name, contract number — yes. Estimated amount, internal notes — no.
Mark those searchable. It takes ten minutes and it is the difference between a system people use and a system people tolerate.
Similarly for filterable: a field is worth filtering on if somebody would want all the cases where it equals X. Claim type, yes. Date of loss, probably. Free-text description, no — a filter with two hundred distinct values is not a filter.
Searching inside documents
The search box also reaches the contents of documents that were processed — not just the values in fields. That is what the extraction pipeline in chapter 3 was for.
A document with Skip AI processing left on is stored but not read, so its contents are not searchable. That is a reasonable choice for a signed contract nobody needs to search inside, and the wrong one for a report somebody will ask questions about.
When to use search and when to ask Genius
They are different tools and the distinction is useful:
- Search answers where is it? — you know what you are looking for and need to get to it.
- Genius answers what does it say? — you have a question and do not know which document holds the answer.
If you find people asking Genius things that search would answer faster, the fields are probably not searchable.
What you should have now
- A dashboard with at least one populated panel.
- Every field somebody might arrive holding, marked searchable.
- Two or three fields marked filterable, and no free-text ones.