Power BI: dashboards implementeren van dev naar prod zonder duplicaten

Samenvatting

ThoughtSpot voorkomt dubbele dashboards in productie met TML, obj_id en REST API v2 voor deployments vanuit Git.

ThoughtSpot en TML: wat er gebeurt

ThoughtSpot beschrijft een CI/CD-aanpak waarbij Liveboards, Models en Tables als TML-bestanden in YAML-formaat vanuit Git naar productie gaan. Een pipeline gebruikt daarvoor de TML-import- en export-API’s van REST API v2, bijvoorbeeld vanuit GitHub Actions of GitLab CI.

Duplicaten ontstaan wanneer ThoughtSpot het binnenkomende object niet aan een bestaand object kan koppelen. De naam telt daarbij nooit mee. Met ingeschakelde obj_id zoekt ThoughtSpot eerst op een zelfgekozen identificatie; daarna werkt een import hetzelfde dashboard of model bij.

obj_id maakt ThoughtSpot-deployments controleerbaar

Zonder obj_id valt ThoughtSpot terug op GUID. Ontbreekt ook die waarde in het TML-bestand, dan maakt het platform altijd een nieuw object aan. Ook create_new: true op bestaande objecten veroorzaakt duplicaten.

De aanbevolen werkwijze is daarom concreet: laat ThoughtSpot Support obj_id activeren, geef objecten leesbare IDs en exporteer met include_obj_id en include_obj_id_ref. Schakel GUID-export uit. Na validatie importeer je met import_policy: ALL_OR_NONE, zodat de pipeline de wijziging als één geheel verwerkt. De aanpak is gecontroleerd tegen REST API SDK 2.29.1 en ThoughtSpot Cloud 26.10.0.cl-documentatie uit oktober 2026.

Concrete takeaway voor ThoughtSpot-teams

Behandel dashboards en modellen als code. Leg elk TML-bestand vast in Git, controleer wijzigingen via een pull request en gebruik overal dezelfde obj_id voor het object dat tussen ontwikkel- en productieomgevingen beweegt. Controleer bestaande content nadat obj_id is ingeschakeld: automatische IDs verschijnen pas nadat een object voor het eerst is gewijzigd. Test daarnaast eerst een import in productie en gebruik daarna ALL_OR_NONE.