Getting Started with… Web-to-Case
Getting Started with… Web-to-Case
This is the first in a series of Getting Started blogs about the Service Cloud. In these blogs I’ll be introducing some standard service features and talking about how you can get set up with them quickly. I’ll also mention some tips and tricks I’ve found from implementing these in the past, and any limits or ‘gotchas’ that you should be aware of.
First up: Web-to-Case.
What is Web-to-Case?
Web-to-Case is a simple feature that helps you to create a Customer Support form to add to your website. When a customer makes an entry using the form, their issue gets created as a Case in Salesforce. You can then use standard Salesforce automation to assign the Case to the right support team, send an acknowledgement to the customer and track the Case through to a successful resolution.
When should I use Web-to-Case?
You should use Web-to-Case if you already have a form on your website that isn’t integrated with Salesforce – or if you were thinking of adding one. You can access this feature if you’re using Professional Edition or above.
I’ve often been surprised by how many Salesforce customers use unintegrated webforms that simply forward entries onto a Support mailbox – taking all that good, structured information and turning it into a long, unstructured email message for an agent to sift through!
By using Web-to-Case to push Support issues straight into Salesforce, you can save your agents the time they normally spend logging these issues manually. The information is structured, making it easier to understand at first glance. You can also prevent the opposite problem of agents not logging these issues as Cases because of the manual effort involved (and, believe me, this will happen).
How do I get started?
Setting up a Web-to-Case form is incredibly simple, and Salesforce already has some great documentation on each step needed. Cast your eye over these, then read on for my Tips and Tricks:
Tips and Tricks
Tip 1: Modifying Picklists
Sometimes you’ll want to include a picklist in your webform but hide specific options from customer use. Although you can generate your HTML automatically in Salesforce, it’s good to know how to make some little amendments of your own.
One scenario where I’ve encountered this before is when a Case Type picklist contains options that aren’t appropriate for a customer-raised case. While you still want to keep these available in the Salesforce picklist, you might want to hide these on the customer-facing form.
Fortunately It’s very simple to modify the Salesforce-generated HTML to hide these options. In this example I’ll show you how to remove some Case Type options from the form, so that the Customer can only select three of the five options we have in Salesforce.
We can do this in just three steps.
1. Generating the HTML: Start by generating your HTML using the Salesforce Web-to-Case HTML Generator. (To see how to use the Generator, see Step 2 of Salesforce’s documentation above, Generate Web-to-Case HTML Code.)
Adding the Type field into the HTML Generator
The resulting HTML code, with the Type field section highlighted
2. Removing options: Find the options you want to remove – these will begin with an <option> tag and end with an </option> close tag. When you remove one of these lines, that corresponding option will be removed from the form.The amended HTML code, with some Type options removed
3. Testing: Copy the HTML into a text editor (I use Notepad) and save the file as a .html file on your desktop. Load up the file to make sure that the options have disappeared.
The resulting test (unbranded) webform, with just three Type options
Tip 2: Adding Hidden Fields
Sometimes you’ll want to secretly add extra information onto web-generated Cases to improve the quality of Case information flowing into Salesforce. For example, if you’re using record types on your Case object, you might want to set a particular record type for webform entries.
Another example I’ve seen before is you’re using more than one Web-to-Case form and you want to distinguish between the different webform entries. This could be because you want to send different Auto-Response emails for each form, or apply different Support processes to those entries.
I’m going to take this example to demonstrate adding a hidden field. In the steps below I’ll be adding a hidden field, Webform, and setting the value automatically, so that every time a Customer submits a Case using this form, the Case will show that it came from that specific webform.
We can add a hidden field in five steps.
1. Generating the HTML: create your Web-to-Case form using the Generator, and include the field you want to hide. This saves you from writing too much code from scratch.
Adding the Webform field into the HTML Generator
2. Hiding the field: add the type=”hidden” attribute to the field’s input or select tag (we see select here because Webform is a picklist field). The new attribute can go anywhere within the tag, since order doesn’t matter.
Hiding the Webform field
3. Setting your value: add the value=”Mech/Structural” attribute to the field’s input or select tag.
Setting the Webform field value
4. Changing the tag: at this point, if your tag is a select tag, change this to an input tag so that the code isn’t expecting the customer to pick the option. (Change <select> to <input> and </select> to </input>) You should also delete the label (the bit that says Webform:), and the other option value tags.
Changing the tag from <select> to <input> and removing other options
5. Testing: Copy the HTML into a text editor (I use Notepad) and save the file as a .html file on your desktop. Submit a test Case to check that the hidden value is set correctly.
Checking the test Case created in Salesforce, with the Webform field highlighted
Tip 3: Linking Cases to Contacts
One other handy feature of Web-to-Case is that Cases are automatically linked to the relevant contact and account wherever possible. This is based on the email address supplied on the webform. (For this reason you should always include this Email field in any Web-to-Case forms you use, even if you request phone or social contact details as well. There are also clear benefits around being able to send the customer Case creation confirmation and updates.)
The linking works by scanning your Salesforce Contact records to find an Email address that matches the one supplied on the Web-to-Case form.
Bear in mind that Salesforce only looks at the standard Email field on the Contact, and it needs an exact match – this means that your mileage may vary if you use multiple email address on Contacts, or if you have duplicate Contacts with the same email address.
Salesforce best practice is to relate Cases to Accounts and Contacts wherever possible to give you a single view of your customers’ interactions with your organisation. The benefits of this single view is huge, because you can start building a history of the Cases raised per customer. This is a fundamental step if you want to personalise your customer interactions, improve agent productivity and increase your interaction consistency across channels.
You can check how many of your Cases are being successfully related to Contacts by using a simple formula. This formula could be used in a Checkbox formula field, to show agents when a Contact record should be sought or created manually.
NOT(ISBLANK( SuppliedEmail )),
ISBLANK( ContactId ))
You could also use this formula in a workflow rule to assign the cleanup task to a nominated user. Alternatively you could use it as part of a validation rule, perhaps to prevent a Case from being closed before a Contact is linked.
As always in Salesforce, there are many different possible solutions to achieve the same goal, and you just need to consider which (if any!) is appropriate in your organisation.
If email linking isn’t a good solution for your organisation, it’s worth considering custom development to deliver a solution better tailored for your implementation. A really good B2B example of this is here, where you can read about how to link Cases to Accounts automatically, based on a customer-entered Account Number.
An infinite variety of other solutions are also possible – feel free to get in touch if you want to know more.
- Bear in mind that when a Case is created via Web-to-Case, it will always show as ‘Created By’ the Automated Case User you have specified in your Support Settings. The default owner will be your nominated Default Case Owner. You can change both of these settings in setup (Setup | Customize | Cases | Support Settings).
- Your organisation can receive a maximum of 5,000 Web-to-Case submissions every 24 hours. (This total applies across all your Web-to-Case forms together – so the limit is the same regardless of how many forms you have). If your organisation exceeds this limit, your Default Case Owner will receive an email containing the additional Case information.
- Remember that standard validation rules will still run when Cases are created by Web-to-Case, and that universally required field settings also apply. Make sure that you test your Web-to-Case forms before putting them live, and check over your existing Case validation rules to make sure that none of them will interfere with Cases submitted from your webforms.
- If you’re using Rich Text area fields on your Case, note that these aren’t supported on Web-to-Case forms. You can still add them to the form, but any entry will be compressed into plain text when the Case is created.
- Web-to-Case is available for Professional Edition and above.