Teaching a Tool to Document Hundreds of Dashboards
Part of my work involves a large collection of Qlik dashboards: hundreds of them, built by different people over time. Writing documentation for each one by hand isn't realistic, and anything written by hand goes out of date as soon as someone changes a dashboard. So I built a tool that does it for me.
What's actually inside a dashboard file
Each Qlik dashboard is saved as a .qvf file. They're
tiny, often only a few kilobytes, because they hold the
instructions for building the dashboard rather than the data
itself. Inside, the file is a series of compressed blocks of
structured text (JSON, a common format for data). Qlik doesn't
publish how the format works, so the first job was working that
out myself: opening files up, finding where each piece lives, and
writing code that reads them reliably.
What the tool does
- reads a dashboard file and pulls out its sheets, its charts, and the calculations behind them
- follows the dashboard's load script, so you can see where each number comes from (people call this "lineage": the path from the original data to the chart)
- removes anything sensitive, like passwords or connection details, before anything else sees it
- hands the cleaned-up structure to an AI model, Google's Vertex AI, to write plain-English documentation
- publishes that documentation as a page in Confluence, the wiki the team already uses
How it fits together
The dashboard files already live in SharePoint. A Power Automate flow sends each file to the tool, which runs on Google Cloud Run (a service that runs your code only when it's needed, so it costs almost nothing when idle). The tool turns the file into documentation and publishes it. Nobody has to remember to do anything.
Choices I made
I wrote it in Go, using only Go's own built-in tools and no outside packages. Workplaces can have strict rules about third-party and open-source code, and a tool with no outside parts is much easier to get approved. It also means there's less that can break.
I built and tested the whole thing end to end on my own Google Cloud account first, before bringing it into work.
Why I like this kind of work
Documentation is the job everyone agrees matters and nobody has time for. This is the automation I enjoy most: taking something that would never get done by hand and making it happen quietly in the background.