The Interaction Log (IL) was designed to take quick notes on a customer interaction. It's a virtual "post-it" for the Console workspace that can serve as a scratch pad or to create reminders for the agents. Agents may not always use it, and when they do, it should serve to capture light, unstructured data. Relevant, structured information must be captured in the correct parent salesforce.com object, such as Cases, Contacts or Opportunities.

There are certain use cases however, where the IL can go beyond just taking notes. It can serve as a key part of a business process, capturing summary information on the interaction itself. The interaction duration, disposition, channel, campaign and next response time are examples of this. Auto-populating such information and automatically saving the IL allows the agent to focus on the interaction and note taking without additional overhead.

One such use case of capturing summary information is Computer Telephony Integration (CTI) integration. With CTI, calls can be handled directly from within the salesforce.com experience through a softphone.

The out of the box Console Interaction Log provides some of the information capturing mentioned above. For active calls, the IL of a newly opened workspace associates itself with the call, unless the call has already been associated with another IL. It then stores the call disposition, duration, call type and call object identifier and saves itself at the end of the call. All of this is behind the scenes, saving a new task record for every call. The fields displayed on the IL are also customizable, adding to its flexibility.

Service Cloud Console Interaction Log and CTI Softphone

With Spring '12, "Primary Tab Components" (PTCs) introduce the ability to build your own interaction logs, with complete control of the interface and a set of Toolkit methods that deeply integrate with the Console and CTI softphone. In case you are asking yourself this already, the table below lists compares the benefits of a custom interaction log against the standard Interaction Log.

If your business process requires capturing complex customer interaction data, or a deep integration with CTI, a custom IL is the right option for you.

A Sample Custom Interaction Log

The IL described below is intended to show the ease with which a custom IL (CIL) can be created. In terms of functionality, it is at par with the standard IL. Additionally, it has deep integration with the CTI softphone to illustrate the use of the APIs described above.

The use case considered here is focused on customers calling in about existing cases. Case identification information is entered via the IVR. The agent records summary information for the interaction and processes the customer request. Occasionally a new case must be created.

An image of the custom interaction log is shown below. The CIL is oriented as the left sidebar component. The case detail is oriented to the right. This ensures that the softphone and CIL don't overlap, allowing the agent to interact with both at the same time.

A Custom Interaction Log (CIL) as a left workspace component.

Setup

A custom interaction log is built using Primary Tab Components. These are components that can be added to Console Primary Tabs which persist across subtabs for that primary tab or workspace. Setup comprises of 2 steps

• Create CIL Visualforce page
  • Setup -> Develop-> Pages. Code for the Visualforce page used in this blog is available here
• Add CIL Visualforce page to page layout for the salesforce object tied to the interaction log
  • In our use case the interaction log is relevant only for the Case object. We add our Visualforce page as a Primary Tab component to Case Page Layout. Go to Setup-> Customize-> Case -> Page Layouts-> #YourLayout ->Custom Console Component

    
    
    

     

    Link to Custom Console Components

  • Add your component (the CIL Visualforce page)

    
    

The Visualforce page and corresponding Apex Controller have been included at the end of this blog.

The Custom Interaction Log

The noteworthy parts of the CIL are described below.

The Apex Controller & Visualforce Page

The CIL Visualforce page uses a small Apex controller class for persistence. Our CIL is associated with 3 salesforce.com objects -

• A task that stores the CIL information
• A case that represents what the CIL was associated to
• A contact that represents who the CIL was associated to

Task fields such as task subject are initialized with default values that can be updated by the agent. For example, the task subject is initial text concatenated with the current time.

Subject = 'Call at ' + DateTime.now();

Association of CIL with Case and Contact

Since our CIL Visualforce page is using a standard case controller and is in a case primary tab, we automatically have all the case information available. We look up the contact on the case and initialize the task with both pieces of information. The case forms the "What" of the task, and the Contact the "Who".

The Custom Interaction Log with default Subject, association with Case and Contact

Associating CIL with Focused Subtabs

As the agent move from one subtab to the other, a CIL should be able to follow and update its association with the currently focused subtab. For example, if an agent moves from one case to another, the CIL should understand that the last case is most like associated with the call. In our use case, the agent may resolve duplicate cases, navigating to other cases under the same contact. The onFocusedSubtab Console Integration Toolkit method provides a handy way to listen to the focus event of subtabs (fired when an agent moves, or shifts focus, from one subtab to another).

sforce.console.onFocusedSubtab(onFocusedSubtabCallback);

The callback of onFocusedSubtab () is passed the object id of the subtab which is currently focused. We can now check to see if it is a case subtab the agent is looking at, by inspecting the id of the object. If it is a case, we update the CIL Who and What association with the newly focused case and its contact.

Integrating CIL with the Softphone

getCallObjectIds

In most cases, incoming calls screen pop (open a new window) associated salesforce.com objects. For example, an incoming call might cause a screen pop of the contact who is calling. In the Console, a screen pop opens a new Primary Tab.

In our example, customers provide case IVR information, namely the case number. We screen pop the case for the agent when the call begins. At that time, our CIL has the opportunity to associate itself to the current call. This is done using the getCallObjectIds method. The method returns a comma separated list of all the Call Object Ids of current active calls in the reverse order in which they arrived. So the first call in the list is the most recent.

When the screen pop occurs, the related case primary tab is opened. The CIL is also opened alongside the case. To associate itself with the current call, it invokes the getCallObjectIds methods to get the currently active call. It then associates itself with the call by setting the task CallObject to the "callObjectId" of the active call. The callObjectId is a unique identifier for every call received by the salesforce.com CTI softphone.

getCallAttachedData

The getCallAttachedData gets all the call data passed with a given call from a salesforce.com CTI adapter. A salesforce.com CTI adapter is any adapter that uses the salesforce.com CTI Toolkit (more information can be found here). Call data is any data passed by telephony system to the adapter, like the ANI, DNI, ECC data etc. It can be passed to the console by populating the mapAttachedData map.

The getCallAttachedData method requires a callObjectId to identify the call from which to retrieve data. In this example we use the getCallAttachedData call to acquire the ANI, which is then saved to a custom field in the Task object.

NOTE – The ANI field is a custom field created for the purposes of this article. To enable the setting of the ANI in the code below, the following steps are needed

• Create the custom "ANI" field of type "Phone" on the Task object
• Uncomment the following lines
  • Controller
    //task.ANI__c = ANI; (occurs in 2 places)
  • Visualforce page
    <!-- apex:inputField value="{!task.ANI__c}"/> -->

onCallEnd

When the current active call ends, information such as the call duration and disposition can be obtained via the onCallEnd listener. This is also the point when a CIL should auto-save, to ensure that all information captured thus far is recorded.

onCallBegin

It is possible that an incoming call may be relate to a case that is currently already opened in the Console. An example of this would be during a customer call back. In such a scenario, some event is required to associate an already opened or previously associated CIL with our new call. The onCallBegin method serves this purpose. The event provides the callObjectId of the newly active call.

sendCTIMessage

A method not covered in this article is the sendCTIMessage API. It allows the console to pass standard as well as custom messages to the adapter. This is very handy when you want to implement a complex telephony control in the CIL, such as dialing lists, dependent picklists, wizards etc.

The API methods described enable the development of a fully custom IL. It is easy to associate the call log with the focused subtab. The same with CTI; your CIL can closely integrate with the CTI adapter to capture the critical telephony data you need. More methods will be added to the Service Cloud Console Integration Toolkit through future releases.

If you have any questions or feedback about custom interaction logs, please feel free to reach out to myself or Michael Ramsey. We would love to hear suggestions about other Service Cloud blog topics as well.