#CRM Analytics12 人がディスカッション中

Diego, that OAuth 2.0 trust connected app is the path I'd point Kathy to for the standard Tableau LWC. Once Tableau Embedding is set up in Salesforce and Enable Single Sign-On is on, the component handles the handshake. She doesn't need a separate token service for that route.

Kathy, the trusted URL and the site ID get the viz onto the page. Each person still needs their own Tableau Cloud user with access to the workbook. The connected app doesn't create those users.

Hi there, 

There is a tracked issue on

: "Einstein Analytics - Adoption App - Apex Error Argument cannot be null," which describes the same WaveMetaDataQueueable class failing after installing the Analytics Adoption Metadata package. The exact error text differs slightly from yours (Argument cannot be null vs. the ApexPages.addMessage context error), but it's the same failing queueable class in the same managed package — worth checking that issue thread for current status/comments, since it confirms this isn't isolated to your org. 

Since the package is managed and WaveMetaDataQueueable's source is hidden, you're right that you can't patch around it directly. Practical options in the meantime: 

1. Disable the Adoption Metadata dataflow trigger. In Setup → Analytics Settings (or via the AnalyticsSettings metadata, analyticsAdoptionMetadata flag), you can turn off automatic Adoption Analytics metadata collection so the queueable stops firing and throwing the exception on schedule. 

2. Check/upvote the existing issue on

rather than filing a duplicate — that's the channel Salesforce Labs teams actually monitor for prioritization, and comments/votes there carry more weight toward getting a fix scheduled than a community thread. 

3. If this isn't business-critical for you right now, uninstalling the package until a patch lands is the cleanest way to stop the recurring failed async job/error emails. 

Since it's a Salesforce Labs (not core platform) managed package, there's no formal SLA on a fix — the

@Murielle Majesté

Good news - that 'unexpected EOF' message is not a problem with your dashboard. It is a known html2canvas CSS-parsing error, thrown when CRM Analytics tries to snapshot your annotated chart into the image it posts to Chatter. It usually fires because a browser extension (ad blocker, dark mode, Grammarly, etc.) injects CSS the snapshot cannot parse, so the annotated post is never created - which is exactly why the grader says it cannot find the annotated Chatter post. 

Fix: 

1. Open your Trailhead Playground in a clean Chrome window - Incognito, or with every extension disabled. 

2. Re-open the dashboard, annotate the chart, and use Post to Feed to share it to Chatter. With nothing injecting CSS the snapshot renders and the post lands on the dashboard Chatter feed. 

3. Re-run Check Challenge. 

if this helps, please mark it as the Best Answer so it helps the next person - thanks 🙂

Hi @SIVA Kishore

nothing in the standard widget palette (chart, list, toggle, date, range, number, text) creates a popup that intercepts interaction on load. What CRMA does give you natively are selection based filter widgets date, list, range, and toggle that let users filter results, and these can trigger selection bindings that dynamically change other query parameters, plus the ability to set initial filter selections that are applied when the dashboard first opens. 

None of that adds up to a true gate, though it pre selects or lets users filter, but users can still interact with every widget before making a choice, which breaks your requirement #6.  

What actually gets you the behavior you described: a custom LWC wrapper, not a dashboard internal component. 

The key distinction is where the LWC lives. Don't embed it as a widget inside the dashboard canvas embed the dashboard inside

an LWC on the Lightning App Page instead:  

1. Build an LWC for the App Page that, on connectedCallback, shows a modal (SLDS modal or the native lightning-modal overlay) with a Customer Name picklist/combobox.
2. Don't render the <lightning-analytics-dashboard> component at all until the user submits a selection - conditionally render it with if:true. This is what actually satisfies "no interaction before selection," since the dashboard genuinely isn't mounted yet, not just visually hidden.
3. On submit, close the modal and mount the dashboard, passing the chosen customer in as a filter - either via the dashboard component's filter/selection input, or via the query-string filter/selection syntax CRMA supports for embedded dashboards.
4. This pattern (custom LWC talking to a CRMA dashboard, Apex backed data lookups feeding the picklist) is a standard, well documented approach embedding LWCs into or alongside CRMA dashboards is explicitly supported.

If you want to avoid a custom component entirely, the closest declarative approximation is: a required Global Filter Panel widget with no default selection, paired with faceting so every other widget shows an empty/prompt state until a Customer is chosen. It's a real CRMA pattern and much less build effort, but it only discourages

interaction with unfiltered widgets it doesn't block it, so it won't fully satisfy your requirement #6 as written. Worth confirming with whoever owns this requirement whether that softer UX is actually acceptable before committing to the LWC build, since it's a meaningfully smaller lift. 

One thing to flag before you build either way: confirm whether this dashboard is embedded (Lightning App Page / Experience Cloud) or accessed directly in the Analytics Studio tab the LWC wrapper approach only works for the embedded case, since you need a page to host the wrapper component around the dashboard.

Hi Siva, one thing up front: standard CRMA has no true modal pop-up that fires automatically on dashboard load. So you achieve this by gating the dashboard behind a selection rather than an actual modal. Two clean ways: 

1. Selection page (closest to a pop-up). Make page 1 a simple Select a Customer page with just a list or dropdown widget and a heading, and put all your charts on page 2. Add a link or button widget that navigates to page 2. The user lands on the picker first, chooses a customer, then moves to the data. This gives the choose-first, cannot-touch-the-widgets-yet behavior you want. 

2. Gate on a single page. Keep everything on one page but bind every data widget to the customer list selection, and build the steps so they return no rows until a customer is chosen. Add a text widget saying Please select a customer so the empty state is clear. 

Gotcha to avoid: do not rely on Require Selection to leave it blank. If a query requires a selection and you set no initial selection, CRMA auto-selects the first value on open, so it will not sit empty waiting for the user. That is why the selection-page or bound-widget approach is more reliable for a true choose-first experience. 

if this helps, please mark it as the Best Answer so it helps the next person, thanks 🙂

In CRM Analytics you do not actually 'connect' separate dashboards, the pattern is to build ONE dashboard and use Global Filters to slice it by region/object/etc. How you get there depends on whether your regional dashboards sit on the same dataset or different ones: 

If they are all on the same dataset (the easy case): 

Create a single new dashboard on that dataset, add the charts/widgets you want, then add Global Filters (the filter panel in the dashboard editor) on Region, Object, and any other fields. Widgets built on the same dataset facet together automatically, so one Region selection filters everything at once. That gives you the 'one global dashboard, filter by region' behaviour you are describing. 

If each region is a separate dataset: 

You first need them in one dataset, otherwise a single Region filter has nothing common to filter on. Use a Recipe (Data Prep) to UNION the regional datasets into one combined dataset, and if a 'Region' column is not already on each, add it in the recipe so every row is tagged with its region. Then build your single dashboard on that combined dataset and add the Global Filters as above. Since you tagged Dataset Recipe, this is likely your path. 

A couple of pointers: 

- Global Filters live in the dashboard's filter panel and apply to every widget bound to that dataset, pin them so they persist. 

- If you keep widgets from more than one dataset in the same dashboard they will not auto-facet, you connect them with bindings, or cleaner, unify into one dataset via the recipe so faceting just works. 

Net: do not try to link the existing dashboards, rebuild as one dashboard on a single (recipe-combined, if needed) dataset, then Global Filters give you the region/object slicing. 

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