Web-to-Case
Web-to-Case is the Salesforce feature that converts HTML form submissions on a public web page into Case records in the org.
Definition
Web-to-Case is the Salesforce feature that converts HTML form submissions on a public web page into Case records in the org. The admin generates an HTML form snippet through Setup, embeds it on a website (or hands it to a marketing team to embed), and visitor submissions arrive in Salesforce as new Cases with the submitted field values mapped to the corresponding Case fields. Auto-Response Rules can send the submitter an acknowledgment email; Assignment Rules can route the new case to the right queue or owner. Web-to-Case is the entry point for many customer-service workflows.
The feature has been in Salesforce since the original Service Cloud release and is intentionally simple. It supports up to 5,000 cases per day at no extra cost. For higher volumes, customers move to Email-to-Case (which has no per-day cap) or build a custom integration through the REST API. Web-to-Case is the right choice for small-to-medium customer-facing forms: support contact forms, warranty registration, product inquiries. It is the wrong choice for high-volume B2C support where 5,000 cases per day is the floor, not the ceiling.
How Web-to-Case turns form submissions into Salesforce cases
How Web-to-Case actually works
Web-to-Case uses a simple HTML form that posts to a Salesforce-hosted endpoint with the org's OrgId baked in. The endpoint receives the form data, validates the OrgId, runs Validation Rules against the submitted values, runs Auto-Response Rules to send a confirmation email, runs Assignment Rules to set the Case Owner, and writes the Case to the database. The form fields map to Case fields by the name attribute on each input. Hidden fields can populate fixed values (Case Origin = Web, Type = Inquiry). The whole flow happens in 1 to 3 seconds end-to-end.
Generating the HTML form
Setup, Web-to-Case, Generate HTML opens a wizard that lets the admin pick which Case fields appear on the form. The wizard outputs an HTML snippet ready to paste into a web page. The snippet includes the OrgId, the return URL (where the visitor lands after submission), and the input elements for each selected field. The output is intentionally bare-bones; styling and form validation are left to the developer embedding the form. Most teams either restyle the form to match their brand or wrap it in a frontend framework component that pre-validates.
Auto-Response Rules and Assignment Rules
Two rules run on every Web-to-Case submission. Auto-Response Rules match the submitted Case against a set of criteria (Type = Sales, Subject contains "pricing") and send the submitter a templated acknowledgment email based on the first matching rule. Assignment Rules match against a similar criteria set and assign the Case Owner to a user or queue. Both rule types run in order until the first match. If no rule matches, the Default Case Owner is used. Auto-Response and Assignment Rules together turn a Web-to-Case submission from a raw form into a routed support workflow.
Daily limit and overflow handling
Web-to-Case has a hard 5,000 case per day limit. The 5,001st submission of the day is rejected. The platform tracks the count per org and surfaces it in the Web-to-Case Settings page. For overflow, customers configure a Default Email Account that receives any submissions beyond the limit, so the data is not lost. Most orgs hitting the limit consider whether Web-to-Case is the right tool. The alternative (a custom REST API integration writing to the Case object) has no per-day cap and supports more validation logic.
Spam protection and reCAPTCHA
Public-facing forms are spam targets. Salesforce supports reCAPTCHA on Web-to-Case forms through a built-in integration. The admin generates a Google reCAPTCHA key in Google Cloud, configures it in Setup, Web-to-Case Settings, and the form requires reCAPTCHA validation before submission. Without reCAPTCHA, expect 30 to 60 percent of submissions to be spam. With it, the spam rate drops to under 5 percent. Always enable reCAPTCHA on production Web-to-Case forms.
Custom validation and Flow integration
Web-to-Case Validation Rules can reject submissions that fail validation, returning the visitor to an error page. Beyond Validation Rules, a record-triggered Flow on Case Create runs after the Web-to-Case submission lands. Flow can enrich the Case with extra fields, look up the related Contact by Email, route by complex logic, or escalate based on the submitted Subject. Most modern Web-to-Case deployments pair the basic form with a Case Create Flow that does the heavy lifting. The form stays simple; the platform handles the rest.
When to outgrow Web-to-Case
Three signals that Web-to-Case has reached its limits. First, the 5,000 cases per day cap becomes a real ceiling and overflow emails accumulate. Second, the form needs complex client-side validation, multi-page wizards, or file uploads with specific size and type constraints. Third, the form needs to authenticate the submitter against an existing Contact or User record. At those points, customers migrate to a custom Lightning Web Component on Experience Cloud (which has full UI control and Salesforce-context awareness) or to a REST API integration from a frontend framework.
Setting up Web-to-Case for a public contact form
Setting up Web-to-Case takes about 30 minutes for a basic form: enable the feature, generate the HTML, configure routing rules, enable reCAPTCHA, embed the form on the public site, and test end-to-end.
- Enable Web-to-Case
Setup, Web-to-Case Settings, check Enable Web-to-Case. Set the Default Case Origin (typically Web) and the Default Response Template.
- Generate the HTML form
Setup, Web-to-Case, Generate HTML. Pick which Case fields to expose. Set the Return URL (where the visitor lands after submission). Click Generate, copy the HTML output.
- Embed the form on the public site
Paste the HTML into the website page (WordPress, marketing site, custom HTML page). Style the form to match the brand. Test that the form submits to the right Salesforce endpoint.
- Configure Auto-Response Rules
Setup, Auto-Response Rules, New. Create rules that match Case criteria and send templated acknowledgment emails. The first matching rule wins; order matters.
- Configure Assignment Rules
Setup, Case Assignment Rules, New. Create rules that match Case criteria and assign the Case Owner to a user or queue. Set a Default Case Owner for unmatched cases.
- Enable reCAPTCHA
Setup, Web-to-Case Settings, configure reCAPTCHA. Get the key from Google Cloud, paste into Salesforce. Re-generate the HTML with reCAPTCHA enabled.
- Test end-to-end
Submit a test case through the public form. Confirm the Case appears in Salesforce with the right field values, the Owner is set correctly, and the submitter receives the auto-response email.
Picklist value applied to every Web-to-Case submission. Typically Web. Used for reporting on the source of cases.
Email template sent to the submitter when no Auto-Response Rule matches. Acts as a fallback acknowledgment.
The page the visitor lands on after form submission. Usually a thank-you page.
Google reCAPTCHA key configuration that adds spam protection to the form.
User or queue that receives any Case not matched by an Assignment Rule. Required to avoid orphaned cases.
- Web-to-Case is capped at 5,000 submissions per day. The 5,001st submission is rejected. For higher volume, use a custom REST API integration or Experience Cloud.
- Without reCAPTCHA, spam submissions can flood the org. Enable reCAPTCHA on every production Web-to-Case form, no exceptions.
- The HTML form generator outputs bare-bones markup. Production forms need styling and client-side validation that the generator does not provide.
- Auto-Response and Assignment Rules run on the first match only. Rule order is critical. Test order changes carefully; a new rule inserted at the wrong position changes routing for existing scenarios.
- Hidden fields in the HTML can be manipulated by sophisticated submitters. Validate critical fields on the server side through Validation Rules or a Flow rather than relying on hidden field values.
Trust & references
Straight from the source - Salesforce's reference material on Web-to-Case.
- Web-to-Case SetupSalesforce Help
- Auto-Response RulesSalesforce Help
- Case Assignment RulesSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Web-to-Case?
Q2. How do you set it up?
Q3. What handles routing?
Discussion
Loading discussion…