Problem
Event agendas and product previews create a fast-moving backlog before teams have separated demonstrated capability, actual availability and their own service operating requirements.
Why it matters
A release evidence pack gives Support, Service, RevOps, IT and Security one inspectable basis for deciding what to test, which customer actions remain human-owned and what evidence is required before broader use.
Separate the preview from the release
Salesforce's 8 September Dreamforce service guide describes event themes around Agentforce Service, employee service and field service. Treat it as an agenda and preview. It does not by itself establish that a named capability is generally available, included in the current contract or approved for the team's data and region.
Create a claim register with the source, date, exact wording, observed demo, documentation link, release status, prerequisites, edition, add-on, region and named verifier. Mark unknown information as unknown. Ask the vendor to resolve the gaps in writing before the capability enters a production plan.
Define the customer request and accepted outcome
Choose one request type, such as scheduling, case summarization or suggested resolution. Describe the customer's starting state, the authoritative records, the accepted action and the evidence that proves completion. A generated response is not completion when a booking, entitlement, case state or customer notification must also change.
Write the entry contract: customer identity, account or entitlement, channel, consent where relevant, request type, language, service priority and the records the workflow may inspect. State what blocks automation and what routes to a person.
Draw normal, exception and human-handoff paths
For the normal path, map retrieval, interpretation, policy, proposed action, execution and verification. For exceptions, include missing identity, conflicting records, insufficient entitlement, unsafe request, unavailable slot, system timeout, duplicate event and customer disagreement. Do not use one generic fallback for every condition.
Define the human handoff packet: customer and record identity, request, evidence used, action already taken, action not taken, reason for handoff, urgency and responsible queue. Test whether the receiving person can continue without asking the customer to repeat the full story.
Bound credentials and decision rights
List every system, object, property and operation available to the workflow. Start read-only or proposal-only where the action changes a commercial promise, entitlement, appointment, case resolution, refund, forecast or customer message. Separate model interpretation from deterministic policy and execution.
Assign one accountable owner for the workflow configuration, one for the business policy, one for permissions and one for the exception queue. Preserve the actor, prior state, reason and result for material writes. Use a dedicated identity where the platform supports it rather than an employee's personal token.
Build representative tests
Use authorized non-production or isolated records that cannot trigger live customer communication or billing. Test ordinary requests, ambiguous language, several associated accounts, missing data, conflicting instructions, stale data, changed state, duplicate submission, timeout after a possible write and a prohibited action.
Write the expected result before running each case. Record source versions, configuration, model, prompt or instruction set, retrieved evidence, tool calls, outcome and reviewer decision. Include abstention and handoff as expected successes where the policy requires them.
Verify the first complete cycle
After a bounded production release, inspect the final system state and next downstream cycle. Confirm the customer received the correct communication, the CRM and service records agree where they should, the owner queue contains unresolved work and no duplicate action occurred. A successful API response is only one observation.
Review accepted actions as well as failures. Required fields can be present and still be wrong. Sample the source evidence, association and downstream result. Pause expansion when a consequential failure lacks a clear repair path.
Decide, document and hand over
The release decision should name the eligible population, authority, exclusions, material blockers, monitoring owner and next review. Link the claim register, test evidence, permission inventory, exception queue and rollback exercise. State what the pilot did not establish.
Handover is complete when another operator can find pending work, pause execution, revoke access, explain the latest accepted configuration and reconcile an affected customer record. Keep the evidence pack beside the workflow, not in an event-notes folder that disappears after launch week.
Step-by-step workflow
- Capture claims and availability separately.
- Define one request and authoritative outcome.
- Map normal, exception and handoff paths.
- Restrict evidence, credentials and actions.
- Run representative and changed-state tests.
- Verify the first full customer cycle.
- Record the release decision and handover.
CRM fields and signals needed
- Verified request-to-outcome completion
- Correct identity and associations
- Expected abstentions and human handoffs
- Duplicate and prohibited actions blocked
- Exceptions with owner and age
- Post-action CRM and service reconciliation
Operating quality check
Use this check before adding more tooling. The goal is to prove that the workflow is owned, current, and inspectable inside the system of action.
| Area | Healthy pattern | Risk pattern |
|---|---|---|
| Availability | Documented release status, entitlement and prerequisites are confirmed. | An event preview is treated as contracted capability. |
| Evidence | Every material action traces to permitted source records. | A fluent answer survives without its evidence. |
| Authority | Objects, fields, actions and cohorts are explicitly bounded. | The workflow inherits broad user permissions. |
| Handoff | A person receives context, reason, urgency and remaining work. | Fallback means a generic queue or repeated customer explanation. |
| Verification | The final record and customer outcome are checked. | A successful model or API call is counted as completion. |
Common mistakes
- Treating a conference preview as an availability matrix
- Testing only a polished normal path
- Letting one identity read or write every connected system
- Counting generated text as customer resolution
- Closing the pilot before downstream verification
- Keeping rollback as an untested document
Weekly service-agent release review
- Identify the customer, account and service record.
- Preserve the request and source evidence.
- State actions completed and not completed.
- Name the handoff reason and urgency.
- Assign an owner and review time.
- Confirm the final customer-facing outcome.
Example operating rhythm
- Daily during pilot: inspect material actions, handoffs and aged exceptions.
- Weekly: sample accepted outcomes and reconcile source evidence with the final record.
- After any model, permission, policy or integration change: repeat affected cases before expansion.
Tooling options
- Use CRM and service-platform audit history for record evidence, but verify retention and export needs.
- Use a controlled test register that retains expected outcomes, versions and reviewers.
- Use a named exception queue in the system where the receiving operator works.
Source notes
These sources support the workflow model and product concepts. They do not prove a specific business outcome, benchmark result, or vendor claim.
- Salesforce: Service at Dreamforce preview: Salesforce's 8 September 2026 event guide for Dreamforce 2026. It describes agenda themes and previews; teams must verify release status, entitlement and product documentation separately.
- Salesforce: Pioneering engineering's agentic shift, part 2: Salesforce's 9 September 2026 account of an internal 30-day pilot and its proposed maturity curve. It is a first-party operating account, not an independent productivity study.
Last updated: 2026-09-10
Decision frameworks to read next
FAQ
Does a live conference demo prove production availability?
No. Verify release status, edition or add-on, region, prerequisites, documentation and contractual terms for the actual environment.
Should every exception go to a human?
A human path is appropriate when evidence, authority or safety requires judgment. Deterministic recoverable errors can use bounded retry rules, but unresolved customer work still needs an owner.