A Dossier is a governed case. It is where one concrete process brings together data, documents, approvals, review, history and evidence.
The difference from a folder appears immediately: an empty folder does not know what is missing. An empty dossier does. It is created from a Process and already carries the expected documents, fields to fill, submission rules, approvers, confidentiality and next steps.
Create a dossier
- Open Dossiers in the menu.
- Choose New dossier.
- Select the right Process.
- Give it a title a person will recognise.
- Fill the initial data the Process asks for.
- Create the Dossier.
When you open it, the expected Documents are already there. Nobody has uploaded files yet, but the Dossier already shows what needs to exist, which items are mandatory and how many files each Document accepts.
The guided dossier
The screen is a guided sequence. The side panel shows where you are and works as navigation.
- Process — identifies the Process, Area, priority and base confidentiality.
- Forms — collects the dossier-level fields.
- Documents — shows the expected Documents and each one's files.
- Approvers — shows who needs to decide.
- Comments — keeps the operational conversation together.
- Review — confirms whether the Dossier is ready to move on.
- History — shows what happened, by whom and when.
The user should not have to guess the next step. The Dossier shows what is missing and what blocks the transition.
Documents and files are not the same thing
A Document is the requirement: "Signed contract", "Identity document", "Proof of address". A file is one delivery inside that Document.
A Document may accept one or many files. It may have a minimum and a maximum. It may have its own fields. And a confidentiality level of its own is on the roadmap.
That supports real cases: the same Dossier can contain a public Document for broad consultation, an internal Document for the team and a restricted Document that only some people can open.
Seeing the Dossier does not automatically mean seeing every Document. When a Document requires a higher access level, the person can see that restricted content exists, but cannot see files, preview, extracted text or Genius sources that belong to that Document.
Document status
Each Document has its own operational status:
| Status | Means |
|---|---|
| Missing | Nothing has been supplied. |
| Partial | There are files, but fewer than the required minimum. |
| Uploaded | Enough files are present, still without human validation. |
| Validated | A person confirmed this is the right Document and it is suitable. |
| Needs correction | A person rejected the Document or asked for replacement/correction. |
| Expired | The Document is no longer valid. |
These statuses answer "is this Document usable?". They are not the state of the whole Dossier.
Dossier state
The Dossier has a separate lifecycle, with fourteen states. The first column is the state's name as this manual and the API use it; the second is what the screen shows:
| State | On screen | Stage | Means |
|---|---|---|---|
| New | New | Preparation | Created, not yet picked up. |
| Draft | Draft | Preparation | Being prepared. |
| Incomplete | Incomplete | Review | Submitted, but something the team has to produce is missing: information, documents, checklist or required fields. |
| Waiting external | Waiting on third party | Review | Waiting on a person or organisation outside the team for something only they can provide. |
| Returned | Returned | Review | Back with its author for correction: sent back by an approver or by quality review, or reopened after a rejection, a failure or a closure. |
| Failed | Failed | Resolution | Recoverable technical failure: AI, OCR, timeout or an external call that broke. |
| Rejected | Rejected | Resolution | Negative decision: the approver's, or a business refusal returned by the external system. |
| Waiting decision | Awaiting decision | Decision | The approval chain is open. |
| Partially approved | Partially approved | Decision | Some approvers accepted, others have not yet decided. |
| AI processing | Analysing documents | Processing | AI/OCR/automatic processing is running. |
| Quality review | Quality review | Quality assurance | Automatic processing results are waiting for human validation. |
| Triggering | Running in external system | Integration | The external operation is being sent, awaited or repeated. |
| Completed | Completed | Closure | Finished successfully. Final. |
| Cancelled | Cancelled | Closure | Administratively closed. Final. |
Three rules make the list easier to read:
- Completed and Cancelled are final. Only the organisation's owner can reopen one, and has to write the reason: the Dossier goes back to Returned, and the approvals it had no longer count.
- A non-final Dossier can be cancelled when the operation requires it.
- Rejected is a negative decision: it goes back to Returned when there is something to correct, or it is cancelled. It is never repeated, because the same request against the same rule would get the same answer. Failed is a recoverable technical failure: it can repeat the step that failed, such as AI processing or an external operation, or be returned for human correction.
Submitting
On submit, the Dossier validates what the Process requires. Missing mandatory Documents, files below the minimum, required fields or unfinished checklist items block the transition.
The message should say what is missing. "The Dossier is incomplete" does not help. "The identity document is missing" or "the certificate has expired" gives somebody something to act on.
After submission, the system routes the Dossier according to configuration:
- checklist or information still to complete → Incomplete;
- approvers configured → Waiting decision;
- ready for automation → AI processing.
Routing never puts a Dossier in Waiting external. When what is missing is in the hands of somebody outside the team, a person says so, from Incomplete and with the reason. The Dossier leaves that wait when it is resumed, going back to Incomplete, or when it is submitted again.
If an earlier execution of the Dossier already reached the external system, the new submission asks for confirmation, with the external reference in view, because it may send it again.
After AI
When automatic processing finishes, the Dossier follows the Process design:
- if it needs human sign-off, or if AI raises an exception, it enters Quality review;
- if an external operation is configured and review is resolved, it enters Triggering;
- if there is nothing else to do, it becomes Completed;
- if there is a recoverable technical failure, it becomes Failed.
Triggering exists because a real process often ends in another system: ERP, CRM, public portal, payment engine or internal system. DOK Genius shows that wait as part of the Dossier instead of hiding it in a log.
When the external system answers, the Dossier becomes Completed if the operation was accepted, Rejected if it was refused for a business reason, with the code and description the system returned, or Failed if the call broke or no answer arrived in time.
Addenda — adding to a completed dossier
A Completed Dossier is closed on purpose: its Documents, decisions and history are the record of what was decided. When the case gains content later — new damage on a claim already settled, a document that only arrived after the contract was signed — reopening it would rewrite that record. An addendum adds to it instead.
An addendum is a Dossier of its own, linked to the completed one, which is called its matrix. It has its own Documents, approvals, state and history. The matrix stays Completed whatever happens to the addendum: completed, rejected, failed or cancelled.
When you can create one
Create addendum is in the Dossier's menu in the list, on the Dossier itself, and in its Addenda step.
- It does not appear on a Dossier that is not Completed.
- It does not appear on an addendum. An addendum never receives an addendum: the chain stays flat, and every addendum belongs to the matrix.
- It appears disabled, with the reason written next to it, when you do not have permission to create addenda, or when the Dossier's Process does not allow them.
The screen explains a refusal; the server applies it. The permission is checked again when the addendum is created, against the matrix's organisation unit (chapter People, roles and groups).
Creating it
The creation screen has four parts:
- Inherited from the dossier, locked: Area, Process, organisation units and the people the Documents are about. The addendum is about the same case.
- Classification and team: they start as in the matrix. Raising the confidentiality is ordinary; lowering it below the matrix is for the organisation's owner. The team is changed on the addendum itself, once it exists, by whoever manages teams.
- Reason, mandatory: why a closed case gains content. It appears in the matrix's list of addenda, on the addendum and in the history.
- Documents to add, from the Process as it is today — not as it was when the matrix was created. New marks the Documents the matrix does not hold. Only the ones you choose go into the addendum, each with its minimum and maximum number of files, counted in the addendum alone. A Document removed from the Process does not appear.
Choose at least one Document: an addendum with nothing to add is not created, and cannot be submitted.
The addendum starts in Draft and follows the Process's current approval chain, like a Dossier opened today. From there it is worked like any other Dossier.
How it is numbered
An addendum takes the organisation's next Dossier number, like any Dossier, and is shown after its matrix's: 123/620 is Dossier 620, an addendum to Dossier 123.
Searching 123 finds the matrix and its addenda. Searching 620, 123/620 or 123-620 finds the addendum.
On the Dossier's screen
- On an addendum, a band under the title reads Addendum to #123 · Addendum 2 of 3 · reason: …, with a link back to the matrix.
- On a matrix that has addenda, an Addenda step appears before Review, with how many there are. It lists the addenda you may open, in any state — a rejected or cancelled addendum also tells the case's story — with number, reason, state, date and approvals.
In the list
Addenda live in the same list as the Dossiers, so an approver keeps a single queue. In the search panel's Scope section, Dossier type narrows it: All (the default), Base dossiers only or Addenda only.
When the Process ends in an external system
If the Process has a Trigger, an addendum runs it like any Dossier, with what the addendum brought — never the matrix's content again. The external system receives the matrix's reference and the addendum's in separate fields, so it never has to take a number like 123/620 apart.
Where the Trigger's effect must happen only once — opening a policy, issuing a contract number — the Process can switch this off (chapter Your first Process), and the addendum then completes without calling the external system. What counts is the switch as it stood when the addendum was created.
The external system's answer lands on the addendum alone: a business refusal makes it Rejected, a technical failure makes it Failed, and the matrix does not change.
History and evidence
Each important move leaves a trace: who submitted, who approved, which Document was corrected, which attachment was replaced, which external operation was called and what came back.
That is what makes the Dossier a governance object. At the end, you do not only have a collection of files; you have the verifiable story of how the decision was built.
What you should have now
- A dossier created from a Process, with the expected Documents listed before any file exists.
- A Document holding more than one file, and its status moving from Missing to Uploaded and to Validated.
- A submission refused for a missing item, with the message naming it — and the same submission accepted once it is fixed.
- A dossier that went through AI processing and reached Quality review, Triggering or Completed, with the history that tells how.
- A completed Dossier with an addendum: the band on the addendum, the Addenda step on the matrix, and the matrix still Completed.