Service and Support Blog
Service and Support Blog - June 2009
-
New in Summer '09: New Portal Administration Capabilities
Jun 25, 2009Since the Customer Portal was introduced back in Summer '07, we've seen enormous uptake of it. As our customers have picked it up, they've been asking us for the ability to manage their portal users better. I'm pleased to say that we've provided a lot of that with the Summer '09 release.
Note that the new features listed here apply to both the Customer Portal and the Partner Portal.
Disable Customer Portal User
Until now, once a contact was made into a Customer Portal user, it was effectively "locked" -- it couldn't be merged or deleted. The Customer Portal user associated with it could be inactivated, but that's about all that could be done with it.
With Summer '09 we've introduced this handy-dandy button to the Contact page:
This button disables the Customer Portal user for a contact. This means that the Customer Portal user gets inactivated, but also that the contact becomes unlinked from that user, which means that you can now treat it like a normal contact. You can delete it, merge it, and generally have your way with it.
Disable Portal Account
In addition to disabling a single contact, you can also disable an entire account's access to the Customer Portal. By pressing the Disable Customer Portal Account button, you can disable the account for the portal and as many as 100 Customer Portal users in that account all at once (if you should have more than 100 Customer Portal users under that account, we recommend that you disable the contacts' Customer Portal users separately).
When you enable an account for the Customer Portal, Salesforce.com automatically creates as many as 3 roles in the system that represent this account. Disabling the account will also delete these autocreated roles.
Transfer Portal User Accounts
As I mentioned, in the past, contacts who were associated with portal users were "locked," and one aspect of that locking was that you could not change the account associated with them. This is no longer the case -- you can now transfer their accounts with impunity just by changing the Account Name field.
Merge Customer Portal Contacts
Let's say you have a contact with a Customer Portal user called Jim Smith, and someone goes and adds a duplicate Jim Smith contact. In the past, because of the aforementioned locking, you would be unable to merge the two contacts; however, now you can merge them like normal accounts, using the Merge Contacts button from the Contacts related list on Account.
You can find the full details of these and all the other Summer '09 features in the Summer '09 Release Notes. Hopefully the features I've described today will help you keep your Customer Portal a well-oiled machine.
-
New in Summer '09: Email Alerts For Case Comment Workflow
Jun 18, 2009Back in Winter '08 we turned on Workflow from Case Comments. That workflow allowed you to perform a field update on the parent Case. Because it is a "chaining" workflow, that means that you could send email alerts or outbound messages by creating another workflow on the parent case which would receive the changes from the Case Comment workflow and react to them. It was a little bit convoluted, but it worked.
Although having a field update capability from Case Comments was useful, many of the use cases for Workflow From Case Comments involved sending emails. As of Summer '09, you can send emails directly from a Workflow From Case Comments. Here's an example of how.
Let's say that I want to create a workflow which, whenever a new comment is submitted to a case, notifies the case team of that new comment.
My first step is to create the workflow rule:
I want any case comment to trigger this workflow, so I'm going to set my criteria to fire whenever a comment is created, and whenever that comment has anything in the body:
In the next step, I can now create an email alert:
Before finishing up this email alert, though, I'll want to make an email template that contains the body of the comment. The {!Case.Last_Case_Comment} merge field is really handy for this:
Finally, I can make my email alert. I want to set it to notify members of the Case Team where their role is Support Staff:
And that's all there is to it! Once I go back to the the workflow rule and click Activate, this workflow rule will fire whenever a case comment is added, notifying the Support Staff members of the case team with an email containing the comment body.
-
New In Summer '09: Salesforce to Salesforce for Cases!
Jun 11, 2009I'm plagiarizing a bit from my esteemed colleague Adi Kuruganti, but I have to trumpet this little nugget -- it's a key addition to the Service Cloud feature set. With Summer '09, specifically as of June 24, 2009, you will be able to share Cases and Case Comments via Salesforce to Salesforce. What this means is that if both you and a partner are using Salesforce.com for customer service, then you can share cases with that partner, and Salesforce.com will ensure that the data remains in sync.
For example:
I have a smartphone issued to me by my company's IT department, and our IT Helpdesk uses Salesforce.com to provide support to our employees. Now let's say that the mobile phone company we use also uses Salesforce.com for their customer service & support. When I have a problem with my phone, I can file a case with IT, and my IT can share that case directly with the mobile phone company using Salesforce to Salesforce. As the mobile phone company works the case, changes its status, and adds data and comments, the corresponding case in my IT Helpdesk will automatically receive those updates and comments. At the same time, my IT department can also collaborate and act on the case, and anything they do with it (any data that they choose to share, at least) will be automatically synced to the mobile phone company's case management system.
We have also posted a video demonstration of Salesforce to Salesforce for Cases for your edification.
Best of all, Salesforce to Salesforce is free to all customers -- it's just another thing that's included as part of the platform.
As I mentioned earlier, this feature will be enabled on June 24, the date on which all of our instances will have been upgraded to Summer '09. Salesforce to Salesforce is an incredible collaboration tool, the kind of thing you can only do with an on-demand system, and I hope to see many of you making use of it soon.
-
Service Cloud Basics: Web To Case
Jun 4, 2009It's been a little while since my last blog post -- I've been out speaking with customers about the Service Cloud. What better place to write a blog post, though, than on a plane? That's right, I'm writing this missive from 38,060 feet over Wisconsin on a Virgin America flight with Wi-fi. How about that!
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 our 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. You can find a quick start here on how to create a custom Web To Case form using Sites.
Bookmark