Hello, We promote Liveboard TML across separate ThoughtSpot clusters (dev → sandbox → staging → prod, each its own instance/org). Each destination cluster's Primary org accumulates its own personalised (saved) views on the tier dashboard over time — e.g. staging has ~100, prod has ~400 — created independently by users in that org. Our current approach: on each promotion we search for the existing tier dashboard by tag in the target org, then re-import the new TML with create_new: false, swapping the TML's guid: to match the existing dashboard's GUID (via metadata/tml/import), rather than creating a fresh object. Is GUID continuity (same liveboard GUID before/after tml/import) + create_new: false sufficient to guarantee all existing personalised views on that liveboard remain intact and correctly attached after import? Or do we need to extract all the view_guid tml, from the to be updated liveboard, and add it into the TML being used in the update?

message has been deleted

Solution: Short answer: No, GUID continuity +

create_new: false

alone is not a documented hard guarantee that all existing personalised views will always remain attached exactly as-is after import. From what’s documented, your current pattern (updating the same Liveboard object instead of creating a new one) is the right baseline for preserving associations, but I could not find an official statement that says you must (or should) merge every

view_guid

into the incoming TML during update. So for your question: - Do you need to extract and inject all

view_guid

TML into each promoted TML? **Generally no**—that is not a documented requirement. - Is your current approach sufficient as an absolute guarantee? Not explicitly guaranteed in docs. Treat it as best practice, but validate in pipeline. A practical safe approach is: 1. Keep updating the existing Liveboard in place (

create_new: false

+ target GUID). 2. Run a post-import validation in target org: - count personalised views before/after - sample-open a few known views - verify report/data APIs can reference expected personalised view identifiers where applicable. --- Suggestions: - Add a **promotion guardrail**: fail deployment if personalised-view count drops unexpectedly after import. - Avoid structural breaking changes in promoted Liveboard (major viz/tab removals/renames) without a controlled migration window, since those can impact user-saved states even if object GUID is stable. - Keep “backup export” of the target Liveboard TML before each import for rollback. - If you need hard contractual behavior for this exact scenario, raise with ThoughtSpot Support for version-specific confirmation (cloud release can matter). --- Docs: - REST API v2 overview: https://developers.thoughtspot.com/docs/rest-api-v2