Dreamforce 2026: What Gets Easier — and What Gets Sharper — When It's Legos, Not Puzzle Pieces

I'm just back from Dreamforce, and I want to get my thoughts down before the week's insights fade into the usual post-conference blur of phone snapshots and sore feet. There was a lot announced this year — pricing changes, a renamed edition lineup, a new Well-Architected Framework — but the thread I can't stop pulling on is one I've been writing about for months.  For me, Dreamforce 2026 was watching Salesforce walk straight into it, in public, at scale.

The team ready for the main keynote

AIforce Is the Architecture Choice, Made Out Loud

Salesforce's headline announcement this year was AIforce, a live interface layer that brings Salesforce data, business logic, workflows, permissions, and AI into whatever tool you already have open — Claude, Slack, Lightning, wherever. The pitch is simple: instead of asking people to come to Salesforce, Salesforce comes to them.

That's the marketing framing (yes, the name is a bit cringe)... But if you've read Why Salesforce Needed Contentful or Every Architecture Has a Tax, you already know what I believe is the more interesting story underneath it: this is a monolith-versus-composable decision, made deliberately and at enormous scale, and Salesforce just showed its work.

Composability, Arriving on Schedule

Quick recap for anyone new here — a monolith is a system where content, logic, and interface are all woven together, hard to pull apart, easy to run. A door on a monolith is an API bolted onto that fused stack — it gives you reach, but hands back rendered blobs an agent still has to parse meaning out of. Composable means the pieces actually come apart: individually addressable, structured, recombinable in ways nobody pre-built. And the tax is due either way — you pay it upstream, in the discipline of structuring things properly, or you pay it downstream, later, usually under duress.

AIforce and the Headless Toolkit have their limits – they aren’t magic.  They don’t pay the upstream tax. They're the payoff for whoever already did. Builder Central's ability to recognize there's already, say, a Birthdate field on the Contact instead of creating a Birthday field to duplicate it, only works because a data model existed that was clear enough to recognize in the first place. That's not something AIforce gives you — that's something it requires. Show it a semantic layer that's actually been structured, documented, sorted, and it looks like magic in a keynote demo. Show it the average org's tangle of duplicate fields and undocumented logic, and the same tool just as quickly reveals the mess that was always there.

The Payoff: Ephemeral, Disposable Interfaces

Here's where the abstract argument gets a face. For twenty years, we've all built Salesforce interfaces to last — a dashboard was a permanent artifact, carefully composed for a whole department, then groomed and protected for years. That's the film-camera model of building software: you had 24 exposures on the roll, so you composed carefully and printed what mattered. If it was particularly successful, you framed it and hung it on the wall.

What we saw at Dreamforce is what happens once the pieces are actually composable enough that assembly collapses toward automatic. Builder Central let someone describe a use case — "we need to issue people new equipment" — and it built the object, reused the existing Contacts relationship, drafted a Flow, and spun up a disposable React-based portal to collect the information. Once the equipment issue is done, you shut it down. That's the smartphone-camera model: fifty photos of the same moment, most forgotten within a week, because the cost of taking one dropped to nearly zero.

BUT.

This is only possible because the pieces underneath are addressable. A monolith with a door can't do this — reach isn't the same as the right unit of work, and you can't spin up a disposable interface out of a poorly structured, undocumented database with rendered pages in a different app (cough, Confluence, cough) that you have to re-parse every time. Composability is what makes ephemeral, personal UI cheap enough to be disposable in the first place.

The cost is real, though, and it's the one part of the pitch nobody at Dreamforce addressed: our tooling for managing all these disposable pieces hasn't caught up. We know how to govern a permanent dashboard. We don't yet have a good answer for a hundred people each spinning up their own Quick Pages a week.

The Twin Thread: Where's the Data Actually Going?

Zero Data Retention (ZDR) got repeated like a magic word throughout Dreamforce. Benioff said it in the keynote. The AIforce press materials lead with it. And I understand why it lands — but if you've read The Vendor You Can't Leave & Data Sovereignty, you know "do we control our data?" isn't one question. It's three: location, mastery, and use rights. And ZDR, as a phrase, only really answers one of them.

Location is solved, loudly. Business data isn't retained by the model provider — fine, that's a location and retention claim, and it's the easiest one to make and verify.

Mastery is the quieter question, and composability actually sharpens it rather than resolving it. When an agent assembles a Quick Page on the fly, pulling structured fields from across Contacts, a new object, maybe Data 360 — what’s the system of record for the thing that got assembled? The underlying objects still have owners. The assembled page, existing for an afternoon and then gone, doesn't quite. That's not a criticism, exactly — it's a genuinely new category of artifact, and I don't think anyone's fully worked out where mastery lives for something disposable by design.

Use rights is the one I'd actually push on. Composability, by definition, makes data more granular and more usable — that's the entire point, that's why agents prefer it. But "more usable" cuts both ways. The same structuring discipline that lets your own agent assemble a trustworthy answer is the discipline that makes data more legible to any system that can reach it. "Not retained by the model provider" is a real and meaningful promise, but it's a narrower one than "not used," and it's worth reading exactly where that line sits before assuming it covers everything composability newly exposes.

None of this is really a question of whether to trust AIforce. Salesforce is being unusually clear about the promise it's making — ZDR is a real commitment, and it's the easiest of the three axes to verify. The harder truth is what it exposes about your own house before AIforce ever shows up. If your organization has spent years keeping its real knowledge in beautifully rendered pages an agent can't parse, or scattered across a project tool that was never built to be queried, then no vendor commitment fixes that for you. AIforce doesn't trap you the way a monolith can. But it can't hand you back the sovereignty you never established in the first place. The same discipline that determines whether a Quick Page looks like magic or a mess is the discipline that determines whether you're actually able to take advantage of what's on offer here — or whether you find out, mid-renewal, that you never had mastery over your own data to begin with.

Security Is a Human Problem Wearing a Technology Costume

Salesforce also announced new security tooling (Salesforce Guardian) for managing risk across a growing web of integrated AI tools — genuinely useful, and it only works if you've already done the unglamorous work of classifying your data by sensitivity. Most organizations haven't. There's no better time to start than today.

I'll say something a little stronger, though, because it's the same mechanism underneath both the security point and the composability one: people — and agents — fail when they have to re-parse under uncertainty. That's not a new idea to me; it's the load-bearing finding from years of human-factors work I did long before Salesforce. Consistency isn't an aesthetic preference. It's a risk control. Feed an agent an inconsistent, half-structured mess and it re-parses under uncertainty exactly the way an under-trained operator does with a bad checklist — and the errors compound the same way. Security tooling can flag a gap. It can't decide, on your behalf, what "consistent enough" or "acceptable risk" looks like. That's still a human call, every time.

Nonprofit Keynote: Beautiful Pages and a Few New Promises

The nonprofit keynote is always one of my favorites, even as I think Salesforce has sanded the edges off most of its other demos in a way that's made them less compelling than they used to be. Blue Star Families showed off some genuinely beautiful pages from their org — possibly the new Quick Pages, possibly OmniStudio, I honestly couldn't tell you which — worth including here as a visual reminder of what's actually possible right now.

Blue Star Families’ Fundraising Home Page

On the roadmap: Events Management is officially teased, joining Grant Making and the Participant Management agent (which supports voice notes!!). Events Management in particular has been a real gap for a while, so this is welcome.

Public Sector: Composable, Defensible Decisions

Public Sector — under the "MissionForce" banner, though I'm still not entirely clear how distinct that is from Public Sector as a category — showed off a Policy Engine that's the cleanest example all week of composability paying off in exactly the terms I've been describing. It takes raw policy documents and turns them into the configuration needed to adjudicate cases like benefits applications, and it returns not just a decision but the reasoning behind it, grounded in a deterministic rules engine rather than a probabilistic guess. Salesforce's own framing: it moves beyond the probabilistic uncertainty of standard AI by grounding every citizen-facing interaction in a deterministic rules-based engine.

A "defensible decision" is just another name for a structured, addressable field instead of a blob you have to take on faith — this is composability's fields-not-blobs argument, applied somewhere the stakes are high enough that everyone can immediately feel why it matters. I'd love to see a version of this land in Nonprofit Cloud; grant eligibility determinations need exactly the same defensible trail benefits adjudication does.

And holy smokes, but is it fast! We’ve had rules-based outcome engines like this for a while now, but to go from a policy document to this architecture is what Agentforce brings to the table.

Twenty Years of Trailblazers

This year marked the Trailblazer Community's 20th anniversary, and the footprint at Dreamforce reflected it — bigger meetup spaces, a more prominent Trailblazer Theater. Salesforce is also moving the community from traditional forums toward Slack, which I'm glad about: one less screen for me personally, and it meets people where they already are. It’s the same instinct behind AIforce and Slackforce, applied to the Community instead of CRM data. The honest challenge ahead is cultural, not technical — encouraging people to use public channels and threads instead of defaulting to DMs, so the openness that made the old forums valuable doesn't quietly get lost in the move. The move to a regional approach will be a challenge for the smaller and more isolated groups as well. Time will tell how this works out.

Closing Thoughts

Everything above is really one argument wearing different outfits. The technology to build fast, disposable, personalized interfaces has clearly arrived — but it isn't Salesforce that paid for it. It arrived as a payoff, cashed in by whoever already did the upstream work: the data model, the structuring discipline, the sovereignty questions asked and answered before anyone was promising a Quick Page in minutes. The same move that makes data addressable enough to assemble one that fast is the move that makes the sovereignty questions sharper, not softer — who holds mastery over something assembled and gone in an afternoon, and exactly what "not retained" does and doesn't cover once every piece of your data is this legible to anything that can reach it.

And here's the part I don't think most people walked out of Dreamforce understanding: the velocity everyone's excited about only works if the pieces were already sorted. Legos snap together fast — but only because someone dumped the bin out first and sorted by color, by size, by piece, long before anyone started building. Skip that, and you don't get to build fast later. You get to dig through a junk drawer while everyone else is already assembling.

That's the sorting nobody demos. It's not on a keynote slide, it's not in a press release, and it's the actual determinant of whether any of this reaches your desk at the speed Salesforce is promising. The organizations who'll move at AIforce's pace aren't the ones who bought the fastest tools. They're the ones who already did the boring work — the data model, the structuring discipline, the sovereignty questions asked and answered on purpose — before the moment arrived that made speed matter.

None of that is a reason to slow down. It's a reason to make the choice on purpose — architecture and sovereignty both, sorted bin included — instead of getting carried there by a very good demo.