Hi. I am trying to parametrize the connection (user and private_key) so that we can publish the table / model. I created the variables DW_USER and DW_PASSWORD (is_sensitive = true) but when I assigned a private key to variable DW_PASSWORD, I always get following error. Private key generated is in following format. -----BEGIN PRIVATE KEY----- ABC CDE FGH -----END PRIVATE KEY----- Error Details [10041] Something went wrong Trace Id for this incident is tracing-disabled Additional Details com.thoughtspot.common.ThoughtSpotException: Not Found My objective is to be in hybrid state where new tables / models are distributed to org through publishing while existing table/model/liveboard are duplicated across tenants. I am following these steps. 1. Create variables DW_USER, DW_PASSWORD (is_sensitive = true). 2. Assign a value of correct snowflake username and private_key for this variable for primary org. 3. Parametrize the existing connection with these variables so existing connection will work as it is while it will allow publishing of new tables/models/liveboards. 4. Publish the new table / model / liveboards to orgs without disrupting the existing content. 5. Share the published table/model/liveboard to respective thoughtspot content sharing group. But I am facing issue in step 3. Thank you in advance for your help. https://cdn.discordapp.com/attachments/1143209464875462756/1495616878134034564/Screenshot_2026-04-20_at_12.40.30_PM.png?ex=69e6e542&is=69e593c2&hm=98be080d60952553157f038c8f512578b91a63923ea4d99372330ffb606654fb&

message has been deleted

Thanks for the detailed steps — this is very helpful. You’re very likely hitting a credential format mismatch in step 3, not a publish/share workflow issue. From the official ThoughtSpot connection docs returned, Snowflake connection configuration uses these fields:

accountName

,

user

,

password

,

role

,

warehouse

(for service-account style auth). I could not find documentation indicating a Snowflake

private_key

field in that connection metadata format. So if you put a PEM private key block into a variable mapped to

password

, ThoughtSpot/Snowflake auth can fail and surface a generic backend error (like your

10041

+

Not Found

). ## What to change 1. Keep

DW_USER

for

user

(good). 2. For Snowflake service-account connection, map

DW_PASSWORD

to an actual Snowflake password (not PEM key). 3. If your org requires key-pair auth, use the Snowflake auth mode/connection type that explicitly supports it (rather than forcing key text into

password

). In the tool results I got, that exact key-pair parameterization path is not documented for the standard Snowflake

configuration

block, so I can’t confirm it exists in this flow. 4. Validate by updating only the connection first (without publish), then test table access, then publish. ## About your hybrid objective (existing duplicated + new published) Your approach is conceptually correct: - Existing content can remain duplicated per tenant. - New content can be rolled out via publish/share. - The key is: published objects must resolve dependencies (connection + model/table access) cleanly in target orgs. So first stabilize connection credentials format, then proceed with publish/share. ## Why this is likely step 3 specifically You reported failure when parameterizing existing connection with: -

DW_USER

= username -

DW_PASSWORD

= private key PEM

I am using keypair authentication type with snowflake as DW. I am using same private key as it is used to create connection. When I just parametrize user, it is working but throwing error when I try to parametrize private_key as well.

Thanks for the additional detail. What's going on: ThoughtSpot stores sensitive variable values (is_sensitive=true) in a secure vault (Confidant Vault), not directly in the variable store. When you parameterize the connection, it resolves the variable reference by fetching the private key from that vault. The SECURE_STORE_ERROR: Not Found means the vault lookup returned a 404 — the private key value is either not present in the vault or the vault is not reachable/configured in your deployment. Non-sensitive variables like DW_USER bypass the vault entirely, which is why that works. Steps to resolve: 1. Re-assign the variable value. Delete the current value for DW_PASSWORD and re-add it. If the initial assignment failed silently while writing to the vault, this should retry the write and fix the inconsistency. 2. Verify the assignment succeeded. After re-assigning, try calling the variable list/get API to confirm the entry exists. If the assignment API itself returns an error when setting the private key, that confirms the vault write is failing at your deployment level. 3. Check the private key formatting. When entering the private key value, make sure you're pasting the full PEM block including the -----BEGIN PRIVATE KEY----- and -----END PRIVATE KEY----- lines, with the line breaks preserved. Some UI inputs may strip newlines — if yours does, the assignment may appear to succeed but store a malformed value. 4. If the above doesn't resolve it: this is likely a Confidant Vault configuration issue in your ThoughtSpot deployment. Please open a support ticket and include the Incident ID 65418459-e113-4ac1-9ca3-534dfd23cb08 — our team can use this to trace the vault operations and confirm whether the write succeeded.