An internal bookings and forecast dashboard that runs entirely inside Snowflake. It is served from a container, gated by the platform's own sign-in, and reads views and an analytics agent that never leave the account. This sheet documents what it looks like and how it fits together.
Two things are drawn here. Part one is the interface: the shell that frames every screen, the five sections beneath it, and the assistant panel that slides over the right-hand side. Part two is the architecture: the path a request takes from a browser to a warehouse view, the client-side loading strategy that decides what gets fetched and when, and the pipeline that moves a commit to production.
Every figure is schematic. Hatched fills mark where real content sits: figures, account names, segment labels. None of it is reproduced. The redaction key at the foot of this page lists exactly what was substituted.
The shell is a fixed-height column, not a stack of sticky elements: the title row, tabs and
filters hold their position while only the panel beneath them scrolls. That choice removes
every calc(100vh − Npx) offset the sticky approach would need, and it is why
the chrome below is drawn as four discrete bands rather than a single scrolling page.
The five sections below share that chrome exactly; only the scrolling panel changes. Each is drawn with its real block order and its real controls, and each notes which of the four data groups it consumes.
| Line A | Line B | Line C | Line D | |
|---|---|---|---|---|
| CQ Budget / Var / Attainment | ||||
| FY Bookings / Var YoY / YoY % | ||||
| CQ Forecast / CQ Pipeline | ||||
| CQ Attach Rate / # Opps / # Attach |
Six sections, each a summary table with a jump button into the tab that owns it. The executive summary sits above all of them as a single table. There is one column per service-line view and one row per measure, so the whole quarter reads across in one pass rather than as a row of floating cards. Its four columns are fixed: they are the four canonical views, not whatever the filter row currently selects.
Five of the six section tables cap at eight rows and scroll within themselves past that; Top Open Deals is the exception, running its ten rows uncapped. The cap is content-sized rather than a fixed fraction of the viewport, because capping every table to a viewport fraction stacks competing scrollbars down a page this long.
Charts degrade to tables on their own: past a bar threshold the stacked chart is unreadable, so the same view model renders a table instead. The per-year expand toggles break a fiscal year into its quarters in place.
Three identical sections, one per quarter in the rolling window. The window itself is derived at load time from the fiscal calendar, so a dashboard left open across a quarter boundary re-derives it on the next refresh rather than showing a stale window.
Each block pairs a chart with the table behind it, so a figure can be read off precisely rather than estimated from a plot. The last block collapses to a small card layout when a single segment is selected, since a one-row table is a worse way to show one number.
| Opp ID | Type ▾ | Quarter | Account ▾ | Segment ▾ | Status | Value (A) | Value (B) | RAG | Review | Reps | Comments |
|---|---|---|---|---|---|---|---|---|---|---|---|
The only section that claims the full viewport and scrolls inside its own pane, so a wide twelve-column table keeps both a reachable horizontal scrollbar and a header that stays put. Because it is already its own scrollport, it draws its native bars on both axes. The page-pinned strip in WF-02 exists for the opposite case, a wide table that grows to its content and would otherwise strand its scrollbar below the fold.
It is also the only section without the shared filter row: the marked columns carry their own filters instead, which is why the shell hides the row entirely here rather than showing two competing sets of controls. Every column sorts from its header, and a review comment opens in a dialog rather than being truncated in place.
Opening the panel adds right-hand padding to the shell rather than covering it, so a figure being asked about stays visible next to the answer. Conversation context is kept until the reader starts a new chat. The panel is anchored to the viewport, which is why the shell around it must avoid any property that would make it a containing block.
The defining constraint is that nothing leaves the data platform. Snowpark Container Services runs the container. A browser reaches it through Snowflake's own ingress, which authenticates and authorizes every request before the container sees it, and the container's calls back to the warehouse and to the analytics agent travel an internal host path rather than the public internet. No outbound network access is needed, and the application holds no authentication code of its own. That is deliberate: a second gate behind the platform's own would only drift out of step with it.
The client is not a thin renderer over that API. It decides what to fetch, in what order, and what to show when a fetch fails. That policy is the part most worth drawing, because it is where the dashboard's behaviour under a partial outage is decided.
Data is split into four groups, each backed by several named queries. Groups load one at a time, prioritised by whichever section the reader is looking at. Each is cached locally for thirty minutes under a key scoped to the fiscal quarter, so a new quarter always misses the cache rather than serving figures from the last one.
Deployment mirrors that discipline. Two long-lived branches map to two separate Snowflake accounts, and the branch a contributor reaches by default is the non-production one. The default branch is the one people land on by accident, and production should never be that branch.
The platform and the shape of the system are drawn as they are. What is replaced below is anything that names an environment, locates an object, or reproduces a figure.
| Actual | Shown as |
|---|---|
| Snowflake account identifiers and endpoint URLs | Account A / Account B |
| Database, schema, view, table and warehouse names | Forecast view · budget table |
| Service user, role, and service-role names | the app's Snowflake role |
| Agent object name and version | Agent object |
| Datasource identifiers carried on each query | omitted |
| Service-line codes used across the filters | Line A – Line D |
| Segment taxonomy | hatched fill |
| Every bookings, forecast, budget and attach figure | hatched fill |
| Account names, opportunity IDs and review comments | hatched fill |
| Product title and division naming | Operating Analytics |