You can integrate your telephony system with NexJ CRM in order to take advantage of the contact center functionality.
After the telephony server, the application server the NexJ application is running on, and the push redirector have been integrated, they can route, handle, and display inbound calls to NexJ CRM users.
For complete integration, you must first ensure that system prerequisites in NexJ CRM are met. Then configure your telephony system to communicate with the
call:InboundCall SOA service.
Inbound call handling
When a user answers a call, NexJ CRM automatically creates a dedicated Inbound Call workspace. In the workspace, a user can review the caller's details and record information about the call.
The following diagram illustrates the path that inbound calls follow from a telephony server to NexJ CRM:
The server component of an IP-based telephony system. The telephony server notifies the application server of inbound calls and call details.
The server that delivers NexJ CRM to the user.
The server that sends an inbound call notification message to the user's browser, which then displays a notification beacon to the user.
The CRM application running on the user's desktop.
The following actions occur as the system routes, handles, and displays inbound calls to users:
When a user answers an inbound call, a Remote Procedure Call (RPC) message is sent from the telephony server to the application server. The message identifies the user who answered the call, the telephone number of the caller, and other relevant information.
RPC messages can have more than one source. As long as a message source is authorized, it can send a message to the application server.
- The application server sends a notification about the user being called to the push redirector.
- The push redirector displays the notification beacon. The beacon appears as the flashing telephone icon in the user's application toolbar to indicate that inbound call information is available.
When the user clicks the telephone icon, NexJ CRM creates a User Call State record and displays a new Inbound Call workspace. NexJ CRM uses information from the RPC message to identify the caller and retrieve their information.
A user can have multiple Inbound Call workspaces open. This allows the user to record all desired details about a call before saving the final record.
To end a call, the user hangs up their phone. The telephony server sends a message to the application server to indicate that the call is disconnected. The details of the call are then cleared from the User Call State record.
User call state record
Details for inbound calls are stored in the system in a User Call State record. The User Call State record contains the following fields:
User Call State record fields
|User||The call center agent (NexJ CRM user) receiving the call.|
|Has the user clicked the beacon||Whether the telephone icon for an inbound call continues to flash. If the user|
has not clicked the icon, then it continues to flash. If the user has clicked the
icon to answer the call, then it no longer flash.
|Phone Number||The telephone number of the caller. The number is used to perform a contact|
search that matches the caller to an existing contact
|Status||The call state of the user. There are two states:|
Set when a user answers an inbound call and the telephony server
sends a message to the application server to indicate that the call is
Set when a user hangs up their phone and the telephony server sends a
message to the application server indicating that the call is disconnected.
|Call Reason||A code used to retrieve the appropriate call script. The call reason is typically|
mapped from the sequence of numbers dialed by the caller through an
interactive voice response system (IVR).
NexJ CRM populates the User Call State record and sets the status to Connected when the telephony server indicates that the user has answered a call. When the application server receives a message from the telephony server to indicate that the call has ended, the call details are cleared from the User Call State record and the status is set to Disconnected. The User Call State record always retains call details until a call is disconnected.
The User Call State record can be modified at design time to accept additional information. The information is passed in the inbound call message and stored in the User Call State record. For example, the User Call State record can be modified to store telephony details and information gathered by the IVR, such as the user's account number, what telephone number the caller dialed, and whether the user is authorized by the IVR.
Computer telephony integration requirements
As part of the integration process, you need to define and configure certain information in NexJ CRM, NexJ Admin Console, and NexJ Studio.
In order to be able to access the Inbound Calls workspace and to view the new inbound call notification beacon, you need to assign each user the gCallUser privilege, using NexJ Admin Console.
The user's login ID needs to be included in the communication from the telephony system. The user's login ID is mapped to a user's record using NexJ Admin Console.
Call scripts and contact center reasons
When a user answers an inbound call, a call script automatically displays in the Inbound Call workspace in NexJ CRM. Each call script is associated with a call center reason. The choice of which script displays is based on the unique reason ID included with the telephony information received by NexJ CRM.
A default "General Inquiry" call center reason has already been created. You need to define a default call script and associate it with that reason. You can also create additional reasons and scripts, depending on your business needs. If a reason ID is included in the communication from the telephony system, then the associated script will automatically display when the user answers the call. If no reason ID is provided, then the “General Inquiry” reason will be used and the default script will display when the user answers the call.
Define scripts and reasons using NexJ CRM, in the Call Management tab on the Customize workspace.
When an inbound phone call is received, a telephone icon flashes in the application toolbar on the user's desktop. To enable this functionality, ensure that push notification is enabled for NexJ CRM. For more information, see Push server configuration.
call:InboundCall SOA definition
The call:InboundCall SOA service provides the only interface between your telephony system and NexJ CRM.
call:InboundCall interface receives and processes the information from the telephony system. It uses the
updateCallState method to update the call state information for the call. The telephony system must provide the following information:
The login name of the currently registered user. It is passed to the
The status of the call. The possible values are CONNECTED and DISCONNECTED. The value is passed to
call:UserCallState class. The CONNECTED status indicates that the call has been assigned to the user and the user is available to take the call. The DISCONNECTED status indicates that the call has been disconnected by the caller.
The inbound phone number. This phone number is used to search either in the
searchableAddress attribute or in the
address attribute of the
Telcom class to identify the contact who is making the call. The value must be provided as an unformatted telephone number.
The reason ID that indicates which call script will be used when the inbound call is answered by the user. The ID should match a value from the call:CallReason class and is then passed to the
call:InboundCall class to identify the script.
The telephony system should send the JSON message to the following address: <
hostname>/<context>/soa/nexj:call:InboundCall:1.0/json-rpc. For example,
To indicate an inbound call, your telephony system must send the following information in the JSON format:
Inbound call without a reason
To indicate an inbound call without a reason specified, your telephony system must send the following information in
the JSON format:
To indicate a disconnected call, your telephony system must send the following information in the JSON format: