DeskFlow

SLA status shows up in four places: the ticket page, the dashboard tiles, the ticket-list filter and a background worker that flags tickets at risk or breached. If each place worked it out for itself, sooner or later they would disagree — a ticket “at risk” on the dashboard but missing from the filter.

So all four call one module. Each priority has a response and a resolution target, stored as deadlines on the ticket. Moving a ticket to Pending pauses both clocks, and when it leaves Pending the deadlines move back by the time spent waiting. A ticket is at risk once 75% of its window has passed.

Trade-off: The clocks run on wall-clock time, not business hours. That kept the rules simple enough to test thoroughly, but it's the biggest gap compared with a real service desk.

Every change to a ticket, asset or article records who made it and the values before and after, in the same database transaction as the change itself. A request that fails leaves no trace, and one that succeeds can't skip the log. Entries are only ever inserted, and they outlive the records they describe: an entry about a deleted record is shown as “deleted” instead of a broken link.

The public demo resets every night, so visitors always find a realistic desk. The first version of that reset cleared the audit log along with the tickets. That made the demo tidy and the log meaningless, so I changed it: the reset only adds to the log, recording what it removed and what it created, and ids are never reused, so an old entry can never come to describe a new record.

The assistant suggests troubleshooting steps for a ticket, but the model is only given up to four published knowledge-base articles, found with the same full-text search as the rest of the app. If nothing matches, the model isn't called at all.

It has to say which articles it used. Ids it made up are dropped, and an answer that cites nothing it was given is thrown away and shown as “not covered”. Ticket text is passed as data with an instruction not to follow anything in it, the answer goes through the same sanitiser as articles, and it never takes an action: it's advice for a person to check. It only runs when an agent asks, it's rate-limited, and every run is audited.

Trade-off: Grounding it this strictly means it often answers “not covered”. For a helpdesk that's the right way to fail: a wrong fix costs more than no suggestion.

The knowledge base uses PostgreSQL full-text search: a generated tsvector column with a GIN index, titles ranked above body text, word forms matched (“printers” finds “printer”), and support for “exact phrases” and -exclusions. Queries go through websearch_to_tsquery, so odd input never causes an error.

Matches come back highlighted with private delimiter characters rather than HTML, so the browser never has to trust markup coming from the database.

Trade-off: One less service to run and keep in sync, at the cost of things a dedicated search engine gives you, like typo tolerance.

Backend tests run against PostgreSQL, not SQLite, each inside a transaction that's rolled back afterwards. That catches what SQLite would hide: constraints, sequences and full-text search.

It also taught me a trap. Because the tests share one rolled-back session, a route that forgot to commit its changes still passed. Routes that write now have tests that check the commit explicitly.