You have a working setup built on invented data. This chapter is about the gap between that and running real work through it.
Three things that are hard to change later
Deal with these before anybody files a real case.
1. Area names
There is no delete for an Area. Not in the interface, not in the API. Deactivating hides nothing — the row stays in the list, marked inactive.
Read your six names once more, as a colleague joining next year would. Claims is fine. Claims (new) is a decision you will regret.
2. What "required" means on each document
A required document blocks submission. That is the point, and it is also the thing that generates the angriest support request in the first week — somebody with a legitimate case that genuinely has no police report, unable to proceed.
Go through every document you marked required and ask: is there a real case that does not have this? If there is, it is not required. Required means this case cannot proceed without it, not we would like this.
3. Who can approve what
Run the test from the approvals chapter against every process: can the person who assembled the case approve it?
Half of the answer is the product's: whoever created a Dossier can never be named its approver, except somebody who holds the critical permission Decide a dossier one created, and that use is audited. Give that permission to almost nobody.
The other half is yours: the colleagues who prepare cases without creating them. If their roles approve too, an approval can record somebody agreeing with work they did, and no amount of later configuration fixes the records created in the meantime.
The checklist
Processes
- [ ] Every process has the SLA (hours) it needs, or keeps its priority's on purpose.
- [ ] The processes with documents that expire have the warning's Days in advance they need (empty uses the default).
- [ ] Every document with a validity period has Require expiry date on.
- [ ] You found a case in the Advanced search by the value of a field somebody would arrive holding.
- [ ] Every field that must never reach AI is under Sensitive fields, on the process's Genius step.
- [ ] Photographs and other "one is never enough" documents have a minimum file count.
Access
- [ ] The organisation tree matches the real one, in companies, branches and departments, including branches you were going to add later.
- [ ] Directors are granted, on each one's Organizational scope, with Include sub-units, not by listing departments.
- [ ] The process's Organizational scope is the rule and the Default team carries the exceptions — no scope was widened to reach one person.
- [ ] For one specific sensitive document, you can say who can open it and through which layer.
Genius
- [ ] At least one narrow assistant exists alongside Total search.
- [ ] You have followed citations back to source on at least three answers.
- [ ] Nobody on the team believes the assistant is checking whether a document is current. It is not — that is what expiry dates are for.
The team
- [ ] Everybody knows the one Inbound rule: when in doubt, Inbound.
- [ ] Everybody knows that a blocked submission names the missing document, and to read the message.
- [ ] Somebody can say, for each process, which data force a new decision when they change — see below.
What an edit does to an approval
An approval given on Tuesday was given against the case as it stood on Tuesday.
The product already decides what happens when the case changes afterwards: a material change restarts the chain on its own, in the save that made it. The decisions taken move to an archived round, whoever had taken them is told, and everybody decides again. Nobody has to remember to do it, and there is no switch to turn it off.
"Material" is defined too: the Dossier's files and the values of its required fields. What is left to your organisation is only the edge of that definition. Go through each process's fields and ask, of each optional one: if this changes after approval, does somebody have to decide again? If so, make it required, or ask for it in a file — otherwise the rule does not see it. Do it before going live: each Dossier keeps the required fields it was created with, so the change only holds for Dossiers created afterwards. Write the answer down, so that the next person configuring a process does not have to guess it.
Cleaning up the practice data
The setup you built following this manual has invented cases in it. Before real work starts:
- Cancel the practice dossiers. They are final and stay in the history, which is honest.
- Deactivate any Area you created while experimenting. Remember: you cannot delete it.
- Keep the processes if the templates are right. There is no reason to rebuild what works.
Where to go next
- Getting started — the three words, if a colleague needs them.
- Your first Process — the reference for every field, when you build your tenth.
- Contact us — for what this manual does not cover.
The manual describes the product as it stands. When something here does not match what you see on screen, the screen is right and we would like to know — a manual that has drifted is worse than none.