Hex 4.0: verify a number before planning a dashboard move
Hex announced version 4.0 and a $100 million financing round on October 27, 2026. Its product announcement places 4.0 in private beta, with broader access rolling out over coming weeks. Existing projects are expected to keep working; a dedicated migration workflow was described as forthcoming. Check your workspace’s actual access and migration options before committing a production dashboard.
Hex company announcement: October 27 funding and platform direction
What the new inspection workflow promises
Hex says 4.0 backs project logic and visualizations with code files and records dependencies so users can inspect a displayed number’s logic and data sources. It also describes parallel execution for independent queries, streaming results, and rerunning only steps affected by a changed input. These are vendor descriptions, not findings from an independent performance or governance test.
Hex 4.0 product announcement: inspection, execution and private-beta access
Start with a four-row KPI exercise
Use a fictional order table with four rows: two paid orders of $100 each, one refunded order of $50 and one canceled order of $30. Define the exercise’s KPI precisely as the sum of amounts on rows whose status is paid. The expected answer is $200. This is a deliberately narrow training definition, not an accounting policy or a report of Hex’s output.
Ask whoever builds the test dashboard to show the source rows, status filter and addition behind the displayed total. A total of $250 would include the refunded row; $280 would include every row. Matching the expected $200 is only the first check: the reviewer should still trace the calculation, because a correct-looking answer can conceal the wrong logic.
Next, change one paid order from $100 to $120 in the fictional fixture. The expected total becomes $220. Record which input changed, which calculation should depend on it and what the refreshed result shows. Treat update behavior as something to observe in your trial rather than inferring it from the vendor’s execution-engine description.
Keep a definition and a review decision with the app
Save a short metric card beside the exercise: field names, allowed statuses, currency, time period, expected result and reviewer. For a real business question, agree on returns, discounts, taxes and time-zone boundaries with the data owner before building the metric. The fictional paid-row rule is useful precisely because its limits are explicit.
Have a second reviewer inspect the source and transformation without relying on the first reviewer’s explanation. Record whether they can reproduce the number and explain any exclusions. If they cannot, keep the result marked unresolved and ask for the missing definition or evidence. A polished chart should not close that question by itself.
Plan migration after access and evidence are clear
Use the exercise to prepare specific questions for your workspace administrator or vendor contact: which version is available, how existing permissions carry over, what migration path is supported, and how to retain the old dashboard until its replacement is accepted. Funding provides company context; the decision to move a dashboard should rest on your own requirements and reviewed results.
Can you trace the KPI?
