Dev, test and production for dashboards

An analyst opens the production dashboard, changes a calculation, and publishes. Three hundred people now see a different number, and there is no record of what changed, no test that it is right, and no way back except rebuilding from memory.

If that happened in an application, it would be a serious incident. In BI it is a Tuesday. The difference is not that dashboards matter less, it is that BI tools make the unsafe action the default one and the safe action something you have to design.

The fix is not heavy process. It is three stages, one rule, and an automated step between them. A ten-person team can run it, and the entire design fits on a page.

The load-bearing row is the third, and specifically the phrase nobody except by promotion. If an author can publish directly into production, the other two stages are decoration and will be bypassed the first time something is urgent.

The test stage points at production data on purpose. A dashboard validated against sample data has not been validated, because most defects in BI content are data-shaped: a join that fans out, a null that changes a total, a date that lands in the wrong period. You cannot see any of those against a tidy sample.

You do not need a new product. Tableau's own guidance is that projects are the mechanism for managing content access, and setting permissions at the project level rather than per asset is how you keep the model comprehensible.

So the three stages are three projects, or three sites for a stricter separation. Development is open to authors. Test grants publish rights to the same authors. Production grants publish rights to nobody except the service account that performs promotions. The rule is enforced by permissions rather than by asking people nicely, which is the only kind of rule that survives a deadline.

Locked project permissions are worth using on the production project specifically, because they stop an owner regranting themselves publish rights on a single workbook and reintroducing the hole.

This costs nothing beyond the thinking, and it is the same project structure a governance model for a small team needs anyway. If you have already done that work, you are most of the way here.

Microsoft's deployment pipelines provide a production environment where creators collaborate to manage the lifecycle of organisational content, developing and testing in the service before it reaches users. That is the three-stage model implemented as a feature, including comparison between stages and deployment rules that repoint data sources as content moves.

Deployment rules are the part worth understanding early, because they solve the problem that otherwise blocks the whole design: the development version needs to point at development data and the production version at production data, without an author editing the connection at each promotion.

Check the supported item types before you plan around it, and check them again at planning time rather than trusting a summary. The feature set moves, and the documentation carries notices about preview status and upcoming changes.

Microsoft also publishes a broader treatment of the surrounding decisions in its content lifecycle management planning series, which is aimed at administrators, centre-of-excellence teams and content owners. Its most useful contribution is naming the roles: someone has to be the release manager, and in a mid-market team that person also has three other jobs.

A promotion that requires a person to download a workbook from one project and upload it to another will be skipped under pressure, and the skip will not be recorded.

Tableau's REST API covers the mechanics: the publishing methods let you publish a workbook, data source or flow to a site programmatically, including large files sent in chunks. That is enough to build a promotion script that takes an asset from test, publishes it to production under the service account, and writes a log line.

Pin the API version when you do. Tableau documents that each release supports a specific REST API version and that requests specify the version in the URI, so a script written against whatever was current is a script that breaks at an upgrade you did not schedule. The wider set of tasks worth scripting is covered in using the Tableau REST API for automation.

The log line is not bureaucracy. Asset, version, who approved it, when it was promoted. That record is what turns a question about when a number changed into a lookup instead of an investigation.

Ask a BI team what their rollback plan is and the answer is usually that they would rebuild it. That is not a rollback, it is an outage with an optimistic tone.

A real rollback needs a retained artifact: the previous published version of the asset, stored somewhere the promotion process put it deliberately, restorable in minutes by someone who is not the original author. Both platforms retain prior versions to some degree, and neither retention setting is guaranteed to match the window you need, so verify yours rather than assuming.

The cheapest version that always works is to have the promotion script archive the artifact it is replacing before it publishes. One extra step, and it makes rollback a file copy.

Test it once. A rollback path nobody has executed is a plan, and plans of that kind fail on their first real use. Run one deliberately in the test stage, time it, and write the time down.

Do not build an approval workflow with multiple sign-off tiers. In a team of ten it will be routed around within a month, and a control that is routed around is worse than no control because it produces false confidence.

Do not require every change to pass through all three stages. A colour change and a revenue calculation change are not the same risk. Define two lanes: cosmetic changes promote with the owner's confirmation, logic and data changes require a reconciliation against the previous version. Two lanes is enough taxonomy.

Do not let the release process substitute for a definition of done. What the owner is signing off has to be written before they are asked to sign it, which is the same argument that applies to any delivered work and is set out in a definition of done for client work.

And do this before a platform move rather than after. A migration is a mass release event, and a programme that already has stages, promotion and rollback simply runs its cutover through them. On a database automation programme decomposed into 159 tracked work items with acceptance criteria and explicit dependencies, the sequencing worked because the release path existed first. The same holds on a BI platform migration: the environment design is not overhead on the move, it is the thing that makes the move reversible.