#Tableau Desktop & Web Authoring178 personnes en discutent

Try with the following. 

"123"+CHAR(10)+"456"+CHAR(10)+"789"

Adding to Farhan's and Steve's helpful comments, I think your finding that a single worksheet works, a web-authored dashboard works, but a Desktop-authored dashboard does not gives us a very useful way to narrow this down further.

Before rebuilding any existing dashboards, I would try creating a very small test workbook in Tableau Public Desktop 2026.2.1:

1. Create one simple worksheet.
2. Publish it and confirm that its thumbnail appears.
3. In the same workbook, create a new dashboard containing only that worksheet.
4. Publish again without adding any other dashboard objects, containers, images, extensions, etc.
5. Check whether the thumbnail becomes blank.

If the worksheet thumbnail works but the minimal dashboard becomes blank, that would be a particularly useful reproducible case because it removes most workbook-specific factors from the equation.

I would also try publishing the same minimal workbook from a different Desktop Public version, if one is available to you. If the exact same workbook produces a thumbnail from another build but not from 2026.2.1, that would provide stronger evidence that the behavior is related to the Desktop build / publishing path rather than the dashboard design itself.

One other thing I would avoid for now is rebuilding the production dashboards in Web Authoring just to fix the thumbnails. Since the published dashboards themselves render correctly, and Steve mentioned that a Tableau Public thumbnail issue is already being investigated, rebuilding could involve a lot of work for something that may ultimately be resolved on the service side.

So, as a next step, I think a minimal reproducible workbook would be very valuable:

Worksheet → thumbnail OK

If that sequence is reproducible, it should give the Tableau team a very clean test case and may also help determine whether this is the same known thumbnail issue Steve mentioned or something specifically related to Desktop Public 2026.2.1.

Hope this helps with the investigation!

Building on Steve's parameter approach and Keisuke's suggestion for keeping Product A and Product B in a consistent display order, I would like to add one more option that may be useful when the requirement goes beyond simply displaying the two products side by side.

The two parameters can also be used directly inside calculated fields. This makes it possible to create comparison metrics such as the difference, ratio, or percentage change between the selected products.

For example, assuming the parameters are [Select Product A] and [Select Product B]:

// Product A Sales
SUM(
    IF [Product Name] = [Select Product A]
    THEN [Sales]
    END
)

and:

// Product B Sales
SUM(
    IF [Product Name] = [Select Product B]
    THEN [Sales]
    END
)

We can then create calculations such as:

// Difference
[Product B Sales] - [Product A Sales]

or:

// B vs A %
IF [Product A Sales] <> 0 THEN
    ([Product B Sales] - [Product A Sales])
    / [Product A Sales]
END

This can be particularly useful when the dashboard needs to answer questions such as:

• How much higher/lower is Product B than Product A?
• What is the percentage difference?
• Which characteristics differ the most between the two selected products?
• How do the two products compare across several business-specific KPIs?

The same pattern is not limited to Sales. The conditional logic can be incorporated into more complex calculated fields, so in many cases the business logic can remain in Tableau rather than requiring the parameter values to be passed into custom SQL.

For a comparison table with many characteristics, another approach I have found useful is to structure the data so that the characteristics are represented as rows, for example:

CharacteristicProduct AProduct BDifference

Sales | ... | ... | ... 

Profit | ... | ... | ... 

Margin | ... | ... | ... 

Volume | ... | ... | ...

This gives us a fairly flexible "Product A vs Product B" comparison framework: the parameters define what to compare, Keisuke's labeling technique controls how A and B are displayed, and calculated fields define how they are compared.

One additional consideration is the level of detail of each metric. If some KPIs need to be calculated at a specific grain before Product A and Product B are compared, LOD expressions can also be combined with this approach. This is especially important for ratios or other non-additive metrics where simply summing the underlying values may produce an incorrect result.

So I would probably try the parameter + calculated-field approach first before moving to parameterized SQL. Custom SQL can certainly be useful, but keeping the comparison logic in Tableau generally makes the workbook easier to interact with and maintain when the underlying dataset is already at an appropriate level of detail.

Hope this provides another useful variation for anyone building a dynamic two-product comparison dashboard. 

Kanna Ato

Hope that points the way for you. See the green tabs in the reattached .twbx workbook. 

If this response answered your question, please mark it as an Accepted Answer? 

This way, others searching for similar solutions will find the answer faster in the future.

Best, Don Wise (Tableau Ambassador)

Hi @Hideaki Shiihara

, 

Thank you for sharing the attachment and the suggested approach. 

I reviewed it, and yes, this appears to be what I am trying to achieve. The dual-axis method for displaying the total value on the Total bar looks good.

However, my primary concern is avoiding LOD calculations, as they can have a noticeable impact on dashboard performance, especially with larger datasets. Since the solution in the attachment still leverages an LOD calculation, I am looking for an alternative approach that delivers the same result without using LODs.

If you have any recommendations using table calculations or other performance-friendly techniques, I would appreciate your suggestions.

Thank you for your help.

Thank you  

Chitti

You need to create a table calculation to filter the data as shown below:

Hi Himshikha - yes, this is doable, but the key thing is that you don't set up RLS 'in Pulse' itself - Pulse metrics inherit the row-level security of the published data source they're built on. So you implement RLS on the underlying data source, then build the Pulse metric on it, and each rep automatically sees only their territory's numbers (including in their Pulse insights and email digests). 

Two ways to implement the RLS on the source: 

1) Virtual Connection + Data Policy (the modern, recommended way). In Tableau Cloud, create a Virtual Connection to your data and add a Data Policy that filters rows by the logged-in user - typically by joining to an entitlement table (a user-to-territory mapping) and matching on USERNAME(). Because the policy lives on the virtual connection, it's enforced everywhere that connection is used - Pulse included - and you maintain it in one place. 

2) Data source filter / user filter (simpler, classic). On the published data source, add a calculated field like [Territory Owner] = USERNAME() (or join to an entitlement table keyed on USERNAME()/USERUSERNAME()) and apply it as a data source filter, then publish. Pulse metrics built on that source inherit the filter. 

End-to-end scenario: build and maintain a user-to-territory entitlement table, apply RLS via option 1 or 2 on the data source, create the Pulse metric on that secured source, and then each rep who follows the metric sees only their territory's value, trend, and insights. 

Two gotchas: make sure the Tableau user identity actually maps to your territory field (via USERNAME()/USERUSERNAME() or a group), and test it by previewing as a specific user (the user-filter dialog lets you confirm what each user sees) before rolling it out. 

Hope that helps!