top of page

Dreamforce 2026 AIforce recap: one foundation, more ways to work

10 minutes ago
5 min read

An operations team in Slack, a seller in Claude, and a manager in Salesforce should not need three different versions of what happened.


The Dreamforce 2026 AIforce keynote explored that problem through a fictional music-festival business. A sponsorship issue, a ticketing problem, and an event-readiness review moved through different interfaces while relying on connected business context. The session then went underneath the experience to show the tools builders and administrators would use. Watch the official AIforce keynote


Our takeaway is that interface choice becomes useful when the work stays connected. Moving a task into a favorite tool should preserve the meaning of the data, the intended action, and the result other teams need to see.


Several workspaces sit on one connected foundation, illustrating shared business capabilities across different interfaces.

The festival demo made the handoffs visible


The session’s fictional company, Stellar Media, was preparing for Stellar Fest. The sales example surfaced a problem with a sponsorship package, proposed an adjustment, and created a view of sponsorship readiness. The operations sequence then moved through Slack, Copilot, and Agentforce Coworker as teams addressed access and event-readiness issues. Official demonstration


It was a demonstration, not a customer implementation case. Its value was making a common problem visible: different people need different views of the same situation, and their decisions depend on one another.


In an ordinary business, the same pattern might involve an account team changing a commitment while delivery prepares to fulfill it. The important question is whether the updated commitment reaches the next team in time, with enough context to act.


We would evaluate that full path. A seller getting a useful answer is only one part of the experience. The receiving team also needs to see what changed, why it changed, and what now needs to happen. That is where revenue systems architecture connects an attractive interface to dependable operations.


The toolkit brings the business behind the screen into reach


The technical chapter described a headless toolkit spanning APIs and MCP connections, skills and plugins, reusable interface elements, identity, and observability. The builder demonstration used Salesforce’s development plugin in Claude to inspect an organization and create an event experience, including data-model changes and a React-based application. Builder chapter


The practical idea is reuse. A new experience should be able to call on the business capabilities a team already maintains rather than recreate their meaning in a separate application.


That still requires understanding what those capabilities do. An existing workflow may encode an essential rule, or it may carry a workaround nobody has questioned for years. Making it easier to invoke does not decide which of those it is.


Before extending a process into another interface, we would trace the action back to its current implementation. That provides a clear answer to a simple question: when someone asks for this change, what actually happens?


The keynote also showed reusable interface cards through the Headless Experience Layer. For users, consistency can make the result easier to recognize across tools. For builders, the useful evaluation is whether the same component behaves appropriately in the places where people actually need it.


Builder Central broadened who could participate


Salesforce demonstrated Builder Central as a conversational environment for building and administering Salesforce experiences. The example used written requirements, inspected the resulting data and agent structure, and requested a branding update. Builder Central demonstration


This could change the first conversation between a business owner and a delivery team. A product manager may be able to express an intended experience and inspect a working result earlier. That can expose misunderstandings before they become expensive.


The useful role for experienced builders remains clear: evaluate the result, understand its dependencies, and make sure it can be maintained. Written requirements are a starting point. They rarely contain every exception, relationship, or operational assumption a live application must handle.


We would use a trial to compare the stated requirement with the generated behavior. The question is not simply whether something appeared on screen, but whether the people responsible for the process agree that it does the right work.


Builder Central was shown in the keynote. The reviewed session did not establish a specific general-availability date for every demonstrated component, so we would confirm access and release status separately before promising an implementation around it.


Agent identity made access more specific


The identity demonstration distinguished a user’s permissions from the narrower actions an agent could perform. It then showed tracing that followed a request through an MCP interaction, an API call, and a flow. Identity and observability demonstration


That is useful for a very ordinary operational reason: a person may be allowed to do several things while wanting an assistant to do only one of them.


For example, someone reviewing an opportunity may want an explanation without requesting a change. Another workflow may need to update a next step. Treating those as separate intentions makes the experience easier to reason about.


Traceability matters when the result is unexpected. A support team needs to determine whether the issue came from the request, the selected action, the source information, or a downstream process. Without that chain, troubleshooting can become a debate between tools that each appear to have done their own part.


The keynote’s examples show the intended direction. Teams should verify the actual controls available in their environment and exercise them with representative tasks.


Where the Enterprise AI Harness fits


The broader Enterprise AI Harness was announced September 10, before Dreamforce. Salesforce describes six capabilities—context, agency, action, governance, security, and models—plus an AI Control Plane, intended to work across Salesforce and third-party technology. Official harness announcement


For roadmap discussions, we find it helpful to separate the user experience from the capabilities supporting it. AIforce’s session showed how work can appear in different places. The harness announcement describes the broader foundation needed to connect enterprise context, actions, and controls.


Availability is especially important here. Salesforce says many underlying technologies are available already, while new capabilities and the unified experience are planned to begin rolling out in early fiscal FY28. Pricing, packaging, and upgrade details are to follow. This is a staged roadmap, not a single package we should call fully available today. Harness availability


That allows two sensible conversations: what a team can evaluate with current capabilities, and what future architecture it wants to prepare for. Keeping those conversations distinct makes the roadmap more useful.


Deloitte’s early experience kept the focus on the people


Deloitte’s Harry Datwani described testing Salesforce in Claude across different personas and building on the organization’s existing Salesforce foundation. He characterized the experience as early, with positive signals around helping people work with less friction. Deloitte customer discussion


We would borrow that evaluation approach. The same experience may help one role and add little for another. Test it with the people who own the actual work, including the person who receives the handoff.


Choose a process that crosses two teams. Follow it from the original question through the resulting action and confirm that both teams understand the same outcome. That is a better test of connected work than counting the number of interfaces in the demonstration.


More ways to access Salesforce should make the business easier to operate. The foundation earns its value when people can change where they work without losing track of what they are trying to accomplish.


About CRM Hacker


We help teams connect Salesforce, revenue operations, and AI around practical business outcomes. Our Salesforce consulting and AI for business work turns architectural possibilities into usable workflows.


If the Dreamforce platform announcements have complicated your roadmap, Contact CRM Hacker. Let’s untangle this. The initial conversation is free; audits and implementation are scoped and paid.

 
 
 

Comments


Thanks for subscribing!

Get in Touch

  • Facebook
  • LinkedIn
  • Instagram
  • Youtube

100 SE 3rd Ave 10th floor

Fort Lauderdale, FL 33394

CONTACT US

Thanks for submitting!

Companies that put their trust in us

securiti.ai
Recast Software
Linux Academy
Digital Resource
CFI
sloane staffing logo
Scribble Live
Placer.ai
NoiseAware
Zone7 logo
spot pet insurance
Tucows
Documo
A Cloud Guru
Axe Trailers
CRM Hacker | Automox

6 — WHO IT’S FOR

© 2026 Carlson Solutions LLC dba CRM Hacker

bottom of page