This page covers solutions to frequently asked questions regarding adapters built with the CTI Toolkit and the "demo adapter" simulator that Salesforce.com offers to simulate that functionality.
As of CTI Toolkit 2.0, there is a simple configuration option at Setup | Customize | Call Centers | Softphone Layouts that allows customers to configure whether and under what circumstances to pop Visualforce pages. Adapters built with toolkits prior to 2.0 will not be able to use this functionality.
Yes, it's described in the Developer's Guide. Here's an example.
Outside the Service Cloud Console, no. The call log that is shown below the CTI softphone is fixed and cannot be modified.
In the Service Cloud Console, the call log function is handled by the Interaction Log. The Interaction Log can be customized by the customer at Setup | Create | Interaction Log Layouts. So if a requirement is to have custom fields in the call log area, we recommend using the Service Cloud Console.
Outside the Service Cloud Console you can customize the adapter code to do that by simply setting the bCallLog variable to false when calling OnCallRinging and OnCallDialing.
In the Service Cloud Console that function is performed by the Interaction Log.
Yes -- wrap-up mode in the CTI Toolkit corresponds to the AGENTSTATE_WRAPUP agent state. Note that in the demo adapter, there is a menu option you can select to turn on wrap-up mode. This menu option can be seen by right-clicking the Salesforce.com phone icon in the system tray.
There is not currently a wrap-up timer, and you can't add one because wrap-up mode is basically an extended version of the call log interface, and as mentioned a couple of questions up, the call log is not presently modifiable.
No, that button cannot presently be hidden.
In the CTI Toolkit, when a call is transferred, the toolkit attempts to attach the contents of the call log to the call. Let's say User 1 has saved a Case, thereby attaching it to his call log, prior to initiating a transfer to User 2. When User 1 initiates the transfer, the CTI Toolkit will try to attach the ID of that case to the call. When User 2 receives the call, he'll get that attached data, and his softphone will pop on that data rather than that of the original call. His call log will also be default-populated with the information that was in User 1's call log.
This is all dependent on the fact that whoever wrote the adapter actually implemented the attached data facility.
Also, it is important to note that as with much of the functionality in the CTI Toolkit, this capability is dependent on the adapter developer calling the base class method when he overrides any functions of CCTIUserInterface. An example is given on this board post.
Adapters that receive an AppExchange security review approval will work with PE licenses. When a vendor achieves AppExchange security review approval, that vendor is granted a Client ID; when their adapter is recompiled with that Client ID, it will work on Professional Edition just as it does on higher editions, with no limitations on its functionality.
Yes, they work with Force.com licenses just as they do with Salesforce.com CRM licenses. There are no particular limitations that apply (except, of course, that the CTI adapter cannot pop any of the objects that Force.com license users can't see, like Lead).
A single adapter can be used across as many orgs as you want as long as the user is not logged into two or more orgs simultaneously. Simultaneous logins are not supported.
A single adapter can be used across as many browsers as you want as long as the user is not logged into two or more browser types simultaneously. This means that the user cannot be logged into salesforce.com on Internet Explorer and Firefox at the same time. Simultaneous logins are not supported.
The best practices for an upgrade depend on whether the update to the toolkit is a minor release or a major release.
For an upgrade based on a minor release, say from 2.01 to 2.02, agents need usually just update to the latest partner adapter. No update to the call center definition is needed. The adapter will be compatible with the call center definition as long as the toolkit that the adapter was built on is from the same major release as the call center definition.
For an upgrade based on a major release, say from 2.02 to 3.0, the following encapsulates best practices for an upgrade -
In your Visual Studio project settings, turn on "Treat wchar_t as a built in type," and then Rebuild All. That will fix it.
Only versions 3.x and under. CTI-4.0 does not work in Remote Desktop or Citrix Environments. Also, there are restrictions to the configurations in which CTI will work. CTI requires a desktop to be rendered. Therefore it cannot work in a pure terminal services or Citrix environment where there is no desktop. The reason for this is that shDocVw, the library used to interact with Internet explorer, requires a desktop. There are Citrix environments where the desktop is rendered. CTI does work in these.
A good way to test if CTI will work in your IT setup is to test with the demo adapter. If the demo adapter functions correctly, you can be assured that any partner's adapter will function as well.
CTI-4.0 will not work in certain terminal services, remote desktop or Citrix environments where ports are shared. This is because the CTI-4.0 adapter listens on a port, and another adapter instance cannot listen on the same port. .Net based "port sharing" (http://msdn.microsoft.com/en-us/library/ms734772.aspx) is an option to overcome this issue. However, it has not been tested with the CTI-4.0 adapter.
This can be done by using query based screen pop instead of search based.
For example, in the DemoAdapter, there is a “Call from IVR” option where we query based on the case number instead of searching for the phone number.
For querying, modifying the mapAttachedData allows you to specify the name value pairs of the fields you want to query on. In the code below, we screen pops based on the ANI for all cases that are in “New” status.
PARAM_MAP mapAttachedData; mapAttachedData[sKey]=sValue; mapAttachedData[L"Case.Contact.Phone"]=L"(415) 555-1212"; mapAttachedData[L"Case.Status"]=L"New"; std::wstring sCallObjectId = m_pUI->CreateCallObjectId(); int nLine = m_pUI->OnCallRinging(sCallObjectId,CALLTYPE_INBOUND,true,true,mapInfoFields,mapAttachedData);
The code above was used in the DemoAdapter.
The object is missing from your outbound softphone layout.
Go to Setup->Customize->Call Centers->Softphone Layouts. In the picklist at the top choose Outbound. Add Case (or whatever object it is you're dialing from) to the list of available objects. You'll have to log out of Salesforce.com and log back in again for that change to take effect.
If this customer has Professional Edition, see the next question.
If this customer has Enterprise Edition or higher, have them have a look at the Profile associated with their User record. In that Profile you'll find a field called "API Enabled." If that checkbox is turned off, then CTI won't work.
To make your adapter work in PE, you need to pass AppExchange security review. When that is complete you'll be granted a special Client ID. Once you have been granted a Client ID, specify it with CCTIUserInterface::SetClientId in the first line of your Initialize method, before calling the base class Initialize method. This will allow it to function in Professional Edition.
Unfortunately, although the backend code is there (which is why it's in the docs) the user interface of CTIComboBox was never implemented, so it is non-functional as of this writing.
Yes, it will compile fine, but you'll have to create your own VS project files for it. Note that as of 1.50 the CTI Toolkit is no longer supported in VS 2003 and prior.
This is a known issue with the CustomSetup table we save those settings to, and there's not an easy fix for it, or else we would have done it already. Login credentials are only saved for those users with the "Customize Application" profile permission. We plan to move the credentials into the Windows Registry instead under HKEY_CURRENT_USER, but we will not do so until a later release of the CTI Toolkit. You can implement it sooner if you want, it is quite simple.
To do this, you can provide an overrided version of CCTIAppExchange -- just make a subclass of it and override CCTIUserInterface::GetAppExchange() to return your subclass instead of the base class. In your subclass, override SaveUserParams and LoadUserParamsFromCustomSetup to save them to and load them from the Windows registry instead. That will fix the problem.
Firefox 3.6 was not yet available at the time CTI Toolkit 1.54 was released. The CTI Toolkit 2.0 supports Firefox 3.5 and 3.6. To attain FF 3.6 support, upgrade to CTI Toolkit 2.0.
If the CTI adapter is emitting strange errors like "The requested lookup key was not found in any activation context," one potential source of this issue is a proxy configured with WPAD (otherwise known as an autoproxy). WPAD is not presently supported by the CTI Toolkit due to lack of support for WPAD in its underlying library. The workaround for this is to turn off WPAD and configure the proxy manually on the machine.
Another source of "The requested lookup key was not found in any activation context" is a corrupted install of Internet Explorer, usually due to an upgrade from IE6 to IE7 or 8. If this occurs one possible solution is to retry the install of the new version.
Cryptic errors like "Unknown Exception in SyncRun::Api Request," can be generated if:
When you create an application with an embedded browser, you must choose to expose that embedded browser if you want external programs like CTI to be able to find it. To expose the embedded browser, you must turn on the RegisterAsBrowser setting on it. If you do not have the source code for the application embedding the browser then the company that produces the app must make this modification for you. There is no other way to make the embedded browser discoverable to the CTI adapter (or any other program for that matter).
The problem that is presented by some CTI adapters is that they create a closed task after a call has been ended but at the same time that a user is editing the parent record in the UI. In essence, the system sees the user touching the System Modstamp twice at the same time, which is not possible, and then erroneously displays the Last Modified By user as a colliding user. This same explanation applies to collision errors encountered when closed tasks or events are synced from Outlook/Lotus Notes while a user is editing the parent records in the UI.
[Note that this only applies to the following objects: Lead, Account, Contact, Opportunity, Campaign, and Contract. To extend this workaround to custom objects, the customer has to update the Apex trigger themselves]"
You can download the Apex as an Appexchange package here.
The “2.0 or Higher” settings appear in the softphone Layout when there is at least one Call Center in your org whose version is 2.0 or higher.
Provided you have an adapter built with the CTI Toolkit 2.0 adapter, you'll need to go to Setup | Customize | Call Center | Call Centers and import the XML setup file included with that adapter; then create a new Call Center Definition. If you are upgrading from an older version of an adapter, import the XML that came with the new 2.0+ adapter and set it up accordingly, and then remove the users from the old call center and add them to the new one. Then these settings will appear in the softphone layout.
You may have installed the CTI Toolkit instead, which is intended for people who are building their own adapters. Instead, install the Demo Adapter from the link here.
In addition to installing the Demo Adapter, it is also necessary to make some minor configurations to your Salesforce.com org to make it work. Make sure you have set up Salesforce.com properly by adding the call center definition file and has added himself to the call center. Here's a handy tip sheet on setting it up.
The Demo Adapter will only work in IE6+ or Firefox 3.5+ with the necessary add-on Salesforce.com CTI 3.0 add on. It will NOT appear in Chrome.
Are you using Professional Edition? The Demo Adapter only works on Enterprise Edition and up. Vendors' adapters can work in Professional Edition though -- this simulator just doesn't.
This was fixed way back in version 1.13 of the Demo Adapter. Install the latest Demo Adapter and you'll be good to go.
This error means that the Office Toolkit DLL, SF_MSApi4.dll, has not been installed or properly registered. Search "Unable To Start The Office Toolkit." in Salesforce.com Help & Training for troubleshooting steps.
This error means that the XML subsystem, MSXML6, has not been installed or properly registered. Search "Unable to start the Softphone XML subsystem." in Salesforce.com Help & Training for troubleshooting steps.
This error means that the adapter DLL has not been installed or properly registered. Search "An adapter for your Call Center was not found or could not be started." in Salesforce.com Help & Training for troubleshooting steps.
An exception to this is when using CTI in the Service Cloud Console. We always screen pop within the console context, since none of the agents work is lost by the pop.
Chances are you are using 32 bit IE on Windows 7. CTI works with 64 bit IE only. To use 64 bit IE -
CTI is supported in the following browsers
Computer-Telephony Integration (CTI) 4.0: Multiple Browser Support Available in: Professional, Enterprise, Unlimited, and Developer Editions Salesforce CRM Call Center seamlessly integrates Salesforce with third-party computer-telephony systems. With Winter '12, developers and partners can use a new CTI Developer's Toolkit to build CTI adapters that work across multiple browsers, such as Internet Explorer, Firefox, Safari, and Chrome—without any browser plug-ins and with smaller adapters that reduce complexity.
This question must be answered by your company's internal IT policy. CTI-4.0 communicates over HTTP with the CTI adapter. However, all communication is restricted to messages originating from the "localhost" domain. This means that only requests originating from the users computer, or "local" requests, will be acknowledged and processed. All other requests will be ignored. This includes requests from within the company network (intranet) or beyond the company network firewall (internet). In this way, the information passed between the browser and the adapter is secured.
In certain cases there may be a need to secure CTI communication via HTTPS. The CTI-4.0 Toolkit does respect HTTPS. For this, the customer must generate a security certificate for the localhost domain and bind it to the SalesforceCTI listener. This is sufficient for Internet Explorer. For Firefox and Chrome, the certificate might need to be imported into the browser's certificate store.
It is the recommendation of salesforce.com that the CTI adapter be HTTPS enabled.
This warning is a "Mixed Content Warning". It indicates that you are accessing salesforce.com over HTTPS, but communicating with the CTI adapter over HTTP. To resolve this issue, please see the preceding question on "Do I need HTTPS with the CTI Adapter".
The warning can also be disabled using the following steps -
It is the recommendation of salesforce.com that the CTI adapter be HTTPS enabled.
CTI-4.0 is compatible with most modern (HTML5 enabled) browsers. There are 2 requirements for a browser to support CTI-4.0 -
The following list of browsers are supported by salesforce.com for CTI-4.0:
While we do support IE8, and Firefox 3.5 performance is significantly improved in browsers like
It is recommended that CTI-4.0 be used with browsers in the above list.
No. At the moment, the softphone can only be run in one browser at one time. This means that the softphone cannot be run with Firefox Chrome or IE at the same time. Agents must log into the softphone with one browser only.
This is because each browser experience with salesforce represents one user session. Logging into the softphone in both IE and Chrome represents 2 user sessions. Currently the CTI adapter can only support 1 user session at a time. The behavior of the softphone in this scenario is not defined.
A possible cause of this is that the XML subsystem, MSXML6, has not been installed or properly registered. Search "Unable to start the Softphone XML subsystem." in Salesforce.com Help & Training for troubleshooting steps.
This is definitely a challenge, and salesforce.com continues to evaluate ways to help partners resolve this.
The root cause of the problem is that the 4.0 adapter is running a port listener on localhost. This listener passes all the messages between the adapter and softphone in the browser. This works fine as long as all the communication is in http.
Unfortunately when it comes to HTTPS, things get a little tricky. HTTPS needs a certificate to encrypt and decrypt communication, and that certificate is issued to each domain. However, the domain here is localhost. There's no way for salesforce.com to issue a certificate for localhost out of the box. That would not be technically feasible (since there's not way for salesforce.com or any other certification authority to verify all communication over localhost).
This means that the certificate must be generated during deployment. What some partners have done is to create a batch script, which installes a pre-created cert on each machine that CTI-4.0 is deployed to.This might be a route to consider.
There are 2 useful resources for this. You've seen the note on httpcfg in the dev guide. Have a look at this link. It contains the basic steps that would be in the batch script.
With CTI-4.03, a new pop-up window was introduced for the Firefox and Chrome browsers. This pop-up window is responsible for maintaining a connection between the CTI adapter and the browser. Don't close it!
Internet Explorer doesn't need the pop-up. The adapter communicates with IE using COM, a Windows technology that allows the adapter to speak directly to IE. Not seeing the pop-up in this case is expected behavior.
Most likely you have you Pop Up Blocker turned on. Disable it for salesforce.com. To do this -
The next time you log into salesforce.com, you will see the pop-up.
When exiting salesforce.com, it is always good practice to exit the CTI adapter as well. To do this -
It's also good to exit the adapter when you leave for the day. The adapter uses a regular network connection to communicate with the browser for the most part. A network disconnect might lead to an inconsistent state that would be a surprise the next morning.
With version 23, Firefox introduced a mixed mode content security warning similar to IE. You can find more here. This prevents CTI adapters communicating with the browser on http from functioning.
Note, CTI adapters communicating with the browser on https do not experience this.
To resolve the issue, simply allow mixed content for salesforce.com. This can be done with the following steps -
Alternatively you can also disable the feature entirely via the following steps -