Salesforce Service

Salesforce Service Cloud Playbook

Practical, DX-first playbook for standing up Service Cloud — case handling, intake channels, agent productivity, Knowledge, Omni-Channel routing, digital/voice channels, SLAs/entitlements, AI service (Agentforce + Einstein for Service), and the order-service action layer. Drawn from a real commerce-service build; objects map to any domain (a Case ↔ a ticket/claim; an Order ↔ any transaction).

Deep per-domain detail (exact metadata XML shapes, field lists, Apex APIs, doc URLs) lives in reference/ — load the relevant file when you actually build that piece:

• [reference/case-management.md](reference/case-management.md) — Case lifecycle, record types/BusinessProcess, rules, queues, case teams, Email-to-Case/Web-to-Case, Service Console, Macros/Quick Text/Case Feed, reporting.
• [reference/knowledge.md](reference/knowledge.md) — Lightning Knowledge enablement, data model, data categories, publishing lifecycle, SOQL/SOSL, agent grounding, permissions.
• [reference/omni-channel-routing.md](reference/omni-channel-routing.md) — routing models, ServiceChannel/RoutingConfiguration/presence metadata, skills routing, PendingServiceRouting (Apex), Omni-Channel Flow + Route Work.
• [reference/messaging-and-voice.md](reference/messaging-and-voice.md) — MIAW/Enhanced Messaging, EmbeddedServiceConfig, conversation objects, pre-chat, JWT user verification, WhatsApp/SMS, Service Cloud Voice / Open CTI.
• [reference/entitlements-slas-incidents.md](reference/entitlements-slas-incidents.md) — Entitlements/EntitlementProcess/Milestones, Service Contracts/Assets/Warranty, Incident Management, Service Catalog, Surveys/CSAT, SLA reporting.
• [reference/agentforce-einstein-service.md](reference/agentforce-einstein-service.md) — Agentforce Service Agent, Einstein predictive + generative features, grounding/prompt templates, Einstein Bots vs Agentforce, enablement/licensing.

#0 rule: Official-first, standard objects, no Frankenstein

Use standard Service objects — Case, Queue, EntitlementProcess, ReturnOrder, OrderSummary, Lightning Knowledge, MessagingSession, ServiceChannel — and declarative routing (assignment/escalation rules, Omni-Channel Flow) before any custom object/Apex. Hand-roll only thin Apex glue invoked by Flow/agent when no native path exists, and say why.

#1 rule: DX/CLI/API first, UI last

sf project deploy/retrieve, sf data, sf apex run, sf api request rest, sf agent. Many Service features are enablement-gated (Lightning Knowledge, Order Management/OrderSummary, Omni-Channel, Entitlements, Messaging, Einstein/Agentforce). When a metadata deploy silently no-ops, that feature likely needs a Setup toggle first. Drive Setup-UI-only steps headlessly via sf org open --path "" --url-only (frontdoor auto-auths with the CLI token; no password). sf org display redacts the token → prefer sf api request rest / Apex session over raw curl.

#2 rule: know the metadata / data / UI-only line (the biggest time-sink)

Half of "why won't this deploy" is filing something in the wrong bucket. The load-bearing classifications:

| Thing | Bucket | How you ship it | |---|---|---| | Support process | Metadata — BusinessProcess (there is no SupportProcess type) | deploy | | Case status/origin/priority values | Metadata — StandardValueSet (org-global) | deploy | | Record types, layouts, compact layouts, list views, FlexiPages, console app | Metadata | deploy | | Assignment / Escalation / Auto-Response rules | Metadata — one file per object, only one rule active | deploy (never partial — overwrites all) | | Queues | Metadata Queue — but deploy queueMembers empty | deploy + seed members as data | | Knowledge enablement, Omni, Entitlements, Messaging, Einstein/Agentforce toggles | Metadata Settings (KnowledgeSettings, OmniChannelSettings, EinsteinGptSettings, AgentPlatformSettings…) — but first activation often UI-gated | deploy (confirm in Setup) | | Macros, Quick Text, Case Team Roles + predefined Case Teams, Enhanced Letterhead, Case Comments | DATA (sObjects) — invisible to package.xml/change sets | sf data tree / Bulk | | BusinessHours, Holiday, Entitlement, CaseMilestone, ServiceContract, Asset | DATA / objects | sf data / Apex | | Agentforce grounding substrate (Data Library, search index, retriever) | NOT deployable — recreate per org | sf agent adl / UI | | ML models (Case Classification, Article Recs) | NOT deployable — retrain per org | UI build | | Email-to-Case routing-address verification, the generated email-services address, MIAW deployment publish + install snippet, Data Cloud provisioning, Trust Layer policy | UI / runtime-only | Setup |

#3 rule: AI-action hygiene (anti-hallucination, gating, traceability)

Service actions (the agent's "fix tools": open/resolve case, return, refund, store credit, cancel) must be:

• Identity-gated — verify the caller's identity (signed-in JWT / OTP) before reading PII or acting. A typed/hidden-prechat email is spoofable; the verified signal is MessagingEndUser.AuthenticatedEndUserId.
• Anti-hallucination — default success=false; flip to true only after the backend write succeeds, and re-query the created record (e.g. CaseNumber) before reporting it. Gate confirmation language on an explicit action-output field, never on intent. (Failure mode: "tests green, prod broke" — agent claims success while the backend gate held 0 records.)
• Idempotent — dedupe before creating (e.g. check for an existing coupon/case) so retries don't double-act.
• Callout-before-DML, fail loud — when an external callout (e.g. WooCommerce) fails, open a failure Case for human follow-up rather than silently succeeding.
• Traceable — log who/when/why/what-changed on every action (cross-agent journey log) and write back to the Case/Order.
• Capped & confirmed — bound AI-issued value (e.g. store credit ≤ $50) and require explicit shopper confirmation for goodwill.

---

1. Case management + lifecycle → [reference/case-management.md](reference/case-management.md)

• Case is the core record. Configure: record types (e.g. Order Issue, Return, Billing, General), each tied to a BusinessProcess (the metadata type behind "Support Process") that scopes the Status values; Origin (Web, Chat, Email), Priority. Closed semantics come from the true flag on the CaseStatus StandardValueSet value, not the literal text.
• Queues (Queue metadata = Group Type=Queue + QueueSObject) for team routing — a queue must list Case in queueSobject before a case can be owned by it. Assignment rules (AssignmentRules) auto-route; escalation rules (EscalationRules, tied to BusinessHours) for SLA breaches; auto-response rules (AutoResponseRules, senderEmail must be a verified OWEA). All three: one file per object, only one active rule, deploy overwrites the whole file.
• Validation rules to enforce required fields per status (e.g. Resolution required to Close) — but gate them by Origin/RecordType so agent/chat inserts don't break (a known failure mode).
• Persist context on the Case: Case.Description (32k long-text) + child Task ("Chat transcript") records, since native ConversationEntry is off-platform.
• Productivity (mostly data, not metadata): Macros, Quick Text (QuickText), Lightning email templates (EmailTemplate UiType=SFX), Case Feed layout + quick actions. Service Console = CustomApplication (uiType Lightning, navType Console) + a UtilityBar FlexiPage (metadata-only — can't be built in App Builder).
• Intake: On-Demand Email-to-Case (default modern choice) + Enhanced Email (EmailMessage sObjects); Web-to-Case for throwaway forms only — prefer an Apex @RestResource/Screen Flow for real forms. Gotcha: Email Deliverability = "No access" hides Case.SendEmail and fails any layout deploy referencing it.

2. Digital + voice channels (MIAW / Voice) → [reference/messaging-and-voice.md](reference/messaging-and-voice.md)

• Messaging for In-App and Web (MIAW) is the modern web/in-app chat channel: MessagingChannel (messagingChannelType=EmbeddedMessaging) + EmbeddedServiceConfig (+ BrandingSet; EmbeddedServiceBranding is legacy-chat only). Both are metadata-deployable; publishing the deployment + generating the install snippet is Setup-UI-only.
• Conversation objects: MessagingChannel → MessagingEndUser (identity lives here — write ContactId/AccountId/LeadId; the session's EndUser*Id are read-only mirrors) → MessagingSession → Conversation → ConversationEntry (off-platform — never SOQL; use the Conversation Data GET API or Data Cloud).
• JWT user verification: RS256/RS512, header kid, payload sub/iss/exp; call setIdentityToken inside the onEmbeddedMessagingReady listener (outside → user falls back to Guest); clearSession() on logout to prevent PII persistence. ⚠️ Do NOT "Switch to V2" if you need login verification — v2 removes user verification. Verified signal = MessagingEndUser.AuthenticatedEndUserId.
• Service Cloud Voice → "Salesforce Voice" (API names unchanged): Amazon Connect (managed), Partner Telephony (BYOT), or BYO-Amazon. CallCenter + ConversationVendorInfo are the wiring anchors; VoiceCall is the record; transcripts are ConversationEntry. Open CTI is maintenance-mode, EOL Feb 28 2028 — build net-new on Voice. Summer '26: Einstein Conversation Insights is now platform-native (Flow/Apex/Prompt-Builder accessible).

3. Web chat → live/AI agent routing (Omni-Channel) → [reference/omni-channel-routing.md](reference/omni-channel-routing.md)

• Web chat does NOT bind directly to an Agentforce/Einstein agent — it routes via an Omni-Channel Flow (Flow with processType=RoutingFlow) + a Route Work action. "Agents are not available" almost always = routing/presence config, not the agent.
• Enable Omni first (OmniChannelSettings; turn on enableOmniSkillsRouting from day one — retrofitting is painful). Build order: Settings → ServiceChannel (relatedEntity=MessagingSession) → RoutingConfiguration (metadata type; its backing object is QueueRoutingConfig) → Queue → ServicePresenceStatus → PresenceUserConfig → Flow.
• The Route Work action: Routing Type (queue/skills), Service Channel, target (Bot picker covers Agentforce agents — only active ones show), and always a Fallback Queue. Route Work must be the last element on its path.
• Pass identity into the agent: in the routing flow Update Records on the MessagingSession custom field from the channel/pre-chat param; the agent variable must be linked to that field (not mutable). Test in a new session.
• Skills/attribute routing or full programmatic control = insert PendingServiceRouting with IsReadyForRouting=false, attach SkillRequirements, then flip to true. AgentWork/UserServicePresence are the runtime assignment/presence objects.

4. Lightning Knowledge → [reference/knowledge.md](reference/knowledge.md)

• Enable Lightning Knowledge first (KnowledgeSettings: enableKnowledge + enableLightningKnowledge — both irreversible; first activation often UI-gated; defaultLanguage is a locale like en_US). Classic→Lightning needs the UI Migration Tool.
• Data model: Knowledge__ka (master, stable kA… id) vs Knowledge__kav (version — what you DML; ka… id). Article types = record types on the single Knowledge__kav. PublishStatus is read-only on DML — never update PublishStatus; transition via KbManagement.PublishingService (pass the KnowledgeArticleId master id, not the version id; methods aren't bulkified → Queueable/@future, watch MIXED_DML).
• Data Categories (DataCategoryGroup): deploy is destructive full-replace — always include the complete tree or categories are permanently deleted. Visibility is Profile-only (categoryGroupVisibilities; no PermissionSet equivalent); no visibility → WITH DATA CATEGORY silently returns 0 rows.
• Querying from Apex: bind variables fail to compile in static SOQL against Knowledge__kav/KnowledgeArticleVersion → use Database.query / dynamic SOSL (Search.find for snippets, Search.query when the type isn't compile-time bindable). Always filter PublishStatus + a single Language.
• AI grounding: the agent answers via the Answer Questions with Knowledge action over an Agentforce Data Library (Data Cloud index + retriever). The library/index/retriever are not metadata-deployable — recreate per org via sf agent adl; poll until index "Ready"; agent user needs Knowledge FLS Read + "Allow View Knowledge".
• Link articles to cases via CaseArticle (create+delete only, idempotent, uses the kA… master id).

5. Entitlements / SLAs / support operations → [reference/entitlements-slas-incidents.md](reference/entitlements-slas-incidents.md)

• SLA engine: enable Entitlement Management → MilestoneType → EntitlementProcess (version-suffixed dev-names; use versionMaster) → milestones with timeTriggers (negative offset = warning, positive = violation; success actions at the milestone level). Milestones only instantiate when a Case has an EntitlementId whose Entitlement points to the process via SlaProcessId — defining the process is not enough. BusinessHours/Holiday/Entitlement/CaseMilestone are data/objects, not source metadata. Modern actions = Flow, not legacy Workflow.
• Service Contracts & Assets (ServiceContract/ContractLineItem/Asset; warranty objects are Field-Service-gated) source entitlements contractually. Incident Management (Incident/Problem/CaseRelatedIssue) for many-cases-one-rootcause. Service Catalog, Surveys/CSAT (Feedback Management; send on case close via Flow "Send Surveys"), Service Intelligence (Data-Cloud-gated).
• SLA reporting: "Cases with Milestones" report type on CaseMilestone.IsViolated/TimeRemainingInMins; ReportType/Report/Dashboard are deployable.

6. AI service: Agentforce + Einstein for Service → [reference/agentforce-einstein-service.md](reference/agentforce-einstein-service.md)

• Agentforce Service Agent (customer-facing, runs as the EinsteinServiceAgent user, no logged-in human): runtime = Bot+BotVersion+GenAiPlannerBundle (v64+); design-time source of truth = AiAuthoringBundle (Agent Script .agent). Attaches to MIAW via Omni-Channel Flow → Route Work; email is a separate path (Email-to-Case + Case Assignment to EinsteinServiceAgent). Always include the standard Escalation topic + an availability-aware Omni flow or handoff dead-ends.
• Einstein predictive (no LLM/Data Cloud): Case Classification + Routing, Article Recommendations, Reply Recommendations, Conversation Mining, Next Best Action (Recommendation/RecommendationStrategy/Flow — fully deployable). Einstein generative (Trust Layer; Data Cloud only for RAG): Work/Case Summaries, Service Replies, Search Answers.
• Settings toggles ARE deployable (EinsteinGptSettings, AgentPlatformSettings, BotSettings, EinsteinAgentSettings). The agent user needs an explicit CRUD/FLS permission set or record creation silently fails. sf agent publish ≠ activate — sf agent activate --api-name X --version N then verify the active version. See the salesforce-agentforce skill for authoring mechanics.

7. Order-related service (returns / refunds / cancellations)

• OrderSummary (Order Management — enablement-gated) is the serviceable view of an order; ReturnOrder + ReturnOrderLineItem for RMAs.
• Refunds/cancellations/store-credit/exchange/reship as Apex service methods (one @InvocableMethod per class) invoked by Flow or an Agentforce action —

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: alexkwitko
• Source: alexkwitko/Salesforce-Agentforce
• License: MIT

Install and usage instructions live in the source repository linked above.