#Tableau Cloud63 diskutieren mit

Hi @Eryck Huizar

, 

From the docs, Subscribe is only available when Tableau Cloud can run the view unattended: for a live OAuth connection, the OAuth credential must be embedded or saved, and the refresh token must be valid (

). The docs don't explain why a workbook-embedded OAuth connection would behave differently from a published data source with embedded credentials, so I can't confirm the cause. It may be a product limitation. 

What I'd try: 

- Delete and re-add the Snowflake credential under My Account Settings > Saved Credentials, then embed it again, to rule out an invalid token. 

- Publishing the data source separately with embedded credentials (what you found) seems to be the supported path, and it gives you one place to manage the token. 

- If you want a service-account style setup, Snowflake key-pair authentication is supported on Tableau Cloud (saved credential, published from Desktop; not available for web authoring):

. I haven't verified that it brings the Subscribe button back, though. 

If the button still doesn't appear, a support case may be worth opening. Is the connection live or an extract, and is the data source published separately or embedded in the workbook?

Chris's set idea is the right way, I built it on Superstore to make sure it really drives the zone (screenshots below). A few details that made it work:  

Create a set on Mission ID (right-click the field > Create > Set) and use it in place of the Mission ID filter, so every sheet that was filtered by Mission ID now has the set on Filters showing IN. Then right-click the set > Show Set, and on the card's menu choose Single Value (dropdown). For your users it looks almost the same as the dropdown they have now, the only difference is there's no (All) option in single value mode.  

Keep the set dropdown outside the container you hide. If it sits inside it, it disappears with the section and nobody can switch back.  

The visibility field must be one value for the whole workbook, so the whole comparison goes inside the braces:  

{ FIXED : COUNTD(IF [Mission ID Set] THEN [Milestone Rank] END) > 0 }   

Written as { ... } > 0 it won't show up in the list, that's the bit Chris mentioned. And because it's a FIXED, normal filters don't affect it. If another filter on the dashboard should count too (date, region...), right click it and Add to Context.  

Put the milestone sheets in one tiled container, select the container, go to the Layout tab, tick Control visibility using value and pick the field. When it's False the container goes away and the tiled items around it take the space, so no blank area.  

In my test the field is "does the selected state have any order with a 50% or bigger discount": Texas shows the section, California hides it. Same structure as yours, just swap in Mission ID and Milestone Rank.  

Those messages (Processing request, Computing models, Preparing results) are the loading spinner for the dashboard you're going to, so the click on the button is most likely working. It's the target dashboard that never finishes, and an error after about an hour sounds like a query timing out somewhere.  

To check that, open the dashboard the button goes to directly, from the workbook's list of views or its URL, without using the button. If it hangs the same way on its own, the buttons aren't the problem. That would also fit with Hideaki's simple test working fine.  

If it hangs by itself, a performance recording will show what it's waiting for. A site admin has to allow it first (Settings, the workbook performance metrics option). Then add :record_performance=yes to the view URL (after a ? or an &, depending on whether the URL already has one) and load it. Once the view finishes or errors, click Performance in the toolbar. The recording lists each query with how long it took, so the slow one stands out.  

Also, is any of this on a live connection through Tableau Bridge? If so, check the Bridge client is on a current version as well, since the site itself just got upgraded. 

@Manit Sachdev

Some questions? 

a. Is Tableau Bridge running on Linux or Windows? 

b. Are you working with a published datasource, or with an embedded workbook datasource?  

If workbook embedded and Linux, it is not supported. 

c. If Windows, run in Service Mode. Required for embedded datasources in Windows.  

d. If using Windows, does the Windows user you input to run Bridge as service has access to the shared folder?  

e. Regarding to the path of the datasource, are you using a UNC (//SERVER_NAME/FOLDER_NAME) or local (

?  If you are using UNC you need to have a Bridge Pool. If you are using a local path, then you need to use the default pool.  (I recommend to use UNC, and a dedicated Bridge Pool). 

f. When you published the datasource, did you uncheck the "Include External Files" option. 

Regarding the last two (I know the articles refers to Tableau Server, however, the same requirements apply to Tableau Cloud) 

If you are working with Tableau Bridge in Linux, then you need a UNC mapping: 

Hi @raju Prasad

Thanks for checking. The documentation doesn't say when Pool Name is filled in, so I can't tell for sure why it is mostly empty. To narrow it down, could you filter to the rows with a Null Pool Name and look at these fields for the same task? 

- Agent Name 

- Agent is Pooled? 

- Agent Version 

- Bridge Job Result 

How to read it: 

- Agent Name is also Null: the run is not recorded as a Bridge run. 

- Agent Name is filled but Agent is Pooled? = No: that client is not in a pool, so there is no pool name. It may be worth checking the pool membership of the Bridge clients in your site's Bridge settings, especially if a task is sometimes run by different clients. 

- Agent is Pooled? = Yes but Pool Name is still Null: this looks like missing data rather than expected behavior. I would open a support case with a few example Job IDs. 

If you can share what those fields show for a few of the Null rows, I am happy to take another look.

Hi @raju Prasad

Thanks for the details. Since PAT authentication works and the log says connectivity_stage "CS::QueryExecution", the 403 seems to happen while Prep runs a statement after connecting, not at login. 

My guess is that the manual test used the Databricks UI or CLI, which goes through a different path than the ODBC driver Prep uses to upload the CSV. This is only a hypothesis, but it would explain why everything works manually and only Prep fails. 

To check, could you try the upload through ODBC (or JDBC) from the same machine, using the same PAT? For example, with a SQL client that supports the PUT statement: 

PUT '/local/path/test.csv' INTO '/Volumes/test_db/test_output/perm_test_vol/test.csv' OVERWRITE 

If that also returns 403, I would ask your Databricks / network admin to check whether the machine can reach the workspace storage (storage firewall / selected networks, proxy, private endpoint), since the driver may upload directly to the storage rather than through the workspace host.

Hi @Kirsty Barlow

Your quartile logic itself looks fine. I tested the same pattern (FIXED [Agent ID] -> FIXED PERCENTILE -> IF ... <= cut-off) in a single data source with sample data, and it splits 120 agents evenly into four groups of 30. So I would look at these two things: 

1. The metric that "groups everyone under the bottom 2 quartiles" probably has many tied values. If more than 25% of agents share the same value (e.g. 100%), the 25/50/75% cut-offs become identical and "<=" puts all of them in the lower groups. In my test, 60% of the agents scored 100: 90 agents landed in Q3, 30 in Q4, and none in Q1/Q2. No value-based split can separate tied agents, so use a tie-breaker (e.g. a second metric added as a tiny weight) or treat that value as its own group. 

2. The quartiles not re-adjusting properly is likely related to the blend. FIXED LODs ignore dimension filters unless the filters are context filters, and LODs on secondary-source fields are computed within the secondary source. I would combine the data in one source (in Prep, aggregate each KPI source to one row per staff number + date before joining, to avoid duplicated rows) and then right-click your Month / Department / Manager filters and choose "Add to Context". 

I attached a small workbook with synthetic data: sheet 1 is your calculation in a single data source, sheet 2 shows the tie case.