A Service Cloud launch has a few setup gaps that are easy to miss, such as a sending domain that never got verified or a data load whose first run happens on cutover weekend. This Salesforce Service Cloud implementation guide walks the build in the order that holds up, so you know what to configure before launch and what proves it works.
We’re HyphenX Solutions, a Salesforce consulting partner, and we deliver Salesforce Service Cloud services. Salesforce Help articles now write the product as Agentforce Service (formerly Service Cloud), while the product page still says Service Cloud. We use Service Cloud here because the product page still uses that name.
Quick answer: Before Service Cloud go-live, configure case record types, queues and rules; verified email and chat channels; Omni-Channel routing; entitlements and milestones; Lightning Knowledge; Flow automation; and permission sets with MFA. Then rehearse the data load and pass UAT.
What Does a Service Cloud Implementation Cover?
A Service Cloud implementation turns a license into a working support desk. This Salesforce Service Cloud implementation guide splits that work into five layers, because each one fails in its own way at launch.
- Case management. Record types, support processes, queues, and the assignment, auto-response and escalation rules. Every request lands here.
- Channels. Email-to-Case, Enhanced Chat, messaging apps and voice, each feeding the case record that reps work from.
- Routing and SLAs. Omni-Channel, entitlements, milestones and business hours. These decide who gets the work and how fast.
- Knowledge and self-service. Lightning Knowledge articles that reps use in the console and, if you choose, customers read in a portal.
- Platform controls. Flow automation, permission sets, MFA, sandboxes, deployment and data migration. These keep the desk secure and releasable.
Skipping a layer shows up fast as unrouted cases, missed SLAs or answers reps can’t find. The next sections take the layers one at a time, then move to launch, the checklist and what it all costs.
Name an owner for each layer before work starts, so the team knows who signs off at UAT.
Five Changes Since December 2025 That Break Older Service Cloud Plans
Check any plan, statement of work or older tutorial against these five changes before you build from it.
- Older automation needs a rebuild. Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025. Existing rules keep running, and new automation belongs in Flow.
- Legacy chat is gone. Live Agent and legacy Chat reached end of support on February 14, 2026. Enhanced Chat replaces them, so any plan that still names Live Agent needs a new channel design.
- The Email-to-Case agent is unsupported. Salesforce’s article dated May 4, 2026 says the agent is no longer supported or available for new installations. On-Demand Email-to-Case is the supported method.
- Sending domains need verification. Salesforce enforced the rule in two phases, with verification required for allowlisted domains from June 29, 2026 in a rollout that ended July 27, 2026. Any plan that sends case replies needs a verified domain.
- Omni-Channel changed versions. Standard Omni-Channel retired with the Summer ’26 release, and Salesforce upgrades orgs to Enhanced Omni-Channel during that rollout. Routing designs built on the Standard version need a second look.
Date-stamp every plan you inherit. Check anything written before mid-2026 against this list before the build starts, and redesign any step that depends on a retired feature first.
Service Cloud Implementation Steps, in the Order That Holds Up
Six Service Cloud implementation steps carry the work from scoping to support. At HyphenX we run our Service Cloud projects in this order, and the last column tells you when a stage is finished.
Step | What Gets Done | Done When |
|---|---|---|
1. Discovery and service scoping | Map channels, queues, SLAs, reports and who handles what | Scope document lists every channel and success measure, and the owner signs it |
2. Data and process review | Inventory legacy cases, contacts and articles, and the rules your team follows today | Source-to-target field map is approved and data issues are logged |
3. Platform setup and configuration | Case setup, channels, routing, entitlements, Knowledge and the console | Configuration matches the scope in a sandbox |
4. Build and workflow development | Flows, validation, integrations and reports | Each automation passes its own test cases |
5. Testing and go-live preparation | UAT, data load rehearsal, training and the cutover plan | UAT is signed off and rehearsal counts reconcile |
6. Launch, training and ongoing support | Cutover, hypercare and handover | Hypercare exit criteria are met |
Setup screens change with each Salesforce release, so a tutorial written for an earlier release may not match your screen. Check its date and its screenshots against your org before you follow it step by step.
The next sections follow build order through steps 3 and 4. The Service Cloud implementation checklist later in this guide is the exit test for step 5.
Start With the Case: Record Types, Queues and Rules
Case is the object every channel feeds, so build it first and in this order. Mistakes here carry into every layer after it, including reports, routing and SLAs.
- Record types. Create one per kind of work, such as product support and billing questions, when each needs different statuses or fields. Add one only when the difference is real.
- Support processes. A support process defines the Case Status values for the cases that use it. Decide which statuses count as closed before anyone builds a report.
- Queues. Make one per team that owns work, named by function, such as Billing Tier 1. Add one catch-all queue so no case sits without an owner.
- Assignment rules. Send new cases to the right queue by criteria such as origin, product or language, then test one case from every channel.
- Auto-response rules. Only one case auto-response rule can be active. End it with an entry that has no criteria, because Email-to-Case has no default template.
- Escalation rules. These act on case age, so use them as the general backstop. Entitlement milestones, covered below, handle contractual clocks.
Salesforce caps rules at 3,000 entries per rule, 50 active rules per object across rule types, 500 rules per object in total and 2,000 across all objects. A rule set migrated from an old system can reach those limits, so count entries before you rebuild it. Keep a one-page routing table of channel, criteria and queue, because it becomes the UAT script for routing later.
Agree on names before you build, because consistent queue, record type and status names make reports, routing tables and UAT scripts easier to read.
Getting Work In: Email, Chat and Voice
Launch only the channels you can test end to end. Each one below follows the same pattern: set it up, prove it works, then check the known trap. Keep a list of your test messages, calls and emails so you can repeat the checks after every change.
Verify Your Sending Domain First
- Set up: Salesforce requires the sending domain to be verified by an active DKIM key, which it recommends, or an Authorized Email Domains entry. The sending-domain verification article has the steps.
- Verify: Send a reply from a test case. Failures read “Not allowed to send from an unauthorized domain” in the composer and “550 5.7.1 Delivery not authorized” in email logs.
- Watch for: Verify the domain behind every address that sends case replies, because a reply from an unverified domain fails. Each org-wide address also needs its own verification through the emailed link. Our post on verified sending domains covers the DNS side.
Email-to-Case
- Set up: Use On-Demand Email-to-Case. Salesforce generates an email services address, and you forward your support mailbox to it.
- Verify: Confirm the routing address is verified, send a test email and check that a case lands in the intended queue with the auto-response firing.
- Watch for: Email-to-Case has daily processing limits, so check Salesforce’s current limit against your busiest day before launch.
Enhanced Chat
- Set up: Enhanced Chat (formerly Messaging for In-App and Web) org setup covers Omni-Channel, an Omni-Channel flow, a Messaging channel and an Embedded Service deployment, plus a few other steps in Salesforce’s setup instructions.
- Verify: Start a chat from your test site and confirm the session routes through your Omni-Channel flow to a rep who is online.
- Watch for: Migrating from legacy chat requires Lightning Experience. Salesforce supplies a Chat Transition Readiness Report and a migration tool.
Other Messaging Channels
- Set up: Salesforce’s glossary lists Facebook Messenger, WhatsApp, Apple Messages for Business, SMS, LINE and Bring Your Own Channel alongside the two Enhanced chat types.
- Verify: Send one inbound message per channel and confirm it opens a messaging session routed to the right queue or flow.
- Watch for: The glossary marks standard WhatsApp as retired on October 22, 2025, and standard Messenger and SMS as retired on February 14, 2026. Build the Enhanced types instead.
Voice
- Set up: Salesforce Voice runs on Amazon Connect or partner telephony and needs an add-on license. Before setup, work through the planning checklist, prepare your network, enable Omni-Channel and create a custom domain with a single sign-on URL.
- Verify: Place an inbound test call and confirm it reaches a rep through Omni-Channel.
- Watch for: Open CTI retires on February 28, 2028, and new Service Cloud orgs haven’t been able to use it since February 16, 2026. Build voice on Salesforce Voice.
Hold back any channel that fails UAT, launch the ones that pass and add the rest later. Retest each channel after any change to routing, domains or permissions.
Queue, Skills or Flow: How Should You Route the Work?
A work item can route by queue, by skills or by an Omni-Channel Flow that decides the destination. Choose one approach per work type before you build.
Approach | How It Decides | Use It When | Watch For |
|---|---|---|---|
Queue-based | Checks the work item against queue membership | Teams split by function or tier, with clear owners for each queue | Queue sprawl as rules multiply, with one more queue for every exception |
Skills-based | Checks the skills a work item needs against rep skills | Language, product or certification decides who can help | Skills that go stale and send work to the wrong rep |
Omni-Channel Flow | A flow picks the destination, with a fallback queue | Routing depends on customer data, such as account tier | A flow bug can strand work, so keep a fallback queue and test every branch |
Within a queue, Salesforce offers three routing models: Least Active sends the next item to the rep with the lowest consumed capacity, Most Available sends it to the rep with the most spare capacity, and External hands the decision to a third-party system through the Omni-Channel API. Presence statuses tell Omni-Channel whether a rep can take work, and each rep has a primary and an interruptible capacity that fill independently.
Our recommendation is to start with queues and add skills only where a real mismatch exists. Use interruptible capacity for work that can wait, such as email cases. Review the choice after hypercare, when real queue volumes show where work waits.
Promises and Answers: Entitlements, Milestones and Lightning Knowledge
Entitlements and Milestones
An entitlement defines the support a customer is owed, and a milestone is a timed step inside an entitlement process, such as a first response. Salesforce publishes a setup checklist for Entitlement Management. A sensible build order is: plan the SLAs, enable Entitlement Management in Setup, add fields and permissions, create templates and milestones, then build entitlement processes and add service contracts and reports.
- Milestone limit. An entitlement process holds 10 milestones by default and 50 at most, and going above 10 takes a limit increase request to Salesforce Support.
- Milestone actions. Each milestone can fire actions when time runs out, so test every one with a short timer before launch.
- Business hours. A milestone’s hours override the entitlement process’s, which override the case’s, so check the milestone first when a clock looks wrong.
- Versioning. Salesforce prevents you from disabling entitlement versioning once it’s on, so turn it on in the sandbox first.
Lightning Knowledge
Lightning Knowledge is a one-way switch: Salesforce’s Enable Lightning Knowledge article says you can’t disable it after you enable it, that it needs Lightning Experience, and that you need the Knowledge User license to see Knowledge Settings. It swaps article types for record types, so orgs with several article types must consolidate first. Authors need more than readers do.
- Authoring. The Knowledge User license (a checkbox on each user record), Manage Articles, and Create, Read and Edit on Knowledge.
- Draft visibility. Salesforce turns on View Draft Articles automatically when you grant the Knowledge app permissions.
- Publishing. Publish Articles, plus Create, Read, Edit and Delete on the Knowledge object.
- Retiring. Delete on the Knowledge object, which you should grant only to the people who retire articles.
SLAs and the knowledge base are the two layers hardest to undo, so build both in a sandbox first and review them with the team that will live with them. Walk reps through the first milestone timer.
Service Cloud Implementation Best Practices for Automation and Access
These Service Cloud implementation best practices apply from the first sandbox build. Each row replaces a common habit with a safer one.
Instead Of | Do This | Why |
|---|---|---|
Rebuilding old Workflow Rules and Process Builder as they are | Rebuild them in Flow, then retire the originals after UAT | Support ended on December 31, 2025. See Flow versus Apex for when code is warranted |
Granting access by profile | Use permission sets on a minimal profile | Salesforce cancelled the planned retirement of permissions in profiles and recommends permission sets. See permission hygiene for the cleanup |
Treating MFA as a later project | Turn MFA on for reps before launch | MFA has been a contractual requirement since February 1, 2022, so reps need it from their first login |
Opening guest access wide for a help center | Keep guest users on Private defaults and grant read-only access through guest user sharing rules | Salesforce’s guest user guidance sets external org-wide defaults to Private and gives guest users no record access without an explicit sharing rule |
Writing Apex tests in the final week | Write tests as you build | Apex needs 75% test coverage to deploy to production, so late tests block the release |
Skipping the security scan | Run Health Check before launch and fix the high-risk items | Salesforce grades 90% and above Excellent and 54% and below Very Poor, and our target is Good (70%) or better |
Sort the six rows by how hard each one is to reverse. Permission and MFA changes are inexpensive on day one and expensive after reps have built habits around the old access, so start with those two.
Where to Build, Test and Load: Sandboxes, Deployment and Data Migration
Pick the Right Sandbox
Salesforce lists sandbox types and refresh intervals like this: Developer refreshes daily with 200 MB of data, Developer Pro daily with 1 GB, Partial Copy every 5 days with 5 GB, and Full every 29 days at production size. Your contract sets how many of each sandbox type you get, so confirm your allowance before you plan. Build in Developer or Developer Pro, run UAT in Partial Copy, and keep the Full sandbox for load rehearsal.
Plan the Deployment Path
Salesforce offers several deployment paths, including change sets, the Metadata API, VS Code extensions and DevOps Center. Change sets move configuration only, so records travel through your data load, and Salesforce’s admin blog says the Next-Generation DevOps Center is generally available without giving a retirement date for change sets. Pick one path before the first deployment and use it for every move. Record each deployment in a shared log, and use change sets for a small admin-only team or DevOps Center once several people deploy.
Load Data in the Right Order
Salesforce’s data migration guidance says dependencies set the loading order, with users first, then accounts, then opportunities, and it suggests storing a legacy ID in a custom field, optionally marked as an External ID. It names no Case sequence. Our recommendation is users and queues, then Accounts, Contacts, Cases, and case comments and files, with a pilot record first. Our guide to migrating legacy data with minimal downtime covers the cutover side. Salesforce says the Data Import Wizard suits loads under 50,000 records and Data Loader accepts CSV files up to 150,000,000 records, so confirm in Setup that the wizard lists Case before relying on it.
Service Cloud Go-Live: UAT, Cutover and Hypercare
A go-live is a sequence of gates. Run these six stages and move on only when the current one passes.
- UAT. Write scripts from real closed cases: email in, chat in, escalate, breach an SLA, close, report. Include awkward ones, such as a reply from an unverified address, an after-hours case and a reassigned case with a running milestone. Aim for zero open severity-1 defects at sign-off, and plan rep time using internal hours by role.
- Freeze. Stop configuration changes. Only approved defect fixes move to production after this point, and each one gets a retest before it ships.
- Load rehearsal. Run the full load in a Full sandbox and reconcile counts by object. Rerun it if any count misses, and time the run so you know the cutover window.
- Cutover. Run the final load, point the support mailbox forwarding at the Salesforce email services address, switch the channels on and push one test case through each. Your rollout approach, whether big bang, phased or parallel, decides how much of this happens at once.
- Go or no-go. Hold the decision meeting against criteria written beforehand, with one named owner. Keep the old system readable until hypercare ends so you have a way back.
- Hypercare. Staff a daily triage of defects and SLA breaches, and baseline day-one reports for backlog by queue, first response time and milestone violations. Salesforce publishes no standard length, so set exit criteria: no open severity-1 defects, a stable queue backlog and SLA reports that match expectations.
Tell reps and customers what changes and when, with the new support address, the hours and the escalation contact.
At HyphenX, launch, training and ongoing support form the last stage of our Service Cloud process. When hypercare ends, the next question is who runs the desk, which our post on moving from partner to managed services covers.
The Service Cloud Implementation Checklist: 30 Checks Before Go-Live
Use this as the exit test for step 5 of the steps table. Every item is a yes or no, and each one maps to a section above, so you can jump back to the detail when a box stays empty.
Case Setup
- Record types exist for each kind of work, each with a support process.
- Case Status values define which statuses count as closed.
- Queues exist for every owning team, plus one catch-all queue.
- Assignment rules route a test case from each channel correctly.
- The auto-response rule ends with a no-criteria catch-all entry.
Channels
- The sending domain has an active DKIM key or an Authorized Email Domains entry.
- Every org-wide email address is verified through its emailed link.
- The Email-to-Case routing address is verified, and a test email creates a case.
- Each messaging channel uses a current type, and a test session reaches a rep.
- Voice has Omni-Channel enabled, a single sign-on URL and an Open CTI replacement plan.
Routing and SLAs
- Each work type uses one routing approach: queue, skills or Omni-Channel Flow.
- Capacity and presence statuses are set, with interruptible capacity for email.
- Business hours are checked at the milestone, the entitlement process and the case.
- Every milestone has an action that fires when time runs out, tested with a timer.
- Each entitlement process stays at 10 milestones or fewer, or Support approved more.
Knowledge and Automation
- Lightning Knowledge was enabled in a sandbox first, and the team accepts it stays on.
- Authors hold the Knowledge User license, Manage Articles and object permissions.
- Article record types are defined before any article is migrated into the org.
- No new automation depends on Workflow Rules or Process Builder.
- Apex tests meet the 75% coverage needed to deploy to production.
Security and Environments
- Reps hold permission sets on a minimal profile, with no extra access by default.
- MFA is on for every rep before their first login.
- Guest users keep Private defaults, with read-only access through sharing rules.
- Health Check scores 70% or better (our target), and high-risk items are fixed.
- UAT ran in a Partial Copy sandbox, and the deployment path was rehearsed.
Data, People and Cutover
- A legacy ID External ID field exists on each migrated object before the load.
- The load rehearsal reconciled record counts by object, and any misses were fixed.
- Data owners signed off the source-to-target field map before the full load.
- Reps are trained on the console, and day-one reports with a baseline are ready.
- Hypercare staffing, exit criteria and a rollback owner are named in writing.
Treat every unchecked box as a launch blocker, or log it as a named, dated risk with an owner. Mark a box only after someone has tested the item in a sandbox, and review the full list again on the day before cutover.
What Will Service Cloud Cost? Editions, Hours and Public Contract Rates
Editions and the Hours Model
Year-one cost has two halves: license fees and the hours the work takes. Salesforce publishes the first half on its Service pricing page, where editions run from $25 to $550 per user per month as of October 2026, and no public source gives the second half as a standard figure. Salesforce announced Core, Advanced and Max on September 3, 2026, and reporting on the announcement says pricing on legacy editions is unchanged for now.
Edition | Price per User per Month (USD) | Billing |
|---|---|---|
Starter Suite | $25 (starting price) | Monthly or annual, with transaction fees |
Pro Suite | $100 (starting price) | Annual, contract required, with transaction fees |
Core | $195 | Annual |
Advanced | $395 | Annual |
Max | $550 | Annual |
Enhanced Messaging adds $75 per user per month on Core and Advanced, and 20 reps on Core cost 20 x $195 x 12 = $46,800 a year in licenses. The full formula is year-one cost = licenses + (billable hours x blended hourly rate) + third-party tools + paid add-ons + internal labor, and your own admins and testers spend real hours in UAT, so count them. Scope the hours line layer by layer, with separate estimates for case setup, each channel, routing and SLAs, Knowledge, automation, data migration, UAT and training, and our Salesforce implementation budget guide covers budget lines across a full program.
What Public Contracts Show
No public record we found lists a Service Cloud project’s cost and duration together. The University of the District of Columbia contract shows 3,915 hours at $236.56 an hour for a recruitment and admissions build, plus a change order of 1,160 hours. The UDC board resolution 2026-24 sets $250 an hour for up to 600 hours a month, including service desk and case management work, and the Utah memo dated August 28, 2024 lists $152,909.36 for 598 hours over about 33.6 weeks, or about $255.70 an hour. At those rates, each 100 billable hours costs about $23,700 to $25,600, so treat them as reference points for your own estimate.
Should You Switch Agentforce On at Launch? Three Questions First
Phase Agentforce in after the base desk is stable, and move it into the first release only if all three answers below are yes. Agentforce also has its own pricing: Salesforce’s Agentforce pricing page lists Flex Credits at $500 per 100,000 and conversations at $2, and the two models can’t run in one org.
- Is Data 360 provisioned? Salesforce’s setup guide works in this order: provision Data 360 first, then Einstein, then the Trust Layer, then agents. The guide says Data 360 is required for the Trust Layer to function correctly.
- Is the material behind the answers clean? The Trust Layer adds grounding, data masking, toxicity scoring, an audit trail and a zero-data-retention policy, so third-party LLMs don’t retain your data. Grounding is only as good as your articles and case history, so finish Knowledge and data migration first.
- Can an agent hand off to a rep? Salesforce’s Agentforce Service Agent setup uses an outbound Omni-Channel flow to escalate a conversation to a rep when needed, so routing has to work and be tested first.
If any answer is no, launch with reps and add Agentforce in a second phase with its own UAT, then measure it against the baseline from hypercare. Our post on Agentforce from day one weighs when it belongs in the first release.
The Team That Takes Service Cloud to Go-Live
The 30 checks above span case setup, channels, SLAs, Knowledge, security and data, and no single admin owns all of them. HyphenX Solutions has 250+ Salesforce professionals, so each layer gets an owner who has shipped it before, from sending-domain verification to entitlement milestones and load rehearsals. The same team stays through hypercare, so nothing gets lost at handover. Learn more about our people.
Case Study From Our Salesforce Projects
To see our work in practice, here is one of our case studies.
From Swivel-Chair Prospecting to Single-Click Pipeline
A B2B SaaS company running structured outbound sales used three prospecting tools that did not connect to Salesforce: Apollo for database reach, Lusha for direct dials and Hunter for email discovery. Reps copied data between the tools and the CRM by hand, which led to duplicate records, rising email bounce rates and forecasts built on unreliable pipeline data. We built a native prospecting action inside Salesforce that queries all three tools in a best-source-first sequence, verifies emails before writing them and handles deduplication and source attribution, with Agentforce taking over account research and Einstein handling lead scoring, routing and forecasting on the cleaned data.
Key takeaway: The client already had good tools and people, and the missing piece was a workflow connecting them. Consolidating three tools into one governed CRM action, then adding AI on clean data, moved the team from manual record-keeping to active selling.
Read the full case study: From Swivel-Chair Prospecting to Single-Click Pipeline
Explore more case studies
Frequently Asked Questions
What Is a Salesforce Service Cloud Implementation?
It is the work that turns a Service Cloud license into a running support operation: case setup, channels, routing, SLAs, knowledge, security, data migration, testing and launch. Salesforce Help now writes the product name as Agentforce Service (formerly Service Cloud).
What Should You Configure Before Service Cloud Go-Live?
Set up case record types, queues and rules; Email-to-Case or messaging channels on a verified sending domain; Omni-Channel routing; entitlements and milestones; Lightning Knowledge; Flow automation; permission sets and MFA; a rehearsed data load; and signed-off UAT. The checklist above lists 30 checks to run before launch.
How Long Does a Service Cloud Implementation Take?
Salesforce publishes no standard duration. Public records give one reference point: a Utah grantmaking build was scoped over about 33.6 weeks. Channels, integrations and data volume decide your timeline, so scope each one before you commit to a launch date.
How Much Does a Service Cloud Implementation Cost?
No sourced standard figure exists. Year-one cost is licenses plus billable hours times a blended rate, plus third-party tools, paid add-ons and internal labor. Public contracts work out to $236.56 to $255.70 per hour, so 100 hours costs roughly $23,700 to $25,600.
Is Service Cloud Now Called Agentforce Service?
Salesforce Help articles write “Agentforce Service (formerly Service Cloud)”, while the product page at salesforce.com/service still says Service Cloud. This guide uses the name on the product page. Current editions are Starter Suite, Pro Suite, Core, Advanced and Max.
What Is the Difference Between Service Cloud and Sales Cloud?
Service Cloud runs support work: cases, queues, entitlements, Knowledge, Omni-Channel and the Service Console. Sales Cloud runs selling: leads, opportunities and forecasts. Both sit on the same Salesforce platform and share accounts and contacts.
Do You Need a Salesforce Partner to Implement Service Cloud?
A partner is optional. A trained admin can run a small, single-channel setup. A partner helps most with multi-channel routing, SLAs, data migration and cutover, where mistakes are costly to reverse. Lightning Knowledge, for example, cannot be disabled once enabled.
How Do You Set Up Email-to-Case?
Enable On-Demand Email-to-Case in Setup, create a routing address, copy the Salesforce email services address, and forward your support mailbox to it. Verify the routing address, send a test email, and confirm a case lands in the right queue.
What Is Omni-Channel Routing in Service Cloud?
Omni-Channel pushes work items such as cases and chats to available reps by queue or by skills, using routing configurations, presence statuses and capacity. Enhanced Omni-Channel is the only version now, because Standard Omni-Channel retired with Summer ’26.
What Are Entitlements and Milestones in Service Cloud?
An entitlement defines the support a customer is owed. Milestones are the timed steps inside an entitlement process, such as a first response, with actions that fire when time runs out. A process holds 10 milestones by default and 50 at most.
In What Order Should You Migrate Data Into Service Cloud?
Load parents before children. We recommend users and queues, Accounts, Contacts, Cases, then case comments and files, with a legacy ID External ID field on each object. Load one record first and reconcile counts. Salesforce’s guidance says to load in dependency order and names no Case sequence.
Does Service Cloud Include AI and Chatbot Features?
Yes. Agentforce for Service adds AI agents to a Service Cloud org. Salesforce’s Agentforce pricing lists $500 per 100,000 Flex Credits or $2 per conversation. Salesforce’s setup guide has you provision Data 360 first, so finish case, routing and knowledge setup before turning agents on.
Can You Still Use Workflow Rules and Process Builder?
Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025. Existing rules and processes keep running. Build new automation in Flow, and rebuild what you depend on before go-live.
Is Salesforce Live Chat Still Supported?
Legacy Chat, including Live Agent and Embedded Chat, reached end of support on February 14, 2026. Enhanced Chat, formerly Messaging for In-App and Web, replaces it. Migrating to Enhanced Chat requires Lightning Experience.
What Is Hypercare and How Long Should It Last?
Hypercare is the staffed period after go-live when defects and SLA breaches get daily triage. Salesforce publishes no standard length. Set the window by exit criteria: no open severity-1 defects, stable queue backlog and SLA reports matching expectations.
