Tableau CRM to CRM Analytics: What Actually Breaks in the Migration and How to Fix It
Salesforce has shipped this product under four names: Wave Analytics, Einstein Analytics, Tableau CRM, and now CRM Analytics (CRMA). Each rename brought documentation reassurances that nothing meaningful changed for developers. The Tableau CRM to CRM Analytics move is the one where those reassurances fall shortest.
If your dashboards stopped loading, your embedded components went blank, or your Apex jobs started throwing cryptic errors after the rename, this guide is for you. Not theory. Not glossary definitions. What actually breaks and where to look first.
The API endpoint shift is a hard failure, not a warning
This is where most teams lose the most time.
Lightning components embedded in Salesforce pages use the Wave API under the hood. When Tableau CRM became CRM Analytics, the versioned endpoint path for embedded component references changed. The old Wave namespace path is deprecated; the new path sits under /services/data/v59.0/analytics/. If your custom Lightning components or external integrations were calling the v58 Wave endpoint, they now return 404 or permission denied.
What makes this particularly painful is that it does not surface as a helpful error message. The dashboard just fails to render. You get a blank widget or a spinner that never resolves.
Where to look: search your component code for any hardcoded /wave/ path references. Also check any sfdcRegister or sfdcDigest calls in your dashboard JSON. If those calls reference stale endpoint paths, or if a lensId reference is resolving against a dataset that does not exist at the new path, you will see "Dataset not found" with no further guidance.
The fix is straightforward once you know what to look for: update every endpoint reference from the deprecated Wave path to the new analytics path. The version number in the URL matters too. Teams that did a bulk find-and-replace on "wave" and called it done often missed the version bump and ended up with a different broken state.
Apex namespace deprecation is the silent killer
Apex code that references the Wave namespace keeps working for now. That is the problem.
If you search your org for WaveApi or WaveDashboard, you will find classes that currently execute without throwing an exception. They do log deprecation warnings, but those are easy to miss in production log volumes. Salesforce will remove these classes in a future release, and when they go, any workflow or scheduled job that touches them will break without warning.
The migration path: WaveApi and WaveDashboard references need to be updated to use EinsteinAnalytics (the current supported namespace). Yes, this is confusing given that Einstein Analytics is itself two product names ago. The namespace did not get renamed again with the Tableau CRM to CRM Analytics move. You are updating to EinsteinAnalytics, not to something called CRMAnalytics.
If your org has Apex jobs that programmatically create dashboards, push data, or interact with datasets, audit them now. Do not wait for production to surface this.
SAQL compatibility has real edge cases
The documentation says SAQL is unchanged. That is mostly true for simple queries. For anything non-trivial, there are parsing changes that bite you.
computeExpression is the one that shows up most often. In Tableau CRM, you could call it without supplying a datasetId in the lens context and it would resolve fine. In CRM Analytics, it requires the explicit reference. The error you get is vague. Nothing in the message tells you which parameter you are missing.
The bucket function has a similar story. Implicit data types that Tableau CRM inferred without complaint now require explicit declaration. If your recipe or lens uses bucket with numeric bins and no declared data type, expect it to fail silently or return malformed results.
filter operations that reference a datasetId are worth auditing too. If the dataset ID in the filter predicate does not match the lens it is running against, you get a runtime error about the dataset not being found. This is not an error from the rename itself. It is an error that the rename makes more likely to surface, because dataset IDs sometimes change when data flows are re-registered under the new API paths.
The diagnostic process here is methodical: export your dashboard JSON, find every SAQL block, and run each one in the CRM Analytics query workbench in isolation. If a query fails in the workbench, the error message is more informative than what the dashboard surface shows. This is how you localize the problem.
Dashboard JSON schema versioning breaks cross-environment imports
If you exported a dashboard from an older Tableau CRM org and tried to import it into a CRM Analytics org, you may have hit a silent import failure.
The dashboard JSON schema version changed between the two products. An older export carries version 1.0 in its envelope. CRM Analytics expects version 2.0. The import does not always throw an explicit error. It can succeed at the validation step and then render a broken dashboard, or it can fail without a clear message pointing to the schema mismatch.
The same issue can trip you up when building deployment pipelines. If your CI/CD process exports from a dev org, transforms the JSON, and deploys to production, and those orgs are on different API versions, the schema version in the envelope may not match. One symptom is that jsonProperties defined in a dashboard component gets silently dropped on import.
Check the version field in your dashboard JSON envelope before any cross-org deployment. If it does not match the target org's expected version, update it manually before importing.
Connector naming affects SAQL joins
Embedded analytics connectors were renamed along with the product. If your SAQL uses append or augment and references a connector by name, the reference that used to say "Tableau CRM Connector" now needs to say "CRM Analytics Connector." That is not a configuration change. It is a string in your SAQL that you have to find and update.
This one is easy to miss because it does not appear in Apex and does not live in Lightning component code. It is inside the SAQL blocks in your dashboard JSON. A text search of exported dashboard JSON for the old connector name string is the fastest way to find affected queries.
Why this takes longer than it should
The failure modes described here share a pattern: they do not throw errors that point at the root cause. A dashboard goes blank. A widget shows no data. An Apex job silently stops doing what it used to do. The surface symptom and the actual cause can be two or three diagnostic steps apart.
That gap is where teams burn time. You spend an hour checking dataset permissions before you notice the endpoint path. You rebuild a query from scratch before realizing the connector name is stale. These are not hard problems once you know what to look for. They are time-consuming problems when you are learning the product's behavior from its error messages alone.
If you have a production dashboard that broke after the rename and you need to understand exactly what is wrong and in what priority order to fix it, that is a finite scoped problem with a known set of failure modes. It does not require guesswork.
A one-dashboard audit from us runs $249 flat. You export the dashboard JSON yourself (no org access needed on our end), send it over, and within 48 hours you get a step-level audit of everything wrong in that dashboard and a prioritized fix list with expected query reduction. In one recent audit we cut dashboard JSON size by 53% and page-one load queries by 37%, with render-identical output verified before and after. If that sounds useful, book a $249 teardown on crmalabs.com.