Solution Reference

This document is a technical solution description of CIM providing brief details on the product features and architecture with all necessary solution prerequisites


Customer Interaction Manager (CIM) acts as a single repository to store customer interactions. It receives and retains all interactions of a customer with the call center for tracking a 360-degree view of a customer journey. It provides interfaces to capture real-time and historical information for callers/customers. Administrators can define and extend the contents of the customer and request objects, attaching fields and information to them as per their requirements.

Business Features

Customer Profile & Screen Popup

In CIM, a person approaching the contact center for a query through any channel is a Customer.  The schema of the Customer object is extendable so in addition to some predefined attributes, an administrator can also add more custom attributes based on their business needs. This helps to define what data each company would like to store for its customers. Customer attributes with the following data types can be defined:

  • Text: This could be any string up to 1000 characters long. 
  • Phone: This is to store any additional phone numbers of the customer 
  • Email: This stores the Email ID
  • Date: This could be any data of type Date.
  • DateTime: This could be any data of type DateTime. 
  • URL: This could be any data of type URL.
  • Bool: This could be any data of type Bool. This can correspond to any flag which is either set to 'true' or 'false'.

Authorized users can upload and manage customer profiles. Customer profiles can also be imported in bulk using CSV files. 

When a customer call lands on Cisco Finesse, the CIM application automatically looks up the customer profile based on the ANI and pops up the right profile in front of the agent (if the customer already exists). If it does not find any matching record, it provides the agent with the interface to create a new profile itself for the customer on call. 

CIM also exposes APIs for third-party applications to read and push data from/to CIM. So the agents can avoid switching screens between the CRM and Finesse desktop to view the complete customer profile while dealing with the customer call. 

All customer records are listed on the Customers List page with filtering, sorting, searching capabilities. 

With the Customer list, you can:

  • Drag n drop columns to reorganize the list view. Each column here represents one attribute in Customer schema.
  • Sort the customer list (ascending/descending) based on any column by clicking on the ascending/descending arrow icons. By default, the list is sorted based on the creation date of the record in descending order; i.e. the latest created being on the top.
  • Page-wise navigation with the page index of the current page
  • Resize columns, change the width according to the view preferences  
  • Column search. Search based on multiple columns is not yet available.

  • At a time, 100,000 customer records can be imported via CSV.
  • The bulk import operation should only be performed in off-peak hours. 
  • CIM currently only supports up to 50 custom attributes
  • Two customers with the same ANI/phone cannot exist. Each customer in CIM is supposed to have a unique Phone number. A phone number can be duplicated among all phone numbers of a single customer but cannot be duplicated across different customers. 
  • If a new customer record with a different name but with the same existing phone number is created, the existing customer profile will be overwritten/replaced with the new customer profile.


CIM stores customer's interactions as they interact with the Cisco call center. This includes both IVR, agent-based voice interactions. 

Therefore, each time when the customer calls in, the CIM agent gadget is automatically loaded with the customer's profile and its previous interaction history. At the end of the active call, the call is automatically linked to the already popped up customer profile. However, agents also have the capability to change the association and link the call to another, most appropriate customer based on the conversation with the customer. 

This way, while dealing with the customer, agents become fully aware of the customer's recent interactions and see why and how repeatedly, the customer had called in the past.

Each interaction is made up of smaller units, called Activities. A CIM activity could be: 

  • An IVR leg in a parent call
  • An agent-transferred call leg (this includes IVR- Agent, Agent-Agent transfer)
  • Wrap-up added by agents to a call

On the Interaction History gadget, you can expand to view all activities tied together in an interaction. 

The following details are available on the interaction history view:



Customer Profile 

Lists the complete profile of the customer in a collapsible mode 


This shows the date when the call was received while individual times in each activity shows the start time of the activity. 

ANIThe phone number of the customer from/to which the call was received/ initiated

Call Wrap up(s)

Finesse Wrap-ups provided by each agent in the call.

Duration The duration of the interaction bar shows the total duration while the duration for each individual activity is also shown under the activity details
Call TypeShows with an arrow if the call was INBOUND or OUTBOUND. The arrow direction is inward to show an inbound call and outward to show an outbound call.
Interaction TypeThis shows, "Finesse" in case if the call includes all agent activities; i.e. if the call was transferred to an agent. Shows "IVR" if the call includes IVR activity only. 

Agent ID

This shows the ID of the agent who handled the call.

Team NameShows the name of the team to which the agent belongs 
Agent Extension Shows the extension of the agent under details of the Agent Activity 

Start Time

This shows the time when the call was landed on the Finesse desktop

CIM also exposes APIs for third-parties to push an interaction to CIM. 

  • In the case of call transfer, the interaction context is not transferred yet. This also means that if the agent A has changed the link of the active interaction to a different customer based on his conversation with the customer, the Agent B to whom Agent A had transferred the call, won't be able to see the updated customer link. 
  • If an agent applies multiple wrap-ups during a call, the most recently applied wrap-up will be recorded at the end of the call.
  • At the moment, the application does not store any barge in, consult and silent monitoring call legs or activities as part of the customer interaction. However, it stores call conference, call transfer activities as part of the interaction.

Click-to-dial call

Agents can manually initiate a call to a customer while viewing their profile.  

Outbound calls are also stored as the customer's interaction history and available to the agent for subsequent interactions.  

  • Manual Outbound calls are initiated through Finesse. So the user must have to be on Finesse to use this feature.
  • Screen popup does not happen in the case of dialing a call manually
  • Automatic Screen popups work in case of campaign outbound calls


Agents can also manually initiate an SMS to a customer while viewing their profile.

The sent messages also become a part of the customer's interaction history.

Customer Labels 

A label in CIM is considered to be a list or a tag assigned to a customer. Customers can be segmented or divided into groups and assigned specific tags. Hence, based on the tag assigned to the customer, different business decisions can be taken such as priority call treatment, blacklisting a customer or routing the customer request to an expert queue. A label has a name and an optional color attribute.

Extend Customer Object Schema 

Add custom attributes to the Customer object based on your business needs. 

System administrators or users with an “Admin” role can extend the schema of the Customer. The user can add as many as 50 customized attributes to store information of their customers based on the needs of the business. 

The attributes in the schema can also be re-ordered to change the order of the display. The order changes from here affect the order in which the fields are shown in the Customer Profile View.  


  1. Customer call rings on Finesse Agent Desktop.

  2. The application looks up the customer record based on the ANI. 

  3. If a matching record is found, the customer profile is popped up in front of the agent and gets linked with the matched customer record automatically. The agent accepts the call. To link the call with a different customer, the agent can choose the right profile from the Customer list sidebar and click the Link button.
  4. If no existing record is found against the ANI, the application provides the options to choose an existing customer manually or create a new customer profile. To link the call with an existing customer, choose the right profile from the Customer list sidebar on the Interaction History page and click the Link button. 

If the agent or supervisor does not accept the call (after the call has landed on the Finesse desktop), the interaction is still stored in CIM, tagged with the agent name to whom it was routed.

Solution Architecture

CIM Profiles & Interactions mainly consist of the following objects:

  1. Customers -  A person approaching the call center through a call center channel is identified as a Customer

  2. Interactions - An Interaction stores information about the communication taken place through the respective channel

All client applications including IVR, Finesse gadgets, and 3rd party applications access CIM via REST APIs to fetch and store information from/ to CIM.

Deployment Models

Non-Redundant/ Simplex Deployment

For a non-redundant deployment, the application Docker images are deployed on a single server without with a single point of the application failure.

Application Deployment Architecture 

For HA, ExpertFlow deploys the solution on two VMs as Docker containers using Docker Compose. If one VM goes down, the traffic will be routed to the other VM.

Each solution component is deployed as a stateless microservice in its own Docker container. Expertflow opted for a service-per-container paradigm in which each backend microservice is executed in its separate container.

Each Docker container is deployed with the “Restart Always” policy which causes it to restart automatically on the same VM. Notice that there might be a downtime of a few seconds while restarting the container. This implies that any requests received during the downtime will be rejected. 

Services will be available via a virtual IP. If one of the VMs goes down, the virtual IP will route the traffic to the other VM.

Source page access restriction: Click the link below to check if the page is accessible.

MongoDB Deployment Architecture 

MongoDB is deployed in a Three-member replica set with a Primary, Secondary, and one being Arbiter. The Arbiter node does not replicate the data. Its purpose is to participate in the election process while electing a primary node. Elections occur when the primary becomes unavailable. The remaining nodes in the replica set, i.e. arbiter and secondary nodes call for an election to select a new primary so that the cluster resume normal operations. The failover from primary to secondary happens nearly seamlessly.

Database Fault Tolerance

When the Primary or Secondary node is down

The system will switch to the other active node.


All applications will continue to work after the seamless failover.




All applications and services will not work.


Manual intervention is required to recover the system.

When primary or secondary CIM datastore is down

The load-balancer (Arbiter) elects the datastore instance on the other node as primary.


All read/write operations on the CIM datastore will continue to function seamlessly.



When primary and secondary CIM datastores are down


All read/write operations on the datastore will fail.


Manual intervention is required to resume the datastore operations.

When CIM primary data store and the Arbiter are down


All write operations on the primary datastore will fail. The read operation (if configured to be read from secondary DB) will continue to work normally.


Manual intervention is required to resume the datastore write operations.

CIM secondary data store and the Arbiter are down


All write operations on the secondary data store will fail. The read operations will continue to work normally.


Manual intervention is required to resume the datastore write operations.

The Arbiter is down


All read/write operations on the datastore will continue to function seamlessly.



Solution Security

Permissions-based User Access

ExpertFlow applications have a central authentication module that automatically synchronizes contact center supervisors and agents from CCX/E into the User Management module. This allows any contact center user to log into the application using the same Finesse credentials without the need to recreate the user credentials in the application again.

With the latest version, the application also allows administrators to create local user accounts for supervisors or/and agents with a user-defined password and username. Restricted permissions on the level of entities allow administrators to assign selective privileges to a particular group of users.


  • Currently, the permissions can only be granted on selective lists/entities. More granular permissions on the level of selective fields or certain data cannot be granted.
  • The password reset option is not available for local users. If a local user has forgotten his password, he needs to request the admin to create a new account to get logged in. 

HTTPS Support

For HTTPS support,  provide a valid certificate from a certified Certificate Authority (CA).

Solution Prerequisites

Hardware Sizing

The following lists the machine specifications for up to 100 concurrent agents deployment.




2 cores 

8 GB

1x100 GB

To support HA, the same specifications would be doubled for the two machines for a redundant deployment.

To get machine specifications for a larger agent volume and/or with other ExpertFlow products in a co-resident deployment, please check here.

Software Requirements

OS Compatibility

One of the following OS software is required on the server:





7.x updated to the latest packages (use Yum update)

Administrative privileges (root) are required to follow the deployment steps.

Internet access should be available with inbound connections on port 9242 enabled. 

Red Hat Enterprise Linux  8.2 (Ootpa)

Administrative privileges (root) are required to follow the deployment steps.

Internet access should be available with inbound connections on port 9242 enabled. 

Database Requirements



Mongo DB
MSSQL 2016

Docker Engine Requirements


Docker CE

Docker CE 18+ and docker-compose (in case of CentOS)

Docker EEDocker EE (for Redhat)

Browser Compatibility





 83.x (64 bit)

FirefoxNot testedThe UI of some pages might not render properly in Firefox.
IENot tested

An on-demand testing cycle can be executed.

Cisco Unified CCX Compatibility

Not tested.

Cisco Unified CCE Compatibility

UCCE 11.6

Port Utilization

The following ports should remain open on the Firewall. The local security policy and any antivirus should also allow open communication on the following ports.


Source Host

Source Port

Destination Host

Destination Port


Enterprise web user





Dashboards & Wallboards server




TCPEnterprise web user
CIM9242 (required only in case of online deployments)

System Access Requirements

Deployment Privileges

Administrative privileges (root) on the machine are required to follow the deployment steps.

Internet access must also be available on the machine with inbound connections on port 9242 enabled.

Time Synchronization Requirements

If the system dates and times are not synchronized, the system can produce unpredictable results. Therefore, the EF applications and Cisco Contact Center should have their time zone and date/time properly configured, according to the geographic region and must be synchronized.

To configure the time zone, please see the instructions from the hardware or software manufacturer of the NTP server. The application servers should be synchronized. This synchronization should be maintained continuously and validated on a regular basis. For security reasons, the Network Time Protocol (NTP) V 4.1+ is recommended.