Salesforce previews its service agenda ahead of Dreamforce 2026

What Salesforce is previewing

Salesforce published a five-minute service guide on September 8 for Dreamforce, scheduled for September 15–17, 2026. The post highlights Agentforce Service, employee service, field service and related sessions or announcements. It is an event-planning article rather than a complete product release note or entitlement matrix.

DailyRevOps therefore treats the post as a preview of themes the vendor plans to discuss. It does not establish that every demonstrated or announced capability is generally available, included in a customer's current edition, supported in every region or ready for the customer's data and security requirements. Those details must come from current documentation and the actual contract.

Turn the event agenda into a claim register

Before the event, create a short register for each capability the team may evaluate. Capture the exact source wording, source date, demonstrated workflow, release status, prerequisites, edition or add-on, region, supported channels and named person who will verify the answer. Keep unknowns visible rather than turning them into backlog assumptions.

Separate capability from outcome. A system may summarize a case, propose a reply, schedule work or complete a configured action. None of those functions by itself proves lower service cost, faster resolution, higher retention or better customer experience. Define the local measure and comparison before using an event claim in a business case.

Bring one real service workflow

Choose one recurring customer request and map it from identity and entitlement through evidence, interpretation, policy, action, notification and verification. Name the CRM, service, product, billing and communication records involved. Identify which state is authoritative at each step and which action changes the customer's commitment or access.

Prepare a normal case and exceptions: ambiguous customer identity, several accounts, insufficient entitlement, conflicting records, unsafe request, missing data, unavailable service, duplicate submission, timeout after a possible write and a changed record before retry. A polished demo is less useful than evidence showing how these cases are contained.

Inspect the human handoff

A service agent should not transfer only a conversation. The receiving person needs customer and record identity, the request, evidence inspected, action already taken, action not taken, reason for handoff, urgency and remaining work. Test whether the person can continue without asking the customer to repeat the story.

Define the queue, owner and response clock for each material exception. A handoff is not complete because a case was reassigned. Confirm that the new owner accepted it and that the customer-facing next action is visible. Preserve the source conversation and prior states with appropriate access controls.

Verify authority and recovery

Ask which identity the agent uses, which records and tools it can access and which actions require deterministic policy or human approval. Keep pricing, refunds, entitlements, case closure, customer status and outbound communication behind the authority appropriate to their consequence. Generated confidence is not authorization.

Run a pause-and-recovery exercise. Revoke the credential, preserve pending work, identify records changed since the last verified run and reconcile the final customer state. Confirm how duplicated events and timeouts are handled. A rollback document is insufficient if the team has never executed the path.

What to take into Dreamforce

Bring the claim register, one workflow map, representative test cases, permission inventory and current baseline. Ask the product team to show the exception and audit evidence, not only the happy path. Ask how model, instruction, tool and release changes are versioned, and how operators find affected records after a problem.

After the event, promote only documented, relevant capabilities into evaluation. Record which claims were confirmed, changed or remain unknown. The useful outcome is not a longer list of possible agents. It is a smaller number of service workflows that the team can test, govern and hand over responsibly.

Keep rejected ideas in the register with a reason. A capability may be technically interesting yet irrelevant to the current service obligation, data model or operating capacity. An explicit no-test decision prevents the same preview from reappearing as an unowned request after the event.

For selected evaluations, name the operator who will own configuration after the event and the manager who accepts service risk. Budget for evidence preparation, review, exception work and customer recovery as well as licenses. A demo can establish possibility; only the complete local workflow can establish readiness.