Tableau Feed

Hi Himshikha - good news that it works for you and your colleagues; that tells us the RLS logic itself is sound and it is now down to just that one user. When a single follower sees blank/error while everyone else is fine, it is almost always one of two things - and the blank-vs-error distinction tells you which: 

1) An ERROR (red banner / cannot load the metric) is usually a data source PERMISSION issue, not RLS at all. This is the number-one gotcha: adding someone as a Pulse follower does NOT grant them access to the published data source the metric is built on. That one rep needs at least View (and typically Connect) permission on the underlying published data source, plus a site role that allows it (a licensed Viewer/Explorer, not Unlicensed). Grant her access to the data source and the error should clear. 

2) A truly BLANK metric (loads fine, just no numbers) is an RLS entitlement MISMATCH - her Tableau identity does not exactly match the value your user filter compares against. USERNAME() returns her Tableau Cloud sign-in identity (usually the full email), and the match is exact and case-sensitive. So if your Territory Owner / entitlement value is her display name, an old email, a different domain, or has a stray space or different capitalization, the filter returns zero rows for her - blank. Her name showing in Tableau is not enough; the value in the DATA has to equal her USERNAME() character-for-character. 

Fast way to tell them apart and pinpoint it: open the published data source (or the workbook) as the owner, drop USERNAME() and your Territory Owner field side by side on a sheet, then use the 'View As / filter as user' option to impersonate her. You will immediately see whether her USERNAME() finds a matching row (a data/mapping problem = blank) or whether it throws a permission error (an access problem). That one check usually settles which of the two it is. 

Diego's advanced-definition idea is good as well, but that is a newer Pulse capability still rolling out - your data-source user-filter approach is the right one to get working now. 

If this helps, please mark it as the Best Answer so it helps the next person - thanks :)

Hi Roman,  

You may want to compute the Denominator along both Dimensions (not only along the Bin one) -- and the calc would be simpler (no LOD). 

Please find the attached. 

Yours, 

Yuri

You would have to create a LOD calculation and use it as a dimension filter to get the desired result. However, You should not use a hierarchy since the dimensions are fixed in the LOD calculation.

 Hi Katherine, 

I've seen this exact pain point come up with Litify orgs before — it's not that there's no relationship, it's that Tableau's native Salesforce connector doesn't always expose the Litify managed-package lookups the same way it does standard Salesforce lookups, especially when the field lives on the "far" side of a conversion (Intake → Matter). 

A few things to check/try: 

1. Look for the lookup field directly on Intake or Matter. In most Litify implementations, the Intake object has a lookup field back to the Matter it converted into — commonly something like litify_pm__Matter__c (or a custom-named equivalent if your admin renamed it). Sometimes it's the reverse — the Matter has an Intake__c/litify_pm__Intake__c field pointing back to the originating Intake. Go into Setup → Object Manager → Intake → Fields & Relationships (and the same for Matter) and search for anything with "Intake" or "Matter" in the field name — a lot of firms customize this field's label so it doesn't show up obviously as "Matter" in the picklist Tableau shows you.
2. If there's no direct lookup, it may be conversion-only. Some Litify configs don't keep Intake and Matter linked via a stored lookup at all — the "conversion" is really just field-mapping data across at creation time, with no persistent relationship ID kept afterward. If that's the case, Support's answer (use SQL, no join) is technically correct because there's genuinely no key Tableau's join UI can see/use. In that scenario, people usually link via a shared Party/Client record (the Account or Contact tied to both) or via a common custom field like Case Number/Matter Number if your intake form captures it.
3. Custom SQL isn't as bad as it sounds — since you're already being pointed there, you can just write something like:

sql

SELECT i.*, m.*
FROM litify_pm__Intake__c i
JOIN litify_pm__Matter__c m ON i.litify_pm__Matter__c = m.Id

(substitute the actual field names once you confirm them in Object Manager). This bypasses whatever limitation is stopping the point-and-click join from finding the relationship. 

1. Alternative: build a formula field or reporting layer in Salesforce first. Some teams create a custom "Bridge" object or just add a formula/lookup field that copies the Matter Id onto Intake (or vice versa) specifically so BI tools like Tableau can join cleanly without needing SQL. If you have admin access, this is often less brittle long-term than maintaining custom SQL in every workbook.

Hey Matz, 

Yeah, I've run into this too — sounds like a regression rather than something you're doing wrong. The "Standard" fit + "Entire View" combo used to keep fixed columns pinned and push the vertical scrollbar out past the last column, but in 2026.2 the scrollbar seems to be eating into the crosstab's own width and forcing a resize/reflow of the columns instead of sitting outside them. A few things worth trying while you wait on a possible fix: 

1. Double-check the fit setting per sheet. Right-click the crosstab → make sure it's still set to "Standard" (not "Fit Width" or "Entire View") — sometimes upgrades quietly reset this.
2. Try fixing the container width, not just the columns. Put each crosstab in its own vertical container with a fixed/set height and width, rather than letting it float in the dashboard. Sometimes forcing the outer container size stops Tableau from trying to "helpfully" resize the inner viz to fill the space when the scrollbar appears.
3. Add a floating layout container for just the long crosstab and give it a fixed pixel width slightly wider than the sum of your column widths, so there's room reserved for the scrollbar to render outside the last column rather than overlapping it.
4. Test with "Show scrollbars" behavior — under the crosstab's Format pane there's sometimes a difference in how it handles overflow depending on whether it's inside a horizontal layout container vs. placed directly. Moving it out of a nested container (if you have one) has fixed similar column-shift issues for others.
5. File it as a bug. This smells like a genuine regression tied to 2026.2's rendering engine changes rather than an authoring mistake on your end, especially since you said it worked fine on prior versions with the exact same setup. Worth opening a case with Salesforce/Tableau Support and referencing that it's reproducible on both Desktop and Cloud at 26.2 — that combo (same behavior across two platforms) usually gets bugs escalated faster than "it just looks off."

Hey Tony, 

The core fix here is architectural: your Apex REST endpoint should do almost nothing synchronously. Right now, if your handler is doing lead validation, dedup logic, or DML inline before returning a response, that's what's blowing past the 504 threshold under load, real business logic execution easily drifts past 2-3 seconds, which the gateway treats as a dropped connection. 

Recommended pattern: 

1. Inbound Apex REST method only: validates the payload/signature, publishes a Platform Event with the raw data, and returns HTTP 200 immediately. Nothing else happens in that thread. 

2. A separate Platform Event trigger picks up the event asynchronously, does your actual business validation, then enqueues a Queueable job (implementing Queueable, Database.AllowsCallouts if you need outbound calls) to do the real processing/DML. 

3. Cap callouts below Salesforce's 100-per-transaction limit, chain overflow records to a new Queueable automatically rather than dropping them. 

4. If Apex's async queue itself hits a capacity rejection under heavy concurrent load, catch that exception and fall back to a Scheduled job (e.g., retry in ~20 seconds) so nothing gets silently dropped. 

This decouples network response time from your actual processing time entirely, so gateway timeouts stop being a factor regardless of how complex the downstream logic is. Your observation that direct REST calls resolve under 150ms but webhooks spike under concurrency confirms it's specifically the synchronous processing inside the handler causing the bottleneck, not the API layer itself. 

Also worth adding: idempotency (dedupe on a unique payload ID) since Platform Events and async retries can occasionally redeliver, and Named Credentials for any outbound calls so secrets stay out of code.