TrailheaDX 2017 Wave Analytics Roadmap: What to Plan for Next 12 Months

We're writing this coming out of TrailheaDX in early June, and the Wave Analytics track gave us enough to think about for the rest of the year. If you've been deep in Wave implementations — and we've had our hands full across manufacturing, financial services, and service-heavy orgs — you know the gap between what gets announced on stage and what actually ships in a form you can build on top of. This post is our honest read on what we saw, what we think matters for client roadmaps, and where we'd pump the brakes before over-committing.

Fair warning: this is not a recap of the keynote. If you want slide screenshots, the internet has you covered. This is a practitioner's read aimed at the architects and analytics leads who are about to go back to their stakeholders and explain what the next twelve months of Wave investment should look like.


The Announcements That Actually Matter

Predictive Maintenance on Wave

This was the one that had our manufacturing and utilities clients leaning forward. The framing around predictive maintenance — using Wave as the layer to surface equipment and asset failure signals — is directionally interesting, but let's be precise about what was actually shown versus what was implied.

What we saw was a demonstration of Wave surfacing asset health data, correlating operational readings with historical failure patterns, and presenting that in a dashboard context that field technicians and operations managers could plausibly use. The underlying inference work is being positioned as an Einstein capability feeding into Wave, not something Wave itself is computing natively.

Why does that distinction matter for roadmaps? Because if you have a client who wants to start this work now, you're still in "bring your own model" territory for the heavy analytical lifting. Wave can absolutely serve as the visualization and alerting layer. What it can't yet do — or at least wasn't demonstrated doing — is let a business analyst configure a failure prediction model from scratch inside the platform without significant data science support upstream.

Our recommendation: if you have clients in asset-intensive industries, this is a credible direction to orient toward in planning conversations. But set the expectation that the first phase is about getting the right operational data into Wave and building the monitoring layer. The predictive intelligence comes later, and it's going to require either platform maturity to catch up or a data science capability to bridge the gap.

Einstein Vision and Image Recognition

This one generated the most hallway conversation, and also the most confusion. Einstein Vision is arriving as a capability that lets you bring image classification into Salesforce workflows — the examples shown included things like identifying products from photos and flagging visual defects in field service contexts.

Here's the honest assessment: Einstein Vision is not a Wave Analytics feature in any direct sense. It's an Einstein platform capability. The connection to Wave is that the classification outputs — labels, confidence scores, what have you — can become data that flows into your analytics layer. A field technician photographs a piece of equipment, the image gets classified, that classification event becomes a data point, and then Wave is what you use to analyze patterns across thousands of those events over time.

If you walk into a client meeting and say "Wave now does image recognition," you're going to have a bad time when the implementation scoping conversation happens. The correct framing is: Einstein Vision gives us a new category of signal we can bring into Wave, and for clients who have meaningful visual data in their operations, this is worth a serious conversation about data architecture.

The use cases we found most credible were in field service — where photos are already being captured in some form — and in retail or manufacturing quality control scenarios. If your client isn't already capturing images in a structured way, this is a longer runway project than anything you'd realistically roadmap for the next twelve months.

Service Analytics Templates

This is the one that's most immediately actionable, and in some ways got the least glamorous treatment in the announcements because it doesn't have the same "future of AI" framing.

The service analytics template work builds on what Wave has been doing with pre-built dashboard frameworks for a while, but the focus here is on Service Cloud parity — giving service operations leaders something they can deploy without a full custom analytics engagement. Case resolution, escalation patterns, agent performance, channel mix, SLA compliance: the kinds of metrics that service managers are reporting on manually in spreadsheets or have been asking for since day one of their Service Cloud go-live.

We've done enough service analytics work to know that this template approach has real value and real limitations in equal measure.

The value is time to first insight. If a client has reasonably clean Service Cloud data and they want to get something on screen for their VP of Service in the next sixty days, a well-constructed template that's been shaped to their terminology and key metrics is genuinely faster than a custom build. We've seen this play out. The template gets you to the conversation faster, and the conversation tells you what to customize.

The limitation is that every serious service operation we've worked with has some metric or business logic that isn't in the template. Escalation paths that reflect their internal org structure. SLA definitions that have exceptions built into contracts. Blended channel attribution rules that are product-specific. The template gets you to eighty percent, and then you're in SAQL and the dataflow editor for the rest of it.

What we'd tell clients: use the template as a starting point and a scope-setting tool, not as the deliverable. If the template lands and nobody wants anything changed, your data quality probably has bigger problems than your analytics gaps.


What Wasn't Said That You Should Read Into

The Mobile Story Is Still Incomplete

Wave on mobile continues to be in a somewhat awkward state, and TrailheaDX didn't change that picture meaningfully. The dashboards render, the experience is functional, but the interaction model for mobile-first use cases — where a field technician or a sales rep in a meeting is the primary user, not the analyst who built the dashboard — still requires more design care than most implementations give it.

If you have clients whose core user base is mobile, we'd be cautious about promising a Wave rollout that treats mobile as equivalent to desktop. It isn't yet, and we didn't see announcements that suggest that gap closes in the near term.

Data Connectors and the Ecosystem Question

A lot of what makes Wave valuable in enterprise settings is data you're pulling from outside Salesforce — ERP data, operational systems, external databases. The connector ecosystem was not a headliner at TrailheaDX, and that tells you something. The work of getting non-Salesforce data into Wave cleanly is still largely configuration and custom work. Expect that to continue to be a meaningful part of implementation effort for the foreseeable future.

We'd actually flag this as a risk area for roadmaps built around the predictive maintenance angle specifically. The operational data from SCADA systems, IoT platforms, and asset management tools that you'd need to make maintenance prediction real is almost never already in Salesforce. The integration work can dominate the project timeline.


How We're Advising Clients Right Now

Given everything above, here's roughly how we're framing Wave roadmap conversations coming out of TrailheaDX.

For Clients Just Starting Wave Adoption

Don't let the AI announcements distract from fundamentals. The clients who are getting the most value from Wave right now are the ones who did the unglamorous work: clean data models, disciplined dataflow design, user adoption programs that got dashboards in front of decision makers with context and training. Start there.

The template offerings — and service analytics in particular — are a reasonable entry point if you want to show value quickly without a multi-month custom build. Just be honest about what the template covers and what it doesn't.

For Clients Already Running Wave Who Want to Expand

The predictive and Einstein-adjacent capabilities are worth beginning to prototype if you have the data infrastructure to support it. We'd structure that as a discovery and data readiness engagement first, not a Wave build. The question you're trying to answer is: do we actually have the data, at the quality level, in a form that can feed a predictive layer? Most clients don't know the answer to that question.

Image recognition is further out for most client contexts. Unless there's an existing image capture workflow to attach to, this isn't something we'd put on a twelve-month roadmap in any concrete form.

For Clients in Service-Heavy Verticals

The service analytics template work is genuinely worth prioritizing. If your client has Service Cloud and isn't doing analytics on it, that gap is increasingly hard to justify. The template gives you a faster path to something credible, and service leadership tends to engage with the metrics in a way that builds the analytics culture you need for longer-term Wave adoption.


The Rebrand Question Nobody Officially Asked

There's been noise in the practitioner community for a while about where Wave sits in Salesforce's product narrative — whether it eventually consolidates with other Einstein capabilities under a different banner, whether the Wave name has a future. We're not going to speculate beyond what we saw and heard, which is that Wave Analytics is still the product name and the team is clearly investing in it.

What we will say is that the increasing integration between Wave and Einstein capabilities — Vision, prediction services, the overall Einstein framing that's been building for the past year — suggests that the product identity is evolving even if the name hasn't changed. The clients who will be best positioned for wherever this lands are the ones who are investing in Wave as a data platform, not just as a dashboard tool. Build your data architecture like it matters, because it's going to matter for whatever this product looks like in two or three years.


Closing Take

TrailheaDX 2017 gave us a clear signal about where Wave is heading: toward tighter integration with predictive and AI capabilities, with service analytics and industry-specific templates as the near-term practical delivery. The gap between the vision and what you can build on today is real, and any roadmap that doesn't account for that gap is going to create credibility problems.

Our practice is coming out of this with three priorities for the back half of the year: pushing service analytics template adoption with clients who have the Service Cloud data to support it, beginning data readiness conversations for clients interested in the predictive maintenance direction, and continuing to do the less exciting but genuinely important work of cleaning up dataflow architectures in existing Wave implementations that were built fast and haven't aged well.

The announcements were encouraging. The work is still the work.