People often ask me about Web To Case -- how it's used, what it can do, and its limitations. I thought I'd take a moment today to discuss it.
First, let's start with the basics.
What is Web To Case and how does it work?
Web To Case is a means by which you can post a simple, unauthenticated web page that allows your customers to submit cases directly to your Salesforce.com instance. This means that you can post a public case submission page on your own website with your own branding and styling. In a nutshell, Web To Case works by generating for you a snippet of HTML. This HTML is a good old-fashioned HTML form that you can put on any page. When your customer presses Submit, the information on this form is posted directly to a Salesforce.com server, which handles the information, converts it to a case, and redirects the customer's browser back to a page of your choosing.
Setting up Web To Case requires a couple of steps; rather than regurgitating them all here, I will refer to the excellent documentation on the subject.
When your customer posts a case via Web To Case, a few fields are generally required, namely the name and the email address. These values will be stored in the newly created Case in the Web Name and Web Email fields. If that email address happens to be associated with a Contact in your system, then Web To Case will automatically associate that case with the contact who has that email address, and with the account associated to that contact. If that email address is not found, or Web To Case discovers more than one contact with that email address, then Web To Case will not know which contact to associate to the case. In that instance, it will leave the Contact and Account fields on the case blank and allow you to fill them (which you can generally find using those Web Name and Web Email fields).
What is Web To Case useful for?
Let's say that you're doing a lot of support by email. Emails are an unstructured medium, so even if you're automating the process with Email To Case , someone generally still has to look at the cases to classify them -- it's not easy to perform workflow on plain text. Web To Case allows your customers to submit the information directly into the individual fields on your case, so you can perform a great deal of automation, like workflow, assignment, and auto-response rules, immediately. That can save you a lot of man hours.
Meanwhile, Web To Case is a very quick way to put up a web form to accept cases. You can generally have a quick-and-dirty page up in minutes, and because it's standard HTML, it's easy to embed into an existing page.
What are Web To Case's limitations?
First, Web To Case is limited to receiving 500 cases per day. This is to keep things like spambots from beating up your org (and beating up Salesforce.com's servers). Speaking of spam, Web To Case does not perform any spam filtering. You could use workflow to filter out cases that appear to be spam, but Web To Case itself does not apply any particular intelligence -- it just takes the cases.
Web To Case cannot handle attachments.
This is a side effect of the simplicity of its setup, and of the simple transactional nature of HTTP. Taking attachments via the web is a remarkably complicated process. For instance, try attaching a document in Gmail. You'll notice that you first have to browse to a file; it posts that file immediately to the server. In the background, it associates your in-progress email with the file it just posted, so that when you finally go to send the email, it knows which attachments go with which email. So there are two posts involved here, plus a fair bit of backend logic. Web To Case, on the other hand, is a simple form with a single post that you can embed anywhere. Attachments don't play nice with that.
Out of the box, if Web To Case does not find a contact to associate a case to, it will not autocreate one. However, a previous blog post discusses how, with a simple Apex trigger, you can set your org up to do so.
Finally, Web To Case is solely a tool for the initial submission of cases. If your customers need to be able to track their cases, or add information to them after the initial submission, then you'll want to look into the Self Service Portal or the Customer Portal -- those are authenticated products that allow your customers to file cases, but also to follow up on them, browse the knowledge base, and in the case of the Customer Portal, lots of other things as well.
How can I work around the volume and attachment limitations?
If you need to take more than 500 cases per day, or you want to be able to take attachments, you can now do so using Salesforce.com's facility for unauthenticated access called Force.com Sites. There's a quick start you can follow on how to create a custom Web To Case form using Sites.
No comments:
Post a Comment