If you’ve implemented Salesforce Live Agent, or are about to, you have probably looked at all the declarative options from the Setup pages related to Live Agent. But what more can you do to help agents reduce clicks or to accomplish common goals such as ensuring a case is always created for the chat interaction?

Remember, the Salesforce1 platform is an “API first” solution. Most product features are also exposed via an API. For example, with two lines of code you can capture the URL of the page the customer was on when they initiated the chat request, and save that URL in a case field. Does this sound like functionality you could use? Let’s do it. This article assumes you have read the first part of this series: 4 Tips for Implementing Chat as a Support Channel and completed the agent side configuration in the console.

Set up a test chat page

First let’s create the base client side JavaScript code using Live Agent configuration.

Go to Setup | Customize | Live Agent | Deployments to create a new deployment code. This is what the code looks like from the configuration wizard when you save the setting.

Next, go to Setup | Customize | Live Agent | Chat Buttons and Invitations to create a new button code. This is what the code looks like from the configuration wizard when you save the setting.

Note your Organization ID, deployment ID and button ID will be different.

And that’s all it takes to set up a test chat page. The deployment code references the Live Agent JavaScript library and initiates the request to the chat server. And button code, well, displays the button and set up the click event to launch chat window. You can copy and paste these two segments of code to a blank text file and save as HTML on your desktop, double click the HTML file and browsers will just run the file for you from desktop. The test page code looks as simple as this.

Notice I uncommented the “Offline Chat Content” from default code. For a test, I want to see the offline message to verify Live Agent code is actually running even if there is no agent available.

Now log in as a chat agent from your service cloud console, next thing you know you are chatting with yourself. Isn’t that fun? This is what I always recommend in Live Agent implementation – test the deployment code and make sure it works before implementing it in your web pages. You don’t have to set up a server first to test the chat configuration.

Automatically create a case

Now that we have a base chat page set up, let’s do something cool. Remember we said a common request was to always create a case, let us add a line in the deployment code, after the “init” method.

And I am sure it would help if we actually load the case record when agent starts the conversation. Might as well attach the chat transcript to the case too.

See what we did? With two lines of code, we actually created the case, loaded the case for agent in the console, and attached the transcript automatically. We also bypassed one screen as well. If you use the OOTB open new case option in the console app, an agent will have to manually select case record type then open a new case. Now, it will be defaulted to the case record type that is set in the agents’ profile. BTW, don’t forget to uncheck the New Case setting in the console app for Live Agent since you have already created a case automatically.

Preset fields with values

While we are creating the case, it makes sense to preset some of the case fields, you know, especially some fields in which the agent would always use the same value for. Case Subject and Origin come to mind. The Live Agent JavaScript API has a “map” function that can be used to set the custom detail variable on a case field. Using the “addCustomDetail” method first, and then use the “map” function to assign the value to a case field can do this.

Let’s do something dynamic. One of the most commonly requested features in Live Agent implementation is to capture the URL where chat is initiated and store that URL in a case field. To accomplish this, let’s first create a case custom field and name it “Chat_Request_Page__c”. Then we can pull the URL value from the “DOM” property of the page and pass the URL to the custom field.

As I promised, two lines of code to capture URL and pass it to a case field!

What else can you do?

With the Deployment API offered by Salesforce1 platform, you can use similar mechanism to enable your agents like never before. How about setting a dynamic subject based on where that page is, so knowledge one widget can preload the most relevant articles for the agents? Or perhaps passing over customer’s shopping cart data to a case field and know how much value you may potentially save with this chat engagement? If you don’t know what the customer is thinking at the moment, at least you can tell what’s in their shopping cart.

In summary, we showed examples what you could do without even leaving the page where chat button is embedded. In the next blog, we will show you what can be done with an extra Pre-Chat form. See you next time.

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS