Tooltip issue for Pivot table

Q&A
,
1

Hi QuickSight Community,

I need a solution for an issue with sheet tooltips in a pivot table visual.

I have two measures:

  1. PF
  2. Running Sum PF

Formula used: Running Sum PF

runningSum(
    sum({measure}),
    [{datefield} ASC],
    [{dimension 1}, {dimension 2}, {dimension 3}]
)

The Running Sum PF value displays correctly in the pivot table. However, when I add this calculated field to a sheet tooltip, the tooltip does not show the running sum value. Instead, it shows the value based on the base PF measure.

I need to understand the correct solution for making the sheet tooltip display the actual runningSum() value from the pivot visual.

Is there any supported way in QuickSight to pass the table-calculated value from the pivot table cell into the sheet tooltip? Or is this a limitation/bug where sheet tooltips recalculate the measure in their own visual context instead of using the already calculated pivot cell value?

Please confirm the correct approach or whether this should be raised as a limitation/bug.

Screenshot 2026-07-03 154915
Screenshot 2026-07-03 154915628Ă—215 33.4 KB

2

Hi @Swetha_Jayachandran

Welcome to the Quick community!

This is expected behavior due to how sheet tooltips are designed in Quick Suite. Sheet tooltips operate as independent visual context.

Because runningSum() is a table calculation. It relies on the ordering and partitioning across all visible rows in the pivot table, when the tooltip sheet recalculates it, it only “sees” a single filtered data point. As a result, the running sum resolves to just the base PF value, which is exactly the behavior you’re observing.

Sheet tooltips do not carry over pre-computed table calculation values from the source visual. They recalculate all measures within their own isolated context. This is by design and not a defect.

The most reliable approach is to pre-calculate the running sum at the data source/SQL level, so it becomes a standard measure rather than a Quick Suite table calculation.

Example:

SUM(pf_measure) OVER ( PARTITION BY dimension_1, dimension_2, dimension_3 ORDER BY datefield ASC ) AS running_sum_pf

You can then use running_sum_pf as a regular measure in both your pivot table and your tooltip sheet visual. Since it’s no longer dependent on Quick Suite’s table calculation context, the tooltip will display the correct cumulative value.

Please refer the following official documentation, which might be helpful for you.

3

Hi @Xclipse ,

Thanks for the response. I tried the suggested approach of calculating the running sum at the dataset/custom SQL level using a CTE.

However, I am still facing an issue when using that pre-calculated cumulative value inside the sheet tooltip.

The running sum column is created successfully in the dataset, but when I use it in the tooltip visual, the value displayed does not match the running sum value shown in the main pivot visual. The tooltip value is either much higher or completely different, even when I try different aggregations such as sum, max, or other aggregation options.

My understanding is that this may be happening because the tooltip is not using the exact same grain as the source pivot visual.

But inside the sheet tooltip, QuickSight seems to aggregate or recalculate the pre-calculated running sum column in the tooltip’s own context. If the tooltip visual does not have the exact same dimensions, filters, partition fields, and date grain as the main pivot visual, the cumulative value loses its original row-level meaning and does not match the pivot value.

So even after moving the running sum logic to SQL/dataset level, the tooltip still does not return the correct cumulative value.

Could you please suggest the correct way to make the sheet tooltip show the exact same cumulative value as the hovered pivot table cell?

Specifically:

  1. What should be the correct grain for the SQL-level running sum?
  2. Which aggregation should be used in QuickSight for the pre-calculated running sum field?
  3. How can I prevent the tooltip from re-aggregating the running sum incorrectly?
  4. Is there a way to pass the exact pivot cell value into the sheet tooltip instead of recalculating it in the tooltip context?

Any guidance would be really helpful.

4

Hi @Swetha_Jayachandran

The behavior you’re experiencing is expected and relates to grain alignment between the SQL-level running sum and the pivot table’s cell-level aggregation.

When you compute a running sum in SQL, it is calculated at the row level of your query. However, your pivot table may be aggregating multiple underlying rows into a single cell. When the tooltip visual then aggregates the running_sum_pf column using SUM, it adds up multiple running sum values from different rows, producing an inflated or mismatched number. Using MAX may also give incorrect results if the underlying grain doesn’t match exactly.

  1. You must first pre-aggregate your base measure to the exact same grain as the pivot table cell, and then apply the window function on that pre-aggregated result.

  2. Since the dataset now has exactly one row per pivot cell (thanks to the pre-aggregation), please use, MAX(running_sum_pf) or MIN(running_sum_pf). Both will return the single correct value for that cell. Please avoid using SUM, as it risks double-counting if there are ever edge-case duplicates.

  3. Please ensure the tooltip sheet visual includes all the same dimensions that define a unique cell in the pivot table:

    • Add dimension_1, dimension_2, dimension_3, and date_period as dimensions or group-by fields in the tooltip visual
    • This ensures that when the tooltip filters to the hovered cell, it isolates exactly one row, and MAX(running_sum_pf) returns the correct cumulative value

If even one partition dimension is missing from the tooltip visual’s context, Quick Suite will aggregate across multiple rows and produce an incorrect number.

  1. Unfortunately, there is currently no mechanism in QuickSight to pass a pre-computed cell value from the source visual into the sheet tooltip. Sheet tooltips always receive filters (not values) and evaluate their own visuals independently.
5

Hi @Swetha_Jayachandran,

Hope everything is well with you! Just checking back in since this thread hasn’t received a response in a while. Was the reply helpful to you or were you able to find a solution yourself in the meantime? Please help the community by marking this answer as “Solution” or following up in general within the next 3 business days!

6

Hi @WLS-Cesar ,

Thank you for following up, and apologies for the delayed response.

Yes, the explanation provided by @Xclipse was very helpful. I understand now that the discrepancy was caused by the difference in granularity between the SQL-level running sum calculation and the pivot table’s aggregation.

The suggested approach of pre-aggregating the base measure at the SQL level to match the pivot table’s grain before applying the window function is the most appropriate solution for my use case. I’ll proceed with implementing the changes in the SQL query and use MAX(running_sum_pf) (or MIN) in the tooltip instead of SUM, as recommended.

Thank you both for the detailed explanation and guidance. I’ll mark this as the solution.