Fifty-Seven Out of Sixty
You publish a dashboard to Tableau Cloud for 60 people. The data comes from an on-premises PostgreSQL behind a firewall, published as a live published data source with embedded credentials. One week after launch: the three APAC analysts get "Unable to connect to the data source" ending in a timeout, while US users load in 2–3 seconds. Your finance partner insists the top-line KPI should read $2.4M - and it does for you - but she sees $2.1M at the same URL. A second workbook in the project, built on an extract last refreshed 14 hours ago, is being used by one team. Separately, the CFO's office objects that anyone with the link can use Download → Crosstab and pull customer-level rows.
1. Diagnose the APAC timeouts and give two remedies with their tradeoffs.
Read the worked answer
The published data source is live and points at a database behind a firewall; Tableau Cloud has no route into that network. US users succeeding tells you it is not credentials or permissions - it is network path and latency, with APAC users round-tripping across the internet to a VPN terminator before any query starts.
Remedies:
- Extract the published data source and schedule a refresh (every 4 hours, say). Every user then queries a fast local copy, no firewall dependency, and the symptom disappears for all 60. Cost: staleness and extract size.
- Tableau Bridge to keep the connection live. Keeps data current but adds a client to run and monitor, needs redundancy if refreshes matter, and the pool size caps concurrent live queries - so a Monday-morning spike is now your problem.
A hybrid is often right: extract for the 57 who read dashboards, Bridge-backed live for the handful who genuinely need intra-day data. Before choosing, measure query time in the data source's connection log to confirm latency rather than a slow view on the Postgres side - the fix is different if the query itself is the problem.
2. How do you run down $2.4M versus $2.1M on the same URL?
Read the worked answer
Two numbers on one URL means you are not looking at the same rows. Work in order, cheapest first:
- Refresh state. There is a second workbook in the project on a 14-hour-old extract, and one team is using it. Confirm which workbook, and which data source, each person actually opened - a 12.5% gap is a plausible day of trading.
- Row-level security. Check for a data source filter or a
USERNAME()/USERATTRIBUTE()driven calculation, then use View As on that user to see what her filter produces. A regional slice is exactly the size of gap you are seeing. - Filter scope. A data source filter applies everywhere; a sheet filter only where it was added. View As plus the filter list (which shows "…of N" when hidden) settles it in a minute.
- Revision. Tableau Cloud keeps revision history - confirm you both have the same published timestamp.
Then fix the architecture, not just the number: one published data source, one definition of the KPI, and a visible "data as of" stamp on the dashboard so $2.1M and $2.4M can never again be argued about without a timestamp attached.
3. The CFO's office wants customer rows locked down. What do you actually change?
Read the worked answer
Two layers, and closing only one leaves the hole open.
- Workbook capabilities. In the workbook's permissions, remove Download Summary Data and Download Full Data for the affected groups (and Save to PDF if the print layout leaks the crosstab). Leave View. Capabilities are additive and inherited from the project - if the group gets Download from the project level, denying at the workbook is the only thing that overrides it.
- Data source capabilities. Anyone with Connect on the published data source can open it in Desktop or Web Authoring and query the table directly, bypassing the dashboard entirely. Deny Connect broadly, grant it to authors only. With embedded credentials, a viewer who can connect inherits whatever the service account can see - that is the real exposure here.
Then answer the question they actually asked, which is not about export: implement row-level security with a user filter or a USERNAME()-based calculation so people see the customers they are entitled to. Test with View As for two or three real users before announcing it, because a broken user filter is worse than an open one.