Almost every Service Cloud project I've run starts the same way. The client already has a "Contact Support" page on their public website, a shared inbox somewhere, and a vague sense that cases are falling through the cracks. They want intake to land in Salesforce, get routed to the right team, and stop living in someone's Outlook. Web-to-Case looks like the obvious answer, and for the first phase it usually is.
The trouble is that Web-to-Case is deceptively simple to turn on and surprisingly easy to get wrong in ways that don't show up until you're in production. I've watched a perfectly configured form dump every case onto the admin user because one checkbox was unticked, and I've watched a public form get scraped and flooded with thousands of junk cases over a weekend. So before I generate a single line of HTML, I want to be clear with the client about what this feature actually is, where its ceiling sits, and what the upgrade path looks like when they inevitably outgrow it.
I'll use a composite of a B2C e-commerce client I worked with to keep this concrete. Picture an online retailer that wants customers to report delivery problems, refunds, and returns from a public help page, without forcing anyone to log in, and have those cases routed to the right customer-service team by issue type. That's a textbook Web-to-Case scenario, and it's also the scenario where the limits start to bite quickly.
What Web-to-Case really is, and where it stops
Web-to-Case lets Salesforce accept a case from a plain HTML form with no authentication. Salesforce generates a form whose action points at its own endpoint, the form POSTs the field values along with a hidden orgid, and Salesforce parses the payload and inserts a Case. That's the whole mechanism. You enable it under Setup, pick a default case origin of "Web" and a default response template, then use the HTML Generator to choose which Contact and Case fields appear on the form. The generated markup is meant to be handed to the client's web developer, who restyles it to match the brand and drops it into the CMS.
Two things about that endpoint matter enormously. First, the orgid sits in the page source as plain text, so anyone who views source has everything they need to script POSTs straight at your org. Second, Salesforce ships no captcha and no attachment support in the built-in form. Those two omissions drive most of the architectural decisions that follow.
The hard ceiling is 5,000 cases per day through Web-to-Case. Past that, Salesforce emails the admin and either discards the overflow or sends it to the default owner, depending on how you've configured excess-case behavior. For a client expecting big spikes around a sale event, that cap is a real risk, and it's the moment I start steering the conversation toward a custom REST endpoint in Apex instead of the built-in form. The decision tree I carry into discovery is simple: low volume, no attachments, no need to track history points to Web-to-Case; high volume or a need for attachments and custom UX points to a direct API; and a need for customers to see and manage their own cases points to a portal.
Making routing and auto-response actually work
The configuration that trips people up most isn't the form, it's the routing. You create a case assignment rule that sends delivery issues to the logistics queue, refunds to the finance queue, high-priority product defects straight to a team lead, and everything else to a general queue. Then you create auto-response rules so the customer gets an acknowledgement email with their case number within a minute or two, ideally with content tailored to the issue type.
Here is the gotcha I now put on every deployment checklist in bold: an active assignment rule does nothing for web cases unless you also tick "assign using active assignment rules" on the Web-to-Case settings page. Those are two separate switches in two separate places. When the checkbox is missed, every web case quietly falls to the default case owner, which is usually the admin, and the service teams never see anything arrive. The rule looks perfect in setup, the cases look fine in the list view, and nobody notices until a customer escalates a ticket that was apparently never touched.
The only way I trust routing is an end-to-end test on staging. Submit a real form, then confirm the Case exists, the origin is "Web", the status is "New", it landed in the correct queue, the auto-response email reached the inbox, and the Contact was matched or created correctly by email. That last point has its own trap: if the form doesn't validate email format client-side, customers submit malformed addresses, Salesforce happily creates the case but can't match a Contact, and you accumulate duplicates. For consumer clients where people change email addresses constantly, I often argue for phone number as the matching key and lean on duplicate and matching rules to keep Contacts clean.
Defending a public form against the obvious abuse
Because the form can POST directly from any browser with a copied orgid, you cannot leave it exposed. My standard recommendation is to never let the HTML form POST straight to Salesforce from the client's site. Instead, the form submits to the client's own backend, the backend verifies a reCAPTCHA token and any signature it cares about, and only then forwards a clean payload to the Salesforce endpoint. If a backend proxy genuinely isn't available, reCAPTCHA v3 with server-side verification is the minimum bar.
The reason I'm firm about this is the failure mode. Junk cases don't just clutter the queue and waste agent time; they burn down that 5,000-per-day allowance, and once you hit the cap, legitimate cases start getting rejected. Spam protection on a public form isn't hardening for later, it's part of shipping the thing at all.
One smaller encoding gotcha is worth flagging if the client's market uses accented characters. Salesforce generates the form as UTF-8, but if the CMS page declares a different charset, picklist values with diacritics arrive mangled and never match the underlying picklist, so the field lands empty. The clean fix is to force UTF-8 on the CMS page, but the defensive move I prefer is keeping picklist API names plain ASCII while letting the display labels carry the accents.
When self-service intake outgrows a form
Web-to-Case is a one-way door. The customer throws a problem over the wall and waits for an email. That works right up until customers want to see what they submitted, reply in the same thread, attach a photo after the fact, or close a ticket themselves once they're satisfied. With the retailer, the tell was that a meaningful share of cases were being reopened simply because customers never received the reply, whether it went to spam or to an address they'd since abandoned. When email becomes the single point of failure for the whole support loop, you've outgrown the form.
That's the point where I move clients to an Experience Cloud portal built on the "Customer Service" template, which gives you case list, case detail, and Knowledge search out of the box. For a straightforward consumer audience I reach for the Customer Community license, which covers Knowledge search, submitting and viewing cases, and commenting, without the role hierarchy and delegated administration of Customer Community Plus. Plus is overkill for B2C end users; I save it for partner and reseller scenarios that genuinely need sharing structure.
The portal also unlocks case deflection, which is where the real ROI usually lives. Putting a Knowledge search box above the submit form, so a customer typing "where is my order" sees the order-tracking article before they ever reach the form, measurably cuts ticket volume. For that to work, the articles have to be published to the Public Knowledge Base channel, not just the Customer channel. I've seen a client lose all of their organic search traffic because help articles required a login, so anyone arriving from Google hit a wall and left. General FAQ and policy articles should be visible publicly; only genuinely internal procedures stay internal-only.
The portal traps that bite hardest
The single most dangerous mistake on a customer portal is case sharing. By default, Cases are private and a community user sees nothing at all, even their own cases. You have to open access, and if you do it carelessly, you do it too wide. A criteria-based sharing rule keyed on something like case type can let one customer see another customer's cases of the same type, which means leaking order numbers and delivery addresses across strangers. In any jurisdiction with a real data-protection regime, that's a reportable breach, not just an embarrassing bug. The correct approach is to rely on implicit sharing through an accurate ContactId on every case, so a user can only see cases tied to their own Contact, and then to prove it by logging in as two different customers and confirming neither can see the other's cases.
The second trap is quieter but ruins reporting. It's tempting to park all consumer users under a single placeholder Account, and functionally that's fine, but every case then rolls up to that one Account and any "cases by account" analysis becomes meaningless. If the client cares about segmenting customers, report at the Contact level with a tier field on the Contact, and consider Person Accounts only if you can enable them at the very start, because that switch can't be flipped on a mature production org.
Finally, run Email-to-Case alongside the portal. Even with a clean in-portal reply experience, customers will reply to the notification email, and unless the reply-to address routes back into Email-to-Case with the thread ID intact, those replies land in some agent's personal inbox and vanish from the case. The end-to-end test here is mundane but essential: agent replies in the portal, customer receives the email, customer replies to it, and you confirm that reply surfaces in the case feed.
The thread running through all of this is that Web-to-Case and the customer portal aren't competitors, they're two stops on the same road. Start clients on the form when intake is genuinely one-way and volume is modest, but make the upgrade trigger explicit from day one: the moment customers need to track, reply to, or close their own cases, it's time for the portal. Naming that boundary up front is what keeps the first phase cheap without painting the client into a corner later.
Implementing or optimizing Service Cloud? Our Salesforce team runs discovery, designs the case process, and configures Service Cloud, Omni-Channel, and Knowledge on production engagements. Get in touch ->
See our full platform services for the stack we cover.
