The work container, from state to history
Cases
A case is the container holding everything about a single line of work: tasks, documents, deadlines and the history of what happened.
Why it isn't a folder
A folder is a passive container: it tells you where the files are, not where the work stands. A case in Xedul carries:
- a progress state updated by the real work;
- the people involved;
- the tasks, open and closed;
- a history of what was done and when;
- the link to the client record.
Creating a case
From the Cases section, the create button asks for:
- Case name — recognisable months later.
- Client — which record it belongs to.
- Initial state — usually the first state of your configured flow.
- Due date — if a binding one exists.
- Assignees — who in the practice works on it.
A useful name includes the reference period: "Annual accounts 2025" rather than "Accounts". In two years it will matter.
Progress states
States are configurable at practice level and describe the real phases of the work. A typical flow for a tax practice:
| State | What it means operationally |
|---|---|
| Collection | Waiting on documents from the client |
| Processing | Work under way in the practice |
| Review | Internal check before closing |
| Filing | Submission or filing with the authority |
The state isn't decorative: it's what lets anyone answer "where are we" without asking the person doing the work.
The case list
The list view shows name, state, client and due date. Overdue and imminent deadlines are highlighted, so the list doubles as a risk-control instrument.
Search and filters let you isolate, for example, all open cases for a client, or all cases in a given state.
Case detail
Opening a case gives you:
- Linked tasks — with priority, assignee and due date.
- Documents — files uploaded in this case's context.
- Comments — the internal discussion, with mentions of team members.
- History — the sequence of relevant events.
Comments replace the internal email thread. They stay attached to the case, so they remain readable for whoever joins the work later.
Connecting email and documents
From Gmail and Outlook, a message can flow directly into a case's context as a task with its attachments imported. That flow is described in Gmail integration and Outlook integration.
Handovers
History is the reason a handover doesn't need a meeting: whoever takes over reads the sequence of events and understands what was done, by whom and when, without reconstructing it from email.
Good practice
- One case per line of work, not one case per client. A client has many cases.
- Keep the state current, even when nothing visible changed: it's the signal everyone else reads.
- Tasks inside the case, not scattered: that's what makes the case a complete picture.
- Close finished cases. A list of perpetually open cases stops carrying information.