Call queue overview as self-service for department heads

The situation

The project folder does not state the original problem explicitly. What is evidenced is only the purpose, in the specification: department heads should get a self-service overview of their call queues rather than depending on somebody else to look it up.

One clue points at the backstory but is interpretation, not evidence: the folder contains a PowerPoint file documenting the call flow of a single department, and both the specification and code comments refer to it repeatedly as “just an example”. That suggests such call flows were previously maintained by hand in slides. Only the department itself could confirm that.

The approach

Two separate parts.

An hourly collection job signs in to Microsoft Teams unattended using a certificate, reads all call queues and auto attendants, and writes them to a database. Why PowerShell rather than a normal interface is stated in the code: for this configuration data no REST API exists. Each object is error-handled individually, so one broken record does not abort the whole run.

The web interface reads exclusively from that database — it never changes anything in Teams. On every request the server checks whether the person is allowed to see that queue.

Live availability comes from Microsoft Graph, batched into one call for everyone on a page and cached for 45 seconds. Pages render immediately from the database and the browser loads availability afterwards — so a slow or throttled Graph call never blocks page load. A banner warns when the last synchronisation is too old.

The call flow is rendered as a diagram, generated entirely from the synchronised data — including announcements, business-hours branches and nested submenus.

Where it could have gone the other way

The data model for the auto attendants was built generically, even though only one specific menu tree was known at the time.

The specification states it as a requirement: any number of options, nested menus, destinations like voicemail, external number or announcement, and queues with no menu at all — “never hard-code its shape, depth, or option count”. The same sentence appears again in the data model itself. It is implemented through a self-referencing tree and a generic destination type; the diagram renderer expands nested menus inline and guards itself with a visited set against cycles and reused submenus.

This could have gone the other way: hard-wiring the one known menu tree would have been faster and would have looked identical to the first set of users. The decision was paid for in the collection job, which has to map every Teams destination type individually — along with the limitation the documentation names itself: Teams objects look different depending on configuration, so the mapping has to be verified per tenant.

The result

Around 3,400 lines across 46 files, 10 database tables, 19 endpoints, six integration points. Built by one person; the commit history is not a usable measure of effort, though — four commits are titled “first commit”, so the history was re-initialised.

Read-only by design: call queues and auto attendants are never modified. Every change still happens by hand in the Teams admin centre, by someone with administrator rights. Also manual: which department head sees which queue is entered by an administrator; it is not derived from organisational data.

One point deliberately not solved in software: aggregate view and anonymisation are switchable per department head — but sign-off from the works council and data protection for showing individual availability remains, per the specification, a separate organisational hurdle. The switch does not replace the process.